Sparkfun lg290p Survey-In Setup

[Marshall_Boser]

I am attempting to set up my sparkfun Lg290p breakout board as a locally hosted base station which I then would use to send all of my rovers the RTCM data corrections to get the RTK lock for each rover.

The problem im running into at the moment is attempting to find the exact location of my base station. I need to be able to utilize the “Survey-In” mode of the quatcel chip so that I can run the survey for a couple hours to get the exact gps location of the antenna for the base station.

When attempting to put my board into base station mode, (and then eventually in survey-in mode) I run into the issue where the serial port just starts spitting out gibberish (maybe binary?) immediately after putting the unit in base station mode and then saving and rebooting.

I factory reset it with:
Sent: $PQTMRESTOREPAR13
Received: $PQTMRESTOREPAR,OK3B

Then I wanted to set it to base station mode:
Sent: $PQTMCFGRCVRMODE,W,229
Received: $PQTMCFGRCVRMODE,OK64

Then upon save and reboot this is what the serial output looks like (just a snippet but you get the point):

Ó3CÁ"b_B €@ €zZ%y?cö!<I•lžCkÒÐ º¶fK€%"ñÓkDa"=™I€ @@ WÒʒjê“菩Ü#ƒŸ)6¼MŒ[hwÈáKÈ'–1ªó@½ÿ=y‘îJ/¶ƾÚXû©XÖ7Ä $Ñ|©tHg»{y—UU@ëp6ëN<ë:ìôëÓ>Ñ û 0Ô d îfKcìÓkDa"=™Y @@ WÒʒjê“ä)¼%'K$F ,"˜Ÿ±cžÒ-©ûYþLœƒõ-øڏ㊞’LxÜú°?¥О«ëúÅu⋏

Idk if this is spitting out raw binary data? Or what is going on, but from the forums I’ve seen, it should not be looking like this… Ive even tried to continue to send it commands to try to get it back to normal, but nothing seems to change the output until I reset it back to factory and then it goes back to spitting out the normal GNSS outputs. Any and all help is appreciated!

[TS-Russell]

Usually when I see characters like that from a serial comm there’s something amiss in the baud settings or there’s an overflow of some kind

Can you successfully send other commands? Software Overview - SparkFun LG290P Quadband GNSS RTK Breakout Hookup Guide (example is a bit scrolled down that section). Also make sure the right COM port is selected

Finally: what firmware version are you running?

[bamarcant]

After each command run savepar & reboot
note that if you have the latest fw, the module receives the specific command (not all) only on the current port;note there are three uart…
Check baud_rate and note that in base_mode it outputs rtcm, so U need an rtcm parser after checked baud & port on module & client_terminal

or rtklib

" I need to be able to utilize the “Survey-In” mode"
not worth it, it is unuseful but U can log the raw (rtcm) data and do a postprocess or use a ppp service instead.
Regards

[Marshall_Boser]

Ahhha, I was originally planning on using some sort of post processor and just logging raw rtcm data, but again struggled with the board turning to gibberish after trying to set up the output for that which turned me to this survey-in mode.

So I take it the survey in is just very inaccurate regardless of how long you run the survey for?

Thank you for the response!

[Marshall_Boser]

I see, honestly I just had the board hooked up to a raspberry pi which was sending it commands through pyserial. I wouldn’t be surprised if the board was not a fan of formatting or something or the other with the way I was sending it commands. I will try to do the setup via the actual quatcel software this time. If I still run into issues I will check the firmware and give you a more detailed explanation of my process using QGNSS along with the firmware version.

Thank you!

[semuadmin]

A few observations and follow-up queries on LG290P Survey-In mode…

(FYI I’m primarily working in Python, but the same behaviour can be seen using the Sparkfun Arduino library on an ESP32).

As noted, base station mode can be enabled via survey-in or fixed coordinates. The command sequence in each case is as follows:

Survey-In (in this example, accuracy = 1m, duration = 60 seconds):

$PQTMCFGRCVRMODE,W,2*29
$PQTMCFGSVIN,W,1,60,1,0.0,0.0,0.0*0B
$PQTMSAVEPAR*5A
$PQTMSRR*4B

