Imux NMEA communication error

[mkgsail]

I am using a Brookhouse iMux with a combination of Raymarine instruments communicating via Seatalk and Garmin instruments communicating through the iMux via NMEA 0183. My chartplotter is a Windows Computer running OpenCPN and connecting through wifi to the iMux..

I have been running without issue for two years but now have a problem after making some system changes. I am hoping someone can help me pinpoint the issue.

Seatalk bus – all Raymarine:
ST60 Wind Instrument
DSM30 Digital Sounder Module
ST60 Tridata (depth, speed, water temp)
P70 Autopilot Control Head (with Seatalkng to Seatalk cable adapter)
S2 Smartpilot Computer (autopilot)
Seatalk bus connected to the iMux Seatalk input for ground shield and data signal only.
The original system had a Raymarine 112LP GPS receiver. This receiver failed and has been disconnected to allow the iMux to use the AIS data as the source for lat/lon position and COG/SOG data and rebroadcast as IIRMC via wifi to OpenCPN and NMEA 0183 to the DSC radio.

Original system also took iMux power from the Seatalk bus. I recently switched the iMux power input (only) to the separate 12V source to the Garmin AIS and VHF to allow the VHF to be used stand alone (at anchor) and still receive position data.

NMEA bus:
Garmin VHF200 DSC radio - connected to iMux channel #2 input and RS-422 output
Garmin AIS600 class B AIS transponder with dedicated GPS receiver – connected to iMux channel #4 input (38400 baud)

I recently added a second connection from the RS-422 output to the NMEA in of the Raymarine S2 Smartpilot to allow it to receive the active route information from OpenCPN. When this connection is made, the problem presents itself.

Problem:
All systems work fine on initial startup. Position, COG, SOG and all instrument data are properly received by OpenCPN and the DSC radio. I have yet to fully test the autopilot route data input for more than a short test at anchor but it appears to be receiving the data and responding correctly to it.
The problem occurs several minutes after system power up: The latitude data in the iMux’s output IIRMC sentence jumps to an erroneous position many miles north of the boats actual position. This error can be seen in both the wifi output to OpenCPN and the RS-422 output to the VHF radio. Several minutes later and another erroneous latitude change occurs.
This problem stops occurring when I disconnect the RS-422 connection at the S2 Smartpilot computer!

I confirmed that the AIS600 was still outputting the correct latitude via direct computer connection to its diagnostic port. AIS data for other vessels also appears correct. So it seems either the AIS600 data output is being corrupted in its transmission to the iMux (seems unlikely as only a latitude error occurs), or the iMux is experiencing an internal logic fault, perhaps due to system noise.

Brookhouse support's comments on this are below. Their reasoning does not seem to consider the fact that the problem only occurs with the NMEA output of the iMux is connected to the Smartpilot and my direct confirmation that the AIS position data is accurate at the AIS.

The GPS (RMC) data to OpenCPN and data to the VHF follow 2 different paths: To OpenCPN via the full combined data stream, to the VHF routed from input 4 to the RS422 port if no GPS data on Seatalk is detected.
If the wrong lat is the same in OpenCPN and the VHF, the problem must occur somewhere between the AIS xponder output and the iMux port 4 input buffer.
Now, if it were an iMux input port (4) or buffer problem, more than just the lat would be garbled. The iMux processes the NMEA sentences transparently, without looking at individual data fields. My conclusion is therefore that the latitude can only be garbled by the only device that is aware of the RMC structure, being the GPS of the AIS transponder.
It would be interesting to check if the RMC sentence checksum is correct. If you have ticked “control checksum” in the OpenCPN settings and the sentence is not ignored (good checksum), this would give extra support to the above conclusion. As you say yourself, it is hard to find any relation between the RS422 output and the erroneous lat field. Any problems caused by noise, poor connection etc. would not selectively affect a specific data field. Again, I can only explain the problem as a result of an (intermittent) problem with the AIS xponder GPS.

[rgleason]

The problem occurs several minutes after system power up: The latitude data in the iMux’s output IIRMC sentence jumps to an erroneous position many miles north of the boats actual position. This error can be seen in both the wifi output to OpenCPN and the RS-422 output to the VHF radio. Several minutes later and another erroneous latitude change occurs.
This problem stops occurring when I disconnect the RS-422 connection at the S2 Smartpilot computer!

