Can't get better than RTK float with the Sparkfun LG290P GNSS RTK Breakout Module

[TCIII]

Hi All,

I have searched the GPS/GNSS Forum for an answer to my issue and have not able to find a solution.

Base Station: Sparkfun RTK Postcard/Portability Shield with L1/L2/L5 active antenna.
ZED-F9P UART3 RTCM3 Telemetry baud rate of 57,600.
Rover 1: Sparkfun ZED-F9P RTK Receiver with L1/L2 active antenna .
Rover 2: Sparkfun LG290P RTK GNSS Breakout Module L1/L2 active antenna.
LG290P GNSS RTK Breakout Module FW: LG290P03AANR01A05S
The baud rate for the LG290P RTCM3 Telemetry UART3 input is 57,600.

I decided to evaluate my Sparkfun RTK Postcard Base Station with the Sparkfun LG290P RTK GNSS Development Module that I plan to install on my Traxxas Rover.
I setup the RTK Postcard/Portability Shield Base Station in the driveway with a clear view of the sky, got a mean deviation of under 0.3 m after a 60 sec Survey-in, after which the RTCM3 transmissions began.
Then I powered up the Sparkfun ZED-F9P RTK Receiver that is presently on my Traxxas Rover, which had a clear view of the sky, and after less than five minutes I had a RTK Fix indication when the board RTK indicator quit flashing.
So I swapped out the ZED-F9P RTK Receiver with the Sparkfun LG290P RTK GNSS Breakout Module and could only get a RTK Float indication as the board RTK indicator kept flashing and never turned off to indicate a RTK Fix indication.
To verify this issue with the LG290P RTK GNSS Development Module, I took the LG290P RTK GNSS Development Module off the Traxxas Rover and hooked it up to a laptop outdoors and used the Quectel QGNSS app to verify that the LG290P RTK GNSS Development Module on the Rover was only getting a RTK Float indication, not a RTK Fix indication, and that was the case as the QGNSS Data View Quality Indicator was showing “Float RTK”.

Since my Sparkfun ZED-F9P RTK Receiver was able to reach RTK Fix using the same Sparkfun RTK Postcard/Portability Shield Base Station I am confident that the same RTCM3 messages should be being received by the LG290P RTK GNSS Development Module too.

Therefore I am presently at a loss as to how to troubleshoot this issue as it looks like I have the latest stable LG290P software version according to the Sparkfun GitHub.

Regards,

TCIII

[TCIII]

Hi All,

After doing a lot of IoT searching, its seems that the LG290P RTK GNSS Development Module requires RTCM3-MSM4 messages on the UART3 input to achieve a RTK Fix indication when in the Rover mode.
I believe that my Sparkfun RTK Postcard/Portability Shield Base Station is only outputting RTCM3 messages.

Is this revelation correct and if so how to configure my Sparkfun RTK Postcard/Portability Shield Base Station for RTCM3-MSM4 message output on UART3?

Further research indicates that the UART3 output of the LG290P can be configured directly for RTCM3-MSM4 output by sending the following commands, using QGNSS, to the LG290P module:

• Stop the module: Command: $PQTMGNSSSTOP*09
• The command $PQTMSETTING,W,MODE,1,0,3*6D puts the receiver into a mode where it will only output MSM4 and RTCMv3 1005 messages.
• Save the new settings to the non-volatile memory by sending $PQTMSAVEPAR*5A.
• Reboot the module by sending $PQTMSRR*4B.

On the other hand, I have tried using the RTK Everywhere serial user interface with PuTTY, but the “Configure GNSS Messages” Menu item only opens up a menu that allows “Set Base RTCM Messages” which allows the selection of available RTCM3 messages, but not the configuration of those messages.

So far I am hesitant to use the QGNSS app to change the UART3 output configuration as I am not quite sure of the impact on the installed RTK Everywhere firmware.

Regards,
TCIII

[TCIII]

Hi All,

The solution to my issue is becoming more convoluted as I have come upon another solution to configure the Sparkfun RTK Postcard’s LG290P to output RTCM3-MSM4 messages on UART3:

• Stop the module: Command: $PQTMGNSSSTOP*09

• Set UART3 to output only RTCM3 messages: Command: $PQTMCFGPROT,W,3,0,4*41.

• Set the MSM4 output rate: Command: $PQTMCFGMSGRATE,W,RTCM3,1074,1*61

• Save parameters: Send the command $PQTMSAVEPAR*5A. The module will respond with $PQTMSAVEPAR,OK*4E.

