View Single Post
  #4   Report Post  
Terry Spragg
 
Posts: n/a
Default how to read AIS data from encapsulated NMEA VDO sentence

Pascal wrote:

See this site:

http://www.navicon.dk/web/normal.php?pageid=95







escreveu:


Hi all, I am a navigation software developer from Italy.

I need to understand how to read AIS data inside the "blob" contained
in VDO NMEA sentece. I have the ITU-R M.1371-1 document that should let
me understand such format. Unfortunately I really cannot understand how
to read the bits.

Someone, some times ago, posted such message:


The AIS sentences are in a strange format, encapsulated 6 bits. One
example he


'!AIVDO,1,1,,,13:r`R5P1orpG60JeHgRSj4l0000,0* 56
' 0 1 2 34 5 6
'1 Total number of sentences needed to transfer the message, 1 to 9
'2 Message sentence number, 1 to 9
'3 Sequential message identifier, 0 to 9
'4 AIS channel number
'5 Encapsulateled 6-bit radio message
'6 Number of fill-bits, 0 to 5


'14eG=ch021rp4FTJdTGRRR0605q4


'VDO.Identifier : 1 000001
'Repeat indicator : 0 00
'MMSI : 316001711 010010110101011100110110101111
'VDO1.NavStatus : 0 0000
'VDO1.ROT : 0 00000000
'VDO1.SOG : 12.9 kns 0010000001
'VDO1.PosAcc : 1 1
'VDO1.Latitude : 46º 39.3182'N 1101011100000010001011010010
'VDO1.Longitude : 71º 38.2703'W
0011010101100100100010111100010100010100
'VDO1.COG : 065º 010000000000
'VDO1.Heading : 064º 110000000
'VDO1.TimeStamp : 3 sec. 000101
'VDO1.NavStatus : 0 1
'VDO1.CommStatus : 15:17 h 11001000100


I really cannot understand how he found such information inside
14eG=ch021rp4FTJdTGRRR0605q4. Please Help

Ciao
Cristiano



Disassembling message protocols is tedious by hand. Automated
equipment does it with logic circuitry, which accomplishes tedious
tasks easily and knows the secret code.

We humans must parse manually.

The data is actually send as a bitstream and the protocol for every
device is proprietary.

The data presented above is actually encoded as hexadecimal or
ascii encode binary characters, so it actually looks more like
11110110010110101010101010101101100110011010101010 1010111010101...,
etc. These bits are sent as analogue levels, data encoded in one
long serial string. 100 character might be 800 bits, or 1600 bits,
in number base 10 notation. It might use another numerical base,
likely octal or hexadecimal.

The ports have their own protocols, and take each byte of 7 or 8
bits (as one example, I am not certain what this one actually uses,
perhaps 16 bit bytes) as a character. Each group of bits represents
one character in the string given above. The alphabet used by the
system may have many more than the 26 in our human alphabet, and
some of those characters are specific to the device in use. The
spacing and syntax is combined with error correcting parity (even -
odd) codes and checksum numbers which must also be decoded in logic
if you are writing an interface. Each receiving device must be up to
date with whatever protocol is used by all of the transmitters if it
is not to become discombobulated and confused, losing track of
character boundaries, etc, and those protocols seem to change with
each new generation of devices.

Different portions of the data string may use different schemes, ie,
the first 6 bits might be all ones, as a preamble and sync. The
next 4 bits might be a code to identify the remainder as a specific
type of statement, ie, sender I.D. Sometimes the info is bitsliced,
so that each bit represents a switch setting in the receiving parser
to cause it to understand that it is radar, weather, whatever.

I once independantly decoded the data sent by telco in it's caller
id string, sent between the ring tones to your phone. There are
padding bits, a preamble, and then each character is sent twice. It
was painful for a while, as I had to scope out the data without
benefit of knowing the protocol, even as simple as it was, using a
capture buffer to read each character out in ascii values, a sofware
protocol analyzer I wrote myself, which spit out gibberish ascii
codes until I learned to read it. If it had not been straight ascii,
normal in telephone modems, I would still be propping up my eyelids
with toothpicks.

You seem to have a protocol guide or data map, which you must now
come to know imtimately. Reverse engineering software data is fun
for some masochists, for a while.

400 page logic diagrams is where I cut my teeth, back in the 60's.
It's one way to burn out your brain so far as computers is
concerned. I got fed up with them, and retired years ago. Wouldn't
touch it, now, without cash up front and a clearly defined mission
statement engraved in titanium.

Good luck.

Terry K -SofDevCo-