December 23, 2021  The Bridge makes old sensors compatible

The new firmware allows re-assembling of NMEA 2000 fast packets and forwarding them in the exact order to comply with the new requirements in Garmin, B&G, Simrad and Lowrance displays.

New math constants

Every time we release a new firmware for the Bridge, we are sure that we have created the best possible product. However, in 2019 we added trigonometry functions to process coordinates and angles, and encryption to distribute encrypted programs and to lock the user program to create your own hardware products on the basis of the Bridge. At the end of 2019, we also added the disassembler, to allow developers to understand the program in detail.

In the beginning of this year, we added configuration of user programs through installation description strings. It is cool feature, because users or installers can configure the setup without access to the code and they do not need to be a programmer.

And now we have rewritten many things inside to make the Bridge much faster. We recommend this update to all users, because it has serious internal changes which are important in high-load applications.

Along with it, we added three new constants: M_180P, M_1800P and M_P180, which are float32 versions of the 180/π, 1800/π and π/180 numbers (the Bridge always had M_PI, M_2PI and M_PI2 constants, which are equal to π, 2*π and π/2).

The Bridge uses 32-bit floating point math and that is enough to calculate coordinates within 10 centimeters' resolution. Actually, the result of 1800/M_PI (hexadecimal 0x440f3d4c) in the Bridge is 0.0000031 less than the actual value of 1800/π. And the constant M_1800P (hexadecimal 0x440f3d4d) is on 0.0000029 bigger. Formally, the new constant is more exact, but the difference is not significant in comparison to how far both are from the actual value. If you want to play with 32-bit floating point numbers, we recommend this link: https://www.h-schmidt.net/FloatConverter/IEEE754.html

We recommend using new constants, because it makes your code more readable and saves time on calculations. Because the Bridge has no code optimization, and every time you write 1800/M_PI, it will load two numbers and perform the operation.

The next new feature is the STRICT_QUEUE setting, which is OFF by default. NMEA 2000 has "fast packets", which allows transferring up to 223 payload bytes in standard CAN frames, which have 8 data bytes. The first data byte in the CAN frame is used for the sequence number and frame number, and the second byte in the first frame is used to indicate the payload length.

For example, below is the "fast packet" with a 23 (hexadecimal 17) payload length:

   19FF1404 40 17 89 98 00 01 BC 43
   19FF1404 41 00 F8 05 1B 4A 45 50
   19FF1404 42 BB 8C 1B 77 00 01 00
   19FF1404 43 01 00 FC FF FF FF FF

The number of the sequence is stored in the 3 highest bits of the first data byte; it is used to separate two consecutive fast packet messages with the same PGN.

The NMEA 2000 standard does not require a strict order of "fast packet" frames on the bus. Many chips have 3 hardware outboxes to send data to the CAN bus. When we need to transfer the "fast packet" as shown above, the first 3 frames can be pushed to 3 outboxes and the software can forget about them and return to other operations. The CAN controller hardware will wait until the bus is free and then send the frame from the first outbox. After that, it will inform the software that first outbox is free and start transferring the frame from the second outbox at the same time.

The software will upload the last frame to the first outbox. It has higher priority than outboxes 2 and 3, so (depending on bus load, interruptions in handling in the software and many other factors) the frames can appear on the bus in the order 0, 1, 3, 2 or 0, 1, 2, 3 or even 0, 3, 1, 2.

It is known that the latest models of Navico MFDs (B&G, Simrad, Lowrance) and Garmin MFDs require the strict order of "fast-packet" CAN frames on the bus. We sure that this is improper. And for sensors with inexpensive chips it can effect on performance, because from now they can use only one outbox and load messages one-by-one to ensure the strict order of frames.

Moreover, old sensors certified for NMEA 2000 may become incompatible with new displays. For example, the Simrad GO7 XSR with firmware 18.3 does not display engine data if the frame order is not strict.

You can turn on the strict order on any CAN interface of the Bridge with STRICT_QUEUE=CAN1 or STRICT_QUEUE=CAN2 setting, or on both with STRICT_QUEUE=ON. This will affect performance slightly.

The new setting allows using the Bridge to ensure the compatibility of existing NMEA 2000 devices with new Navico firmware. When the Bridge receives the CAN frame, it (with factory settings) forwards it to the other CAN interface. So, the setting STRICT_QUEUE=ON will only effect messages sent by Bridge itself or generated in the user program. To assembly a fast packet (for example with the PGN 126996 and 126998) and then forward it in the strict order to CAN1, use the following settings:

PGNS_TO_ASSEMBLY=126996, 126998
FW_CAN1_TO_CAN2=ON
FW_CAN2_TO_CAN1=ON
STRICT_QUEUE=CAN1

We hope that Navico and Garmin will remove the requirement for strict frames order in future updates.

The firmware 1.40 for NMEA 2000 Bridge is available on Downloads page.

 

Next articles:

Previous articles:

See also: recent news, all news...