• Reboot the module: Send the command $PQTMSRR*4B. The LG290P will then restart with the new settings.

Comments please.

Regards,
TCIII

[bamarcant]

TC third, I don’t understand where you got these commands from…you should strictly refer to the manual: Resources - SparkFun LG290P Quadband GNSS RTK Breakout Hookup Guide

Quectel_LG290P03LGx80P03_GNSS_Protocol_Specification_V1.1.pdf

However, I thought it would be better to set the breakout as the base and the postcard as the rover.I tested the breakout at 57K (errata corrige) baud but you have to use MSM7 & ephemerides.
Using the protocol the commands to set the base are these in order
For the postcard just reset it and it is already ready.
base_mode for breakout:

$PQTMRESTOREPAR*13   Clear all data to default
$PQTMGNSSSTOP*09
$PQTMCFGRCVRMODE,W,2*29   # set receiver to base mode
Set the base in ecef -->   $PQTMCFGSVIN,W,2,0,0,x,y,z*<Checksum>   <-- need to compile and run the checksum
$PQTMCFGSVIN,R*26 check if ecef base is correct (U can ask in postcard sending the above command and copy the coord)
$PQTMCFGRTCM,W,7,0,15,07,06,2,30*36
$PQTMSAVEPAR*5A
$PQTMSRR*4B
$PQTMGNSSSTOP*09
$PQTMCFGMSGRATE,W,1,3,RTCM3-1019,1*56
$PQTMCFGMSGRATE,W,1,3,RTCM3-1020,1*5C
$PQTMCFGMSGRATE,W,1,3,RTCM3-1041,1*5B
$PQTMCFGMSGRATE,W,1,3,RTCM3-1042,1*58
$PQTMCFGMSGRATE,W,1,3,RTCM3-1044,1*5E
$PQTMCFGMSGRATE,W,1,3,RTCM3-1046,1*5C
$PQTMSAVEPAR*5A
$PQTMSRR*4B
$PQTMCFGMSGRATE,W,1,3,RTCM3-1033,0*5F
$PQTMCFGUART,W,3,57600*34
$PQTMSAVEPAR*5A
$PQTMSRR*4B

Anyway if U would try on the postcard first, set as follows for the base mode
not rover…

$PQTMCFGRTCM,W,7,0,15,07,06,2,30*36
$PQTMSAVEPAR*5A
$PQTMSRR*4B
$PQTMGNSSSTOP*09
$PQTMCFGMSGRATE,W,1,3,RTCM3-1019,1*56
$PQTMCFGMSGRATE,W,1,3,RTCM3-1020,1*5C
$PQTMCFGMSGRATE,W,1,3,RTCM3-1041,1*5B
$PQTMCFGMSGRATE,W,1,3,RTCM3-1042,1*58
$PQTMCFGMSGRATE,W,1,3,RTCM3-1044,1*5E
$PQTMCFGMSGRATE,W,1,3,RTCM3-1046,1*5C
$PQTMSAVEPAR*5A
$PQTMSRR*4B
$PQTMCFGMSGRATE,W,1,3,RTCM3-1033,0*5F
$PQTMSAVEPAR*5A
$PQTMSRR*4B

as you notice, you have to save and reset several times
Regards

[TCIII]

@bamarcant,

Thanks for the response, much appreciated.

Unfortunately due to physical limitations, there is no way for me to swap the LG290P GNSS RTK Breakout Module for the RTK Postcard and vice versa.

I assume that the second set of commands is an attempt to get the RTK Postcard/Portability Shield, which is presently the Base Station, to send the correct RTCM3-MSM7 & ephemerides messages to the LG290P GNSS RTK Breakout Module which is presently the Rover?

If I do reconfigure the RTK Postcard/Portability Shield to send the correct RTCM3-MSM7 & ephemerides messages, will there be any issues using the RTK Postcard/Portability Shield with the Sparkfun ZED-F9P RTK GNSS Breakout Module as the Rover?

Regards,
TCIII

[bamarcant]

The MSM7’s are more complete and ublox and other receivers also benefit, but you have to wait and change the firmware for the postcard RTK_Everywhere
when ready for msm7.I don’t know if the manual setup revert to default once reboot…

[TCIII]

@bamarcant

I actually found a simpler solution here: Postcard RTK: Choose msm4 or msm7 message format · Issue #735 · sparkfun/SparkFun_RTK_Everywhere_Firmware · GitHub

Regards,

TCIII

[PaulZC]

Hi @TCIII ,

