Sparkfun lg290p Survey-In Setup

GPS/GNSS Development Boards
1

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!

2

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?

3

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

immagine
immagine709×204 16 KB

or rtklib
immagine
immagine171×318 4.8 KB

" 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

1 Like
4

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!

5

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!

6

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?
3 Likes
7

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

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...

immagine

2 Likes
8

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.

3 Likes
9

I’m confused, what’s the point of doing a survey in with 1M accuracy? my phone can do that.
is survey in even worth doing?
it seems to be way off from what my local free guv correction station indicates.

10

In General, using “Survey-In” is good for local sites where repeatability is needed on recurring (future) Base Station deployments occupying the same base position. A Surveyed-In Base allows the Rovers to produce RTK positions with increased Precision (due to the canceling of Atmospheric Errors, etc), but not necessarily any increase in Accuracy… which is absolutely fine in some situations.

CORS are generally expressed in the NAD83 System (usually with a 2015 Epoch Reference), which will be different than a solution using a Surveyed-in Base :slight_smile:

1 Like
11

I can add that to reduce the mean_acc to submetric you have to inject corrections even if module is in base_mode.
Regarding the CORS, I remember this post, maybe could help…
especially this
and here , before finally
immagine

1 Like
12

Setting the base station with an accuracy of 1m in survey-in mode does not mean that the survey will be with an accuracy of 1m.

Survey-in mode is a useful and very fast measuring tool.

Survey-in mode means measuring points relative to each other without determining the position on Earth. For example, you can determine the corners of your car and after marking them in the CAD application, read the length and width of your car with an accuracy of 1 cm, even though the position of the base station was set with an accuracy of, for example, 1 m. You will not be able to determine where your car is on Earth.

What are the advantages:

  • quick setting of the base station at any point,
  • no need to access another base station, e.g. a public one
  • precise measurement of points.

When you start Survey-in, you start the so-called session. You set the base station and start measuring points. Measured points in Survey-in mode are called a plan, because unlike a map they only show the position of points relative to each other.

Survey-in can be compared to drawing an element in a CAD program. You start drawing an element at any place in the system.

Now you will say that it is a big limitation that you can only create one plan.
Plans can be combined if you measure the same point during different sessions. Then in CAD or QGIS you can move one plan so that the common point overlaps. You can even attach a plan to a map if during a session you measure a point that is on the map and thus determine the position on Earth. In each session, the station can be set in any place, not the same.

What is the disadvantage of combining plans:

  • the error of measuring the common point will be added to the error of measuring the points
1 Like
13

I was wondering how we could go backwards from a known survey marker.
it looks like I can do a survey in and make sure I take the position of that known marker as a data point.

14

If I understand you correctly, it is about measuring a known survey marker during each session.

There is a second way. If you have a known survey marker with known coordinates, you can set the base station over this point in Fix mode (not Survey-in mode), where you have to enter the coordinates of the point as the station coordinates. This method seems more difficult to me, because you have to set your base station antenna over the known survey marker.

15

ya, id have to setup a lora radio for that too.

eventually to put my Pi base station into a waterproof box with a little solar charger so I can do such things.