The only thing I have to go off is this attached PCAP file that was posted on a forum in 2014 with some kind of AIS receiver that is working with his NavNet. I assumed at first it was an FA-30, but after re-reviewing the wireshark I think it's actually the plotter echoing AIS data it's getting via serial 0183 onto the network port, either way - it is still in Furuno-flavor.
I see two devices in the traces:
- 172.31.254.3 (Radar)
- 172.31.100.254 (I'm calling this "AIS emitter", but as above I now think it's the plotter)
The Radar broadcasts on port 10034.
The "AIS emitter" is broadcasting on many ports, I assume as different categories of data have different update rates?
10038 | GPMWV
10036 | HCHDG
10021 | [AIVDM] | [GPDPT, GPZDA, GPGG, GPGS]
Both devices also broadcast on port 10010 but these packets are weird - they have the preamble with a zero byte counter and then mostly binary data after. There is no ASCII NMEA payload that I see on this port, so I'm ignoring those.
The sequence counter in the Furuno preamble seems to be bound to an (IP-source, Dst-Port) pair and in incremented per UDP packet emitted regardless of how many NMEA sentences are inside the UDP payload.
Evidence for this:
- There are many cases where multiple GPS sentences are packed into a single UDP payload on port 10021 and the counter is incremented just once per payload.
- There is only one cases I see where AIS message are packed into a single UDP payload - this is packet #783 where there are two AIVDM's and the counter is again only incremented once.
- Port 10021 is either emitting payloads with both AIS or GPS data and the counter is incremented regardless of type.
Also - across all of these packets (all ports and both sources) the rest of the Furuno preamble bytes remains constant.
--
FWIW, OpenCPN has a flag you can set in it's config (EnableUDPNullHeader=1) that will allow ingestion of Furuno null messages. I was looking at what they did when that is set: