Librem 5 GPS/Location Tracking

hey sorry to bother but am stuck on 4. and 5. i dont know how to fix name resolution. GPS i got running and share is build and installed (cargo git clone).

Do you mind adding more detailed steps?

Hello @blendergeek1 and others

I have provided HW related information and video how to disassemble Librem 5 to the service company and I have received quote from Mr. Stepan Rak based on this information and soldering rework done on my piece.

  • mainboad soldering/fix according to Purism GNSS ECO 1890 Kč (around 78 EUR)
  • complete GNSS ECO on delivered whole phone with disassembly and assembly 2490 Kč (around 102 EUR)

You can contact them directly info@primeservis.cz and negotiate visit and or continue over the forum and I try to help with things going. I will deliver my small stock/spare components when repair is negotiated, but give me info in advance to manage visit service. If more than 20 repairs are needed, then we need to order more of them. Price is really small.

If there evolves need to coordinate more repairs then we can open thread specific for this service. If batch of 5 or more reworks are coordinated then discount is offered.

By the way, I have registered talk (sorry Czech language only) at local Brno OpenAlt open-source/GNU/Linux enthusiasts conference where I will present my adventures, findings and analysis of Librem 5.

If you want to know something about our little more professional contributions to open technologies, then this article is for our automotive/CAN bus work, and this for computer architectures education

3 Likes

If found the following boot log entries. Am I reading it correctly that gnss is not powered?

Sep 02 12:27:32 pureos kernel: reg-fixed-voltage regulator-gnss: GPIO lookup for consumer (null)
Sep 02 12:27:32 pureos kernel: reg-fixed-voltage regulator-gnss: using device tree for GPIO lookup
Sep 02 12:27:32 pureos kernel: of_get_named_gpiod_flags: can’t parse ‘gpios’ property of node ‘/regulator-gnss[0]’
Sep 02 12:27:32 pureos kernel: of_get_named_gpiod_flags: parsed ‘gpio’ property of node ‘/regulator-gnss[0]’ - status (0)

So I installed and ran hwinfo and it shows gnss_mtk and gnss_serial ‘Live’. So, it appears the hardware is powered. But I still do not get any output from sudo cat /dev/gnss0 or the socat command.

Where is this found? It was not found with ‘find’

You cannot find this in the /sys. The pinctrl_gnsspwr is only handle referencing list of pins for IMX8MQ IOMUX controller to route correct pin to the correct GPIO where it can be controlled by voltage regulator.

The pin setup is declared in arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi (Purism Gitlab), mainline

pinctrl_gnsspwr: gnsspwrgrp {
		fsl,pins = <
			/* GPS3V3_EN */
			MX8MQ_IOMUXC_NAND_DATA06_GPIO3_IO12	0x83
		>;
	};

The last value 0x83 is pad_setting, it selects 75_OHM, SLOW, HYSteresis.

The pin is referenced from

	reg_gnss: regulator-gnss {
		compatible = "regulator-fixed";
		pinctrl-names = "default";
		pinctrl-0 = <&pinctrl_gnsspwr>;
		regulator-name = "GNSS";
		regulator-min-microvolt = <3300000>;
		regulator-max-microvolt = <3300000>;
		gpio = <&gpio3 12 GPIO_ACTIVE_HIGH>;
		enable-active-high;
	};

Which you already find in the /sys hierarchy as device tree node /sys/firmware/devicetree/base/regulator-gnss. Actual GPIO in is controlled by GPIO 3 module, pin 12.

Actual regulator is then /sys/devices/platform/regulator-gnss. You can check its state in my case as /sys/devices/platform/regulator-gnss/regulator/regulator.9/state.

It is disabled after boot but it is automatically enabled when I have gnss-share running and ask it to provide location by

socat unix-client:/var/run/gnss-share.sock -

Even when I run simple

cat /dev/gnss0

then state is enabled. The need to enable regulator is controlled by link from the override data for UART2

&uart2 { /* TPS - GPS - DEBUG */
	pinctrl-names = "default";
	pinctrl-0 = <&pinctrl_uart2>;
	status = "okay";

	gnss {
		compatible = "globaltop,pa6h";
		vcc-supply = <&reg_gnss>;
		current-speed = <9600>;
	};
};

UART 2 is handle to serial@30890000 declared in arch/arm64/boot/dts/freescale/imx8mq.dtsi. The /sys hierarchy location at /sys/devices/platform/soc@0/30800000.bus/30890000.serial. Link to the power source is found at /sys/devices/platform/soc@0/30800000.bus/30890000.serial/serial0/serial0-0/supplier:regulator:regulator.9.

