Alternative SeaTalk wiring

[Adrian]

TL;DR: On the MacArthur HAT, connect SeaTalk 12V to MacArthur SeaTalk1 DATA, SeaTalk DATA to MacArthur SeaTalk1 GND, set ST GND jumper to OPEN position.

This statement by Sailoog in a post on another thread, got me thinking about how SeaTalk actually works.

[...] maybe we should replace the 4K7 resistor in the MacArthur HAT by a variable resistor.

Seatalk1 devices wait for the idle state (+12V for at least 10/4800 seconds) of the bus to send data, if you do not use the correct resistor for your bus, you may have been forcing a "busy" state (near to 0V) unintentionally. You will notice that because your device (any Raymarine MFD) will stop sending data to the bus when using the wrong resistor.

Based on the above statement, here's a simplified schematic of how a SeaTalk device works internally:

   

Inside the SeaTalk device, a pull-up resistor of several 10K keeps the data line high when idle. When TX outputs a one, the NPN transistor turns on and pulls the DATA line low. Conversely, when TX is outputting a zero, the transistor is turned off and the pull-up resistor pulls the DATA line high. This is very similar to how I2C works.

The SeaTalk device monitors the state of the data line via its RX input. If DATA is low while the SeaTalk device is idle, this indicates another device on the bus is talking. If DATA is low while TX is transmitting a zero, this indicates that a bus conflict with another device occured. 

Note, that when multiple devices are connected to a SeaTalk bus, their pull-up resistors will be in parallel, lowering their combined value. Also note, that the threshold that RX uses to distinguish between low and high is not known. It could be 6V, but it could also be 10V or 1V.

Here is the circuit we currently use to receive SeaTalk data. It can be found in similar form around the internet.

   

When SeaTalk is idle (12V), the optocoupler conducts. R1 together with the pull-up resistor(s) inside the SeaTalk device(s) will create a voltage divider, pulling DATA below 12V. The actual voltage on the DATA line depends on the forward voltage of the optocoupler (~2V), the value of R1, and the pull-up resistor(s) inside the SeaTalk device(s). If R1 is too low, our circuit will pull the DATA line below the RX threshold where the SeaTalk device decides that the bus is busy, resulting in no data being sent.

Unfortunately, the correct value for R1 depends on the specific setup, as we don't know the value of the pull-up resistor inside the SeaTalk device, the device's RX threshold, nor how many devices are connected to the bus. To make this work in all setups, we'd have to add a variable resistor for the user to tweak until it works in their environment. And even then, it might stop working when adding another device, or at full moon.

Here's what I think is the correct, or at least a more robust way to receive SeaTalk data via an optocoupler:

   

The positive side of the optocoupler is connected to 12V. When the SeaTalk DATA line is high (idle), the optocoupler is off and DATA_RX will be high. When a SeaTalk device pulls the DATA line low, the optocoupler turns on, and DATA_RX goes low. The DATA line will stay near 0 as the SeaTalk device is able to sink the few mA of current flowing through the optocoupler.

In this circuit, the exact value of R1 is not very critical. R1 needs to keep the current in the range of the optocoupler, and the sink capability of the SeaTalk device. Anything in the range of 3-10K is probably ok, limiting the current to 1-3 mA.

As a side note, in a variation of this circuit, the activity LED D1 could be on the left side of the optocoupler, either between 12V and optocoupler or between optocoupler and R1. In that scenario, R3 is omitted.

In summary, MacArthur users should use the following connections for SeaTalk1:

SeaTalk 12V -> MacArthur SeaTalk1 DATA
SeaTalk DATA -> MacArthur SeaTalk1 GND
MacArthur ST GND jumper: OPEN

