[TG] [TG11] ST5000+. NO DATA error.

[davenz]

I have an Grey ST5000+ autopilot (AutoHelm Series) which displays NO DATA, but I think my NMEA input data is OK.

There was a Furuno GP31 wired to the ST5000+ but I don’t know if it worked, and due the GPS rollover I ,unfortunately, threw it away. I assume it used to work, the previous owner may not have used it. This is in a small 2002 launch, well maintained and dry.

I now have iSailor, sending AP commands via wifi to a (TeamSurv NMEATools) wifi/nmea mux, then by wire to the ST5000+. iSailor NMEA logs and voltage testing indicate the NMEA output is working, and I have tried reversing the NMEA wires.

When I put the ST5000+ in to TRACK mode it always give ‘no data’ error. There is no Seatalk connection to the ST5000+. The Autohelm part of this works perfectly.

Is there some ST5000+ setting I am missing, maybe it is ignoring the NMEA input? or is there another way I can test the data input to the ST5000+?

Thanks for any help.

[Tom - Raymarine - Moderator]

Hello davenz,

Do you know that what the NMEA mux is transmitting is exactly (character for character) what iSailor is sending? If so, it would be good to attach one of those NMEA logs.

Some common problems with NMEA0183 data:

• Voltage tolerances. Signalling voltage levels have changed with later revisions of the 0183 spec and older devices tend to be less sensitive to lower signalling voltage levels than newer ones.
• Single-ended versus differential signalling. 'Modern' (ha ha) NMEA0183 is differential, that is voltage is applied positively to one wire and negatively to the other and the signal must be measured as the difference between the two, whereas older devices use/expect a single transmitting wire and a common (0V) reference potential. The ST5000+ is old-style non-diff. What does the mux use?
• many NMEA0183-ish devices use NMEA0183-formatted data over the RS232 electrical signalling layer, which is not strictly 0183 compliant.
• data content: is everything the pilot needs there, and are the Data Valid (A, V) flags present and correct?
• checksums - must be present and correct
• ... I'm sure there are some more I've forgotten from my days handling 0183 regularly.
  

To really see what's happening, you would need to read what was coming into the ST5000+ with a PC and serial terminal (I use Teraterm on Windows or Moserial or Cutecom on Linux) and check the signalling with an oscilloscope.

What the pilot needs to see will be at least bearing-to-waypoint, distance-to-waypoint and cross-track error (later pilots also need waypoint name.) These can come from any combination of the supported NMEA0183 messages which you will find in the ST5000+ handbook. RMB should provide all that's required as long as all fields are present and valid.

Regards,
Tom

[davenz]

Tom, thanks for your good reply. I've been unable to login for a while and have just seen it. Now we are locked down in NZ and I can't get on to the boat!!

I'll check the points you raised re electrical interface, with the vendor if necessary.

In the meantime I've noticed one difference in a Polstar GPS (that does work), and iSailor.
One of the sentences RMC has two new fields (mode and precision. 'A,S' ) at the end. Are these ignored by the ST5000+ or could these be the problem??

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

From iSailor- note the last 'A,S' - two extra fields that the Polstar does not send.
$MARMC,000532.39,A,3649.13831,S,17445.94387,E,0.00,33.4,240320,,E,A,S*6D

From Polstar GPS receiver, the following DOES work
$GPRMC,051906,A,3649.1353,S,17445.9411,E,000.0,020 .0,210320,,,A*64

[Tom - Raymarine - Moderator]

Hello davenz,

The ST5000+'s software was written when NMEA0183 v2 was current, which did not include those flags on RMC. The ST5000+'s software ought to ignore the extra unknown fields, but whether it actually will or not is another matter, and of course it's not likely that any engineers who were with us in the early '90s, and worked on ST5000+ software, are still with us and would have any recollection of this detail if so.

The other thing that strikes me in that message is the source identifier mnemonic, MA: neither the v2 nor v3 spec. documents I've looked at list that as a supported/recognised source identifier.

Finally - I've not checked the checksum field, my checksum checker is not accessible where I am working remotely, but I've seen a surprising number of incorrect checksums over the years.

Regards,
Tom

[davenz]

thanks Tom,
That’s a big help, even if it means that in the end they may be incompatible without some translator/modifier in between.
I’ve now got access to my boat so I can do more specific testing of sentences manually created from OpenCPN and them iSailor.
Thanks
Dave.

[davenz]

Hi Tom,

I’ve established that the ST5000+ is accepting NMEA sentences, and it ignores the two new fields at the end of an RMC sentence, but it seems to want the data valid field to be a ‘A’ and not ‘V’ (void). Other sentences work as well.

It is working with data from a Mac and a USB/serial cable, but will not accept data from the Wifi mux I have.

As in the first possibility you listed earlier, it is looking like the issue with the wifi mux is the voltage levels. The serial cable has a voltage of about 6V to 2V (TXD negative relative to GND) crudely measured with a multimeter. The mux output is more like 5V to 2V.

Question: is there a specified voltage level or differential needed for the ST5000+ NMEA input to be accepted?

[Tom - Raymarine - Moderator]

Hi Dave,

I'm sorry to say that I could have answered that accurately when the ST5000+ was current or recently retired, but not now. All I can say is it would have complied with the NMEA0183 spec that prevailed at the time, which I am assuming would have been v2.x. A quick look at a spec of that sort of age says that there should be a minimum 2v differential between high and low lines, but that designs should be backwards compatible with earlier spec versions that used (roughly) 0V .. -15V as a Low and +4V .. +15V as a High.

Again, you'd need an oscilloscope to be sure of what was happening (PC oscilloscopes are very cheap nowadays, and not too hard to use), but it sounds pretty convincingly as if the signalling level is the cause of the problem. If there's no setup in the mux for this then you'd be down to either:

• replacing the mux
• building some new hardware, or sourcing some intermediate box that will step up the levels (perhaps an RS422->RS232 convertor might do the trick?)
• daisy-chaining multiple convertors, e.g. mux->NMEA0183-2000 convertor->Seatalk via our E22158 convertor (this seldom ends well, I only mention it to dissuade from it)
• looking at upgrading the pilot
• ...
  

I have to say, I can't stand NMEA0183. It's dot-matrix printer, VHS video, TV-remote-with-a-hardwired-cable generation technology that I am somewhat over troubleshooting. There are a lot of good reasons why all of us hardware manufacturers moved over to NMEA2000 many years ago and if there's any way for you to do the same, you'll save yourself some pain.

Regards,
Tom

[davenz]

Thanks Tom, Really appreciate the replies.
I agree re NMEA, but $ prevent me upgrading at present.
I've proved with a new VHF radio that the wifi mux NMEA output is OK with new NMEA receivers, but not the ST5000+. I think the voltage differential is too low, but don't have equipment to measure it.

For anyone else reading, the ST5000+ ignores the new fields at the end of (at least the RMC) NMEA sentences. So long as the GPS valid flag is A, not V, it works fine. It also ignores the send ID (the first 2 characters in a sentence) So mine works with the $MARMC sentence for example, from iSailor on the iPad. (not via this mux but via a serial PC output.