Twitter Follow Button

Monday, 24 June 2013

GW Shore Station MMSI Encoding

In my last post I described how ships using the GW data network encoded their MMSI in GW type 2/101 packets before sending a position report and how Alan W had managed to reverse engineer this. When I wrote that we didn't understand how GW shore stations told ships that they had traffic for them. Clearly the GW network has to be able to tell ships that it has traffic (a telegram or an email perhaps) for them without waiting for an hourly traffic list but how was this done.

 Myself and Alan Ws suspicion had always been that this was that this information was sent in type 5/41 packets sent by shore stations and which looked like this ..

18:18:40 GW Type=5 Count=0 Subtype=41 (10010100101001) (0x9d,0xfa,0xa8,0xb2,0x9b,0xf9)

packets with the same content would be sent for a minute or so then (presumably if there was no reply) a little latter and so. Attempts to decode the MMSI using the GW ship side encoding method resulted in the recovery of an invalid MMSI so it was clear a different encoding method was being used by the shore side.

 The solution to this problem was found once again by Alan W who had the idea that at least some of the time when a ship was told by the shore station that there was traffic for it , that the ship would send back its position and therefore its MMSI. That way we would have the MMSI and would he would be able to work out how it was encoded in the shore side 5/41 packet. Just a couple of days after he proposed using this method Alan W got back to me to say he had worked out how these MMSIs were being encoded.

 Basically its a modification of the ship side encoding method. As before 4 bit nibbles are used to represent numbers in the following way ..

0x0 = "7"
0x1 = "3"
0x2 = "5"
0x3 = "1" or alternate "9"
0x4 = "6"
0x5 = "2" 
0x6 = "4"
0x7 = "0" or alternate "8"
0x8 = "7" 
0x9 = "3"
0xa = "5"
0xb = "1" or alternate "9"
0xc = "6"
0xd = "2"
0xe = "4"
0xf = "0" or alternate "8"

 Notice how this is almost the same encoding map as used for the ship side encoding but the map has been "moved"  along by one digit.

Once again the best way of showing how this is done is with an example. So taking the six byte payload of the 5/41 packet above ..

9d fa a8 b2 9b f9

The hex nibbles are decoded from left to right two digits at a time. As with the ship side encoding the nibbles in each byte are reversed. So the first nibble represents the second number and the second nibble the first number. If the nibble to right of the one being decoded is less than 0x8 then the alternate numbering scheme is used. So from our example 0x9d becomes 23 then 0xfa 50 (so the MMSI so far is 2350) , 0xa8  is 75 (making the MMSI so far 235075) , 0xb2 59 (making the MMSI so far to be 23507559) then we have 0x9b now a MMSI is always 9 digits so has we already have 8 digits we only need to decode 0xb which is 1 making our full MMSI 235075591 which happens to be a vessel called the Kathy C . The final 3 digits which in this case are 330 are some kind of an alert or indicator to the ship telling it what kind of traffic the shore station has for it.

 Now with the latest builds of Rivet if you monitor a GW shore station and have the ships.xml file in the same folder (which can be downloaded from here ) then decoded 5/41 packets will look like this ..

18:18:40 GW Type=5 Count=0 Subtype=41 (10010100101001) (0x9d,0xfa,0xa8,0xb2,0x9b,0xf9)
Traffic For : MMSI 235075591 (KATHY C-2CTI7,Great Britain)

Please note that Rivet is a free and totally open source decoder for various HF modes written in Java so it should run on Apple , Linux and Microsoft Windows PCs. The executable JAR file can be downloaded from here  and all the source code is available on Github . If you are interested please join the Rivet mailing list .

Once again many thanks to Alan W for all his work on this.