Mixed data types with uBlox

Many people use RTKLIB and its STRSVR program to convert uBlox into RTCM 3.x message types before sending them to SNIP for distribution. This data can then be used by any devices that consumes RTCM 3.x data, although it contains only L1 observations.

Others prefer to send the raw uBlox observable in the vendor’s native formats (the RXM message and other messages) to to SNIP for distribution.   Often these users have a copy of RTKLIB or one of the open source or commercial derivative products at the rover end to decode the data.

SNIP supports both ways.  The key issue is to send one or the other (depending on what your rovers expect), and to remove the various extra NMEA-183 strings that may be present.  [You can of course send each in its own stream, but in any event, remove the NMEA content]

Sending Raw uBlox

This would be an example of a stream that would not be parsed.  The auto-parse ability in SNIP will examine the stream and determine it consist of raw uBlox messages, then disable further parsing.  Here is a console fragment showing this

[uBlox6T]:   Parsing for this stream is: ENABLED
[uBlox6T]:   Analysis of Stream Format and Contents started... [uBlox]
[uBlox6T]:   Parsing for this stream is: DISABLED
[uBlox6T]:       Stream analysis completed... Unknown format, parsing is Disabled.   [Detected uBlox, Decoded: uBlox]

Sending uBlox as RTCM 3.x

There are several tools available that can convert raw uBlox messages to RTCM 3.x  (including the STRSVR program in RTKLIB).  The raw data stream is connected to one of these, and the output is then connected to SNIP using any of the supported stream types.   This would be an example of a stream that would be parsed. The auto-parse ability in SNIP will examine the stream and determine that it consists of RTCM 3.x content.   Here is a console fragment showing this:

[uBlox6T]:   Parsing for this stream is: ENABLED
[uBlox6T]:       Stream analysis completed... Parsing is Enabled.   [Detected RTCM3, Decoded: RTCM3]

Sending Raw uBlox and NMEA

This would be an example of a stream that would not be parsed.  It is also one where the setup and control of the uBlox chip set is less than ideal.  You can create this for uBlox 6T chip using this serial setup command file: /serialPortSetups/uBlox6T/uBlox6T_Uart1_Send_RAW_SFRB_andNMEA.txt if you desire.  The file: /serialPortSetups/uBlox6T/uBlox6T_Uart1_Send_justRAW.txt  is more typically used to send just raw observational data.]

[uBlox6T]:   Parsing for this stream is: ENABLED
[uBlox6T]:   Analysis of Stream Format and Contents started... [uBlox]
[uBlox6T]:   Parsing for this stream is: DISABLED
[uBlox6T]:       Stream analysis completed... Unknown format, parsing is Disabled.   [Detected NMEA, uBlox, Decoded: NMEA, uBlox]

Detection vs Decoding

The universal decoder is used during the analysis stage for a data stream.  It is a two part decoder.  It first ‘detects’ that message might be present by looking for starting and ending framing details.  If a message family is detected it then tries to ‘decode’ the message by applying more logic to ensure the message is well formed and not random bits and bytes in the stream.  And this often involves a message framing process as well.  This is why you see some messages that may be detected but not decoded.

Best Practices:

Regardless of which type of data you wish to send…

  1. Set your data type to be the content you want from the uBlox device (or any other GNSS device)
  2. And remove other content to avoid bloating the channel
  3. Confirm this is really what is being send using both the universal decoder and the RTCM decoder abilities of SNIP.
  4. Finally, be sure sure to turn the decoder’s per-message display features off when you are done with them.  They clutter up the console display quickly making it unreadable. [The clear console button is also useful here]

 

Was this article helpful?

Related Articles