GW FSK

One of the modes I was asked by Rivet users to support was Globe Wireless (GW) FSK. For those of you who have never heard of them before GW are a commercial company that provide communications services (using HF and satellite) to the shipping industry. You won't be surprised to hear that it is the HF modes that interest me. Now this is where things start to get complicated because GW doesn't just use one HF mode but multiple ones which include ..

1. 100 baud FSK (200 Hz shift)
2. 200 baud QPSK
3. PACTOR
4. OFDM (22,24,26,28 and 30 carriers)

Now for the time being the mode that interests me is the 100 baud FSK one. This is frequently logged by hobbyists due to the fact that when they aren't sending traffic the shore stations transmit what are often called "Free Channel Markers". This consists of 144 bits (or 18 bytes) + a preamble and takes the form ..

20  38  a3  1f  6c  35  3b  4b  f2  f2  f2  cc  cc  cc  cc  cc  cc  ff

The first 11 bytes as well as the last byte (ff) are always the same and currently their meaning is not understood however the bytes numbered 12 to 17 are the ones indicate the GW shore station sending the transmission. In this case cc indicates the shore station is HEC in Bern , Switzerland. Rivet displays these channel markers in the following way ..

11:34:49 GW Free Channel Marker from Station Code 0xde (SAB, Goeteborg, Sweden)  20  38  a3  1f  6c  35  3b  4b  f2  f2  f2  de  de  de  de  de  de  ff 

These station indicator bytes are interesting though there are 255 possible values sometimes the same ones are used by different shore stations. 

In addition to the 144 bit free channel markers you will also see short 8 bit transmissions (which appear to always be 10010101) which are probably ACKs or acknowledgements that a transmission has been received and also 63 bit + preamble transmissions. It is the latter form of transmission which is the most interesting. These seem to take the form ..

Two bits (always 10) which probably make up the end of the preamble

Twelve bits which appear to determine the type of the packet (i.e what is contained in the payload)

Forty eight bits (or 6 bytes) of actual payload

Of the twelve type packet bits , I found that one bit (no 7) appears to alternate during data transfers and as such is probably a simple counter. One that basis I decided the bits 3 through 6 to represent a number I call the "type" and bits 8 through 14 represent a number I call the subtype. To shorten this I call a packet that is for example type 2 and subtype 101 a 2/101 packet.

The most interesting data sent on the GW FSK networks is probably position reports from ships. To see these you need to find an active GW shore station channel (listen for the free channel markers if you don't hear one within a few seconds that channel is in use) then tune to the corresponding ship channel frequency.  A screen shot of a position report decoded using Rivet can be seen below ..

 When sending such a report a ship initially establishes a connection with a shore station by sending a 5/41 packet. If the shore station hears this then it responds with a 5/41 packet back on the shore side of the link. Now the ship side 5/41 always has the same payload contents which is believed to be "Hello" but the contents of the shore side 5/41 payload change and its purpose is currently unknown. If the shore station does respond then the ship sends a 2/101 packet. We believe this contains the ships MMSI but can't as yet understand how it is encoded (thanks to Alan W for all his ongoing work on understanding this packet).

 Following this the ship sends a succession of 5/86 packets (with alternating count bits) which contain the body of the position report. Finally the ship sends a 2/106 packet possibly to say the report is complete. At this point if everything is OK Rivet will display the entire position report which will look something like ..

<<<<<<$GLOBE,203610.00,A,4927.7702,N,00019.0063,E,000.0,000.0,250113,04.8,W,N*11

What confused me greatly at first was that GW doesn't use ASCII to encode characters but instead uses its own 8 bit character mapping alphabet. With help from Patrick in France we compared the output of a position report decoded in Rivet with one decoded by another program and from that was able to work out much of the encoding system they are using. I won't list the entire alphabet here but if you are interested have a look at the source code for the Rivet GW decoder method getGWChar() which is here.

Another packet you will see is a 9/73 which appears just before another mode (usually OFDM) is used and must be a part of the link negotiation process.

 There is a lot we don't understand about the protocol used by GW FSK. Being able to decode the probable MMSIs in the 2/101 packets would be very useful but we don't understand the contents of the shore side 5/41 or 2/101 packets either.

 Rivet is a free open source decoder for various HF data modes. If you wish to learn more or want to help the project please join the groups mailing list.