ST5000+ NO DATA error

[daveNZ]

I have an Grey ST5000+ autopilot (AutoHelm Series) which won’t accept AP commands from my NMEA system.

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.

[ilenart]

Is your wifi/nmea mux transmitting the data in Seatalk format? My Multiplexer has a Seatalk mode for talking to Raymarine instrument. The following is from the manual.

NMEA In1 can be switched to SeaTalk1®, which is a proprietary protocol developed by Raymarine®. This protocol is used for communication between Raymarine navigation instruments like the ST40, ST50 and ST60 series. While In1 is just an input for NMEA 0183, when switched to SeaTalk1 mode, it becomes a bi-directional port capable of receiving and sending SeaTalk1 data. To be able to use these instruments with commonly available navigation programs or to feed their data into other non-Raymarine instruments, the SeaTalk data needs to be translated into NMEA. Even Raymarine’s own navigation software, Raytech Navigator, needs this translation.

Ilenart

[daveNZ]

Thanks, but the mux output is NMEA 0183, which I assume are compatible with the NMEA input on the ST5000+
It may be sending commands that are not recognised by the ST5000+ but I assume these would be ignored?

[daveNZ]

I’ve proven the ST5000+ works, with another GPS receiver.
But these NMEA sentences below are from iSailor and are not understood, hence the NO DATA in TRACK mode or just dashes in the SOG page of the ST5000+
$MARMC,000532.39,A,3649.13831,S,17445.94387,E,0.00 ,33.4,240320,,E,A,S*6D
$MARMC,235554.92,A,3649.14042,S,17445.94426,E,0.31 ,117.1,230320,,E,A,S*58
$MAAPB,A,A,0.0121,L,N,V,V,321.6,T,002,320.5,T,320. 5,T,A*62

