Raymarine forum

Full Version: [TG11] SeaTalk 1 to MNEA 2000 via ST70
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
I have a few questions interfacing SeaTalk 1 to NMEA2000. Found some of the answers in your Forum but not all.

I have an existing SeaTalk 1 based system ,consisting of an S3G course computer, 1 ST7002+, 1 ST6000+, 1 ST600R, 1 smart controller w. Base station, 1 ST60 Multi, ST60 Speed, ST60 Depth, ST 60 Wind, ST 60 close hauled, and 1 ST70 instrument. Also there are still 2 SeaTalk 1 to NMEA0183/RS232 bridges that I may not use any more.

The SeaTalk 1 bus with all above listed instruments is powered by the S3G.

The functions (PGNs) I would like to get from SeaTalk 1 to NMEA2000 are wind, water speed and depth related data, as well as rudder angle and heading. The other way I would like to send GNSS data like position, SOG, SOG, and autopilot (RMB type) data to facilitate track mode. Fast heading I have already picked up directly at the NMEA0183 port of the S3G and passed it via an Actisense gateway to the N2k backbone - that works just fine and is used as backup heading should the Airmar 220WX sensor fail.

To bridge between the SeaTalk1 network and the NMEA2000 backbone and get the above function, it looked to me like I had about three options.

1) ST70 instrument bridging to the NMEA2000 backbone using spur cable A06046.

2) Using a SeaTalk1 to SeaTalkng converter kit E22158 and splicing a backbone cable to connect it with the NMEA2000 backbone.

3) Using one of the SeaTalk 1 to NMEA0183/RS232 bridges in conjunction with another Actisense N2k/N0183 gateway.

Since I already had the ST70 instrument I tried version (1) and it appeared to work right away. However I noticed that the ST70 would occasionally freeze and not get going again without cycling power. I also noticed that it was passing on SeaTalk power to the N2k backbone. I actually found this quite convenient as I would need to power N2k from an inverter as my DC system is 24V. Checked the S3G and it claims to provide up to 5A for SeaTalk power. The load on the N2k backbone is rather mild as the bigger participants have their own power supply. What’s left is currently two Actisense gateways with 35mA (LEN1), 1 Yacht Devices gateway with 18mA (LEN1) and one Airmar 220WX sensor with <50mA (LEN1).

I have not tried version (2) as I don’t have the conversion kit (yet) and I’m not sure if it would be any different to using the ST70 for the same task. I realise that the ST70 is a bit dated and the reason for it to occasionally freeze may simply lay in the fact that N2k specs have advanced since and some new PNG format may confuse it. It has worked flawlessly as long as it was just connected to good old SeaTalk 1. So one of my questions is, would the conversion kit be a save bet, and the best way to do this?

With respect to version (3), I have not tried it yet, but am quite sure it would work ok. It just seems a bit odd to translate twice. With version (3) the choice of SeaTalk power for N2k goes away and I would need to separately power the two networks.

So, am I making some false assumptions and/or is there a best way of solving this that you would recommend.

Regards Harald
Hello Harald,

Thanks for the detailed info about what's in your system and what you're looking to achieve, that helps give you an informed answer.

I'd go with Option 2.

Option 1 ought to work, but since there have been no software updates for ST70 since 2011 it will not support any modifications to the NMEA2000 standard released since then. Regarding the freezing though, I'd check that it does indeed have the latest (v3.04) software.

Option 3 is the least desirable option in my opinion. Multiple conversions can introduce problems such as 'stale' data relaying between networks, missing data such as magnetic variation and local time offset, different depth/speed unit preference (feet/metres) in different parts of the system, and more. I always recommend avoiding multiple conversions unless there is no alternative. The fewer networks, the better.

Thanks Tom,

Sure makes sense, will go with option 2.

Checked firmware on ST70 and its up to date, it was bought in 2014.
ST70 seems to work if I power it up before anything else on the backbone, but then may still freeze after some hours. If I power it later, joining the game it freezes after a few seconds.

I will go back to only connecting the ST70 with SeaTalk 1 and get a conversion kit to bridge. Hope this will work ok.

Regarding power you haven't voiced any opinion. As I have only some very light consumers on N2k I would prefer to continue to power both, SeaTalk1 and N2k from the course computer.

If you think that's a bad idea, I would the want to only power N2k from another source and leave SeaTalk one powered by the S3G.
That would either mean that I would have to cut the red wire in the SeaTalk 1 Spur cable. Or I keep the converter powered from SeaTalk and not connect the red wire in the spliced backbone cable.

Thanks Tom,

makes sense, I will go with option 2.

Checked the ST70 and it is on the latest software, it was bought in 2014. It seems it will usually work when it is the first thing that gets powered up, but even then it may freeze several hours later. I decided to keep it on SeaTalk 1 as it has worked in that mode just fine for many years and I think chances to get the freezing problem solved are very slim.

You haven't voiced an opinion on power. I know the recommendation is to not power N2k from SeaTalk1, but in my case the N2k power needs are very low and the S3G has specified up to 5A on the SeaTalk supply side.

Doing it this way is very convenient in my case, as I would have to feed the N2K power from one of the two 24/12V inverters.

One 12V supply is for general use like USB sockets, car radio, 12V sockets and as such I don't consider it particularly clean and reliable.

The other one is supplied by a permanent 24V supply, bypassing the main battery switches as it is used for those things that stay on all the time. and I wouldn't want to keep power on on N2k all the time.

On the other hand I need Seatalk and N2k always together and I definitely don't want to change the way I power SeaTalk from the course computer.

Is there any strong reason to keep power separated?

Sorry Harald, I hadn't noticed that I'd missed the power question.