I have a very similar situation which needs to be resolved, and I believe it is associated with a nmea connection to my Autohelm Raytheon Wheelpilot 4000 which I need to resolve before I can record useful depth data for VfKaps_pi and VentureFarther.com.

Some of the responses upon seeing my carefully draw wiring diagram were, "That's far to complicated." and try to isolate the problem by simplifying the system.

My system has
Raymarine ST60 Tridata, Depth and Wind Instruments.
Wheelpilot 4000
Raymarine STng - ST converter for the Instruments (old ST1 to STng Nmea2000)
A carefully hand wired connection from STng to Nmea2000 to get instrument data on the chartplotter

B&G ZeusTouch12 + 4G Radar
GadgetPoole ST Link from ST Seatalk bus for the PC with OpenCPN

In addition, I have in the past taken nema data from the nema input (or output maybe) on the Wheelpilot forward to my VHF + GPS puck. I believe it may be this wiring that is the problem, and causing a backfeed of nmea O183 that makes its way back onto the nmea2k bus. I need to trace it out.

How many GPS devices do you have connected?
Do you have any nmea0183 wiring which will create doubled sentences?

See my unresolved troubles here:
http://www.cruisersforum.com/forums/...ml#post2467799

Shows the Gps jumping and malformed RMC without date and time.
http://www.cruisersforum.com/forums/...ml#post2467076

[Hakan]

mkgsail

I recently added a second connection from the RS-422 output to the NMEA in of the Raymarine S2 Smartpilot to allow it to receive the active route information from OpenCPN. When this connection is made, the problem presents itself.

If I understand you correct that's not possible.
One sender, like a GPS, can be direct connected to one or more receivers.
But the opposite is not possible. To connect two senders to one receiver you must use some kind of multiplexer. (Like OpenCPN for example) Connect the two transmit signals to two OCPN USB. Send it out to wherever you want.
Håkan

[rgleason]

Hakan,
This made me think that perhaps I had some extra OpenCPN output connection that was causing the intermittent spurious gps sentences? After checking the wiring, I'll have to verify the connections settings in Opencpn as well, because my nmea o183 connections are through the gadgetpoole ST Link which is "bidirectional".
Thanks.

Connect the two transmit signals to two OCPN USB. Send it out to wherever you want. Håkan

[mkgsail]

RGLeason, Looking at your other threads you appear to have an even more complex situation to debug than I do.
I have only my AIS for GPS data on my network as my Raymarine LP112 has an inexplicable COG offset error so I am not using it.
I do want a second GPS source on the network and am going to try a Dual XGPS150A bluetooth puck. This will of course not be dependent on the NMEA network and multiplexer so may have a favorable outcome on the problem I am currently experiencing.

[mkgsail]

Hakan,
I am not trying to connect two senders together.
The RS-422 output from the multiplexer is a sender. The VHF radio and the Smartpilot receive data from that multiplexer output.

[Moo]

Words are one thing... a picture usually a lot less ambiguous.

Can you post a diagram please?

Cheers

[jstevens]

Sorry if I'm asking an obvious question. I've used a Brookhouse Mux (not the iMux) for over 13 years, but not using the VDO AIS sentence as the source of the vessel's position. Does the iMux use the VDO sentence to create a GPS sentence (RMC?) to provide position data to OpenCPN and separately for DSC radios?
Then the iMux must be not be transparent to that NMEA sentence, and the Brookhouse response is not correct. If my assumption about the iMux function is correct I would take the issue back to Brookhouse for further analysis.
I've worked with Wout at Brookhouse on many occasions, and he has always been thorough and responsive. I'd give him another chance.

John

[jstevens]

Just read the Garmin manual, and realize the AIS600 transmits the RMC sentence along with the VDM sentence to the iMux. So the Brookhouse analysis is reasonable.

John

Added: It appears your are sending the RMC sentence to the AP via the NMEA network. The AP will probably put that data on the SeaTalk network which the Imux will likely convert to an RMC for output on the NMEA output of the mux. This should not cause a major roblem, but I would talk to Brookhouse once more on the issue. Also ask them for an editing script to suppress the RMC sentence from the SeaTalk port. You don't need that sentence as long as the AIS600 is powered on.

