MyBB Internal: One or more warnings occured. Please contact your administrator for assistance.
Raymarine forum - [CA11] Heading Flash Offset

Raymarine forum

Full Version: [CA11] Heading Flash Offset
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
With our previous e-series units targets dead ahead were on the heading flash with no offset dialed in - we never had to adjust this. With the new Axiom Pro 12 units just fitted we had to dial in an offset of 15degS to align targets with the heading flash. The 12kW SHD 48" array was not re-positioned or moved. It's not clear why this would be. Does this indicate something is amiss? Software has been updated to 3.8.105.
Welcome to the Raymarine Forum Ian,

The radar bearing alignment value should be stored within the radome or open array pedestal. Accordingly, swapping the MFDs should have not required any re-configuration of the radar bearing alignment. If the radar has been configured to head up mode and radar target returns associated with objects at 000 relative are not appearing in line with the ships heading marker, then the radar bearing alignment will need to be adjusted. It would be recommended that the Radar application's performance in head up mode be monitored to determine if any additional adjustment is required in the future. If so, then it may indicate a problem with the radar pedestal's circuitry, necessitating the it be sent to Raymarine’s Product Repair Center to be bench checked / serviced.
Thanks for your response.

We have noted another issue that appears to be related to the 15°S heading flash error described above.

Magnetic variation in our area is 16°E. We normally leave the variation set in auto mode, however if we change to manual mode and set it to 0, the radar image rotates by about 16°E (clockwise). It is not obvious why there would be any link between magnetic variation and the head up radar image alignment.

We have also noted that most of the time at 25kts+ and in water free of currents the blue COG vector on the radar display lies up to 15° off the heading flash.

Heading information for the system is from an Airmar H2183 heading sensor and is usually within 5° of the reported COG while on a constant heading.

Hopefully this will help to troubleshoot the issue.


Thanks for the additional information. As you have suggested when operating in Head Up chart orientation and Relative Motion Mode (please verify), the vessel's heading and variation should have no effect upon the orientation of the radar image. Please attach a system diagram of this system for permit us to analyze it and make further recommendations. The diagram should list the makes/models of each marine electronics device and additionally indicate how these devices have been interfaced to the system.
Yes, relative motion. I'll work on getting a system diagram and list of equipment made up. Thanks!
The instrument diagram is attached. The 48" SHD array and the Airmar H2183 heading sensor were added prior to the MFD upgrade and did not affect the radar image alignment. The 15° alignment offset was not required until the Axiom Pro MFDs were installed. Please let me know if there is any further information that would be useful. Thanks for the help!

Please note that the H2183 cannot be interfaced to the system's Ethernet switch as indicated within your diagram. The H2183 is designed to be to support NMEA 0183 or NMEA 2000 communications. Accordingly, it must be interfaced either to the NMEA 0183 terminal strip as was the last sensor or as a spur to the system's SeaTalkng / NMEA 2000 backbone. Additionally, has your system been configured for True bearings or for Magnetic bearings?
It's configured for magnetic bearings.

Apologies, there is an error in the instrument diagram markup I sent - the Airmar H2183 is connected into the network NMEA backbone per the original drawing and not into the hub per the markup.

Another interesting discovery today, if we disconnect the H2183 heading sensor the radar image is properly aligned without any offset dialed in. The heading sensor appears to be introducing the error.

Per our conversation earlier this morning, with MFDs running LightHouse 3 software, the radar image on the radar screen is not updated once per sweep as it was in prior generation of Raymarine products. Within such systems which additionally feature heading source, the radar image is reoriented with each update from the systems heading source. In doing so, targets displayed on the radar screen (head up) will maintain proper orientation with respect to the ship's head between sweeps ... including situations where the vessel is executing a turn. As mentioned, this could easily be observed on my bench system because of the very close proximity of the radar transducer (source of magnetic deviation) to the heading sensor. As the radar transducer's motor turned, the amount of deviation would change, thereby shifting the image with sensed changes in the magnetic field. Accordingly, when performing the radar bearing alignment in Head Up mode, the system's heading source should either be disconnected or switched OFF. In doing so with my own system and then plugging the EV-1 CCU (heading source back into the MFD (Auto Variation = 14.5 deg W), I did not observe the offset which you had reported. I look forward to learning your results after having replaced the H2183 with an EV-1 CCU or AR200 (the latter may be calibrated via LH3 v3.8.105 software) within your system.
Yesterday the Raymarine dealer installed the EV1 sensor core on a trial basis and accompanied us on a sea trial. The behavior of the radar image was identical to the behavior with the H1283 sensor, i.e. an installation offset of 16°S (equal to our magnetic variation) was still required to align the image with the ships head. When the 16°S offset is dialed in the head up image in the radar app becomes properly aligned, but the radar overlay in the chart app then rotates out of alignment by the same amount.

We appreciate Raymarine providing the EV1 sensor on loan. This was a useful exercise in that it has ruled out the heading sensor as the source of the issue. Does this now look like a software issue?

We continue to operate with our heading sensor disconnected until a solution can be found.
Pages: 1 2
Reference URL's