The enable signal under software control is labelled as GPS3V3_EN in schematics. It is combined with 3SW_KILL signal (controlled by all three switches KILL function activated). There is additional signal GPS_RST, but i do not see it in the device tree so it is probably left inactive for whole time.

2 Likes

Thank you for the detailed explanation.

I checked the state as you describe and indeed it is disabled until I run socat or cat commands. Then it transitions to enabled. But, I still get zero output from either command.

Does the gnss device accepts any commands via its serial interface?

Yes it accepts lot of commands. See Teseo-LIV3 GNSS Module manual

I think that default behavior is to start to send data when it is powered on. At least I have seen that behavior each time. If you do not see any data then there is probably some other hardware problem. You can try gnss_test or can try to send directly some command, for example set constelation to GPS

$PSTMSETCONSTMASK,1*14

The 14 after asterisk is checksum, I am not 100% sure that it is matching. Algorithm is described in manual. But really, if you do not get anything then I would expect some HW problem with module. Only other disable controllable by SW is that reset pin but it seems to not been configured, routed in Linux kernel.

So if no data and enable is seen in the regulator, then contact Purism support.

But on the other hand, your dmesg report does not match mine

[    3.260605] reg-fixed-voltage regulator-gnss: GPIO lookup for consumer (null)
[    3.260614] reg-fixed-voltage regulator-gnss: using device tree for GPIO lookup
[    3.260626] of_get_named_gpiod_flags: can't parse 'gpios' property of node '/regulator-gnss[0]'
[    3.260648] of_get_named_gpiod_flags: parsed 'gpio' property of node '/regulator-gnss[0]' - status (0)
[    3.390644] of_get_named_gpiod_flags: parsed 'gpios' property of node '/leds/gnss-nreset[0]' - status (0)
[   19.999203] gnss: GNSS driver registered with major 241

What kernel are you running?

Mine is current from Pureos update Linux pureos 5.18.0-1-librem5 #1 SMP PREEMPT Fri Jul 15 15:27:41 UTC 2022 aarch64 GNU/Linux
and I have only single dir with device tree /boot/dtbs/5.18.0-1-librem5 where is link imx8mq-librem5-r4.dtb pointing to freescale/imx8mq-librem5-r4.dtb which needs to match HW revision as I understand it.

By the way, GNSS reset seems to be routed in Purism kernel device tree version. I have missed it because I have done final lookup at mine local mainline Linux repo not on their GitLab

	leds {
		compatible = "gpio-leds";
		pinctrl-names = "default";
		pinctrl-0 = <&pinctrl_hub_nreset>,
			<&pinctrl_sd_pwr>, <&pinctrl_charger>
			, <&pinctrl_smc>,
			<&pinctrl_gnss>,
			<&pinctrl_wwan_pwr>,
			<&pinctrl_wwan>;

		gnss-nreset {
 			label = "gnss_nreset";
 			gpios = <&gpio1 8 GPIO_ACTIVE_HIGH>;
 			default-state = "on"; 		}; 

So if that is active for some reason then it can block GNSS module.

Check state in /sys/class/leds/gnss_nreset/brightness. It should be 1.
If I do

echo 0 >/sys/class/leds/gnss_nreset/brightness

then module stops output. When I run

echo 1 >/sys/class/leds/gnss_nreset/brightness

it starts to send data again.

1 Like

I am interested in bringing my phone to the repair shop sometime between September 9 and 12. Would you be able to let them know I am bringing a phone by and have parts available by then?

And thank you for everything you have done for repairing original Librem5 Evergreens

I am leaving for RVfpga seminar to Munich till Thursday tomorrow. I will make it to deliver components to the service or even to meet your courier on Friday. Send me your e-mal address. You can find mine on my page or in some of my projects pages. You can send even directly with CC to me to the service info@primeservis.cz.

@blendergeek1: I have delivered components to PrimeService and you should have my e-mail to them. Please negotiate time when the phone can be delivered to them.

If somebody else has interest, then components for about 20 more phones fixes are available at PrimeService/PrimeSolder now.

2 Likes

What does ECO mean? Is this fix basically adding some components (that are missing on some early boards) to improve the GNSS sensitivity?
@ppisa: Did you try to improve the GNSS ground, if yes, what were the results?

https://en.wikipedia.org/wiki/Engineering_change_order

2 Likes

I checked the version, which is same as yours. I checked the state, which was ‘1’. I cycled the state to ‘0’ then back to ‘1’. Still no output.

There are three different version directories under /boot/dtbs/ but the one matching my kernel, has the link.

Dear Eric Kuzmenko,

have you got some information if the GNSS antenna electro-mechanical design has been changed between different Evergreen shipments? I am preparing talk about Librem 5 for the Czech open community gathering - OpenAlt 2022 https://www.openalt.cz/2022/ . I want to highlight Purism effort, HW adventure and major contribution to generic Linux SW stack for Convergence. But I want to be honest so I will speak about difficulties to tame power hungry automotive targeted SoC and USB connected mostly industrial modem etc… and even problems found and corrected in HW. Thise are problems which will be solved by other SoC one day, may be RISC-V based one??? But company strange attitude in some questions is important too. There is so much PR about openness and in some areas it does not match reality and even that I respect keeping investment and secret of clever RF HW, I think that users deserve some level of help/confirmation when there is a problem.

Preliminary version of my slides for this Sunday is available there https://cmp.felk.cvut.cz/~pisa/openalt/Librem5-OpenAlt-2022.pdf

Thanks for you work,

Pavel

1 Like

Hey Pavel,

My initial suspicion was wrong. The antenna design (and its feedline) between v1.0.3 and v1.0.6 is considerably different, and customers should not alter the impedance matching circuit that came with their v1.0.3 device to match v1.0.6’s values.

Here are the values which are used in v1.0.3:
R256 = ERJ-1GN0R00C, 0-Ohms 0201 resistor
L3 = ERJ-1GN0R00C, 0-Ohms 0201 resistor
L12 = NC
C53 = GJM0335C1H2R2BB01D, 2.2pF 0201 capacitor
C85 = 7447840047, 4.7nH 0201 inductor
C86 = NC

If you have a v1.0.3 phone, you may play around with these matching component values if you so wish, since you are the owner of your device, but we do not recommend it.

I am sorry that we are unable to share further details regarding the specifics of the antenna design.

2 Likes

Thanks for information and your effort and reply to my Friday reminder. The reply come after my presentation at OpenAlt. Presented slides version there https://www.openalt.cz/2022/slides/pavel-pisa-telefon-librem-5-ocima-vyvojare-automobilove-laboratorni-medicinske-a-roboticke-techniky.pdf (English), actual presentation Video (Czech language) there https://youtu.be/iv0OikILa_k?t=9783 .

It is shame for Purism that it does not provide clear hardware revision documentation for backers and it seems that not to found easily even for people inside Purism developers group as well. Sound PCB assembly houses provide spreadsheet for each PCB assembled with list of actually placed components with their production lot number - I am no to big fan of all iso9000 bureaucracy, but these parts belongs to good practice. Same for the variant number of aluminum frame/display/touchscreen antennas sandwich. There should be at least table with each variant of the setup and information from which serial number or production date is given combination applicable. There is mismatch between advertisement, price belonging to industrial high-tech systems and customers treatment typical for consumer/disposable grange of products. This is something for response by @todd-weaver or somebody else from the Purism officials.

Probably only solution to check match between PCB and mechanics is to go to our colleagues from LVR and ask for X-RAY imagining. By the way, X-RAY images has been promised for anti-tamper measures by Purism in the past… If they exists for each revision, it would be easy to check what is inside the sack.

Anyway, if I know now, that tuning my piece will help limited number of users with devices around 1.03 main board revision, then my motivation to invest the time considerably decreases.

Anyway thanks for all good you have done for GNU/Linux ecosystem. it has great value, but I will not mask or hide criticism in areas where I consider behavior harmful for backers and even more for Purism company recognition and future.

I am wondering what people feel the state of GPS/Location tracking is?

My opinion: it is still bad and does not work. Can someone point me in the direction of their particular “solution” or possibly a “fix” for this issue? I have read many posts about this issue here and I don’t easily find a “fix”.

I truly miss having a GPS app. I tried offline maps. I tried Gnome Maps. I tried PureMaps. I uninstalled all of them and then installed them again. Many times. As of today, I have no map software installed and simply use a browser - which isn’t great.

Thanks in advance.

2 Likes

I asked Purism support once, and they gave me a quick response on how to try to connect the antenna better, but I did not dare to take the L5 that far apart. So maybe, I’m suffering a hardware issue, but also for me GPS/Location tracking is still never functioning. For me missing navigation is one of the main issues that I still have to carry my Android device with me too often.

This is what support at Purism wrote to me:

Hello,

Thanks. I spoke to our engineer, she suggested to check first if the GNSS antennae spring contact has proper contact with the frame - this to her is the most likely cause of the problem.

Detailed steps to perform this:

1. take of the back cover
2. open the three screws to open the cover of WiFi / modem
3. disconnect antenna cables and remove modem and WiFi card
4. open all six screws of the frame plus the two screws in the M.2 card compartments
5. before lifting the frame the antenna cables must be removed from the guides in the frame
6. then start in the battery compartment and carefully lift and click out the frame

The GNSS antenna spring contact is a tiny metal part on the top edge of the PCB, close to the rear camera. This metal spring contact must have firm contact with the metal frame.

4 Likes