Here's a link to my experience with earlier models of the Brookhouse Mux
NMEA Multiplexer

[mkgsail]

Moo - good point. I will work on a diagram.

JStevens - Thank you for your comments and sharing your multiplexer setup and experience.
I had not thought about the AP creating new NMEA output once it is receiving NMEA data in. I looked it up and it does output GLL. While this should not be a problem it could be the case that I have a problem in my AP and it is outputting erroneous position data and only outputting that data when it has NMEA in. It definitely gives me good ideas for my next steps in investigating the issue.
Unfortunately my boat is on the hard in Grenada and I will not be back aboard to investigate this possibility until late this year.

[jstevens]

mkgsail,
I was also thinking the AP might put GPS data on the SeaTalk network since it was not receiving any position data from that channel. That data would feed to iMux SeaTalk port and the iMux would likely create an RMC sentence from that data. Those thoughts are questions for Raymarine (will the AP generate position data on SeaTalk if no GPS on that network) and Brookhouse (would the iMux generate a RMC from SeaTalk position data generated by the AP).

FWIW, just in the last few days I've had to trouble shoot my AISC mux for the first time in 5 or 6 years, due to the old Prolific USB driver issues. That made me remember (something I don't do very well these days) that I have a similar problem with my NMEA network (driven by the AISC mux), where the latitude for one second goes due north for 20 miles or more. I only noticed this problem when I started processing GPX track files from OpenCPN. Real time it happens so fast I never noticed the blip on my plotter or PC. Since it didn't affect my navigation I never pursued the issue with Brookhouse or Raymarine. I long ago disconnected the AP NMEA output from the mux, but I don't remember if I did that before or after the latitude issue appeared.
This does smell like a Brookhouse issue.

John

[MikeFergie]

I’m not sure what AIS unit you have but on my Raymarine 650 AIS unit it specifically warns about using the gps unit for the AIS connecting to anything else and using the GPS info

[bcn]

The Ray &50 AIS is a rebranded em-trak unit.

Those devices will forward the AIS and GPS NMEA data when configured correctly.
For example via the USB port as NMEA0183 stream.

Doing that since 6 years ...

[rgleason]

Originally Posted by jstevens

mkgsail,
I was also thinking the AP might put GPS data on the SeaTalk network since it was not receiving any position data from that channel. That data would feed to iMux SeaTalk port and the iMux would likely create an RMC sentence from that data. Those thoughts are questions for Raymarine (will the AP generate position data on SeaTalk if no GPS on that network) and Brookhouse (would the iMux generate a RMC from SeaTalk position data generated by the AP).

FWIW, just in the last few days I've had to trouble shoot my AISC mux for the first time in 5 or 6 years, due to the old Prolific USB driver issues. That made me remember (something I don't do very well these days) that I have a similar problem with my NMEA network (driven by the AISC mux), where the latitude for one second goes due north for 20 miles or more. I only noticed this problem when I started processing GPX track files from OpenCPN. Real time it happens so fast I never noticed the blip on my plotter or PC. Since it didn't affect my navigation I never pursued the issue with Brookhouse or Raymarine. I long ago disconnected the AP NMEA output from the mux, but I don't remember if I did that before or after the latitude issue appeared.
This does smell like a Brookhouse issue.

John

Thank you John. This is a familiar symptom for me, and I believe it is some gps type loop you mention.

[mkgsail]

jstevens,
I have seen instantaneous position errors on openCPN tracks on my computer screen. Sometimes a latitude only glitch and sometimes longitude. Once it was both. I visited the canary islands for 4 seconds. I have seen this with my original Raymarine GPS and with my AIS-derived RMC, both reaching my computer via my Wifi-enabled imux-ST. I can see single erroneous RMC sentences reaching openCPN that cause this. I had not associated my position error that shows up only when I connect the NMEA in to my AP as the position error remains for an extended time. Perhaps they are related.
Based on input received in this thread and new ideas I have I intend to test (in December):
- Capture the NMEA stream at openCPN when I connect the AP NMEA in. I will look for GLL and the erroneous RMC sentences.
- Turn on NMEA checksum in openCPN. I thought I had it on but will double check. It seems unlikely that it is a data transmission error since only one field of data in the RMC sentence is corrupted.
- Evaluate a bluetooth GPS puck, bypassing the NMEA network and iMux for RMC data.