Brief "No Fix" from GPS' NMEA Converted to SeaTalk(1) for a Raymarine Chartplotter

[Andrew G]

Brief "No Fix" from GPS' NMEA Converted to SeaTalk(1) for a Raymarine Chartplotter

I had raised this issue on two other threads but am now trying to consolidate discussion to this new one (sorry if I have caused confusion).

I infrequently get "No Fix" alarms when there are plenty of strong satellite signals.
I am feeding my GPS’ NMEA output into the “NMEA In” of a Raymarine E85001, which then converts this to SeaTalk(1) (via the E85001’s “SeaTalk out”) which is then connected to the main SeaTalk bus. I input the SeaTalk, from the ST bus, to my Raymarine SL631 Chartplotter. (The +/- 12V for the E85001 is taken from the main SeaTalk bus' + & -).
About once an hour (or less frequently) the chartplotter briefly reports a “No Fix” alarm, even when there are plenty of strong satellites (I have been logging the GPS’ NMEA via HyperTerminal and can “read” the sentences). The CP and instruments also briefly show SoG = “- - -“.
I noticed that it happened before I purchased the E85001 and fed the GPS’ NMEA directly to the “NMEA In” of the chartplotter (I’d prefer to not have to have the CP turned on just to see SoG on my instruments).

I suspect there is an issue on the ST bus as I can’t replicate it at home (ie with the E85001, the Chartplotter with ST, and GPS). On the boat the SeaTalk bus has depth, wind, temperature, fluxgate compass and, when active, Autopilot data – but it also happens with/without AP on).
The GPS is a new modern 50 channel unit and my problem has occurred when receiving GGA/GLL/RMC/GSV/GSA/VTG/ZDA messages on one setting, or RMC/GSV/GSA messages on another – I have not yet tried the RMC-only setting as this defeats the purpose of having an expensive device acting as a cheep and cheerful one).
One quirk is that the GPS’ NMEA output (and hence the Chartplotter) reports a Differential Fix even though there are no Differential signals around.
The supplier has been quite good (they have “never seen this”) and has sent me another GPS antenna in case mine was at fault – it occurs with both, but only on the boat.

Any suggestions? Andrew
Nigel Mercer has queried whether there could be congestion or collision of messages on the SeaTalk bus – the old setup was with a Ray 120 which communicated similar traffic directly to the ST bus without any problems.

 

[Talulah]

I assume this happens if you are just sitting in the dock. Not actually sailing anywhere.
What is powering the Seatalk Bus?
My first suspicion would be the AP pulling down the ST bus even though the AP is not engaged. I would disconnect the Autopilot Seatalk from the Seatalk bus and see if the problem continues.

 

[Bru]

Okaaaaaayyyyyy

I suspect Nigel is substantially correct - Seatalk avoids (for the most part) talker collisions by assigning variable delays to the "is there anything already on the bus" algorithm in each individual talkers software and what I don't know and can't discover is what delays are assigned to what

My guess, and it is just a guess, is that the E85001 is a fairly low priority talker i.e. it has to wait until pretty well everything else has shut up before it can talk to the Seatalk bus

This jives with the problem not being replicated with just the 3 devices but happening when there's six or more devices chucking data onto the bus

The Ray 120 is probably a fairly high priority talker

If that guess is right, there's not much you can do about other than up with it put

However, another thought has just occurred to me and it's one we've had a problem with on our setup (now resolved) which is the possibility that the SL631 is itself outputting position related data onto the Seatalk bus which then conflicts with the data from the GPS. I can't find a manuel for the plotter online so you'll have to look that one up

 

[Andrew G]

Hi Talulah. The AP is on a different power circuit but does load/read data from the SeaTalk bus. This is happening at the dock and at sea with and without the AP connected or activated (eg in Standby).
The SeaTalk bus is powered from its own circuit with 15A cable, 3A fuse. The E85001 is less than a metre from the switchboard. All the connectors are soldered tabs onto screwed terminal blocks (except for the Raymaine 2.8mm spade connectors).
I could progressivly disconnect ST devices - but it can take 1 to 2 hours between occurances (usually after I have started packing up to head home) so it might be hard to say which disconnection changed things?

Happy to look at any possibility. Andrew

 

[Talulah]

