dotMorten
Add support for encapsulation sentences.
I want to add AIS support, but their messages start with !. Is there any way to implement it?
This is the first I hear of messages starting with !. Re-reading the spec I did find it described (included further down for future reference).
This wasn't something the API was currently designed for, and it'll be some work to incorporate. Do you have some example of some NMEA data that includes this, that can be used for testing such an implementation?
5.2.1 Address Field
An address field is the first field in a sentence and follows the "$" or "!" delimiter, it serves to define the sentence. The "$" delimiter identifies sentences that conform to the conventional parametric and delimited field composition rules found in Section 5.3.3. The "!" delimiter identifies sentences that conform to the special-purpose encapsulation and non-delimited field composition rules found in Section 5.3.4. ...
5.3.4 Encapsulation Sentences
These sentences start with the "!" (HEX 21) delimiter. The function of this special-purpose sentence structure is to provide a means to convey information, when the specific data content is unknown or greater information bandwidth is needed. This is similar to a modem that transfers information without knowing how the information is to be decoded or interpreted.
The basic rules for encapsulation sentence structures are:
- The sentence begins with the "!" delimiter.
- Only approved sentence formatters shall be allowed. Formatters used by conventional parametric sentences cannot be reused. See Section 8.1
- Only valid characters shall be allowed. See Section 6.1, 6.1.2 (Table 4 and Table 5).
- Only approved field types shall allowed. See Section 6.2 (Table 8, Table 9, Table 10).
- Only Six bit coding may be used to create encapsulated data fields. See Section 6.2.4. Encapsulated data fields may consist of any number of parameters, and their content is not identified or described by this standard
- The sentence must be defined with one encapsulated data field and any number of parametric data fields separated by the "," data field delimiter. The encapsulated data field shall always be the second to last data field in the sentence, not counting the checksum field. See Section 5.2.2.
- The sentence contains a "Total Number Of Sentences" field. See Section 5.3.3.1.
- The sentence contains a "Sentence Number" field. See Section 5.3.4.1.
- The sentence contains a "Sequential Message Identifier" field. See Section 5.3.4.1.
- The sentence contains a "Fill Bits" field immediately following the encapsulated data field. The Fill Bits field shall always be the last data field in the sentence, not counting the checksum field. See Section 5.3.4.1.
Note:
This method to convey information is to be used only when absolutely necessary, and will only be considered when one or both of two conditions are true, and when there is no alternative.
Condition 1: The data parameters are unknown by devices having to convey the information. For example: the ABM and BBM sentences meet this condition, because the content is not known to the Automatic Identification System (AIS) transponder. Condition 2: When information requires a significantly higher data rate than can be achieved by the NMEA 0183 (4,800 baud) and NMEA 0183-HS (38,400 baud) standards utilizing parametric sentences.
By encapsulating a large amount of information, the number of overhead characters, such as "," field delimiters can be reduced, resulting in higher data transfer rates. It is very unusual for this second condition to be fulfilled. As an example, a AIS transponder has a data rate capability of 4,500 messages per minute, and satisfies this condition, resulting in the VDM and VDO sentences.
5.3.4.1 Approved Encapsulation Sentence Structure
The approved encapsulation sentence structure is shown below. A description of each character or character group is provided in Table 3.
!ccccc,x1,x2,x3,c -- c,x4*hh<CR><LF>Table 3 - Encapsulation Sentence Elements
| ASCII | HEX | Description |
|---|---|---|
! |
21 | Start of Sentence. |
ccccc |
2C | Address Field. Alphanumeric characters identifying type of TALKER, and Sentence Formatter. The first two characters identify the TALKER. The last three are the Sentence Formatter mnemonic code identifying the data type and the string format of the successive fields. Mnemonics will be used as far as possible to facilitate readouts by users. |
, |
Field delimiter. Starts each field except address and checksum fields. If it is followed by a null field, it is all that remains to indicate no data in a field. | |
x1 |
Total Number Of Sentences field. Encapsulated information often requires more than one sentence. This field represents the total number of encapsulated sentences needed. This may be fixed or variable length, and is defined by the sentence definitions in Section 8.2. and 9.2. | |
x2 |
Sentence Number field. Encapsulated information often requires more than one sentence. This field identifies which sentence of the total number of sentences this is. This may be fixed or variable length, and is defined by the sentence definitions in Section 8.2. and 9.2 | |
x3 |
Sequential Message Identifier field. This field distinguishes one encapsulated message consisting of one or more sentences, from another encapsulated message This field is incremented each time an encapsulated message is generated with the same formatter as a previously encapsulated message. The value is reset to zero when it is incremented beyond the defined maximum value. The maximum value and size of this field is determined by the applicable sentence definitions in Section 8.2 .. and 9.2. | |
c -- c |
Data Sentence block. Follows sequential message identifier field and is a series of data fields consisting of one or more parametric data fields and one encapsulated data field. Data field sequence is fixed and identified by 3rd and subsequent characters of the address field (the "Sentence Formatter"). Individual data fields may be of variable length and are preceded by delimiters ",". The encapsulated data field shall always be the second to last data field in the sentence. | |
x4 |
Fill Bits field. This field represents the number of fill bits added to complete the last Six bit coded character. This field is required and shall immediately follow the encapsulated data field. To encapsulate, the number of binary bits must be a multiple of six. If it is not, one to five Fill Bits are added. This field shall be set to zero when no Fill Bits have been added. The Fill Bits field shall always be the last data field in the sentence. This shall not be a null field. | |
* |
2A | Checksum Delimiter. Follows last data field of the sentence. It indicates that the following two alphanumeric characters show the HEX value of the Checksum. |
hh |
Checksum Field. The absolute value calculated by exclusive-OR'ing the 8 data bits (no start bits or stop bits) of each character in the Sentence, between, but excluding "!" and "*". The hexadecimal value of the most significant and least significant 4 bits of the result are converted to two ASCII characters (0-9, A-F (upper case)) for transmission. The most significant character is transmitted first. The Checksum field is required in all transmitted sentences. | |
<CR><LR> |
Terminates Sentence. |
I need support for messages from an AIS receiver. The format description is, for example, here https://gpsd.gitlab.io/gpsd/AIVDM.html. An example of a stream from my receiver:
!AIVDM,1,1,,A,144e<20P00R:Jg0R@kQkTgv625BT,0*48
$GPRMC,104104.00,A,5957.77213,N,03014.52169,E,0.013,0.00,300425,,,A*6D
$GPRMC,104105.00,A,5957.77214,N,03014.52172,E,0.012,0.00,300425,,,A*60
!AIVDM,1,1,,A,144fKwPP022:I1`RB1@79r4605BT,0*53
$GPRMC,104106.00,A,5957.77215,N,03014.52174,E,0.013,0.00,300425,,,A*65
!AIVDO,1,1,,B,B44fV20000RVwP8TvOT000010<00,0*78
!AIVDO,1,1,,A,C44fV20000RVwP8TvOT00000LNd:HH20000000000000B0P0PQ20,0*38
!AIVDM,1,1,,A,144N:`0P002:LE8RB4N>4?v<20Ri,0*76
!AIVDM,1,1,,B,H44StlU365340di0000000204310,0*4D
$GPRMC,104107.00,A,5957.77216,N,03014.52175,E,0.004,0.00,300425,,,A*60
$GPRMC,104108.00,A,5957.77216,N,03014.52176,E,0.013,0.00,300425,,,A*6A
$GPVTG,0.00,T,,M,0.013,N,0.025,K,A*38
$GPGGA,104108.00,5957.77216,N,03014.52176,E,1,11,0.74,11.1,M,15.9,M,,*65
$GPGSA,A,3,05,26,18,23,13,16,27,29,10,15,07,,1.51,0.74,1.31*07
!AIVDM,1,1,,A,144VHcg000R:HNNRAuuWKnh>25BT,0*3B
$GPRMC,104109.00,A,5957.77217,N,03014.52178,E,0.019,0.00,300425,,,A*6E
!AIVDM,1,1,,B,144d3;`P?w<tSF0l4Q@>4?wp0W3h,0*2A
!AIVDM,1,1,,B,144alwP0?w<tSF0l4Q@>42kp2h5e,0*4B
!AIVDM,2,1,8,B,544d3;P0004D0000000lu<eH6oGL0000000000150000000Ht31mC1`3,0*7B
!AIVDM,2,2,8,B,i`1RCS0CQ000008,2*4F
$GPRMC,104110.00,A,5957.77217,N,03014.52178,E,0.018,0.00,300425,,,A*67
At a minimum, I don't need full support for AIS messages. It would be enough if I could add them using the NmeaMessage.RegisterNmeaMessage(typeof(AISMessage).GetTypeInfo()); function.
Thanks. I’ll be honest this will be significant work and not something I can commit to doing right now.