Feature Request: SPARTN compatiblity

[Katawann]

Hello,

I open the discussion regarding SPARTN integration in PX4. In my case, I use SPARTN with PointPerfect (from ublox). I succeed to forward the SPARTN data through UART to ublox device by doing the following:

• Add parameter in ubx.h #define UBX_CFG_KEY_CFG_UART1INPROT_SPARTN 0x10730005
• Enable it in ubx.cpp cfgValset<uint8_t>(UBX_CFG_KEY_CFG_UART1INPROT_SPARTN, 1, cfg_valset_msg_size);
• Send the data with send_rtcm_data() function of MAVSDK

Using ucenter, I can see the SPARTN package received but it never switches to RTK mode (which it does if I send directly the same data without going through PX4)

I guess the limitation of 180 bytes of the GPS_RTCM_DATA could be an issue as we have sometimes bigger messages.

Happy to share my work and see how we can successfully integrate this functionality in PX4 !

[Katawann]

FYI the feedback I got from Ublox regarding this issue:

it seems to be a delay in the information coming through. Then it seems to come through all at once with some of it being rejected.

We reviewed the logs for FCUUART1COM15__9600230319_125817.ubx and can see that there are bytes on UART1 interface that are unknown in UBX-MON-MSGPP - not perceived by the receiver as SPARTN (see following screen shot).

Please check in UBX-RXM-COR if all the SPARTN message types come through. HPAC messages are really important to be all there to get in RTK . There might be limitation on UART buffer not letting all the HPAC messages get through.

It appears that not all messages are coming through - see below screen shot snip for UBX-RXM-COR when I debugged FCUUART1COM15__9600230319_125817.ubx.

The file they analyze where I send the SPARTN through a Pixhawk 4 using send_rtcm_data:
FCU_UART1_COM15___9600_230319_125817.zip

[bkueng]

I guess the limitation of 180 bytes of the GPS_RTCM_DATA could be an issue as we have sometimes bigger messages.

You can split up the SPARTN messages, and always fill the full buffer. That's what RTK is doing.
I would check if there's some buffering anywhere in between on the link.

[Katawann]

Actually, I did not explain well. I first sent the full data with send_rtcm_data(), but I was receiving "Too Long" from MAVSDK so I split the SPARTN data into messages of 180 bytes like you propose and this is the error ublox provided the support.

The same code (splitting the messages in 180 bytes) is working well when not forwarded by PX4 so I guess PX4 is buffering somewhere

[bkueng]

What is the data rate? And what hardware do you use (client, link, autopilot)?

[Katawann]

• Host:
  Linux Ubuntu 21.04 running MAVSDK C++ v1.4.9
• FCU:
  Pixhawk 4 with PX4 v1.13.2 (+ custom version with SPARTN enabled as mentioned above)
• F9P:
  CUAV F9P RTK

Host with MAVSDK <-- USB @921600 --> Pixhawk 4 through UART (TELEM4) @ 115200 ---> CUAV F9P through UART1

[bkueng]

That's fairly direct. You can monitor the injection rate with gps status or uorb top gps_inject_data

[Katawann]

Here is the output of gps status. I see that RTCM injection rate is at 0.39 Hz. Is it this value which should be increased and if yes, could you help me to define where is the place to do it ?

[Katawann]

@bkueng I tried to increase value of some variables which I supposed to be related to RTCM limitation:

• RTCM_INITIAL_BUFFER_LENGTH in rtcm.h
• max_num_injections in gps.cpp
• always return false for RTCMParsing::addByte(uint8_t b) in rtcm.cpp

but it does not fix my issue. I probably misunderstand where the RTCM is still truncated or adapted. If you have any guidance to provide it is more than welcome :)

[bkueng]

0.39 Hz is rather low. I'm not familiar with SPARTN though. You can compare it against the sending rate (before MAVSDK). I'd look into how MAVSDK handles the data. On PX4, the data is forwarded as is. The only risk is if the data rate is too high, leading to drops.

@bkueng I tried to increase value of some variables which I supposed to be related to RTCM limitation:

None of these things should make a difference, as RTCM parsing is only used for reading RTCM output from a GPS. In your case I assume you get the SPARTN data from an internet provider?

[paujar]

does fix my issue. I probably misunderstand where the RTCM is still truncated or adapted. If you have any guidance to provide it is more than welcome :)

Did you mean "doesn't fix my issue" or did it actually fix the issue?

[Katawann]

Did you mean "doesn't fix my issue" or did it actually fix the issue?

arf yes sorry it does not fix my issue. I corrected in the previous comment thank you.

I'm running out of time to dig into the code unfortunately so I will go back to my previous solution (stream PointPerfect through USB of F9P device instead of forwarded by PX4 as I wanted to do). At the end of the day, it could be really interesting to implement that capability

[paujar]

So it's a dead end with ARK GPS RTK (that only has debug port for that and it's no longterm solution).

Also I don't have that level expertise to try and fix this; but I vote this up 👍 Trying to figure out this on conceptual level

[AlexKlimaj]

@paujar The ARK RTK GPS has UART2 exposed from the F9P. SPARTN could be injected directly there. Or there is no reason preventing it from being transmitted over CAN and injected through the MCU over UART1.