L26-P raw data file format missing parameters

We’re using a L26-P module to collect raw data and process it into single point positioning (spp).
When we query for our firmware version, this is the response: $$PSTMSETPAR,1500,L26PNR01A02V01_QX*58

We’re trying to get the position of one sensor by Single Point Positioning (SPP) by using $PSTMTS data. However, we can’t because we can’t find some key data, so we have a few questions.

Where can we get the following variables?

Satellite clock error

Tropospheric and ionospheric corrections (is the atmospheric correction a combination of both in the case of the PSTMTS data?)

Dear Sir

Satellite clock error
——Excuse me, what exactly is this parameter used for? The PSTMTG sentence contains time information, but it is necessary to confirm whether it is what you need.

Tropospheric and ionospheric corrections (is the atmospheric correction a combination of both in the case of the PSTMTS data?)
–Yes.

In addition, this firmware version can be switched to standard RTCM protocol output through command configuration. If you can use RTCM observations to implement SPP, you can also consider this method.

Best Regards

Thanks for your answer mr Stone!

About the satellite clock offset:
To give more context, we’re trying to get the position of our sensor by Code Base Positioning by using satellite data. A brief explanation of this method can be found here: https://gssc.esa.int/navipedia/index.php/Code_Based_Positioning_(SPS)

However, one of the variables that we’re missing is in equation #2 in the previous link is the satellite clock offset (see next line after the equation (2) in the previous link, where Dj = …+…+…).

So when it comes to the satellite clock offset, where in the PSTMTG data can I find the satellite clock offset? Also, how can I correlate it to certain satellite IDs (or PRN)?

  • About switching to RTCM protocol:We used Teseo Suite for sending commands to the L26-P. We used the following sequence of commands to convert NMEA to RTCM found in this forum:

$PSTMSETPAR,1227,9,2
$PSTMSAVEPAR
$PSTMSETPAR,1227,20020,1
$PSTMSAVEPAR
$PSTMSRR

In NMEA format the messages looks like:

$GPRMC,103517.000,A,5149.18761,N,00445.86316,E,0.1,0.0,270241,D66
$GPGGA,103517.000,5149.18761,N,00445.86316,E,2,08,0.8,021.69,M,47.2,M,6C
$PSTMTG,3190,297334.99958060,8,277891418,9,-45849.4160,902a,125557.717767,125422.614,277891846,277891846,129,0,0,7,3190,297334.999581,9,3190,297320.999581,10
5D
$PSTMTS,9,161,32733362.312,41964.94,140136539.074,83,53,245471,0,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0,-5821614.033,-1.977,0,0.00,0.00,13,790,13,0
28
$PSTMTS,9,165,30305784.188,45841.56,127495378.348,83,34,243859,0,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0,-5821614.465,-0.355,0,0.00,0.00,300,1784,16,021
$PSTMTS,9,175,30110353.875,48032.80,126477841.695,83,46,243499,0,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0,-5821614.710,0.559,0,0.00,0.00,-20,893,12,0
23
$PSTMTS,9,13,30884663.812,-46315.64,-131707125.758,83,33,219737,1,-14093094.47,5437004.41,21703588.62,-631.19,-2714.51,282.35,47229.91,28.34,1,-5821614.471,-0.191,14,-27.38,0.00,134,2238,15,01F
$PSTMTS,9,30,7032347.062,-44572.03,-6362444.020,50,14,45231,1,-10859993.72,-11496243.62,21397125.75,1814.86,-2015.19,-185.84,-135089.28,22.22,-1,-5821614.278,0.531,14,-21.08,0.00,-92,35872,113,0
36
$PSTMTS,9,145,45981844.938,45436.10,209124865.391,83,36,202854,0,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0,-5821614.420,-0.523,0,0.00,0.00,0,3218,95,0*2C

However the messages received through serial UART communication are as follows:

