Librem 5 GPS/Location Tracking

ppisa · June 13, 2022, 10:09am

GPXSee mainline silently included required changes for touchscreen zoom support. So even that application is not tuned for touch screen it basic function to show actual position in bitmap or Garmin format maps works on Librem-5.

PS: Still no progress with repair of GNSS hardware, none of the companies and experts who do for us professional assembly is brave enough to do repair with some confidence that they do not destroy device. I would be happy if Purism provides information who was successful with repair and what kind of equipment has been used. May it be I can find some moment to invest into this now. I was quite busy till now with our switch of education to RISC-V, simulators, videos etc. You can meet with or presentation on Embedded World 2022 conference in Nuremberg. We have contributed some CAN bus drivers to Linux kernel and NuttX mainline etc…

ppisa · July 26, 2022, 3:40pm

Librem 5 - Teseo-LIV3 GNSS Module reports weak carrier to noise ratio - probably HW/design problem

Minor progress, preparatory steps done:

found phone repair shop in Prague brave enough to proceed 201s soldering finally, after our regular PCB partners and university prototype labs with BGA, cameras, manipulators and other top equipment evaluated repairs as too risky or requiring another special tools production.
Bought Purims suggested components, 50 for each to not lose them on the table.

I will report further progress. Hopefully, I or repair shop do not destroy the device…

If somebody has succeed already to do fix according to GNSS_sensitivity_ECO_for_customers.pdf, I am eager to hear about results.

I would like to know even actual observed results with GNSS module sensitivity on current shipped/updated Librem 5 hardware.

Generally all this is more for my curiosity, Librem 5 is low on my priority scale. Mainline Linux CAN FD support for our open-source design, ESA and RISC-V education are much higher priority and all move forward without choked information tap…

carlosgonz · July 26, 2022, 4:14pm

My 2 Evergreen get g.n.s.s position on less 2 minutes, this time it very decent compared to 4 minutes for normal gnss reception time in some circumstances like without a.g.n.s.s.

boondocks · July 29, 2022, 12:38pm

I get no output from sudo cat /dev/gnss0 with unit outside, face down, atop four foot wood post. Let it run 20 minutes. Any ideas?

irvinewade · August 1, 2022, 7:45am

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.

boondocks · August 3, 2022, 5:17pm

All switches on, reboot, run cat command, no output.

carlosgonz · August 3, 2022, 5:37pm

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.

Normal time will be up to 4 minutes.
Geolocation start after 4 satellites reception.

guru · August 4, 2022, 12:27pm

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?

ppisa · August 4, 2022, 11:13pm

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.

ppisa · August 4, 2022, 11:48pm

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

carlosgonz · August 5, 2022, 12:45am

sudo dpkg -i libgeoclue-2-0_2.5.7-3pureos4+librem5ci77671.f5ec605_arm64.deb geoclue-2.0_2.5.7-3pureos4+librem5ci77671.f5ec605_arm64.deb

guru · August 5, 2022, 7:38am

Is somewhere logged, when a given package was installed?

ppisa · August 5, 2022, 8:21am

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.

guru · August 5, 2022, 9:49am

ppisa:

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…

Thanks. This is the best place to look.

boondocks · August 6, 2022, 7:54pm

I have the latest GeoClue installed. Do I need to specific download you recommend?

pit · August 7, 2022, 7:23pm

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?

ppisa · August 8, 2022, 7:40am

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

https://cmp.felk.cvut.cz/~pisa/foto/2022/220804-Librem-5/p1130142.jpg(image larger than 4 MB)

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.

ekuzmenko · August 8, 2022, 2:21pm

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:

R144 = ERJ-1GN0R00C
R106 = DNP (not populated, remove the component that’s there)
R136 = HKQ0603W27NH-T or LQP03HQ27NH02D
R163 = ERJ-U01F1602C

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.

pit · August 8, 2022, 8:03pm

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?

ekuzmenko · August 8, 2022, 11:58pm

@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:

Without 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).