Hi Talulah. The AP is on a different power circuit but does load/read data from the SeaTalk bus. This is happening at the dock and at sea with and without the AP connected or activated (eg in Standby).
The SeaTalk bus is powered from its own circuit with 15A cable, 3A fuse. The E85001 is less than a metre from the switchboard. All the connectors are soldered tabs onto screwed terminal blocks (except for the Raymaine 2.8mm spade connectors).
I could progressivly disconnect ST devices - but it can take 1 to 2 hours between occurances (usually after I have started packing up to head home) so it might be hard to say which disconnection changed things?

Happy to look at any possibility. Andrew

What AP do you have?

 

[Andrew G]

Erbas - you could be on an interesting track (with due defference to Nigel of course). I'm getting "turn that PC off" sounds so won't check the manual tonight. How would that sit with the fact that it occurs without the E85001 by inputting straight to the NMEA in of the CP? (if the CP IS outputting something onto the ST bus that would do it - but why now and why not with the old 120 setup? [Edit: because the 120 had a higher priority?]).

Andrew

 

[Andrew G]

Talulah, Hi, I have ST60 instruments (wind, tridata) and a 4000+ tiller AP.

 

[Talulah]

Talulah, Hi, I have ST60 instruments (wind, tridata) and a 4000+ tiller AP.

If this were me I would rig the AP as a standalone system for the time being and see if the problem goes away.

 

[Gypsy]

Andrew
The fact that the problem occurred when connecting GPS NMEA directly to the plotter means it can't have anything to do with the priority of the ST from the E85001. Of course we don't know how the SL631 deals with multiplexing the ST and NMEA inputs but they are different inputs and have a processor to sort them out. I do know that generation of Raymarine gear always gave priority of ST over NMEA if both were present. However, in this case GPS is only on one source.

Perhaps you should try RMC only from the GPS connected direct to NMEA on the SL631 to start at the simplest possible combo. If all OK then connect the normal ST bus to the 631. If it fails you can then look to disconnect ST items individually, a tedious exercise I know. If OK you can then increase the messages from the GPS.

But, I can't believe it is bus congestion. Raymarine say you can connect something like 30 ST devices on any ST bus. The ST data is very efficient. It is all Hex and although sometimes a message can be up to 18bytes they are normally only 4-8bytes.

Another point to check is how long the plotter takes to sound the No Fix alarm after you remove the GPS signal. I will check my system when I go to my boat tomorrow but I think it takes seconds, not milliseconds. If so it would point to something other than data collisions which are random in ST due to the previously described transmission method and therefore unlikely to lose more than one message which shouldn't cause the Plotter to think the fix is Lost. Remember, the GPS signals send fix/no-fix info as part of GGA & GSA so you might be getting the alarm message from the GPS not from the plotter. If that were to be the case logging the GPS output on a PC would be a great diagnostic tool but it would be much better if you had a logging program with timing so that you could go back in the log to the approximate time of the error to look for the detail of the NMEA messages.

I’ll experiment on board and let you know the results. Also tks for the other info on the software update C-Map Card.

 

[Bru]

How would that sit with the fact that it occurs without the E85001 by inputting straight to the NMEA in of the CP?

I'd say that scuppers my theory :ambivalence:

 

[nigelmercier]

... How would that sit with the fact that it occurs without the E85001 by inputting straight to the NMEA in of the CP? ...

I missed that in the original thread, please disregard my suggestion regarding bus contention.

 

[Andrew G]