b’\xd3\x00\x99CP\x01]>\xbaB\x00\x00z@R\x00\x00\x00\x00\x00 \x00\x00\x00\x7f\xd4\x80\x92\x11\x11\x91\x93\xd2\xd3\xc0\x00\x00\x00\x02\xd3\x0e\xbc\x11\xca\xe2\xa2\xa4\\xb0\x9d\x0b\xbb\xdc0y\xc0*\xfb+\xe5\x90\x97\x02\t\t\x10@\xbd\xcb\xa1\xb3\xf3\xf4\xb8\x08H\x87\xc3\x8cts\xe0\x99L\x03\xa7Zi\xc1\x14c\xc2\xe7\xe9\x7f\x93\x1d}\x8e\xd5\x82]\xec\x02\xec\xe0\xbf\x82\x88B\xf1\xad}7l\x9c\xc0\x01am\x1e\x07\x81rx\x1e\x04\x04\xb2\x91?\x93\x8c9F\xc3t\x8c Ig\xfa\xd70\xce\xdca-\x89#\x81\xc7#\xf7\xb6\xc0\xcd$-\xd3\x00\x8bC\xf0\x01\x8dk\x0f\x02\x00\x00A\xc0\x83\x80\x00\x00\x00\x00 \x00\x00\x00\x7f\xa5!\xa0\xa5\xa5% \x85\xc6j\xb2T\xfe\xe9\xda\xaa\xf2:Y>\xb9n\xfa\xea\rW\xe5>\xee\x00\x8c\x19\xf0\x07>\xeex\x1d\xb0\xefs\x11\xb0\x1e3\xcd\xffB\x7f2\xcc\xe9\xe3v\xa7\xe0~\x01\xf0\x83\xbdj\x03\x97\x19\xf7\x9az\xff\xcfS|\x8em\xfaxl\xfa\x9d&\xa9\x80\x03<\xc0\x00\x05\xf0\x00\x00\x00\xb9\xa8{\xe7\n’
b’\xa2.\xaa\xf0\x92\x88{\xef\xc5\xce(\x8c\x81\x03\xb0\t\xbf]\xfa\xd2\x00\xe0#!\xd3\x003D\x90\x01]>\xba@\x00\x00\x08\x00\x10\x00\x00\x00\x00\x00\x04\x00\x00\x00ji\xc0\n’
b’0\x83\xf3\x98\x13\x9b\xdc\xfez\x10\x9e\xf7\x0c\xe1\xe8\xbc\x0e\x0b,\xd2\x8e\x10\xd2\xde\xfb\x00\xb6\xd6\x8c\xd3\x00\x15>\xe0\x01\x03\x08\xf2\xba\xa7\xb1\x80\xbd\xf9\xd8\x96\x0b\xc9\xf0\xcal\x00\x00\xc3A\xe6$PSTMDRSENMSG,30,549728056,-2915,5264,15445*02\r\n’

The messages from the sensor are still the same as in the NMEA format:
$PSTMDRSENMSG,31,277946015,94,-87,-119*25

Teseo suite cannot decode this message in satellite information, did we convert the message correctly?

Also, we do not have a protocol specification for the latest firmware, so we are highly dependent on asking questions and being lucky on this forum finding answers. How can we get the full protocol specification for the current firmware? It might prevent us asking a thousand questions :slight_smile: If you want to send a document please send to info@parsectiming.com !

Dear Sir

  1. The NCO parameter of PQTMTG is receiver clock drift, and the unit is Hz.

  2. What is your application? Why use SPP to calculate location?
    If you only need to get the location of L26-P, you can parse the latitude and longitude directly from the GGA or RMC of the NMEA sentence.
    PQTMTS and PQTMTG messages, or RTCM protocol messages (RTCM is an international standard protocol), are mainly used for external algorithms to implement RTK. The PSTMDRSENMSG sentence is the original data of the L26-P internal sensor, which is mainly used for external algorithms to achieve inertial navigation.

  3. Teseo suite is mainly to parse NMEA messages.

  4. The latest protocol document corresponding to L26-P is Quectel_L26-T&L26-P_GNSS_Protocol_Specification_V1.1

Best Regards

Hello Stone Chen!
Thanks a lot for the reply.
We’re using SPP in order to get the coordinates of moving vehicles (bycicles mainly)
We knew we could get coordinates from GGA messages, however, we also tried to get them thru PST data, so we could filter or weight data from certain satellites and therefore get more accuracy. Also, by doing that, maybe we could also build an RTK system in order to get even more precise positioning.

On the other hand, now we have another question.
About switching to RTCM protocol, how can we decode the PSTMDRSENMSG message that looks like that?
b’\xd3\x00\x99CP\x01]>\xbaB\x00\x00z@R\x00\x00\x00\x00\x00 \x00\x00\x00\x7f\xd4\x80\x92\x11\x11\x91\x93\xd2\xd3\xc0\x00\x00\x00\x02\xd3\x0e\xbc\x11\xca\xe2\xa2\xa4\xb0\x9d\x0b\xbb\xdc0y(…)
What type of codification is that? Is it just hexadecimal?
Because when we try to decode it from hexadecimal to ascii, we get something like this:
‘d300994350015d3eba4200007a40520000000000200000007fd48…’

So we are wondering the folloinwg questions:
What type of encryption are the ones of those messages?
Is the resulting message also compressed? If yes, how can we decompress it?

Dear Sir,
For L26PNR01A02_QX f/w, its RTCM output is not officially supported. Please don’t use it.
In general, customers use L26P GNSS and IMU raw data to implement RTK+DR feature. GNSS raw data includes PSTMTG/TS messages and IMU raw data includes PSTMDRSENMSG,30/31/24 messages. L26P also provides some PVT messages, such as RMC, GGA.
The latest L26P protocol document doesn’t state update of PSTMTS message parameters. Please find the attached screenshot for PSTMTS message.

BRs

Attached PSTMTS protocol screenshot.