Let’s continue the discussion here. The GitHub issue in your link above was about the generation of MSM7 corrections vs. MSM4. It seems clear you need more general help with achieving RTK Fix. Here is a much better place for that discussion.

As I said on GitHub, it is almost end of day for me. So it may be tomorrow before I can reply with more comments and suggestions. If there is time today, I will try and summarise your difficulties and suggest some things to investigate.

Best,
Paul

[TCIII]

@PaulZC

Since this topic has been solved I will start a new topic.

Regards,

TCIII

[PaulZC]

Hi @TCIII ,

Here is my test setup:

I have a Postcard + Shield running RTK Everywhere 2.2 (July 16th). The LG290P is running the v05 firmware.

I have re-flashed the LG290P using QGNSS so we have a known starting point.

I have set the RTK Firmware back to its Factory Defaults, so we have a known reproducible starting point. Options “s r y” from the serial menus.

I put the RTK Firmware into Base mode with “s B x x”. It performs its survey-in. This completes and it begins transmitting corrections. These are accessible via the white locking JST connector, which connects to LG290P UART3.

I am using a logic analyzer to study the data on the JST TX pin. It is 115200 baud and contains a mix of NMEA and RTCM. The RTCM messages are: 1005, 1033, 1124, 1074, 1084, 1094, 1114. I.e. is is outputting MSM4.

I have an LG290P Breakout which I am using as my Rover. It too is running v05 firmware. I have re-flashed it just to be sure.

Here is what I see using QGNSS on UART1 (via the USB connector and the CH342):

The white JST connector on the Breakout provides access to UART3 also.

I use JST cables to link the Postcard to the Breakout: GND to GND; Postcard UART3 TX to Breakout UART3 RX.

UART3 on the Breakout defaults to 460800 baud. The Postcard is outputting corrections at 115200 baud. I change the baud rate on the Breakout using QGNSS, and sending $PQTMCFGUART,W,3,115200*07.

The effect is immediate. I see:

The white LED on the Breakout is illuminated.

@TCIII : as a starting point, please try and replicate this. Please ensure you have a wire link from JST to JST. Please do NOT use Radio. Start with wire. Once you have this working, you can start to make changes: one at a time - and re-test.

It is 6:30PM here. Please send updates and I will read them in the morning.

I hope this helps,
Paul

[PaulZC]

@TCIII : I have unsolved this issue. Please continue here. Thank you.

[TCIII]

@PaulZC

I have been having trouble getting my Sparkfun LG290P RTK GNSS Breakout Board on my Rover to reach a RTK Fix solution when receiving RTCM3 messages on UART3 over a Radio telemetry link from a Sparkfun RTK Postcard. I was originally told that I needed to send RTCM3 + MSM7 correction messages and deferred to this issue which did not work.

I am presently running firmware version RTK_Everywhere_Firmware_v2_2.bin and firmware version LG290P03AANR01A05S.pkg on the Sparkfun RTK Postcard Base Station and firmware version LG290P03AANR01A05S.pkg on the Sparkfun LG290P RTK GNSS Breakout Board on the Rover.

Contrary to expectations, the RTK Everywhere version 2.2 does not replace the QGNSS app installed UART3 57600 baud with 115200 baud at every bootup and leaves it at 57600. Using 115200 baud for both the Base Station and the Rover UART3 does not result in RTCM3 transmissions whereas using 57600 baud does and the Rover obtains a RTK Float, but never a RTK Fix.

I am at a loss as to why the Sparkfun LG290P RTK GNSS Breakout Board on the Rover cannot reach a RTK Fix solution whereas my Sparkfun ZED-F9P RTK GNSS module, when receiving RTCM3 messages at 57600 baud from the same Sparkfun RTK Postcard, can reach a RTK Fix solution.

Comments please.

Regards,
TCIII

[TCIII]

@PaulZC

Both of my 3DR 915MHz telemetry transceivers are hardwired to the UART3 connector.

TCIII

[PaulZC]

I suspect your radio link may be the root cause of your issues. Please try a simple wire link first.

[TCIII]

@PaulZC

My Sparkfun ZED-F9P RTK GNSS module on my Rover, when receiving RTCM3 messages at 57600 baud from the same Sparkfun RTK Postcard using the same 3DR telemetry transceivers, can reach a RTK Fix solution.

So something else is going on with the Sparkfun LG290P RTK GNSS Breakout Board on the Rover other than the Radio Telemetry link.

I am beginning to think that I may have a defective Sparkfun LG290P RTK GNSS Breakout Board (I received it second hand) as I get the following from the QGNSS Data View when the RTK LED and the PPS LED are flashing:

