State of kill switches?
If all switches are in the “kill” position then the GNSS is off and so you won’t get anything? (If they were “kill” at boot, it may be a good idea to boot with at least one switch in the “on” position i.e. just for testing.)
? Even inside, phone on the desk, that cat command immediately gives a whole lot of output. I’m not saying that I get a fix inside but I get something.
All switches on, reboot, run cat command, no output.
Install this pack: https://source.puri.sm/angus.ainslie/geoclue-2.0/-/jobs/393818/artifacts/download?file_type=archive
…and try again. Also try disabling WLAN and Modem data.
The zip file contains:
$ unzip -t artifacts.zip
Archive: artifacts.zip
testing: debian/output/geoclue-2-demo-dbgsym_2.5.7-3pureos4+librem5ci77671.f5ec605_arm64.deb OK
testing: debian/output/geoclue-2-demo_2.5.7-3pureos4+librem5ci77671.f5ec605_arm64.deb OK
testing: debian/output/geoclue-2.0-dbgsym_2.5.7-3pureos4+librem5ci77671.f5ec605_arm64.deb OK
testing: debian/output/geoclue-2.0_2.5.7-3pureos4+librem5ci77671.f5ec605_arm64.buildinfo OK
testing: debian/output/geoclue-2.0_2.5.7-3pureos4+librem5ci77671.f5ec605_arm64.changes OK
testing: debian/output/geoclue-2.0_2.5.7-3pureos4+librem5ci77671.f5ec605_arm64.deb OK
testing: debian/output/geoclue-doc_2.5.7-3pureos4+librem5ci77671.f5ec605_all.deb OK
testing: debian/output/gir1.2-geoclue-2.0_2.5.7-3pureos4+librem5ci77671.f5ec605_arm64.deb OK
testing: debian/output/libgeoclue-2-0-dbgsym_2.5.7-3pureos4+librem5ci77671.f5ec605_arm64.deb OK
testing: debian/output/libgeoclue-2-0_2.5.7-3pureos4+librem5ci77671.f5ec605_arm64.deb OK
testing: debian/output/libgeoclue-2-dev_2.5.7-3pureos4+librem5ci77671.f5ec605_arm64.deb OK
testing: debian/output/libgeoclue-doc_2.5.7-3pureos4+librem5ci77671.f5ec605_all.deb OK
No errors detected in compressed data of artifacts.zip.
How do you install this?
I am not sure if you need development version of geoclue-2.0.
I have installed standard package and it works
sudo apt install geoclue-2.0
You need gnss-share to read actual GNSS module data and provide them through geoclue D-BUS API to applications.
You should check that socket /var/run/gnss-share.sock is created. There has been mismatch in the past, that gnss_share.sock has been expected… Check that gnss-share and geoclue config agrees about socket path in /etc/gnss-share.conf and /etc/geoclue/geoclue.conf There should be in /etc/geoclue/geoclue.conf
# use aa nmea unix socket as the data source
nmea-socket=/var/run/gnss-share.sock
You can test that data flow to the socket by
sudo socat unix-client:/var/run/gnss-share.sock -
Cat directly from serial device file woks for me
sudo cat /dev/gnss0
but you should stop gnss-share first, because else you fight over device from two concurrent reads and what get one and another is question
systemctl stop gnss-share.service
I am not sure if there is some power management mechanism else that three switches off which can disable/power down the GNSS module that you have no cat output as the result.
…
Yes there is alternative SW power off controlled by pin
GPS3V3_EN/NAND_DATA06 ball L19 GPIO3 IO12
It is declared as pinctrl_gnsspwr in imx8mq-librem5.dtsi and connected to
reg_gnss: regulator-gnss
Mapping to uart2 is provided. Driver “fsl,imx8mq-uart”, “fsl,imx6q-uart” but I do not see anywhere reference to vcc-supply.
I expect that power supply to GNSS module is enabled after kernel start unconditionally. So the can and sockat should work. If not then there can be HW problem.
I have finally found company in Prague, Czech Republic which have offered to do rework (to reach actual Librem 5 production setup for GNSS, V1.06.1 from V1.03 state delivered last November) on already populated board. The first measurements shows enhancement estimated roughly to about 5dB. Recorded NMEA tracks match paths in OSM significantly more precisely as well. But I need to do more measurements… Some more can be found in the issue solution record
To assemble and disassemble board, Purism provided video helps a lot
There are some pictures of the Librem 5 HW from my disassemble with reasonable resolution to see GNSS signal path etc…
https://cmp.felk.cvut.cz/~pisa/foto/2022/220804-Librem-5/pics001.html
Is somewhere logged, when a given package was installed?
You can check modification time of the file
/var/lib/dpkg/info/<package_name>.list
This is regenerated for each successful install/update of the package by low level Debian dpkg tool which are controlled by apt, aptitude etc… Then there are log files
/var/log/dpkg.log
/var/log/apt/history.log
May it be there is even some better option.
Thanks. This is the best place to look.
I have the latest GeoClue installed. Do I need to specific download you recommend?
I have bad GPS-reception on Librem5v1-05 - it get fixes only outdoors on clear sky, indoors no chance, where every other gps device gets a fix quite fast.
I have some questions regarding Librem5 versions and necessary ECOs, I cite statements from https://source.puri.sm/Librem5/OS-issues/-/issues/252 *:
“All v1.0.6 phones and later have this change implemented (along with v1.0.3 L5 USA phones). If you were to compare a v1.0.6 phone and a v1.0.3 phone that does not have this ECO then you will notice the improved SNR.” @ekuzmenko
So my Phones and all others with v1.0.5 need the ECO? Or what do they need for a normal GPS-reception?
“One of the best ways to determine which version of the phone you have is based on the date you received it.
Phones that are on v1.0.3 and prior may require this GNSS ECO. This change reached new shippments to customers at some point near the end of 2021.” @ekuzmenko
I received my Phones in March and May 2022 from purism. So this change should have been reached the mainboards long before my device was shipped. So, my phone does not need the ECO (although it is 1.0.5)? This information is very confusing.
All in all, what’s the matter with v1.0.5? Are there hardware differences between 1.0.5 and 1.0.6 regarding GNSS? Why is the reception so bad even on fifth iteration?
* I post here, since I cannot login to https://source.puri.sm/. Error message: “Your account is pending approval from your GitLab administrator and hence blocked. Please contact your GitLab administrator if you think this is an error.” Is this normal?
The approval for GitLab login is manual by Purism developers, which I am not. I hope that @ekuzmenko can help.
As for the exact version, you can find it on the mainboard
On the picture it is on the right between DC motor (vibrator) and microphone.
But you need to go with disassembly quite far to see this area of the mainboard
https://cmp.felk.cvut.cz/~pisa/foto/2022/220804-Librem-5/pics001.html
I have seen some improvement after ECO Fix but followup test on Saturday and Sunday are again weak… I made mistake to forgot front camera attaching and then run the fisrt test when I have even noticed at start 34 dB on one satellite for while.
When I have disassembled and inserted front camera and assembled again, I was able to get weak fix even on our flat balcony which did not wok before ECO. But results and chance to get fix seems to worsen next days… I am not sure f that can be some oxidation etc… I try something when I have some time, but cannot declare when etc… I have quite lot of other projects backlog…
Best wishes, Pavel
PS: it will be great if you report back when you find something, I have some 3 MB of gzipped NMEA Librem 5 data. I think about writing script which collects GPSV records and plot values of three most strong satellites in the time. It could be reasonable metric to compare different runs.
There were no v1.0.5 phones that customers received, this was an internal version only. The version before v1.0.6 is v1.0.3.
Here is a document that describes the process: GNSS_sensitivity_ECO_for_customers.pdf
Here are the components we use:
There’s an assembly drawing for the main board in our git repo here: https://source.puri.sm/Librem5/l5-schematic/-/blob/master/librem5_mainboard_assembly_drawing.pdf
These are 0201 components so it is not trivial to do this ECO. If you don’t have experience soldering then please do not attempt this. Anyone doing this would likely need to do it with a stereo microscope. Any damage caused from attempting this wouldn’t be covered by Purism.
Thank you for your clarification. OK, then my phone is v1.0.6 on the mainboard. I was slightly irritated since the sticker under the battery reads “Librem5 v1.05” - but this sticker version obviously has nothing to do with the mainboard version.
OK, then my phone does not need the ECO.
The question remains why it does get fixes only outdoors. Indoors no chance, where every other gps device gets a fix quite fast. Can other librem v1.0.6 (shipped roughly since end of 2021) confirm that gps reception is that bad?
@pit if you’re willing to go through the trouble of taking the midframe of the phone off and then snapping a photo of the components next to the GNSS module, I would be able to confirm whether your phone has this ECO on it or not. There are some v1.0.6 phones that were shipped in 2021 that did not have this fix applied to them, I cannot confirm if yours was one of those since it’s possible we shipped an older one from our facility at the time which did not have this ECO applied to them.
If you follow the disassembly procedure here up to the 1:27 mark of the video then you’ll be able to get to the components and take a photo without having to take out the main board (leaving the thermal paste undisturbed): https://docs.puri.sm/Librem_5/Disassembly.html
Also, since you don’t have to take out the main board you don’t risk damaging the GNSS clip.
Once you have the midframe off you can take a photo of the small SMD components just above the GNSS module (“above” in this context being while the headphone jack is point up).
Here are a couple photos I have, one with the ECO applied and the other one without the ECO:
With the ECO:
You can see how the one with the ECO applied has a component popualted for R144 but not R106. For the one that doesn’t have the ECO it is vice versa. You can also see the blue-ish part installed for R136 on the one which has the ECO applied, this is an inductor, on the non-ECO board it’s a 0-Ohm jumper. Though this part may not necessarily be blue, the HKQ0603W27NH-T inductor could also be used which is not blue.
There’s also the change to R163 being 16kOhms, that part is not shown in these photos but you can find it underneath the EMI shield can next to the GNSS module. @angus.ainslie has had success implementing this ECO without having to change R163 to 16k so it may not be necessary for you. It is possible to do this soldering task without necessarily having to take the main board out of the chassis, but you would need to be extra cautious not to touch your soldering iron to nearby plastic and not heat the board too much. If possible, it’s best to do it with the main board taken out, potentially needing to apply new thermal paste, but it can be done while still in the chassis if you’re exta cautious. Unless your vision is really good, using a steromicroscope is required (I needed to use one).
Thanks. I check, when I have some spare time.
I have a Librem 5 Evergreen (it says 1.05 under the battery). When looking at the mainboard, it says 1.02 and 2020-09-29.
Is there any chance that GPS will work on this device? Do I have to do a hardware mod to fix GPS? Would pictures of the inside of the phone help?
According to my limited knowledge, your situation in GNSS area is the same as was mine. I have resolved ECO and there was temporal enhancement but I have probably pressed/bent the second GNSS antenna grounding point when I have returned front camera to the place. I have not time to bend it back and correct the contact and there is another additional suggestion so I probably buy referred component the first
@ekuzmenko Eric Kuzmenko
On the v1.0.6 phones we modified the impedance matching network, which might make an improvement for your v1.0.3 device. Previously, it was L3=0-Ohms and C53=NC.
On v1.0.6 we are using the following components:
L3 = MLG0603P9N1HT000, 9.1nH 0201 inductor
C53 = GRM0335C1HR50BA01D, 0.5pF 0201 capacitor
The rest of the matching network is the same.
If you have professional solder equipment and microscope you can try yourself, but Purism official response about warranty is missing and unofficial is that it is lost by disassemble.
I have chosen to order soldering at found phones repair shop. You need to find real companies not there who advertise service but are able to use only some tools to clear/update Flash or replace display.
It would worth to collect list of the companies capable to do repair over the world. If you are in Central Europe then company found in Prague can be usable/reachable for you. I have lot of spare components from the strip of the reel when I ordered them for my phone so I can offer these for free. All bought at 50 to not lose them on a table…
Is there any chance that GPS will work on this device? Do I have to do a hardware mod to fix GPS? Would pictures of the inside of the phone help?
It mostly like would need this fix, unless your device is able to get a fix as-is. If you were to look on the area of the board that I shared earlier, then this would make it apparent for you. Unless it’s an L5 USA phone, then v1.0.3 or earlier does not have the ECO applied to it. So given that, I don’t think it’s even necessarily to check it, simply based on the version you’ve got.
You can check the performance of your phone’s GNSS by running cat /dev/gnss0 and seeing if (and how quickly) it gets a fix. The “GPGSV” NMEA sentence would give the most relevant info, the third number tells you how many satellites are in view and the seventh number tells you the SNR. You can use this to see whether it works indoors or requires you to be outdoors, works in your car, etc.
Also, if you feel comfortable with it, you could enter the “GPRMC” NMEA code you get into this website to see if it got your location correct on a map (neither I nor Purism is affiliated with them in any way, use at your own risk; you can also use the coordinates from this GPRMC sentence to determine if it’s correct through other means but this is relatively simple): https://rl.se/gprmc
You can find details about all of the different NMEA sentences and what they mean here: http://aprs.gids.nl/nmea/
Alternatively, you can install and try out Pure Maps (this is not GNOME Maps which is installed by default) to see if it gets your location (though I have experienced that Pure Maps can be a couple miles or kilometers off of where the GPRMC sentence says I am which is much more accurate). I think it might also attempt to use your network to roughly guess your location so you may have to make sure it’s not doing that and actually using the GPS, which makes this verification method less dependable to indicate how well it actually works.
I imagine that warranty may cover it being RMA’ed, though you’d probably have to go without having the phone for some number of days while it’s being serviced. You would have to talk to customer support about what options are available (sorry, I am not familiar with the policy myself).
