I am using a Brookhouse iMux with a combination of Raymarine
instruments communicating via Seatalk
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.
bus – all Raymarine
DSM30 Digital Sounder Module
ST60 Tridata (depth, speed, water
(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
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
to allow the VHF
to be used stand alone (at anchor) and still receive position data.
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.
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.