LR1110 Gnss scan status

[tve]

First le me say thank you for having started to implement the Gnss scanning for the LR1110!!! I got a WM1110 Tracker dev board and tried to use the Seed stuff, which was a total no-go 'cause they're stuck on the 3.x firmware, which doesn't support autonomous almanac updates or calculating a 2D fix. I spent a day trying to upgrade the software but it's just such a nightmare... Eventually it dawned on me that I might want to check RadioLib...

Anyway, I'm using master and am wondering whether there is any further progress in some fork or other repo?

If not, that's OK, I'll just plug away at implementing the stuff that I find missing. I've adapted the WiFi scan example and I now see a GNSS scan result in the debug output but so far it's not seeing any SV after 63 secs (I'm indoors with a "repeater" antenna and my phone does see the expected number of SVs). I'll start by reading the LR1110 docs to understand where I need to start...

[tve]

Aha! Found this in the Seeed WM1110_Geolocation repo:

    lbmWm1110.attachGnssPrescan([](void* context){ digitalWrite(PIN_GNSS_LNA, HIGH); });
    lbmWm1110.attachGnssPostscan([](void* context){ digitalWrite(PIN_GNSS_LNA, LOW); });

Updated the rf switch table:

// set RF switch configuration for Wio Tracker with Wio WM1110 Module
// Wio WM1110 uses DIO5 and DIO6 for RF switching
// Wio Tracker 1110 dev board adds LNA for GNSS antenna controlled by PIN_GNSS_LNA
// NOTE: other boards may be different!
static const uint32_t rfswitch_dio_pins[] = { 
  RADIOLIB_LR11X0_DIO5, RADIOLIB_LR11X0_DIO6,
  PIN_GNSS_LNA, RADIOLIB_NC, RADIOLIB_NC
};

static const Module::RfSwitchMode_t rfswitch_table[] = {
  // mode                  DIO5  DIO6 GNSS
  { LR11x0::MODE_STBY,   { LOW,  LOW, LOW } },
  { LR11x0::MODE_RX,     { HIGH, LOW, LOW } },
  { LR11x0::MODE_TX,     { HIGH, HIGH,LOW } },
  { LR11x0::MODE_TX_HP,  { LOW,  HIGH,LOW } },
  { LR11x0::MODE_TX_HF,  { LOW,  LOW, LOW } },
  { LR11x0::MODE_GNSS,   { LOW,  LOW, HIGH } },
  { LR11x0::MODE_WIFI,   { LOW,  LOW, LOW } },
  END_OF_MODE_TABLE,
};

But the GNSS scan code doesn't set the rf switch table so have to add that... And the LR11x0::setRfSwitchTable doesn't seems to allow GPIO pins to be used. Hmmm... Gonna turn it on globally for now...

---

With the LNA turned on I'm finally seeing some SVs:

RLB_DBG: Detected 8 SVs:
RLB_DBG:   SV 0: C/N0 43 dB, Doppler 3476 Hz
RLB_DBG:   SV 1: C/N0 42 dB, Doppler -860 Hz
RLB_DBG:   SV 2: C/N0 40 dB, Doppler 709 Hz
RLB_DBG:   SV 3: C/N0 40 dB, Doppler 3706 Hz
RLB_DBG:   SV 4: C/N0 38 dB, Doppler 4368 Hz
RLB_DBG:   SV 5: C/N0 36 dB, Doppler 3502 Hz
RLB_DBG:   SV 6: C/N0 35 dB, Doppler 548 Hz
RLB_DBG:   SV 7: C/N0 34 dB, Doppler 4516 Hz

But I mostly get a "demod status: -17" which the manual says is "20 ms real time failure". So far I have not found what that means... Other times I get 'The satellite selected for demodulation lost' (sic), or 'No bit change found during advanced scan', or 'Too many parity check found' (sic).
At one point I did see 'Week Number found (Time Of Week as well)' but nothing more came of that.

I'm wondering whether there's something I'm missing that is required to cold-start the lr1110...

---

Hmm, GnssReadTime says "No 32kHz clock available". Gotta look at schematics to see what I need to do to enable that.

---

My WIP code is in the lr1110-gnss branch of my fork https://github.com/tve/RadioLib/tree/lr1110-gnss

[tve]

I pushed my stuff with some minor clean-up. It's not a PR. Feel free to pull sections if you want to move forward. I'm still futzing around with stuff.

One item that is an issue in the lr1110 driver is the RfSwitchTable. It has moved into the chip but function like transmit and others still call the setRfSwitch method. In the case of the WM1110 tracker board that's actually needed 'cause the GNSS LNA is controlled by a gpio pin. But to actually make that function there's some more work required... (Right now I just set the LNA once for all in the app code)

I also noticed that there are several methods to retrieve the status from the device, that could be simplified into one. I had to fix one that didn't work at all.

Not done yet...

[tve]

I updated the PR adding a bash script to submit the NAV data to LoRaCloud and intersperse it into the demo script. I tried to keep this simple but it still takes a bunch of lines of code to make it work...

I'm seeing some oddities with the cloud stuff. There is some ambiguity about how gnss_capture_time is used and I have the feeling there are cases where omitting it produces a (good) result when omitting fails, have to test some more...

Unfortunately I have not been able to get any support from Semtech so far. Everything on their site leads to the contact form and I'm pretty sure they'll just keep ignoring me. If someone has a technical contact and could forward a handful of specific technical questions I'd very much appreciate the help!

Here's a sample output (The LoRaCloud section is added by the bash script):

[LR1110] Starting GNSS scan ... 

RLB_DBG: GNSS scan start 'medium effort'
RLB_DBG: Starting GNSS scan with effort=1 resMask=3c nbsvMax=8
RLB_DBG: Status: 5 CMD_OK, INTR, mode=1
RLB_DBG: IRQstatus=00080000 errors=0x0000
RLB_DBG:     IRQ bit 19 set
RLB_DBG: GNSS scan done in 10946 ms
RLB_DBG: Demod status 'Time Of Week found' (3), info 03
[LR1110] Reading GNSS scan result ...
RLB_DBG: Last scan mode 'Assisted mode (Time and Assisted Position known)' (3)
RLB_DBG: Detected 7 SVs:
RLB_DBG:   SV 0: SNR 12 dB, Doppler 300 Hz
RLB_DBG:   SV 1: SNR 12 dB, Doppler 3983 Hz
RLB_DBG:   SV 2: SNR 10 dB, Doppler 3959 Hz
RLB_DBG:   SV 3: SNR 5 dB, Doppler -931 Hz
RLB_DBG:   SV 4: SNR 5 dB, Doppler 2529 Hz
RLB_DBG:   SV 5: SNR 3 dB, Doppler 1815 Hz
RLB_DBG:   SV 6: SNR 3 dB, Doppler 2698 Hz
GPS time=1410390673 407205us accuracy=11397us unix=1726355455
NAV @1410390664: 631052c00000000c94e1b0000007dcc35d722e5565bbe78df146009
LoRaCloud:
  Position: 35.12345 -119.12345 alt: 560.39
  Real error: 26m
  Claimed accuracy: 110.5m
  GPS time: 1410390665.293538 -- delta=1s
  UTC time: 1726355447.293538 -- 2024-09-14T23:10:47+00:00
Demodulated position (using 7 SVs):
  One-shot: 35.999999 -119.970703 | accuracy:39[?] xtal:1046ppb | real err: 14721m
  Filtered: 35.584961 -119.707031 | accuracy:51[?] xtal:1035ppb | real err: 13937m
Last scan timing, power, and % of power:
  GPS: total 4.3s/55.8mJ | P1:45.5% Adv:54.5% | capture:38.7% cpu:51.2% sleep:10.0%
  Beidou: total 0.0s/0.0mJ | P1:nan% Adv:nan% | capture:nan% cpu:nan% sleep:nan%
  GPS demod: total 6.7s/56.2mJ | capture:46.0% cpu:8.2% sleep:45.8%
  TOTAL: 11.0s/112.0mJ | GPS:49.8% Beidou:0.0% Demod:50.1% Init:0.0%
GPS almanac status: 'At least 1 satellite must be updated' (1)
  SVs needing update: 1 (SVs 63 25)
  Update in 364.7s, first subframe 4, 2 subframes
BDU almanac status: 'No satellite to update' (0)
  SVs needing update: 0 (SVs 0 0)
  Update in 0.0s, first subframe 0, 0 subframes

[jgromes]

To be honest, my goal when starting with the LR11x0 GNSS scanning was to make it completely independent of the could component. I profoundly dislike the business model of "to be able to fully use the IC you paid money for, you have to register in our cloud service that probably won't be running in 3 years or less".

If it was optional, then sure, some users might like the convenience of CLOUD-based GEOlocation (funny as that terms is once you think about it). But not having the option to run my own server that would be able to provide almanac updates and decode the NAV data, that's just a big nope from my side. Hence me trying (and you succeeding ;) ) in getting it to run standalone. So I will strongly advocate in favor of keeping RadioLib free from all that interaction with the Semtech cloud.

It seems that there is still some ongoing development in the PR - please let me know once it's at a point where you'd like me to review and talk about how to merge it. We might have to think a bit how to best handle the public interface and the example(s).

[tve]

Hey, I totally sympathize with the subscription-free goal. At the moment I don't see an non-cloud option for evaluating the data coming out of the LR1110 (or a U-Blox gen 10 chip either). The only thing in the PR that has to do with the cloud service is the sample shell sript and it's there primarily for evaluation purposes. Now, to be honest, from what I've seen, if you don't use the cloud service I'm not sure why you would use the LR1110. The sample sketch and shell script let you specify the exact location of the device (assuming it's stationary) and it prints the location error. Using the cloud service you get the typical 8-20m error. Using the solver built into the chip you get anywhere from 8km to 30km error. The uses case where that amount of error is acceptable are not that many...