MacArthur beta testers that use SeaTalk: Please let us know if that works (or doesn't) in your setup!

[Sailoog]

We have tested the new wiring for seatalk1 on the current MacArthur HAT v1.0 and it works like a charm connected to an old Raymarine E80. The first difference you will see is that the SEATALK1 LED is no longer fixed, it will blink when data is received.

This is what we are asking beta testers to try. The first image is when it is not powered from the seatalk1 bus and the second is when it is. You need to check Invert signal in OpenPlotter GPIO configuration.

   

   

   

Publish here your results please, thanks!!!

[holgerw]

shure it is better to have an blinking feedback led for the traffic on the bus, but it would be better to get an 2-way-traffic as intended on the old seatalk bus. As this is somekind of special serial communication with 9 bits we need an better library to realize this. i am in the hope for one with spare time to put this togeher. so an future design of arthur should bear this in mind.

[Sailoog]

shure it is better to have an blinking feedback led for the traffic on the bus, but it would be better to get an 2-way-traffic as intended on the old seatalk bus. As this is somekind of special serial communication with 9 bits we need an better library to realize this. i am in the hope for one with spare time to put this togeher. so an future design of arthur should bear this in mind.

• Did you try the new wiring?
  
• Does it work for you?
  
• Could you provide details about your seatalk1 bus and devices?
  
  

The blinking LED isn't the improvement here, just a positive side effect. The important thing is that using this new wiring, seatalk1 systems that are not capable of using this optocoupler-based connection will now be able to connect regardless of the values of their bus resistors.

IMHO I do not think it is worth investing time and effort into software or hardware solutions to send seatalk1 data.
Setalk1 and NMEA 0183 are really old data formats, but NMEA 0183 will still be around for a long time and seatalk1 will not. New GPS, AIS receivers and autopilots, still accept NMEA 0183 but only old and discontinued devices use seatalk1.

In the other hand the idea of this connector is to receive data from our old devices before they die and are replaced. I can not think of any case where we should send seatalk1 data to the bus from OpenPlotter when you can use NMEA 0183, NMEA 2000 and Signal K. We should help the seatalk1 format die with dignity

[Boatingbaileys]

I'm on the boat for a couple of days so let me know how I can check this, however, on the first test that doesn't work on my Seatalk1 network. The LED is more responsive as if it's getting data and SK dashboard shows 0.4 in terms of data throughput. If I leave the invert signal off it's 0 and then with it on it's 0.4 but I dont seem to be getting anything meaningful.

The only thing to say is my board is not powering my Pi yet. They are all hooked up to the same power source however.

Seatalk1 Network - Pi <>ST60 Depth<>ST60 AutoPilot <>ST60 Wind <> C80

I'll change how my pi is powered next and report back again.

[Sailoog]

I'm on the boat for a couple of days so let me know how I can check this, however, on the first test that doesn't work on my Seatalk1 network. The LED is more responsive as if it's getting data and SK dashboard shows 0.4 in terms of data throughput. If I leave the invert signal off it's 0 and then with it on it's 0.4 but I dont seem to be getting anything meaningful.

The only thing to say is my board is not powering my Pi yet. They are all hooked up to the same power source however.

Seatalk1 Network - Pi <>ST60 Depth<>ST60 AutoPilot <>ST60 Wind <> C80

I'll change how my pi is powered next and report back again.

Thanks for reporting. I would say this is a positive result. When signal is not inverted there is data traffic (LED blinking) but the signal k server can not understand this data, when signal is inverted the signal k server can understand and parse data. This means that the new wiring is working as expected but what surprises me is the low traffic that the signal k server indicates, 0.4, having wind and depth in your network. A possible explanation could be that only the MFD C80 is sending data (usually date and time). Some suggestions to debug:

- Where does that 0.4% data come from? you will see that in Signal k "Data Browser".
- Are ST60 Depth and ST60 Wind devices on?
- Can you see depth and wind data in the C80?
- What happens if you use the old wiring? (yellow cable to DATA connector, black cable to GND connector and ST GND jumper open. Signal not inverted)

[Boatingbaileys]

I'm on the boat for a couple of days so let me know how I can check this, however, on the first test that doesn't work on my Seatalk1 network. The LED is more responsive as if it's getting data and SK dashboard shows 0.4 in terms of data throughput. If I leave the invert signal off it's 0 and then with it on it's 0.4 but I dont seem to be getting anything meaningful.

The only thing to say is my board is not powering my Pi yet. They are all hooked up to the same power source however.

Seatalk1 Network - Pi <>ST60 Depth<>ST60 AutoPilot <>ST60 Wind <> C80

I'll change how my pi is powered next and report back again.

Thanks for reporting. I would say this is a positive result. When signal is not inverted there is data traffic (LED blinking) but the signal k server can not understand this data, when signal is inverted the signal k server can understand and parse data. This means that the new wiring is working as expected but what surprises me is the low traffic that the signal k server indicates, 0.4, having wind and depth in your network. A possible explanation could be that only the MFD C80 is sending data (usually date and time). Some suggestions to debug:

- Where does that 0.4% data come from? you will see that in Signal k "Data Browser".
- Are ST60 Depth and ST60 Wind devices on?
- Can you see depth and wind data in the C80?
- What happens if you use the old wiring? (yellow cable to DATA connector, black cable to GND connector and ST GND jumper open. Signal not inverted)

Just to be clear, its not working or showing any data. The 0.4 is the overall data amount showing in the Data Browser, normally thats around 13% or 14% of my data incoming so when i switch the wiring around, i can't see wind, depth, or position data, nothing is working for me other than the LED is flashing as you described aove. As soon as i switch it back, i can see all my data and the LED is on as it was with the Opto device.

All devices are on and powered from the same BUS.
Yes, switching the wiring doesn't seem to affect any instruments, i just cant see the data in SK
Old wiring works for me straight away.

I'll grab some pictures.

[Sailoog]

I think I have been able to reproduce your issue:

Raymarine E80 connected to a GPS by NMEA 0183.

Raymarine E80 connected to MacArthur HAT by alternative Seatalk wiring (red wire to DATA, yellow wire to GND, black wire unconnected, ST GND jumper open, Invert signal: yes).

Since I am indoor at the lab, I have not GPS fix, so the E80 is sending only its own data, navigation.magneticVariation.

The Signal K Dashboard shows 0.4(100%) for the seatalk connection.

The signal K Data Browser shows just navigation.magneticVariation key updated every 10 seconds.

----------------------------

I think something is muting your devices as soon as you use the alternative connection and only data from the C80 is received. Could you check if that 0.4 belongs to navigation.magneticVariation or anything else from the C80?

These Raymarine displays have a useful tool to check the traffic in your bus. Go to Menu - System Diagnostic - External interfaces - Seatalk - Buffer. There you can filter by TX, RX or both. Please check this traffic when connecting/disconnecting the MacArthur and we will see if the devices mute or they keep talking but the MacArthur stop listening or whatever...

Question: where exactly do you make the connection?

Another theory could be that this alternative wiring only works for self-powered devices (C80) and devices powered from the bus (ST60 Depth, ST60 Wind) can not be read but I have not any electrical explanation for that.

[Duncan]

I have a similar setup to boatingbaileys Seatalk1 Network - Pi <>ST60 AutoPilot<>ST60 Depth <>ST60 Wind. I did have a C80 but removed that last year and and have used the old C80 seatalk cable and connected it to the Hat. My board is powering the Pi.

Using the old wiring, the LED is on and SK is receiving data from the Depth and Wind instruments. However, I'm getting an STLINK FAIL error on the AutoPilot. Although the AutoPilot is still powered on, the error takes out the unit and it no longer functions. Its strange that I'm receiving data from the depth and the wind instrumentation even though the AutoPilot is the first device in the seatalk 1 chain.

I'm not sure if I need to diagnose this issue first or just change the wiring and config as advised above and see what happens?

[Adrian]

I don't know how the chaining is implemented in Seatalk1. From the result, my guess would be that it's an electrical pass-through with the device tapping into the data line. At least that would explain why you still receive depth and wind data even with the autopilot complaining.

If you could try the alternate wiring and config, and report results that would be great.