Fix Mode is blank whereas it should say 3D
Quality Indicator shows DGNSS where as it should say Float RTK
Total Epochs and Fixed Epochs are showing increasing five digit numbers
RTK Fixed is 0 as it should be
RTK Float is 0 where as it should be some numerical value other than 0.

If I unhook the Telemetry Radio input to the Radio connector on the Breakout Board the RTK LED quits flashing but the PPS LED keeps flashing.
If I keep the Telemetry Radio input hooked up, but detach the active L1/L2 antenna, the RTK LED keeps flashing, the PPS LED keeps on flashing, but most of the Data View indicators go blank except for Date, Time, Total Epochs and Fixed Epochs.

As bamarcant says, it might be that I need an active L1/L2/L5 antenna with the LG290P unlike the ZED-F9P?

Again, please keep in mind that my Sparkfun ZED-F9P RTK GNSS Receiver module achieves a RTK Fix solution with the same Sparkfun RTK Postcard and the same 3DR Telemetry Radios.

Comments?

TCIII

[bamarcant]

Postcard RTK: Choose msm4 or msm7 message format#735

– L1 / L2 only
may be an issue.
As already said (errata corrige)

and get rtk fix despite the 57K baud…
I chose msm7 because with msm4 it remained in float in this particular circumstance
but I can say that with a station that broadcasts only RTCM 1004 and 1012 (therefore only L1 L2) it immediately goes to fix despite not being supported in the official documentation!
P,s.
use strsvr for debug rtcm stream at the end of radio_link.

[clive1]

I’d agree that the exact band mix in the RTCM3 MSM messages will impact ability to resolve.

If they only have the L1 band in common, FLOAT could persist for many minutes or indefinitely, for example a NEO-M8P operating as a Base for a ZED-F9P as a Rover.

The M8P’s would take about 7.5 minutes to get to FIXED RTK

The L2 ZED’s use L2C, I’d have to pull the exact encoding, but it’s also possible that the RTCM3 can contain a mix of pairing, ie L1+L2, L1 Only, L2 Only, for any given satellite. You can see this in u-Blox packets with a lot of dead space (zeros) in the latter half of the packet, commonly about 15-17%

On the Github thread LEICA receivers were mentioned, these have very accurate / disciplined local clocks, so the RTCM3 data will be a lot cleaner / quieter / stable, unlike u-Blox and other retail receivers which use TCXO, and the performance / offset computed as part of the solution. The relative instability of the local clocks might contribute to being able to resolve the carrier ambiguities, and keep the receiver in FLOAT (~20cm CEP) vs FIXED (~2cm CEP)

On the GNSS boards, perhaps guard against draft and airflow, as this can cause instability in TCXO frequency, which the receiver’s see as acceleration. This would be perceptible via doppler / range-rate, or cross the board loss-of-lock.

[PaulZC]

@TCIII : Here is the data stream between the Postcard and the Breakout at 115200 baud:

The duty is around 45%. If you halve the baud rate, the duty will be 90%. Perhaps this is too much for your radios, leading to errors or partial packets? Perhaps the ZED is better at coping with partial data?

If you insist on 57600, I recommend decreasing the number of messages. You can probably turn off all the NMEA messages, except GGA?

becomes:

The duty drops to about 17% at 115200 baud:

And I still have RTK Fix:

I hope this helps,
Paul

[clive1]

The “Age of Diff” certainly suggests low latency/error packets. It might be helpful to understand this in the systems which aren’t working so well.

The SiK/3DR radios can have different baud rates for wire and AIR. The buffering on the 8051 implementation isn’t that deep, and the AIR rate needs to be higher to avoid swamping.

The u-Blox is pretty resistant to packet loss/corruption, and resyncing. And in most cases the RTCM3 is assisting in maintaining the solution once carrier lock and ambiguity resolution. RTK Fixed can persist on the ZED-F9P up to 60 seconds, and that can be configured higher, that timeout clears with good packets.

Timeliness is important, ie low latency, so the data received has close commonality with the local observations, and doesn’t need much extrapolation. Best to keep sending fresh data than try to retry.

[clive1]

Contributing factors:

High Latency

High Packet Loss (bigger ones prone to more damage, especially packed awkwardly or spanning AIR packet limits)

Noisy Observations (if the target keeps dithering about it’s hard to contain within a carrier cycle, around 19 cm in GPS L1. RTK receiver is solving for both Base and Rover measurements)

Lack of Commonality in Constellations, Satellites, and Bands (u-Blox wanted 8 satellites for RTK, with at least 5 from a single constellation)