How to configure SparkPNT TX2 for PPK raw data logging via SW Maps?

GPS/GNSS SparkPNT / Consumer Products
1

​Hello everyone,
​I recently started using a SparkPNT TX2 device and I am trying to set up a proper workflow for PPK post-processing. Since my specific unit relies on logging directly to my phone, I am using the SW Maps app over Bluetooth.

​On my first attempt, the log file saved with a .ubx extension turned out to contain only standard NMEA text sentences (like $GNGGA). Because of this, post-processing software like Emlid Studio and RTKCONV failed to convert it to RINEX or read any time/satellite data.

​I am currently looking at my SparkPNT TX2 Web Configuration GUI (which shows menus like GNSS Configuration, Ports Configuration, etc.). Could anyone guide me on the correct setup for this model?

​What exact messages or settings do I need to enable in the SparkPNT TX2 Web GUI (under Ports or GNSS Configuration) to force the device to output raw u-blox binary data (like RXM-RAWX and RXM-SFRBX) over Bluetooth?

​What is the proper workflow on the SW Maps side to ensure it captures this raw stream into a true binary .ubx file instead of just text logs?

Thank you in advance

2

Hi Sebastian (@Sebastian_Navarro ),

The SparkPNT TX2 uses the Quectel LG290P GNSS. It does not support RXM-RAWX and RXM-SFRBX. Those are specific to u-blox GNSS modules.

Instead, you need to configure the TX2 to output the relevant RTCM messages.

Working through the RTK Everywhere menus and message rates, you need to:

Disable NMEA RMC, GSV, GSA, VTG and GLL. Set their message rates to zero.

You can leave NMEA GGA enabled if you wish.

Enable RTCM3 1019, 1020, 1041, 1046, 107X, 108X, 109X, 112X.

I suggest message intervals of: 1 second for 107X, 108X, 109X and 112X; 5 seconds for 1019, 1020, 1041 and 1046.

Hopefully SW Maps will be able to log this for you. I have not tried this myself.

Then, once you have the RTCM data, use RTKLIB (RTKCONV) to convert the RTCM3 to RINEX before you submit it to CSRS.

There is a little more information about this in the documenation.

I hope this helps,
Paul

3

Hi all,
if the purpose is only to log (rtcm) data U can use Lefebure app and send also gga to swmaps enabling mock data, logged_data are in /storage/emulated/…/Download/NMEA-date.txt also if rtcm ones…

in the latest fw there is also rtcm 1230.
Regards

4

I think 1041 was a typo?

For PPK, I’d use MSM7 - so:
RTCM 1019, 1020, 1042, 1046, 1077, 1087, 1097, and 1127.
1 second rate for the first (4) messages, 10-30 second rate for the last (4) in the list.

Also, I believe 1230 (from a Rover) will be ignored by PPK.

Because SW Maps saves the log with a .ubx extension, RTKCONV will mistakenly try to read it as a u-blox binary file, as you discovered. To parse LG290P data successfully, open RTKCONV and manually switch the Format dropdown menu from “Auto” to RTCM3. This forces the software to correctly decode the raw RTCM stream from the LG290P and output your clean RINEX for Post Processing.

5

Thank you very much for your valuable response.

I did what you told me, made the changes, and now the .nav file appears as well, thanks

I have another question: how long should I wait before using CRSR services? I’m still learning, sorry if these are very obvious things.

6

Thanks! I was trying first with RTMC3, RTMC2 and RTMC3 it works fine

Is there anything else I should keep in mind for this SparkPNTTX2 Tregarding PPK?

I’ll keep you updated until I manage to do the PPK correction. I tried the CRSR service, but it didn’t use Galileo corrections — maybe because I did it too quickly? I should wait longer, right?

7

How long did you wait ?
I don’t think Galileo is supported with Ultra-rapid orbits, so you can re-submit and it might work fine the 2’nd time.

CSRS-PPP says 18 hours after the end of Day (UTC Time).

If you finish a survey on a Tuesday afternoon:

  1. The official “GPS day” wraps up at 7:00 PM CDT (in the USA) on Tuesday, for example.
  2. You should wait 18 hours, so submit your RINEX file on Wednesday afternoon.

If you submit before 1pm on Wednesday, CSRS-PPP will default to the less accurate “Ultra-rapid” orbits instead of waiting for the cleaner “Rapid” data. The most accurate data will be available 2 weeks after the end-of-week (Saturday for me).

Just remember everything revolves around UTC time/date, and the End-Of-UTC-Day…not just 18 hours for example.

[Edit] Just for clarity, CSRS-PPP is PPP, not PPK :wink: It’s an entirely different animal than PPK with RTKLib.

8

Well… Probably? :wink: It was early. Not enough coffee consumed…

1041 is the NavIC ephemerides. 1042 is the BeiDou (BDS) ephemerides. There are many more BeiDou SVs up there than NavIC… 1042 is the better choice, although the LG290P supports both.

:hot_beverage:

9

Well, just to say that this toy can spit many rtcm data…
but also eat and digest (non documented) legacy rtcm like 1004 and 1012 for internal rtk_engine.