The Universal Decoder provides a textual summary to the console of the message contents seen in a selected stream.
It can be used to detect and decode various message protocols and types mixed together in a single data stream including types such as RTCM3, RTCM2, NMEA-183, uBlox Raw, Hemisphere raw, etc. If the stream is being parsed for RTCM3, it will report only the RTCM3 content by message type. If the stream is not parsed, it will detect and report other message types as well as any RTCM3 content. Its most frequent use is to confirm the presence or the absence of a given message type in the stream.
It is enabled and disabled in each stream by right-clicking on the stream table display and selecting the “Show Message Types” menu item. A check box appears next to the menu item when that stream is being decoded.
Hint: While you can enable this for multiple streams at once, it is more typically used on only one stream at a time in the context of analysis or in debugging. Use the filter controls to enable or disable given streams by either type or by mountPt name to control this if you are decoding more than one stream at a time. This prevents cluttering the console log display.
Overview
The Universal Decoder is invoked when the menu item “Show Message Types” is checked and when RTCM3 parsing (the menu item “Parse“) is UN-checked. If RTCM3 parsing is enabled, a strict RTCM parser reports (only) on what RTCM3 content is found.
This is controlled by the settings of two menu items noted by arrows seen in the console display shown at right. These menu items are shown, as well as the two variations in the console log that some RTCM3 content has produced.
The upper set of listings were produced using the Universal Decoder, while the lower set used the RTCM3 Decoder to produce definitive message types and counts of messages.
The Universal Decoder considers each new read as a blob of data to be detected with limited fragmentary data from the prior read event. The design is based on a two layer decoder design for opportunistic decoding. As a stream of data is fed to it, the outer layer detects various well known patterns for each of the support message types. These consist of framing details such as start and stop patterns and various word counts and check-sums. At this level the possibility of a well formed message is established and reported on. [Note the phrase used–the “potential presence” of message content]
Once a given message pattern type has been potentially detected, further analysis can then be performed on the stream to determine more about the potential messages. For most stream types some rudimentary visual highlighting of the binary type message content is also provided. The purpose of this is not to replace specialty tools for each protocol, but to allow the user to quickly determine what content is really present.
Note: A few words about message byte counts. Most messages have an element that describes how many bytes remain in the message measured from the point at which it appears, rather than the entire message size. In the highlighted messages displayed below, we display the entire message size, adding whatever constant is required. For example, in a uBlox message the word count value has 8 bytes added to it, while in a Hemisphere message 12 bytes are added.
Mixed Content Decoding
With each new load of data, the initial report of detected types is given for all the types, and then the contents of each stream type that were successfully decoded are reported on in a group. This allows reading messages with a common theme in order. If a detected type is not reported on, it was either incomplete or did not pass further validation testing. The overall pattern is as follows:
[TEST]: On Port COMxx, MountPt TEST has sent XXX Bytes [#Sxx]. A summary decoding follows.[TEST]: Detected the potential presence of TYPEA msg content Detected the potential presence of TYPEB msg content Detected the potential presence of TYPEC msg content [TEST]: TYPEA msgs, found: A decoded message of type TYPEA with various details highlighted. A decoded message of type TYPEA with various details highlighted. [TEST]: TYPEB msgs, found: A decoded message of type TYPEB with various details highlighted. A decoded message of type TYPEB with various details highlighted. etc.
The Universal Decoder is always in this mode of operation, but when only one type of protocol is present in the stream, this is not evident. We now consider several of the content types which the Universal Decoder can detect and process at this time.
RTCM3 Messages
As mentioned above, when decoding RTCM3 messages the Universal Decoder provides only a summary of the presence of the message types, as shown below. Please use the RTCM3 Decoder dialog to decode these messages completely as the various examples in that article show.
[foobar]: MountPt foobar [R003], 3 RTCM3 messages decoded, of 21,751 so far. [foobar]: RTCM3 Type 1117 (028 bytes), the 5,306th message of this type found so far. [foobar]: RTCM3 Type 1010 (113 bytes), the 5,306th message of this type found so far. [foobar]: RTCM3 Type 1002 (153 bytes), the 5,306th message of this type found so far. [foobar]: --
See also: These lists of RTCM3 messages: The cheat sheet and the full list of messages.
RTCM2 Messages
As mentioned above, when decoding RTCM2 messages the Universal Decoder provides a basic level of message decoding. The current z-count (time) is also noted. Other tools, still in development at this time, will display these messages in a table view similar to how RTCM3 content is treated. The current decoder pattern served to see what the content contains and is as follows:
[AB49_RTCM]: MountPt AB49_RTCM [R005], 1 RTCM2 messages decoded, of 606 so far.
[AB49_RTCM]: RTCM2 Type 18 (105 bytes at z=2490.6 s=3), the 296th message of this type found so far.
[AB49_RTCM]: —
[AB49_RTCM]: MountPt AB49_RTCM [R005], 8 RTCM2 messages decoded, of 614 so far.
[AB49_RTCM]: RTCM2 Type 18 (105 bytes at z=2490.6 s=4), the 297th message of this type found so far.
[AB49_RTCM]: RTCM2 Type 18 (095 bytes at z=2472.6 s=5), the 298th message of this type found so far.
[AB49_RTCM]: RTCM2 Type 18 (095 bytes at z=2472.6 s=6), the 299th message of this type found so far.
[AB49_RTCM]: RTCM2 Type 19 (105 bytes at z=2490.6 s=7), the 298th message of this type found so far.
[AB49_RTCM]: RTCM2 Type 19 (105 bytes at z=2490.6 s=0), the 299th message of this type found so far.
[AB49_RTCM]: RTCM2 Type 19 (095 bytes at z=2472.6 s=1), the 300th message of this type found so far.
[AB49_RTCM]: RTCM2 Type 19 (095 bytes at z=2472.6 s=2), the 301st message of this type found so far.
[AB49_RTCM]: RTCM2 Type 24 (040 bytes at z=2490.6 s=3), the 6th message of this type found so far.
See also: The full list of RTCM2 messages.
NMEA-183 Messages
When decoding NMEA-183 style messages (called sentences in that document) the Universal Decoder displays each sentence on its own line, highlighting the sentence type and suppressing the final end of line and line feed.
[TEST]: Detected the potential presence of NMEA-183 msg content [TEST]: NMEA-183 msgs, found: $GPRMC,204016.00,A,3407.66310,N,11749.52703,W,0.012,,010616,,,A*6B $GPVTG,,T,,M,0.012,N,0.022,K,A*20 $GPGGA,204016.00,3407.66310,N,11749.52703,W,1,11,0.77,282.1,M,-32.2,M,,*63 $GPGSA,A,3,28,01,17,30,19,24,07,11,13,15,06,,1.33,0.77,1.08*0D $GPGLL,3407.66310,N,11749.52703,W,204016.00,A,A*71 $GPZDA,204016.00,01,06,2016,00,00*65
As a general rule of thumb, you do not want to have NMEA content interspersed with your stream. It is very unlikely you will want to send this information to NTRIP Clients. The typical device setup is to include messages that suppress sending this sort of data to the SNIP Caster. Links to 3rd party NMEA content decoders are at the bottom of this page.
uBlox Messages
When decoding uBlox style messages (revisions 4,5,6,7,8 are supported) the Universal Decoder displays each binary message on its own line. It begins by highlighting the major type, underlining the sub-type, placing the remaining byte count in parentheses, and then presenting the core message in a bracketed bold font, followed by the check sum. An example of some setup status messages follows (aside: raw observable messages are quite long to display).
[TEST]: Detected the potential presence of uBlox msg content [TEST]: uBlox msgs, found: TIMB562-0103-1000(24)-[D0D9E21303DD00009DAD00002E480D00] *5F67 TIMB562-0101-1400(28)-[D0D9E213EB624BF1CC7423E4DE913515AA000000] *E752 TIMB562-0102-1C00(36)-[D0D9E2135843C5B9FE7957141FD00300D04D04001204000045050000] *2B0D TIMB562-0104-1200(26)-[D0D9E2139300840040006C004C0038003300] *2F40 TIMB562-0111-1400(28)-[D0D9E2130100000001000000FFFFFFFF02000000] *C4E3 TIMB562-0112-2400(44)-[D0D9E213FFFFFFFF0000000002000000020000000100000000000000020000002EFA0601] *0751 TIMB562-0120-1000(24)-[D0D9E213AAF506006B07110703000000] *0177 TIMB562-0121-1400(28)-[D0D9E21303000000AAF50600E007060114281107] *BE7F
Hemisphere Messages
When decoding Hemisphere (Crescent) style messages, two formats are followed depending on whether the message itself is textual or binary in nature. Each is presented in turn in the console. The textual messages are normally only seen during setup.
[Hemi]: Detected the potential presence of Hemisphere msg content [Hemi]: Hemisphere msgs, found: Bin96 (312B) 0x[00006B07060 - Msg Cut for Example - 0000000000000000]*8560
Hemisphere is another GNSS device which can coexist with other message types. See the remark regarding NMEA-183 content in such streams.
Other message types
The abilities of the Universal Decoder are frequently expanded as new patterns are required.
Text and Hex Data
The Universal Decoder does not process textual or binary content; rather, it seeks for message patterns in these types of streams. If there is a need to display the textual or the hexadecimal values of the raw stream, the Show Raw Data menu command (located right below the Show Message Types command) may be used.
Decoding NMEA-183
As a rule SNIP streams are not in the NMEA-183 format. Typically this sort of message content is considered clutter which SNIP will remove when parsing so you are not wasting bandwidth sending it to the NTRIP Clients. It does have some value with clients if you wish to plot the NMEA-183 data that an NTRIP Client sends to your Caster using one of SNIP‘s built-in map display functions. And for the most part, these are human-readable strings. But it can be helpful to have a tool to decode them for you. Here are two web based tools that can decode NMEA-183 sentences. Simply paste the string you want translated into one of these pages.
http://freenmea.net/decoder and https://rl.se/gprmc
See also the article about SNIP’s RTCM3 Decoder dialog used to provide detailed decoding of RTCM3 contents.