{"id":1224,"date":"2016-04-13T19:40:47","date_gmt":"2016-04-13T19:40:47","guid":{"rendered":"\/?post_type=ht_kb&p=1224"},"modified":"2018-03-10T20:43:59","modified_gmt":"2018-03-10T20:43:59","slug":"using-the-universal-decoder","status":"publish","type":"ht_kb","link":"https:\/\/www.use-snip.com\/kb\/knowledge-base\/using-the-universal-decoder\/","title":{"rendered":"Using the Universal Decoder"},"content":{"rendered":"

The Universal Decoder provides a textual summary to the console of the message contents seen in a selected stream.<\/p>\n

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.\u00a0\u00a0\u00a0 If the stream is being parsed for RTCM3, it will report only<\/span> the RTCM3 content by message type<\/a>.\u00a0 If the stream is not parsed, it will detect and report other message types as well as any RTCM3 content.\u00a0 Its most frequent use is to confirm the presence or the absence of a given message type in the stream.<\/p>\n

It is enabled and disabled in each stream by right-clicking on the stream table display and selecting the “Show Message Types<\/strong>” menu item.\u00a0 A check box appears next to the menu item when that stream is being decoded.<\/p>\n

Hint<\/strong><\/span>: 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<\/a> or by mountPt name<\/a> to control this if you are decoding more than one stream at a time.\u00a0 This prevents cluttering the console log display.<\/p>\n

Overview<\/h4>\n

\"UniDecoder\"<\/a>The Universal Decoder is invoked when the menu item “Show Message Types<\/strong><\/em>” is checked and when RTCM3 parsing (the menu item “Parse<\/strong><\/em>“) is UN-checked.\u00a0 If RTCM3 parsing is enabled, a strict RTCM parser reports (only) on what RTCM3 content is found.<\/p>\n

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.<\/p>\n

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.<\/p>\n

The Universal Decoder considers each new read as a blob of data to be detected with limited fragmentary data from the prior read event.\u00a0 The design is based on a two layer decoder design for opportunistic decoding.\u00a0 As a stream of data is fed to it, the outer layer detects various well known patterns for each of the support message types.\u00a0 These consist of framing details such as start and stop patterns and various word counts and check-sums.\u00a0 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]<\/p>\n

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.\u00a0 For most stream types some rudimentary visual highlighting of the binary type message content is also provided.\u00a0 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.<\/p>\n

Note<\/strong><\/span>: A few words about message byte counts.\u00a0 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.\u00a0 In the highlighted messages displayed below, we display the entire<\/em> message size, adding whatever constant is required.\u00a0 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.<\/p>\n

Mixed Content Decoding<\/h4>\n

With each new load of data, the initial report of detected types is given for all<\/span> the types, and then the contents of each stream type that were successfully decoded are reported on in a group.\u00a0 This allows reading messages with a common theme in order.\u00a0 If a detected type is not reported on, it was either incomplete or did not pass further validation testing.\u00a0 The overall pattern is as follows:<\/p>\n

[TEST<\/strong><\/span>]:\u00a0\u00a0On Port COMxx, MountPt TEST has sent XXX<\/span> Bytes [#Sxx]. A summary decoding follows.[TEST]:\r\n   Detected the potential presence of TYPEA<\/strong><\/span> msg content\r\n   Detected the potential presence of TYPEB<\/strong><\/span> msg content\r\n   Detected the potential presence of TYPEC<\/strong><\/span> msg content\r\n\r\n[TEST]<\/strong><\/span>:\u00a0\u00a0\u00a0\u00a0\u00a0 TYPEA<\/strong><\/span> msgs, found:\r\n   A decoded message of type TYPEA <\/strong><\/span>with various details highlighted.\r\n   A decoded message of type TYPEA <\/strong><\/span>with various details highlighted.\r\n\r\n[TEST]<\/strong><\/span>:\u00a0\u00a0\u00a0\u00a0\u00a0 TYPEB<\/strong><\/span> msgs, found:\r\n   A decoded message of type TYPEB <\/strong><\/span>with various details highlighted.\r\n   A decoded message of type TYPEB <\/strong><\/span>with various details highlighted.\r\n\r\netc.<\/pre>\n
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.\u00a0 We now consider several of the content types which the Universal Decoder can detect and process at this time.<\/p>\n
RTCM3 Messages<\/h4>\n
As mentioned above, when decoding RTCM3 messages the Universal Decoder provides only a summary of the presence of the message types, as shown below.\u00a0 Please use the RTCM3 Decoder<\/a> dialog to decode these messages completely as the various examples in that article show.<\/p>\n
[foobar<\/strong><\/span>]:\u00a0\u00a0MountPt foobar<\/strong> [R003], 3 RTCM3 messages decoded, of 21,751 so far.\r\n[foobar<\/strong><\/span>]:\u00a0\u00a0\u00a0\u00a0\u00a0RTCM3 Type 1117<\/strong>\u00a0(028 bytes), the 5,306th message of this type found so far.\r\n[foobar<\/strong><\/span>]:\u00a0\u00a0\u00a0\u00a0\u00a0RTCM3 Type 1010<\/strong>\u00a0(113 bytes), the 5,306th message of this type found so far.\r\n[foobar<\/strong><\/span>]:\u00a0\u00a0\u00a0\u00a0\u00a0RTCM3 Type 1002<\/strong>\u00a0(153 bytes), the 5,306th message of this type found so far.\r\n[foobar<\/strong><\/span>]:\u00a0\u00a0--<\/pre>\n
See also<\/strong><\/span>: These lists of RTCM3 messages: The cheat sheet<\/a> and the full list<\/a> of messages.<\/p>\n
RTCM2 Messages<\/h4>\n
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.\u00a0 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:<\/p>\n
[AB49_RTCM<\/span><\/b>]:\u00a0\u00a0MountPt AB49_RTCM<\/b> [R005], 1 RTCM2 messages decoded, of 606 so far.
\n[AB49_RTCM<\/span><\/b>]:\u00a0\u00a0\u00a0\u00a0\u00a0RTCM2 Type 18<\/b>\u00a0 (105 bytes at z=2490.6 s=3), the 296th message of this type found so far.
\n[AB49_RTCM<\/span><\/b>]:\u00a0\u00a0—
\n[AB49_RTCM<\/span><\/b>]:\u00a0\u00a0MountPt AB49_RTCM<\/b> [R005], 8 RTCM2 messages decoded, of 614 so far.
\n[AB49_RTCM<\/span><\/b>]:\u00a0\u00a0\u00a0\u00a0\u00a0RTCM2 Type 18<\/b>\u00a0 (105 bytes at z=2490.6 s=4), the 297th message of this type found so far.
\n[AB49_RTCM<\/span><\/b>]:\u00a0\u00a0\u00a0\u00a0\u00a0RTCM2 Type 18<\/b>\u00a0 (095 bytes at z=2472.6 s=5), the 298th message of this type found so far.
\n[AB49_RTCM<\/span><\/b>]:\u00a0\u00a0\u00a0\u00a0\u00a0RTCM2 Type 18<\/b>\u00a0 (095 bytes at z=2472.6 s=6), the 299th message of this type found so far.
\n[AB49_RTCM<\/span><\/b>]:\u00a0\u00a0\u00a0\u00a0\u00a0RTCM2 Type 19<\/b>\u00a0 (105 bytes at z=2490.6 s=7), the 298th message of this type found so far.
\n[AB49_RTCM<\/span><\/b>]:\u00a0\u00a0\u00a0\u00a0\u00a0RTCM2 Type 19<\/b>\u00a0 (105 bytes at z=2490.6 s=0), the 299th message of this type found so far.
\n[AB49_RTCM<\/span><\/b>]:\u00a0\u00a0\u00a0\u00a0\u00a0RTCM2 Type 19<\/b>\u00a0 (095 bytes at z=2472.6 s=1), the 300th message of this type found so far.
\n[AB49_RTCM<\/span><\/b>]:\u00a0\u00a0\u00a0\u00a0\u00a0RTCM2 Type 19<\/b>\u00a0 (095 bytes at z=2472.6 s=2), the 301st message of this type found so far.
\n[AB49_RTCM<\/span><\/b>]:\u00a0\u00a0\u00a0\u00a0\u00a0RTCM2 Type 24<\/b>\u00a0 (040 bytes at z=2490.6 s=3), the 6th message of this type found so far.<\/span><\/p>\n
See also<\/strong><\/span>:\u00a0 The full list<\/a> of RTCM2 messages.<\/p>\n
NMEA-183 Messages<\/h4>\n
When decoding NMEA-183 style messages (called sentences<\/em> 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.<\/p>\n
[TEST<\/strong><\/span>]:\u00a0 Detected the potential presence of NMEA-183 msg<\/strong> content\r\n[TEST<\/strong><\/span>]:\u00a0 NMEA-183 msgs, found:\r\n   $GPRMC<\/span>,204016.00,A,3407.66310,N,11749.52703,W,0.012,,010616,,,A*6B\r\n   $GPVTG<\/span>,,T,,M,0.012,N,0.022,K,A*20\r\n   $GPGGA<\/span>,204016.00,3407.66310,N,11749.52703,W,1,11,0.77,282.1,M,-32.2,M,,*63\r\n   $GPGSA<\/span>,A,3,28,01,17,30,19,24,07,11,13,15,06,,1.33,0.77,1.08*0D\r\n   $GPGLL,<\/span>3407.66310,N,11749.52703,W,204016.00,A,A*71\r\n   $GPZDA<\/span>,204016.00,01,06,2016,00,00*65<\/pre>\n
As a general rule of thumb, you do not want to have NMEA content interspersed with your stream.\u00a0 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<\/strong><\/span> Caster.\u00a0 Links to 3rd party NMEA content decoders are at the bottom of this page.<\/p>\n
uBlox Messages<\/h4>\n
When decoding uBlox style messages (revisions 4,5,6,7,8 are supported) the Universal Decoder displays each binary message on its own line.\u00a0 It begins by highlighting the major type, underlining the sub-type, placing the remaining byte count in parentheses,\u00a0 and then presenting the core message in a bracketed bold font, followed by the check sum.\u00a0 An example of some setup status messages follows (aside: raw observable messages are quite long to display).<\/p>\n
[TEST<\/strong><\/span>]:\u00a0 Detected the potential presence of uBlox msg<\/strong> content\r\n[TEST<\/strong><\/span>]:\u00a0 uBlox msgs, found:\r\n\u00a0\u00a0 TIM<\/strong><\/span>B562-0103-1000(24)-[D0D9E21303DD00009DAD00002E480D00<\/strong>] *5F67\r\n \u00a0 TIM<\/strong><\/span>B562-0101-1400(28)-[D0D9E213EB624BF1CC7423E4DE913515AA000000<\/strong>] *E752\r\n \u00a0 TIM<\/strong><\/span>B562-0102-1C00(36)-[D0D9E2135843C5B9FE7957141FD00300D04D04001204000045050000<\/strong>] *2B0D\r\n \u00a0 TIM<\/strong><\/span>B562-0104-1200(26)-[D0D9E2139300840040006C004C0038003300<\/strong>] *2F40\r\n \u00a0 TIM<\/strong><\/span>B562-0111-1400(28)-[D0D9E2130100000001000000FFFFFFFF02000000<\/strong>] *C4E3\r\n \u00a0 TIM<\/strong><\/span>B562-0112-2400(44)-[D0D9E213FFFFFFFF0000000002000000020000000100000000000000020000002EFA0601<\/strong>] *0751\r\n \u00a0 TIM<\/strong><\/span>B562-0120-1000(24)-[D0D9E213AAF506006B07110703000000<\/strong>] *0177\r\n \u00a0 TIM<\/strong><\/span>B562-0121-1400(28)-[D0D9E21303000000AAF50600E007060114281107<\/strong>] *BE7F\r\n<\/pre>\n
Hemisphere Messages<\/h4>\n
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.<\/p>\n
[Hemi<\/strong><\/span>]:\u00a0 Detected the potential presence of Hemisphere msg<\/strong> content\r\n[Hemi<\/strong><\/span>]:\u00a0 Hemisphere msgs, found:\r\n    Bin96<\/span><\/strong> (312B) 0x[00006B07060 - Msg Cut for Example - 0000000000000000]*8560<\/pre>\n
Hemisphere\u00a0 is another GNSS device which can coexist with other message types. See the remark regarding NMEA-183 content in such streams.<\/p>\n
Other message types<\/h4>\n
The abilities of the Universal Decoder are frequently expanded as new patterns are required.<\/p>\n
Text and Hex Data<\/h4>\n
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<\/strong><\/em> menu command (located right below the Show Message Types<\/strong><\/em> command) may be used.<\/p>\n
 <\/p>\n
Decoding NMEA-183<\/h4>\n
As a rule SNIP<\/strong><\/span> streams are not in the NMEA-183 format.\u00a0 Typically this sort of message content is considered clutter which SNIP<\/strong><\/span> will remove when parsing so you are not wasting bandwidth sending it to the NTRIP Clients.\u00a0 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<\/strong><\/span>‘s built-in map display<\/a> functions.\u00a0\u00a0 And for the most part, these are human-readable strings.\u00a0\u00a0 But it can be helpful to have a tool to decode them for you.\u00a0 Here are two web based tools that can decode NMEA-183 sentences.\u00a0 Simply paste the string you want translated into one of these pages.<\/p>\n
http:\/\/freenmea.net\/decoder\u00a0\u00a0\u00a0 <\/a>and\u00a0\u00a0\u00a0\u00a0 https:\/\/rl.se\/gprmc<\/a><\/p>\n
 <\/p>\n
 <\/p>\n
See also the article about SNIP\u2019<\/strong><\/span>s\u00a0 RTCM3 Decoder<\/a> dialog used to provide detailed decoding of RTCM3 contents.<\/p>\n","protected":false},"excerpt":{"rendered":"
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, […]<\/p>\n","protected":false},"author":13,"comment_status":"open","ping_status":"closed","template":"","format":"standard","meta":{"_exactmetrics_skip_tracking":false,"_exactmetrics_sitenote_active":false,"_exactmetrics_sitenote_note":"","_exactmetrics_sitenote_category":0,"footnotes":""},"ht-kb-category":[112,341],"ht-kb-tag":[295,308,241,307],"class_list":["post-1224","ht_kb","type-ht_kb","status-publish","format-standard","hentry","ht_kb_category-general","ht_kb_category-message-decoding","ht_kb_tag-decoder","ht_kb_tag-message-decode","ht_kb_tag-nmea","ht_kb_tag-rtcm"],"_links":{"self":[{"href":"https:\/\/www.use-snip.com\/kb\/wp-json\/wp\/v2\/ht-kb\/1224","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.use-snip.com\/kb\/wp-json\/wp\/v2\/ht-kb"}],"about":[{"href":"https:\/\/www.use-snip.com\/kb\/wp-json\/wp\/v2\/types\/ht_kb"}],"author":[{"embeddable":true,"href":"https:\/\/www.use-snip.com\/kb\/wp-json\/wp\/v2\/users\/13"}],"replies":[{"embeddable":true,"href":"https:\/\/www.use-snip.com\/kb\/wp-json\/wp\/v2\/comments?post=1224"}],"version-history":[{"count":41,"href":"https:\/\/www.use-snip.com\/kb\/wp-json\/wp\/v2\/ht-kb\/1224\/revisions"}],"predecessor-version":[{"id":5086,"href":"https:\/\/www.use-snip.com\/kb\/wp-json\/wp\/v2\/ht-kb\/1224\/revisions\/5086"}],"wp:attachment":[{"href":"https:\/\/www.use-snip.com\/kb\/wp-json\/wp\/v2\/media?parent=1224"}],"wp:term":[{"taxonomy":"ht_kb_category","embeddable":true,"href":"https:\/\/www.use-snip.com\/kb\/wp-json\/wp\/v2\/ht-kb-category?post=1224"},{"taxonomy":"ht_kb_tag","embeddable":true,"href":"https:\/\/www.use-snip.com\/kb\/wp-json\/wp\/v2\/ht-kb-tag?post=1224"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}