Determining L-Band operating region

[cturvey]

Subject of the issue

US Facet L-Band units being moved to UK/EU theater, the auto-set operation may overly cumbersome and opaque.

https://portal.u-blox.com/s/question/0D5Oj00000E3f9tKAB/pointperfect-perfomance-in-the-uk

https://github.com/sparkfun/SparkFun_RTK_Firmware/blob/main/Firmware/RTK_Surveyor/menuPP.ino#L1154

Looks to make a determination when beginLBand() is called from setup(), when device starts

SparkFun_RTK_Firmware/Firmware/RTK_Surveyor/RTK_Surveyor.ino

Line 936 in ad3899b

beginLBand(); // Begin L-Band

It needs a position fix to see which Inmarsat shadow it's in, and from there it selects the L-Band frequency. So you'll need to have a fix, and then restart the Facet whilst not resetting the receiver .

One of the older screen shots showed "Configure LBand" but I think that's been deprecated, and now it's "Configure PointPerfect", but there really needs to be a method to report the frequency, and update that based on the location when the menuPointPerfect() is triggered, or a manual method is provided for.

[cturvey]

User is reporting unit persistently remains in DGNSS and does not move to RTK FLOAT/FIXED
My working hypothesis is that the unit is not configuring the NEO-D9S for the region it is situated in, and consequently is not acquiring SPARTN data.
No easy way to diagnose/audit what's happen.
Documentation doesn't illustrate how to determine or change operational region for PointPerfect L-Band. Probably needs something in/near where the manual key configuration is permitted.
There are probably some "slight of hand" mechanics to update the region, by resetting software/board without resetting receiver and losing position fix. User is not necessarily aware this has occurred, or what they did to make it occur.
Any way thoughts on this moving forward, and ways to communicate and diagnose these things with end-users.
-Clive

[nseidle]

Original forum post: https://forum.sparkfun.com/viewtopic.php?f=88&t=61480

We don't think it's frequency related - it may be that the user hasn't gotten keys or has a ZED with pre HPG 1.30 firmware (incompatible with SPARTN packets).

We're waiting for customer response. Closing this for now as it's not a bug.

[cturvey]

Yes you'd need a viable firmware and crypt keys

SPARTN has been fully supported since HPG 1.20 (15-Jan-2021), there's been a couple of release to make the decoding more defensive/robust so garbled data doesn't crash/abend the receiver

Still looks to be a cart-horse issue where the auto-determination is made at startup where it's probably not reasonable to have a valid GNSS fix with a location.

Is the L-Band frequency in a config file you can read-back and inspect?

HPG 1.30 supports 2.0.1 (17-Dec-2021)
https://content.u-blox.com/sites/default/files/ZED-F9P-FW100-HPG130_RN_UBX-21047459.pdf

[cturvey]

User reports unit has HPG 1.32 and that modifying the frequency setting on the NEO-D9S directly via VALKEYs got them an RTK fix

[nseidle]

Thanks Clive! We'll have a look again at the zone selection.

[cturvey]

Thanks

Thoughts:

Probably want to limit the constant repetition of the test, and writes to flash or wherever this is stashed. Currently test not repeated or revisited as in setup() path.

Want to revisit setting once you have a fix, and adapt dynamically if it changes. Or have some user-interface method to reevaluate based on current fix. Buttons or Serial Port Config Menu dialogs

Perhaps change CFG-PMP-CENTER_FREQUENCY in RAM. The NEO-D9S also has FLASH so could be changed there as a default.

Reporting to display, or otherwise, of SPARTN lock / signal strength / decode via UBX-MON-PMP / UBX-RXM-COR/SPARTN to aid diagnostic. Display also of current operating region.

[PaulZC]

Resolved in commit 7edb87f

settings.LBandFreq has been deleted. The user now defines settings.geographicRegion (US or EU) - either through the PointPerfect serial menu or the Web Config PointPerfect tab. At startup, the code will attempt to set the correct frequency based on latitude and longitude, compared to the areas defined in Regional_Information_Table. If a fix is not available, or the position is not within a known area, the code defaults to the frequency for the geographicRegion.

[cturvey]

Thanks Paul

[PaulZC]

Note to self - and @nseidle : we need to update the docs to match:

[PaulZC]

To anyone following this thread:

The geographic region is available in the June 10th Release Candidate firmware. Please give it a try.

https://github.com/sparkfun/SparkFun_RTK_Firmware_Binaries/blob/main/RTK_Surveyor_Firmware_RC-Jun_10_2024.bin

Update instructions are available at:

https://docs.sparkfun.com/SparkFun_RTK_Firmware/firmware_update/

You can update Over The Air if you select the "Allow Beta Firmware" option.