Yes, powering ST1 from the S3G and then passing that power through the ST1-STNG convertor to power the STNG/N2K network is ok, with loads as light as you describe. I wouldn't attempt to power a large STNG network through the convertor or from a course computer but your small network should be fine.

The main thing, for anyone else reading this, is to make sure that you STNG/NMEA2000 network only has a single point of power, whereever that is. The NMEA2000 specification says that multiple points of power are ok only if each is an isolated supply.

Hi Tom,

I'm picking up on this thread as new question just crossed my mind.

I have now obtained a SeaTalk1 to SeaTalkng converter kit E22158, but won't be able to try it out until 5 weeks from now.

The question is whether there is a way to control what data gets passed either way, or if there is not what the behaviour would be.

In particular I want to receive from ST1 all ST60 type data like wind, water speed etc. And send to ST1 autopilot track and waypoint data (like in APB).
But also numerous other infos that the ST70 can display, like GPS position data, COG, SOG.

All that seemed to have worked with the ST70 as a bridge, aside of it freezing after a while.

What I hadn't tested is heading. So far it came from the autopilot via ST1. But I'm introducing a satellite compass and would prefer the ST70 to use its true heading instead.

The autopilot on the other hand works well the way it is with its own flux-gate and yaw giro. An absolutely correct true heading isn't required for it, so I thought I'd rather leave it the proven way.

For the set and drift calculation on the ST70 however I would prefer the true heading from the sat compass.

Another question is what happens when I have two GPS feeding into NMEA2000 / SeaTalkng, they are probably saying the same, but that's not guaranteed. Will it be sticking to the first one it sees or process both.

Is there any way to control this?

Hello Harald,

There's no way to control what gets passed by the ST1-STNG convertor: by design it will pass everything that's available and supported on the other network, and there's no configuration for this because we don't want people being able to cause problems by accidentally switching things off. People love to push buttons, for some reason the default setting is always seen as the wrong one.

In a system of ST70 vintage, there is no software support for multiple sources of a particular kind of data, and results will vary if multiple sources of heading, GPS and more are present. Each consuming product's software may handle the situation differently depending on its age and the inclination of its software developer. The source used may be the most recent received, the first received, the one with the lower or higher CANbus address (for NMEA2000), or lower or higher serial number, and so on.

Back in the day, it wasn't expected that people would have multiple GPSes or heading sensors connected. Later, when this became more commonplace, we introduced our Multiple Data Source support, in which the system negotiates and agrees on a single preferred source system-wide. MDS support was introduced in products introduced from late 2011 (Lighthouse a, c, e, eS and gS-series MFDs, i70/p70 and later) but is not present in ST70, SPX pilots etc..

Having products in a system which either produce or consume data which is now handled by MDS source selection (heading, rudder, speed, depth, wind, GPS, datum), but which are not MDS-aware, will prevent/block source selection. This means that you can't do MDS in a system that contains ST70, SPX pilots etc. Don't be tempted to remove the offending item, do an MDS selection and then add it back in again, as this will lead to differing behaviour on the MDS and non-MDS products (e.g. different GPS positions.)

The short answer: unless all the products in the system are i70 vintage or later and MDS-ready, you should stick to only a single source of each kind of data.

I now had a chance to try out the E22158 SeaTalk bridge in my system.

The data I really needed to bridge, from N2k to ST1, like route and waypoint info for the autopilot track function, seem to come across just fine. Also in the other direction I do get wind data and speed through water.

Of the nice to have data, GPS position, SOG, COG, and time also come across fine. Interestingly the date doesn't come across and remains at some date in 1997.

But the real problem is heading: It does come across, but unfortunately wrong. The bridge seems to mistake true for magnetic and apply the variation to true to calculate its new true heading. When I look at what the sat-compass sends out on N2K, I see 50 magnetic, -5 variation, and 45 true in PGN 127250. - On SeaTalk1 instruments 40T is displayed.

When I take out the E22158 bridge and connect ST1 to an old N0183 bridge and that bridge to an Actisense gateway bridging N2k to N0183, it seems to work like in the old days when I had no N2k devices. That means, that now the date comes across ok, and no heading is passed to ST1 as long as the course computer sends out his own heading.

If I then disconnect the fluxgate sensor from the course computer, the heading from the sat compass is apparently passed to ST1 and this time correctly, showing the 45T.

So I have to conclude that the course computer heading gets priority when using the old N183 bridge, and the external heading gets priority when using the E22158 bridge.

I also have to conclude that the E22158 passes on wrong heading and doesn't pass on date.

It looks like I have to stick with the 'old' way of bridging unless there is a fix for the E22158. No idea what software level it has, but it was just purchased 5 weeks ago.
Hello Harald,

It sounds like you've been looking at the NMEA2000 traffic, which is great - is there any chance of posting some of the raw data that that we can what is and is not there and test for ourselves?

Are you absolutely sure there's no source of Variation on ST1? Some ST1 products could have either a manual variation configuration or calculate for themselves - I'm wondering whether the double-applied variation is happening in the E22158 as you suspect, or subsequently on ST1.
You don't have an MFD (e.g. C-series or E-series Classic or Widescreen) connected to ST1? If you did, you could use that to examine/record the ST1 traffic and post that back here. Let me know if you do and I'll give details.

Re. the date, again, I'm wondering whether it's that the E22158 isn't outputting date or whether there's something else with a higher priority that's explicitly transmitting 1997 on ST1. Usually, no data gives dashes ( -.- ), not an incorrect value.

To resolve either of these issues, I'd really need to see the raw hexadecimal data on either/both networks if you can get it. A Classic or Wide MFD can record either to its CompactFlash card slot.

Reference URL's