Ray and Erbas - thanks for your efforts. It takes at least 5+ seconds after disconnecting the GPS before there is an alarm (I havn't timed it). In fact the SoG goes to "- - -" a few seconds before the alarm. I can log the NMEA to file AND the resulting SeaTalk (I can read and write SeaTalk - that's another story). I am logging the NMEA before it gets to the E85001. I have been writing down the time the fix is lost and then checking the NMEA (and ST) logs for that time (UTC + 10 at present). I did get lost in the mass of files (I had 2 GPS' going) so I'll have to repeat some of it.
What do you think of the possibility of ST messages from the chartplotter conflicting with incoming ST position messages?

The GPS supplier suggested RMC only so I'll try that and then disconnecting ST item by item.
I'm off to Auckland (work) for a while (a 04:00 taxi tomorrow) so won't be able to get to the boat for a while - please don't take my silence to be lack of interest. Cheers, Andrew

 

[Andrew G]

Nigel - no problem, Andrew

 

[Gypsy]

Andrew
I have an RL80CRC and an E120W. When tested individually by removal of the GPS signal (removed from the NMEA input to the E58001) the results are:
RL80 - Loses SOG/COG after 35sec no alarm. Loses "Position" after 55secs and alarm/screen splash displayed.
E120W - Loses SOG/COG after 45sec no alarm. Loses "Position" after 70secs and alarm/screen splash displayed.

This indicates that you would need a LOT of data collisions or overtalk for that to be the cause of the problem. I think you can exclude it from your diagnosis. I'd suggest that if there was other interference on the bus then other data would be corrupted at some time or other too, not just GPS.

My GPS (Evermore SA320) is set to output GGA, GSA, GSV and RMC. In order to try to replicate the problem I decided to log the GPS NMEA data as it is fed to the E85001 and cause a GPS dropout and then analyse the data. The 'dropout' was achieved by putting a saucepan over the GPS mushroom antenna. As I was on my own I couldn't critically time the moment of the saucepan being fully in place and the drop of SOG/COG and arrival of the alarm messages, but the alarm delay was similar to that which occurred when disconnecting the GPS physically. Today I downloaded the GPS data from the test (about 2.5mins linear time) and imported it into an Excel spreadsheet to better separate and organise the data. Part of that process was to sort the data into messages so I could easily see what occurred. As GGA and RMC carry 'time' it is easy to track what is happening, and when.

I'd be happy to send you (or others interested) the spreadsheets if you want but here is the summary:
GGA
The number of satellites 'seen' quickly drops from 10 to 5 at the time of the initial cover-up of the GPS then over a period of 52secs the sat qty falls to zero. At that time GGA "GPS Quality" which was at 'Fix' drops to 'No Fix'.
RMC
"Status" drops from "A=valid" to "V=Warning" and SOG/COG go to no data at exactly the same time as GGA reports No Fix.

So the GPS sends No-Fix flags and stops sending SOG/COG to the plotter at the same time. I saw that when I simply removed the data the plotter takes 35secs after loss of data for the SOG/COG to disappear and a further 20 secs to sound and display an alarm. I expect that these delays are built in to the plotters by Raymarine to allow for the occasional dropout or corruption of the GPS and instrument data and the delay may even be altered by 'damping' in some plotters. The longer reaction time to the 'cover-up' is seen in the GPS data as it takes time to realise it has lost the satellites since it really only needs 4 and can work with 3, whereas 'pulling the plug' causes the plotter to start the count immediately.

So where does that leave you? Dunno! You say you have tried an identical GPS with the same results. I think you also said you tested the GPS/Plotter combo at home and it worked fine. In your place I would log the GPS output and note when a No-Fix occurs. Since both GGA and RMC carry time it is easy to get back to the approximate time of the problem. Chop out a 5min segment of the log with the problem time included and import it into Excel, then sort by NMEA sentence type. Once you see those separate sentences you will quickly see changes and holes in the data, if the GPS is the cause. If you can't see a hole in the data of many seconds then I doubt the GPS is the culprit and you'll be back to suspecting the plotter or other general interference, however if there was general interference I would expect it to corrupt other data too, not just GPS which actually takes quite a long time to show it is messed up.

An interesting bit of detection, I'm glad I only had to do it with NMEA not Seatalk!!

PM me for my phone number if you want to discuss any of this.

 

[Andrew G]

Hi Gypsy - I've PMed you. I suspect it is not the GPS but the chartplotter/the system but I will keep looking (I'm back in Aus now). Thanks Andrew.

 

[Gypsy]

Hi Andrew
You have previously mentioned that the GPS is a 50ch unit. What is the model? I would be interested to see the GSA and GSV messages to see how many satellites are seen and how many fields of satellite data are sent. I don't have a formal NMEA spec but the sentence listing I have suggests GSA can only handle 12 satellite data fields and I think the same limitation is placed on GSV which should have only 3 sentences in a group to a max of 12 satellites. If your GPS is putting out more than 12 channels of data in its NMEA sentences, then perhaps the SL631 plotter eventually gets confused. It was designed when 10-12ch GPS were the norm.
Operating the GPS with RMC only at the output could help prove/disprove this point. If the SL631 operates without problems for a long period with RMC only, it would suggest the GSA and/or GSV sentences are confusing the plotter. When you have RMC only, the SL631 won't show the satellite signals (histograms) but it should be quite happy to operate for Position and SOG/COG data.

Worth a try.