2nd YAPP in production - Seatalk to USB

AngusMcDoon

Well-Known Member
Joined
20 Oct 2004
Messages
9,067
Location
Up some Hebridean loch
Visit site
It was nearly 2 years ago that I posted about a Seatalk to USB converter I had made. When I say USB, what I mean is that if you plug the device in it appears as a virtual COM port on your computer from where you get NMEA 0183 format messages. What this can be used for is to get all your data from your Seatalk network into an application like OpenCPN or MaxSea. The original thread is here with some photos of the data coming into OpenCPN...

http://www.ybw.com/forums/showthread.php?278332-YAPP-Homemade-Seatalk-to-USB-interface

Finally I have made a PCB and put it into small production - 10 to be precise. I have revamped the software and now the following NMEA-0183 format messages are produced...

DBT (depth)
VWR (apparent wind speed and direction old format)
VWT (true wind speed and direction old format)
VHW (true heading, magnetic heading, boat speed)
HDM (magnetic heading different format)
MTW (water temperature)
RMC (time, date, lat, long, SOG, COG, magnetic variation)
VLW (trip and total log)
RMB (distance and bearing to destination, but not the other RMB fields)
MWV (true and apparent wind speed and direction, new format)

I have bought enough bits to make 10. They cost me £10.31 each. No box, but it can go in any small project box from Maplin. A standard USB cable will be needed too. I've tested it with OpenCPN and MaxSea running on Windows XP, Vista and 7, all 32 bit versions. If anyone wants one send me a PM. I don't specify a price, just make a contribution for what you think it's worth when you are happy with it, or else send it back.

Power for the device is taken from the Seatalk power line, not from your computer's USB port.

sdc11714z.jpg


Some techy information hidden at the end...

I'm using a better voltage regulator this time. It's a LM2931. This is a load dump regulator designed for automotive applications like cars and boats. What this means is that it can reject up to 60V voltage spikes.

As Seatalk has 12V on its data line and USB going into someone's expensive computer is only 5V I have put in an opto-isolator to make sure that I don't damage anyone's computer if anything goes wrong in my design.

I haven't paid the USB consortium £2000 for a VID and a PID. I'm using the Microchip development one, so it might clash if you plug in something else that is also using the same ones at the same time. It's highly unlikely though, and if you did, you are probably a geek and realize what you are doing.

In USB speak this is a self powered device. This device must never source current on to the USB Vbus line. To achieve this, this device has an attach detector which controls when this device's processor enables its USB module.

Thanks to Thomas Knauf for his work on Seatalk...

http://www.thomasknauf.de/seatalk.htm

Seatalk is a trademark of Raymarine. These devices are not CE marked or EMC tested. See this thread for further information...

http://www.ybw.com/forums/showthread.php?359650-YAPPs-in-production-and-CE-marking
 
Last edited:
I have revamped the software and now the following NMEA-0183 format messages are produced...

There's obviously choices to be made in doing the conversion: Whether to store seatalk and output the nmea sentences triggered on a particular seatalk command, whether to store and output when any of the components change, whether to assign a "valid" time to anything you store etc. IIRC my GPS puts out SOG/COG twice as fast as position which is a subset of that and equates to a choice of having half the COG/SOG rate or duplicating the same stored position info in 2 successive sentences.

I remember you mentioning you also did some work with Frank Wallenwein testing his converter boards.

Are you just making sensible choices with the conversion algorithm or are you basing them on an analysis of what the E85001 seems to do?
 
There's obviously choices to be made in doing the conversion: Whether to store seatalk and output the nmea sentences triggered on a particular seatalk command, whether to store and output when any of the components change, whether to assign a "valid" time to anything you store etc. IIRC my GPS puts out SOG/COG twice as fast as position which is a subset of that and equates to a choice of having half the COG/SOG rate or duplicating the same stored position info in 2 successive sentences.

Are you just making sensible choices with the conversion algorithm or are you basing them on an analysis of what the E85001 seems to do?

There is not a one-to-one relationship between Seatalk and NMEA 0183 messages. I was putting out an NMEA message every time a Seatalk one came in with the missing NMEA data fields empty, thinking that it would be ok as the next NMEA message would have it. However, although legal NMEA, this annoyed the MaxSea software package, so I had to have a rethink. Now the Seatalk data is stored with a timestamp as it comes in. Periodically a NMEA message is sent with as many fields filled in as possible where the data are valid - i.e. received within each item's timeout. If the data goes stale, it is not sent any more. Different data types have different timeouts; magnetic variation for example doesn't go stale very quickly but COG does.

I don't know how the E85001 works as I have never seen one, and it's probably better that way. Software copyright rules allow the likes of Thomas Knauf and me to reverse engineer a protocol like Seatalk for interoperability purposes, but we're not allowed to use any knowledge of their internal software.
 
Reason for asking was because I've been pondering the problem for seatalk->0183 conversion in software. I had suspected that the "leaving fields blank" approach might cause problems with dodgy software erroneously treating blank fields as 0, so thanks for confirming I'm not just paranoid.

Yours is a sound approach. Mine's slightly different, with output triggered when the last bit of a "set" arrives and no components are "stale" but I'm still playing with different approaches.

I don't believe (in this country at least) there's a problem with reverse engineering the algorithm used by the the E85001 (ie watching/manipulating packets in and watching what it sends out) so long as you don't have access to the proprietary design docs for it.
 
Have you measured the current at the output? I know an 18F2550 can consume 200mA, but wondered what they were used in a single port situation. I'm still looking for a 5V/3.3V solution using a SMPS.

I measured the current into the circuit when it was powered by a 5V external supply. I don't have the information with me right now, but I remember it was within the specification of the LM2931. The 200mA consumption by the 18F2550 would only be reached if it was sourcing current onto its pins, for example driving external LEDs. In this design there are no pins set as outputs other than the USB data lines which take a tiny amount, hence the current consumption is much less. I'll update this later when I have the information with me.
 
They have all gone, but if the feedback from batch 1 is favourable and there's enough interest I will get some more. The PCB manufacturer sent 12 for the price of 10, so 1 for me and 11 have been sent around the world.

For more I would have to do another printed circuit board order and the minimum number is 10. Takes 3 weeks to get them.
 
Last edited:
Top