Seatalk/NMEA Raymarine/Garmin connection and ZDA sentence

[Plevier]

I know there have been similar threads before but haven't been able to find - don't talk about the new software.

I have Raymarine ST60 wind, tridata, and multi instruments and ST4000+ wheelpilot.
I'm thinking of getting a Garmin 750 chartplotter.
My interpretation of the manuals is that:

1 I can connect the Garmin's NMEA output to the Raymarine system input at either the multi instrument or the ST4000+, whichever is easier (one is at the helm, the other at the nav table), and either will accept the data, convert to Seatalk and send it around as necessary.

2 I can connect the multi's NMEA output to the Garmin's NMEA input to transmit depth etc. According to the manual it converts DBT, HDG, HDM, MTW, VHW and MWV from Seatalk and outputs them as NMEA.

3 The multi manual does not say whether it also re-transmits all NMEA received as well as the conversions listed above, so

QUESTION 1 - can I connect this output to the DSC radio, or will I have to connect that direct to the Garmin to get position?

4 My DSC radio - a Skanti 1000P DSC, same thing can also be badged Sailor - will only take the time from a particular NMEA sentence, ZDA. Without that sentence there is a built-in clock but it can get out of step. Neither the Garmin nor the Raymarine outputs that sentence (nor does my existing Interphase plotter.) In fact I can't find any leisure market device that does.

QUESTION 2 - does that matter? If the internal clock is wrong, is a DSC message out going to be timestamped wrong? Seems a poor system if so. If it does matter,

QUESTION 3 - is there any way of creating the ZDA sentence from the Garmin output. It's implicit within RMC or GGA isn't it? (This sounds like a YAPP!) Alternatively:

QUESTION 4 - does any of the cheap GPS devices that I could dedicate to the radio instead of connecting to the Garmin output ZDA?

Thanks!

 

[nimbusgb]

With an Arduino board ( other brands are available ) you could synthesise the ZDA sentence from others available quite simply.

Does it matter if the radio clock is wrong. Good question I somehow doubt it but as you say the timestamp could be used by the receiving radio to calculate something but I have no knowledge in that arena! The manual for the Sailor radio mentions the logs being scrambled by an out of sync timesource, oh and the radio will ask you for the time every 4 hours apparently

 

[Plevier]

With an Arduino board ( other brands are available ) you could synthesise the ZDA sentence from others available quite simply.

Does it matter if the radio clock is wrong. Good question I somehow doubt it but as you say the timestamp could be used by the receiving radio to calculate something but I have no knowledge in that arena! The manual for the Sailor radio mentions the logs being scrambled by an out of sync timesource, oh and the radio will ask you for the time every 4 hours apparently

Thanks Ian - I would have no idea how to program it! I can build hardware though.
I think you must have looked at a different Sailor radio. Mine is http://ebookbrowse.com/skanti-vhf-1000-p-dsc-pleasure-vhf-operators-manual-pdf-d35776866
Mine does not nag me for time. As said it does have an internal clock that you set manually or synchronises if you have ZDA input.
Mike

 

[pvb]

I'd connect the plotter NMEA output to the radio separately. And I'd ignore the idea of automatically synchronising the time through a ZDA sentence - how wrong does the clock get over 24 hours or so?

 

[earlybird]

.. Neither the Garmin nor the Raymarine outputs that sentence (nor does my existing Interphase plotter.) In fact I can't find any leisure market device that does.

....QUESTION 4 - does any of the cheap GPS devices that I could dedicate to the radio instead of connecting to the Garmin output ZDA?

Thanks!

FWIW, my Furuno GP32 outputs NMEA ZDA, and so does the Raymarine Seatalk / NMEA bridge, if it has a suitable Seatalk input. Neither is a cheap solution though.

 

[AngusMcDoon]

You could do it with a PIC16F882 (£1.27), 2 RS422 transceivers (25p each), a voltage regulator (20p)...and not much else. You would need someone to write the software if you could not.

The ZDA sentence is local time rather than UTC. I'm not aware of any other NMEA sentences that have local time in them, although lots have UTC. So you would also need some way of setting local/UTC offset. You could do it with a piano switch which would cost you another 50p.

 

[Otter]

I've got a NMEA Garmin/Raymarine Seatalk setup; but as I understand it, NMEA is designed for single talker and multi listener, the only way I think around that is to use a multiplexer.

I use the Garmin to talk position, speed, XTE blah blah and the Raymarine autopilot uses that (the wind jobby could as well for true wind). If I'm wrong please tell me but I think that means only the Garmin can be the talker?

 

[nimbusgb]

You could do it with a PIC16F882 (£1.27), 2 RS422 transceivers (25p each), a voltage regulator (20p)...and not much else. You would need someone to write the software if you could not.

The ZDA sentence is local time rather than UTC. I'm not aware of any other NMEA sentences that have local time in them, although lots have UTC. So you would also need some way of setting local/UTC offset. You could do it with a piano switch which would cost you another 50p.