Anyway, at this stage I've moved on to sending the data from the script to a database and evaluating the performance of the LR1110 under various conditions, so not something that I will be adding to the PR. I'm still trying to understand how the ingredients to the GNSS work and have just added the list of open questions I have to the PR. Some of the open questions may affect what could be exposed in the API. But I expect my rate of change to slow down dramatically now.

[HeadBoffin]

@miguelcz123, this thread is all about GNSS on the LR1110. Communication between a module & an MCU is totally different and also well covered in the wiki. I've started an issue for you on this.

[tve]

I'm starting to accumulate some questions about the LR1110 operation for which I can't find answers... I've submitted a support request but have not heard back and may not hear back since I don't work for some big ass company... So far I have:

• is there any clean method for resetting the almanac data?
• in the data returned by GnssReadDopplerSolverRes what are the units for the accuracy value?
• in the data returned by GnssReadDopplerSolverRes what filtering is applied to the FilteredLongitude/Latitude?

---

WRT the filtering, after a cold-start I've noticed the following:

first fix:

Demodulated position (using 4 SVs):
  One-shot: 34.541016 -119.882812 | accuracy:54[?] xtal:1018ppb | real err: 7517m                    
  Filtered: 34.541016 -119.882812 | accuracy:54[?] xtal:1018ppb | real err: 7517m                    

(the real error is based on me having hard-coded the real GPS location and using the haversine formula)

second fix:

Demodulated position (using 4 SVs):          
  One-shot: 35.551758 -120.146484 | accuracy:95[?] xtal:982ppb | real err: 120779m 
  Filtered: 34.584961 -119.882812 | accuracy:56[?] xtal:1017ppb | real err: 11208m 

What I find significant is:

• the first filtered coords are the same as the one-shot values
• the second FilteredLongitude is the same as the first fix's while the FilteredLatitude is not and it's not an average either