These are declared invalid by an online decoder ( https://rl.se/gprmc ) but without an explanation.
Can anyone tell me what might be a wrong with them? I’ve looked at the spec and I can’t spot the problem.
Looks like old Raymarine autopilot not understanding new NMEA data.
Any help appreciated.
Thanks

[smac999]

it's probably looking for a $gp signal. I have never seen a $ma. you might be able to change it in the wifi mux settings.

the first 2 letters are telling it what is sending the signal. $gp = from a gps.


if this is a computer. you could try to run a cable from the PC to the pilot to test it. and also see what sentances that sends out. you'd need a serial to USB adapter.

if this is a tablet then you probably can't.

[Dsanduril]

There are several potential problems and testing each one would require being able to inject NMEA sentences into your autopilot.

First, the sentences you posted look fine until the very end. For the RMC:

E,A,S*6D

The "S" seems to be an extra field, the RMC definition (v2.3 and up) ends with the mode field "A" that is previous in your sample. And the autopilot may not be v2.3, in which case to it the autopilot it is also an extra field.

Your decoder won't decode because it only accepts talker IDs GP, GA, GL, and GN. So the decoder doesn't recognize the MA talker (as smac999 noted). The autopilot shouldn't be so fussy, there isn't really a restriction on what talker can provide what data. But maybe it does. Although the extra field(s) also get in the way.

If you try this sentence in the decoder it will work:

$GPRMC,000532.39,A,3649.13831,S,17445.94387,E,0.00 ,33.4,240320,,E,A*09

note that I have removed the ",S" from the end, and then recalculated the checksum here.

Also be careful if you check for yourself, the forum does some weird things when posting these sentences, it inserts an extra space at character 50. Check your own post, there's an extra space after "0.00", you'll need to remove that space for things to parse properly (or recalculate the checksum to include the space).

Bottom line, if you have a computer and a RS-422/485 port/adapter you could send sentences and see what works. You could start with the one above. If that doesn't work I'd try:

$GPRMC,000532.39,A,3649.13831,S,17445.94387,E,0.00 ,33.4,240320,,E*64

Then:

$MARMC,000532.39,A,3649.13831,S,17445.94387,E,0.00 ,33.4,240320,,E*7F

And finally:

$MARMC,000532.39,A,3649.13831,S,17445.94387,E,0.00 ,33.4,240320,,E,A*12

That might give you an idea of to what the AP is objecting. If it is only the ",S" at the end of the sentence you may have to contact iSailor to find out why it is there (and whether it can be removed).

[daveNZ]

Thanks very much for these comments, plenty to work on.
Noted about the blank...should have select/copy'd it back to check, thanks.
1. yes there is a new field at the end of the RMC sentence..'mode'. See below.
2. MA is the code prepended by iSailor in its output.
3. The GPS that worked for me did, in fact, prepend 'GP' !!
4. I assumed, but could well be wrong, that the first 2 letters would be ignored, but maybe used where some ID of the sender was useful.
5. So I need to find out if a 2002 ST5000+ (grey) is fussy about the NMEA version
Cheers..


The new RMC field:
"The last version 2 iteration of the NMEA standard was 2.3. It added a mode indicator to several sentences which is used to indicate the kind of fix the receiver currently has. This indication is part of the signal integrity information needed by the FAA. The value can be A=autonomous, D=differential, E=Estimated, N=not valid, S=Simulator. Sometimes there can be a null value as well. Only the A and D values will correspond to an Active and reliable Sentence. This mode character has been added to the RMC, RMB, VTG, and GLL, sentences and optionally some others including the BWC and XTE sentences."

[Dsanduril]

The extra space isn't anything you did, it's the forum. I posted in the forum help section to see if tech support can help.

Yes, but the sentence has two mode characters the A and the S. The last "E" is the direction of the variation, the end of the "old" RMC. The mode character should be A or S, but not A,S.

Yes, the MA talker ID shouldn't really matter, but it does to the online decoder, so who knows who else put in similar code.

[daveNZ]

OK, I see the two extra S and A characters. I'll ask but iSailor seldom answer questions.
The link for Checksums is useful thanks.

iSailor (on iPad) only lets you enable/disable a list of sentences, and ignore checksum for incoming ones, so will need another NMEA talker. Maybe OpenCPN?

Unfortunately NZ is now in 4 weeks 'stay at home' lockdown, we're allowed to walk but the boat is 3.5 kms from home, which might not be a walk 'nearby'.


This is a string from the GPS (puck) that works with my ST5000+
$GPRMC,051906,A,3649.1353,S,17445.9411,E,000.0,020 .0,210320,,,A*64

[Dsanduril]

Now that's a nice looking sentence

We use OpenCPN to drive our Raymarine autopilot all the time. Before the great sequestering had it on the radar to try PyPilot but that may be delayed a bit. Regardless, OpenCPN does fine with Ray/Autohelm APs.

If you want to use the iSailor output and have OpenCPN as well then the NMEA converter plugin would handle this easily. It could take the MA data (if that is going to be your source), change the identifier to GP (in case that is what the AP expects) and strip away the newer fields (in case that is what is throwing off the AP). Easy-peasy.

[daveNZ]

Thanks, I have OpenCPN on a Mac, but didn't really want to have it onboard. We're only a 33' launch, coastal cruising, Autohelm is fantastic, but AP is really just for fun. I use iPad/iPhone/iSailor/Navionics all the time.
When I can get back to the marina, I'll test what you suggest. I was chasing connection issues, assuming too much about tolerance of NMEA content. Nearly there, I think.

[daveNZ]

From my very helpful NMEATools (maker of my mux) contact, the extra RMC sentence field, after the MODE field, is apparently something related to high precision positioning. I can't find it even in NMEA version 4.1 docs. Still waiting for access to boat, to see if the presence of these two fields is why the ST5000+ says 'NO DATA'.

[daveNZ]

I've now proved that the ST5000+
-ignores the sender ID, as I could change these first 2 characters to MA, GP, etc.
-ignores the 2 new fields at the end of the RMC sentence. It does need the valid flad to be 'V'

I'm sure the issue is the voltage differential on the NMEA mux output (or level?). It works fine with iSailor sending via a serial output from a PC.

NMEA syntax was not the issue at all!

[daveNZ]

correction to my previous reply. I said ...
It does need the valid flag to be 'V'
My typo, 'V' actually means GPS fix is VOID, I should have said 'A'.
It must be 'A" for the sentence to be valid. If it is 'V' the NMEATools wifi mux will not pass the sentence form wifi to NMEA output.

[daveNZ]

Just noticed I didn’t post the outcome of this issue.
I spent ‘hours’ proving that the wifi mux was the ‘issue’ and the supplier very kindly swapped it for another one. Problem solved. The trusty ST5000+ was ok, and tolerant of the new codes in the sentences sent from iSailor.

Interestingly the most used function is just having SOG on the ST5000+ as my iPad is behind me when at the helm.
The autopilot function works fine, although occasionally there is a dropout of the connection from the iPad to the wifi mux, it usually resolves by itself, I haven’t investigated it, but I have a new iPad Pro so will be interested to see if there is any change.
Now if only iSailor would answer queries, update their s/w.