And some soldering technique and a programmer, time, and and and....

To get time zone just get the longitude and work it out ..... Close enough to not matter or just keep the radio at UTC

 

[Plevier]

I'd connect the plotter NMEA output to the radio separately. And I'd ignore the idea of automatically synchronising the time through a ZDA sentence - how wrong does the clock get over 24 hours or so?

You may well be right on both counts. However if I put the new Garmin at the helm it would be so much easier if I can connect to the radio from the multi instrument that is below.

 

[Plevier]

You could do it with a PIC16F882 (£1.27), 2 RS422 transceivers (25p each), a voltage regulator (20p)...and not much else. You would need someone to write the software if you could not.

The ZDA sentence is local time rather than UTC. I'm not aware of any other NMEA sentences that have local time in them, although lots have UTC. So you would also need some way of setting local/UTC offset. You could do it with a piano switch which would cost you another 50p.

Interesting - I didn't realise ZDA is local time. I would have thought DSC would want to use UTC for timestamping.
No, I couldn't do the software.

 

[Otter]

I found that Garmin do a very funny connection for NMEA, the wires were unlike other connections but I can't remember what it was. Had to google it anyway.

 

[Plevier]

I've got a NMEA Garmin/Raymarine Seatalk setup; but as I understand it, NMEA is designed for single talker and multi listener, the only way I think around that is to use a multiplexer.

I use the Garmin to talk position, speed, XTE blah blah and the Raymarine autopilot uses that (the wind jobby could as well for true wind). If I'm wrong please tell me but I think that means only the Garmin can be the talker?

You may be right, I really don't know, but I hadn't seen it that way.
A single NMEA connection is not bidirectional, but both the Garmin and the Raymarine (the multi instrument only, do you have that one?) have separate in and out NMEA connections so why can't I have them giving info to each other?
Similarly I understand that the radio can give the Garmin the location of an incoming DSC alert as well as receiving position from the Garmin.

 

[pvb]

You may be right, I really don't know, but I hadn't seen it that way.
A single NMEA connection is not bidirectional, but both the Garmin and the Raymarine (the multi instrument only, do you have that one?) have separate in and out NMEA connections so why can't I have them giving info to each other?
Similarly I understand that the radio can give the Garmin the location of an incoming DSC alert as well as receiving position from the Garmin.

With separate in and out ports, you can have NMEA data going in both directions. However, if you hook 2 talkers on to a single input, you'll get conflicts and corrupted data. So if you want to send DSC data to the plotter as well as depth (etc) data, you'll have to wire each talker to a separate input port - the 750 plotter has 2 NMEA inputs, so that's OK.

 

[Plevier]

With separate in and out ports, you can have NMEA data going in both directions. However, if you hook 2 talkers on to a single input, you'll get conflicts and corrupted data. So if you want to send DSC data to the plotter as well as depth (etc) data, you'll have to wire each talker to a separate input port - the 750 plotter has 2 NMEA inputs, so that's OK.

Thanks, you're confirming what I thought.

 

[AngusMcDoon]

And some soldering technique and a programmer, time, and and and....

To get time zone just get the longitude and work it out ..... Close enough to not matter or just keep the radio at UTC

The soldering would be easy - all through hole 0.1" pitch. Could be done on Veroboard in 20 minutes. A programmer costs about £8 new from EBay. The hardest bit is writing the software for someone who doesn't know how to do it.

Using just longitude for UTC offset would immediately give the wrong value when sailing from Dover to Calais. An algorithm giving local time from lat/long/UTC time/date would not be a trivial undertaking.

 

[laika]

The local time issue may be a red herring. ZDA carries UTC and local time offset. I suspect the latter may be used for display but I seriously doubt that is anything more than cosmetic: Timezones are set manually on the device that transmits them. I don''t feel in any danger not changing my plotter's local time offset when entering French waters . If you're doing a conversion and happy to have UTC displayed, I'd just stick in 0s for local hour/min offset. The time in RMC, GGA etc. is conceptually the time of the associated fix rather than "the time" but in practice for that should be irrelevant.

My C90W will output ZDA, as (I note from the manuals) will the new Raymarine plotters. The e7 is rather more than the Garmin 750, but might be worth looking at other brands?

 

[AngusMcDoon]

The local time issue may be a red herring. ZDA carries UTC and local time offset. I suspect the latter may be used for display but I seriously doubt that is anything more than cosmetic: Timezones are set manually on the device that transmits them. I don''t feel in any danger not changing my plotter's local time offset when entering French waters . If you're doing a conversion and happy to have UTC displayed, I'd just stick in 0s for local hour/min offset. The time in RMC, GGA etc. is conceptually the time of the associated fix rather than "the time" but in practice for that should be irrelevant.

My C90W will output ZDA, as (I note from the manuals) will the new Raymarine plotters. The e7 is rather more than the Garmin 750, but might be worth looking at other brands?