Fixed Mode:

$PQTMCFGRCVRMODE,W,2*29
$PQTMCFGSVIN,W,2,0,0,-2213544.83,-4577238.41,3838050.12*08
$PQTMSAVEPAR*5A
$PQTMSRR*4B

In both cases, the UART port will turn to mush for a few seconds following the reset (so you may seem some spurious bytes), but should be re-established OK shortly afterwards.

In the case of Survey_In, there will be a period of inactivity (typically 2-20 seconds) while the receiver acquires the initial RTK observations. You can monitor this by enabling the PQTMSVINSTATUS message:

$PQTMCFGMSGRATE,W,PQTMSVINSTATUS,1,1*58

Response:

(for the first few seconds, no observations...)
$PQTMSVINSTATUS,1,485825449,0,,00,0,60,0.0000,0.0000,0.0000,0.0000*2A
$PQTMSVINSTATUS,1,485826449,0,,00,0,60,0.0000,0.0000,0.0000,0.0000*29
$PQTMSVINSTATUS,1,485827449,0,,00,0,60,0.0000,0.0000,0.0000,0.0000*28
$PQTMSVINSTATUS,1,485828449,0,,00,0,60,0.0000,0.0000,0.0000,0.0000*27
(...then the observation count will start to increment, and some RTCM3 MSM messages will be output...)
$PQTMSVINSTATUS,1,485878000,1,,11,1,60,-2213544.8212,-4577238.3082,3838050.0331,7.4092*3B
$PQTMSVINSTATUS,1,485879000,1,,11,2,60,-2213544.8300,-4577238.3256,3838050.0481,1.3000*30
$PQTMSVINSTATUS,1,485880000,1,,11,3,60,-2213544.8321,-4577238.3301,3838050.0477,2.8179*3F
...
(...finally, when the observation count reaches the specified period, the 'valid' status will change to '2' and you should start to see RTCM3 1005 (ARP) messages output, signifying that the survey has been successful...)
$PQTMSVINSTATUS,1,485937000,2,,11,60,60,-2213544.8322,-4577238.3351,3838050.0458,3.4591*05

By default, the LG290P will output RTCM MSM4 messages - 1074, 1084, 1094, etc.

In my case I wanted to output RTCM MSM7 messages - 1077, 1087, 1097 etc. This can be done using the PQTMCFGRTCM command:

$PQTMCFGRTCM,W,7,0,-90,07,06,1,0*26

However - and this is my follow-up query - if I add this command to my cohort of other Survey-In commands, i.e.:

$PQTMCFGRCVRMODE,W,2*29
$PQTMCFGSVIN,W,1,60,1,0.0,0.0,0.0*0B
$PQTMCFGRTCM,W,7,0,-90,07,06,1,0*26
$PQTMSAVEPAR*5A
$PQTMSRR*4B

… it appears to have absolutely no effect on the first attempt - I still get the default RTCM MSM4 messages. If, however, I send exactly the same set of commands a second time, I now get the expected MSM7 messages. My query is:

1. What is the official definitive sequence of commands to establish Survey-In with MSM7 messages - surely it should not be necessary to undertake two successive saves and resets to accomplish this???
2. Where are the official command sequences documented by Quectel? I have the LG290P (03) GNSS Protocol Specification, but this only appears to document the NMEA message payloads - it says nothing about which commands require hot/cold/full resets and/or NVM saves before taking effect. Is there a public domain document which actually specifies this?

[bamarcant]

We discussed this (2) on the quectel forum, Splee was among the first to make this fact known…

MSM7 CFGRTCM not being respected on LG290P after a restore unless it's done...

for (1) note that the mean is around 1//7m too much for a base.

Look at <MeanAcc>  survey-in mean position accuracy in metres...

[semuadmin]

FWIW the workaround I’ve adopted is to poll for an incoming PQTMVER message (which the LG290P sends out on restart) after the first restart, and then send the second batch of commands once it arrives. Clunky as hell but it appears to work.