unstable heading reading

[wefleenor]

I have a Furuno heading sensor that outputs nmea0183 and I connected that to the pi4 with a USB-TTL adapter. All was fine. I then connected my Navico radar to the pi and all worked fine. Finally I connected, via UDP, the heading to 2 other pi4 units and all was still fine. The first pi4 also has gps and depth input to it from a Maretron nmea2000-nmea0183 USB100 box. Sent all the info to the other 2 units via UDP and all was fine. After 3 days the heading readings have become unstable. Does anyone have a likely culprit or way to find the culprit? The heading sensor output seems stable on the Furuno autopilot, but perhaps it just maintains the last reading. Thanks.

[bdbcat]

First step:
Using the VDR plugin, record (and post) your incoming datastream on the device exhibiting the problem. Any instability of a particular NMEA message class should be clear by inspection.


Next steps: Depends on what you see in the datastream.

Dave

[wefleenor]

Thanks, I was not aware of this plugin and its ability.

[wefleenor]

I only recorded a very small time period, but the heading went in and out 3-4 times. Not knowledgeable enough to know the problem.


https://1drv.ms/u/s!AsqqtXq_ThqYhaIr...6hNOw?e=UyRxxE

[wefleenor]

I turned off all but the heading sensor and recorded until the error occurred and got:

$HCHDG,53.4,,,0.0,E*1B
$HCHDG,53.4,,,0.0,E*1B
$HCHDG,53.4,,,0.0,E*1B
$HCH,53,0,E*1CCHDG,0.,
$HCHDG,53.3,,,0.0,E*1C
$HCHDG,53.3,,,0.0,E*1C
$HCHDG,53.3,,,0.0,E*1C
$HCHDG,53.3,,,0.0,E*1C
$HCHDG,53.2,,,0.0,E*1D
$HCHDG,53.2,,,0.0,E*1D
$HCHDG,53.2,,,0.0,E*1D
$HCHDG,53.2,,,0.0,E*1D
$HCHDG,53.3,,,0.0,E*1C

There are times when it reads 53 MAG and times when the MAG is missing. Thanks for any thoughts.

[Hakan]

Originally Posted by wefleenor

I have a Furuno heading sensor that outputs nmea0183 and I connected that to the pi4 with a USB-TTL adapter.

A thought...
Why USB-TTL and what voltage is the TTL circuit made for?
A NMEA-0183 connection would be RS232(or RS424) and a TTL is normally not made for that voltage. If the USB-TTL can stand the higher voltage without a breakage the reading may be unstable?
What about testing a USB-RS232 converter instead?

[wefleenor]

Thanks, Hakan, that seems the likely culprit at this point. The autopilot runs well with its connection to the same heading sensor and I tried the usb-ttl adapter with another nmea0183 output and it wouldn't work at all. just need the waves to calm to make the last 200nm to the boat's new hoe and I can try that change to usb-rs232.

[wefleenor]

Hakan, I installed a usb-232 adapter with no change so I started from scratch and discovered both adapters are stable until I add the heading reading as a device in signalK and then it goes unstable for both. Is that to be expected? Thanks.

[Dsanduril]

How unstable is unstable? I see a discrepancy of about two degrees between VTG and HDG sentences (not necessarily unexpected). The HDG sentence has empty fields for deviation/variation, so, per the manual OpenCPN should use the WMM value (~14E for 40N 124W) unless a manual setting had been made. Any chance the instability is around that 14 degree amount? If not either of those, what seems to be the amount of instability?

[wefleenor]

My apologies, Dsanduril, by unstable I meant the value reporting goes on and off irregularly. It isn't just a WMM value error but a complete loss of the reported value.

[Dsanduril]

Digging a bit in the VDR file, the HDG sentences generally look like:

$HCHDG,54.1,,,0.0,E*19

But there is one place where the HDG sentence has the deviation field completely missing:

$HCHDG,54.1,0.0,E*19

Unfortunately, the checksum is still correct even though the sentence is incomplete. I don’t know what O would do with this.

If you play back the VDR file does the behavior occur? If it does, try again after removing that incomplete sentence. I’ll see if I can’t give it a try myself, but it will be later today before I can run the VDR playback.

[Hakan]

The "bad" HDG sentence is not used by OCPN. The checksum is parsed from position six and that's not present so it's "kicked" out.
And if the time between two valid HDG sentences exceed six seconds the heading is "lost" until next is received.

[wefleenor]

Originally Posted by wefleenor

Hakan, I installed a usb-232 adapter with no change so I started from scratch and discovered both adapters are stable until I add the heading reading as a device in signalK and then it goes unstable for both. Is that to be expected? Thanks.

Hakan, have you had a chance to think about why adding the heading reding as a device could cause the conflict that occurs? Thanks.

[Hakan]

Originally Posted by wefleenor

Hakan, have you had a chance to think about why adding the heading reding as a device could cause the conflict that occurs? Thanks.

Delayed....Sorry....sailing!
No I don't understand why and not the real connections either to be true.

My view so far:
-The heading signal from the compass instrument (Furuno?) is serial connected into one OCPN on a RPi4 - correct?
-This OCPN is used to forward the heading and more to other units via network and UDP - correct? (And no "feedback" by a simultaneous input on the output UDP connection!?)
-Is the bad heading occurrence connected to when the radar is working? (If so - check that you don't transfer the heading from radar_pi back to OCPN!)

[wefleenor]

Originally Posted by Hakan

Delayed....Sorry....sailing!
No I don't understand why and not the real connections either to be true.
)

For heaven's sake keep sailing. I have a work-around. Let's forget there are downstream UDP receivers, all the error originates in the sending Pi. It receives gps and depth from a Maretron USB100 device reading my nmea2000 backbone. It also reads nmea0183 heading from my Furuno heading sensor. It is also my signalK server. All works well until I add the heading sensor as a device in signalK. Can that be causing feedback? Thanks.