I can understand the idea of leaving the time in UTC, but Troubadour's original problem was the clock was wrong and had to be manually set. I change my on-board clocks for summer time as well as different time zones, but I can understand that not everyone wants to. If I don't I turn up at shops at the wrong time and miss the Archers.

On the imaginary solution I have proposed there could be 2 push buttons. Push one for incrementing offset by 30 mins, push the other for decrementing, and save the new offset in the processor's flash memory so that it is remembered between power cycles. Even cheaper and less to solder. I know that some countries have time offsets of quarter hours, but I don't often sail past Nepal.

 

[laika]

I can understand the idea of leaving the time in UTC, but Troubadour's original problem was the clock was wrong and had to be manually set. I change my on-board clocks for summer time as well as different time zones, but I can understand that not everyone wants to. If I don't I turn up at shops at the wrong time and miss the Archers.

Troubadour can answer this but I had assumed (not necessarily confirmed or denied by re-reading original post that the concern was more about whether accurate time in any generated DSC message was an issue. If you just keep zone offset as 0 and display UTC you get accurate DSC timestamps with minimum complexity. Knowing your instrumentation is in UTC sidesteps any fuss over timezones when travelling east/west (or to france). I would have thought wall clocks or wrist watches were more commonly checked for proximity to closing time than the VHF.

Analogue electronics is not necessarily simple to all, and I suspect many people would rather do 10 years of mental zone conversions from UTC when necessary than stare at Farnell or RS's list of voltage regulators trying to decide which one to use

 

[AngusMcDoon]

Troubadour can answer this but I had assumed (not necessarily confirmed or denied by re-reading original post that the concern was more about whether accurate time in any generated DSC message was an issue. If you just keep zone offset as 0 and display UTC you get accurate DSC timestamps with minimum complexity. Knowing your instrumentation is in UTC sidesteps any fuss over timezones when travelling east/west (or to france). I would have thought wall clocks or wrist watches were more commonly checked for proximity to closing time than the VHF.

Analogue electronics is not necessarily simple to all, and I suspect many people would rather do 10 years of mental zone conversions from UTC when necessary than stare at Farnell or RS's list of voltage regulators trying to decide which one to use

My understanding is that he is not getting time via NMEA at all, because his system does not produce the needed message, so a NMEA conversion is needed, whether this outputs UTC only or UTC and local offset. All I'm saying is that if a DIY converter was made, it would be trivially simple to add a manual local offset capability. No analogue electronics involved. It's all digital.

I'm not suggesting Troubadour stares at RS parts lists; he has already said that he cannot do the software. However, with a bit of support here I might have been persuaded to create a device that does what he needs. However, I'm not finding the posts encouraging.

 

[Plevier]

I've been thinking about this and independently come to same conclusion as laika.
Looking at the manual for my previous boat's M-TECH radio (which is written in English where the Skanti one is in gobbledygook!) as a comparison it clearly says that it takes UTC for DSC transmissions from the GPS (the RMC sentence the only input sentence it takes). It also shows the display screen when you receive a DSC message and that displays the time of call as UTC.

The Skanti takes in GGA, GLL - both of which include UTC - and ZDA

I found this about ZDA.
$GPZDA

Date & Time

UTC, day, month, year, and local time zone.

$--ZDA,hhmmss.ss,xx,xx,xxxx,xx,xx
hhmmss.ss = UTC
xx = Day, 01 to 31
xx = Month, 01 to 12
xxxx = Year
xx = Local zone description, 00 to +/- 13 hours
xx = Local zone minutes description (same sign as hours)

So it appears to send UTC and an offset rather than a corrected time (as laika said).
How does it know the offset? Is it just geographic (i.e. longitude based), in which case frequently wrong as Angus points out, or is it truly local (impossible surely!)? That would be utterly confusing for DSC!

The manual for the Skanti does say "if a GPS is connected, time and position are automatically selected." It doesn't define what time and which sentence it gets it from. It doesn't say whether it needs ZDA for it.
If a GPS is not connected and you make a distress call, it prompts you (this is in the manual, not done it) for lat, long and time, doesn't say whether to use local or UTC.

If you are manually setting the internal clock, you input in this order "Tzone XX (must allow negative too?), UTC Hour XX Mins XX Secs XX Year XX Month XX Day XX" (page 28 of the manual I linked to earlier).
The time is not normally displayed. If you call it up to view it you get a scrolling bar of "Tzone XX, Localtime XX XX XX, Date XX XX XX"

The Skanti is a high spec system and its radio performance and clarity are the best I've ever encountered. Unfortunately the manual is the worst I've ever encountered on anything!

I'm going to set the clock to UTC and leave it there (as I do with the clock in the cabin!) and check the memory battery (CR2032). Time is never displayed on the unit unless you deliberately call it up to check it, involving going into setup routines with multiple button presses. So why does it bother with local from ZDA? It seems pointless!