From MicronetToNMEA to AvNav on a Raspberry Pi over USB

[nmeyne]

We are using AvNav as a Chartplotter running on a Raspberry Pi (RPi) with GPS and AIS coming over wires from an ICOM AIS device. All is working well. We also have an old TackTick Micronet on the boat which we would like to connect via NMEA0183 to the new chartplotter. I have built a MicronetToNMEA installation on a teensy 4, with CC1101 and a compass. The setup menu seems to compile, start and work normally when accessed from the monitor in the Arduino IDE on my main Linux computer.

When I try to connect with AvNav, it detects and tries to open the USB port for MicronetToNMEA(MTN) ... all good so far, but then I need to get a reliable console connection to do the calibration from the AvNav Rpi installation, so:

1. SSH into the AvNav Rpi
2. Open up a terminal emulator (tio) on the Pi to connect to the USB serial port 'discovered' by AvNav, using what I hoped was pretty standard serial configuration
3. enter '0' and try to operate from the setup / calibration menu options
4. start the conversion and get AvNav to open and send / receive to the USB port

Unfortunately the output at 3 is patchy and slightly scrambled even at 4800 baud. I have tried lots of settings by trial and error, but without success in getting clean comms. It seems to me that perhaps the monitor in the Arduino IDE on my other linux computer works nicely because it is using a special library that provides compatible serial comms objects:

This is not 'standard' serial and will need some code at the AvNav end.. any suggestions / alternative ideas? Otherwise it looks like I am stuck! Grateful for any advice!
Nick

[nmeyne]

Apologies - this is now working fine. I did not realise that I had another process still running that was in contention for the port. I stopped it and the tio console to MicronettoNMEA seems to be working without any obvious data errors. I need to investigate the port speed settings a bit more as well. Thanks for your patience!

[Rodemfr]

Sorry for not answering earlier.
Happy to hear that it is working fine now.
There is something interesting to know in the way MicronetToNMEA (MTN) serial port is working : when you use a Serial-over-USB connection with MTN, the baudrate is in fact not used by the system. The actual baudrate is the one of the USB. It can be more than 400MB/s on a Teensy. So if the Raspberry PI decides to send a big burst of data to MTN, the SW may not be able to cop-up with it.
I don't really know at which level MTN will start loosing data, I never experienced it with my configuration, but it is theoretically possible.

[nmeyne]

Hello,

It has been a year since I looked back at this after a few tries. Thanks for your great work on Micronet To NMEA: I have ALMOST :-) got it working, but I am still a little stuck, this time with the Micronet protocol.

As before, all compiles well on the Arduino IDE and it seems to run well and connect to our MN100-2 display. I had hoped to be able to send some test NMEA data to this display over serial USB for the Teensy to forward to Micronet and be read on the display, but I see nothing, only dashes - - - - for the depth and speed data …..and no other data.

The test data works fine when connected to AvNav via a USB serial port or a socket over wifi, so I think MicronetToNMEA should be able to convert and forward the NMEA for Micronet.

For example:
$SDDPT,2.0,,*57
$SDDPT,2.1,,*56

I don't understand Micronet very well, so I could be doing something stupid. Using the console over the USB serial I seem to be able to connect the Teensy and observe traffic that the display puts out, but I don't have any Micronet tools to observe what, if anything, is arriving in Micronet while my test host (simulated depth sounder) is sending the Teensy data over the USB Serial. Maybe the MN100-2 has to have another 'proper' device connected to make this work?

Example from the console:

*** MicronetToNMEA ***

0 - Print this menu
1 - General info on MicronetToNMEA
2 - Scan Micronet networks
3 - Attach converter to a network
4 - Start NMEA conversion
5 - Scan surrounding Micronet traffic
6 - Calibrate RF XTAL
7 - Calibrate compass
8 - Test RF quality

Choice : 2

Scanning Micronet networks for 5 seconds ... done

List of scanned networks :

Network 0 - 810372D2 (very strong)

Choice : 3

Enter Network ID to attach to : 810372D2
Now attached to NetworkID 810372D2

Choice : 5

Starting Micronet traffic scanning.
Press ESC key at any time to stop scanning and come back to menu.

Network ID : 0x810372D2
Nb Devices : 3
Master : : 0x810372D2
S0 : 0x03123458 30 0 8296
S1 : 0x03123457 31 8296 8540
S2 : 0x03123456 29 16836 8296
Async : 20 32332 7200
A0 : 0x03123456 2 39532 5328
A1 : 0x03123457 2 44860 5328
A2 : 0x03123458 2 50188 5328
A3 : 0x810372D2 2 55516 5328

810372D2 810372D2 01 09 00 9A 23 23 -- 81 03 72 D2 17 03 12 34 58 1E 03 12 34 57 1F 03 12 34 56 1D 00 00 19 (-67, -7512)

Network ID : 0x810372D2
Nb Devices : 3
Master : : 0x810372D2
S0 : 0x03123458 30 0 8296
S1 : 0x03123457 31 8296 8540
S2 : 0x03123456 29 16836 8296
Async : 20 32332 7200
A0 : 0x03123456 2 39532 5328
A1 : 0x03123457 2 44860 5328
A2 : 0x03123458 2 50188 5328
A3 : 0x810372D2 2 55516 5328

810372D2 810372D2 01 09 00 9A 23 23 -- 81 03 72 D2 17 03 12 34 58 1E 03 12 34 57 1F 03 12 34 56 1D 00 00 19 (-67, -7512)

Note that the number of devices seems quite variable… I have seen values from 3 down to 0, but there are only two devices on test here - the MN100-2 display and the MicronetToNMEA Teensy.

See below for the Boardconfig file I am using. Note that I have changed
#define DEPTH_SOURCE_LINK LINK_NMEA_EXT // Depth data (DPT)
#define SPEED_SOURCE_LINK LINK_NMEA_EXT // Speed data (VHW, VLW)
..to send the depth/speed data to the display for test.

/***************************************************************************

•                                                                     *
  

• Project: MicronetToNMEA *
• Purpose: Decode data from Micronet devices send it on an NMEA network *
• Author: Ronan Demoment *

•                                                                     *
  

---

• Copyright (C) 2021 by Ronan Demoment *

•                                                                     *
  

• This program is free software; you can redistribute it and/or modify *
• it under the terms of the GNU General Public License as published by *
• the Free Software Foundation; either version 2 of the License, or *
• (at your option) any later version. *

•                                                                     *
  

• This program is distributed in the hope that it will be useful, *
• but WITHOUT ANY WARRANTY; without even the implied warranty of *
• MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the *
• GNU General Public License for more details. *

•                                                                     *
  

• You should have received a copy of the GNU General Public License *
• along with this program; if not, write to the *
• Free Software Foundation, Inc., *
• 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. *

---

*/

#ifndef BOARDCONFIG_H_
#define BOARDCONFIG_H_

//
/ Includes /
//

//
/ Constants /
//

// Select EU (868MHz) or not-EU (915MHz) Micronet frequency
// 0 -> EU (868Mhz)
// 1 -> non-EU (915Mhz)
#define FREQUENCY_SYSTEM 0

// Selects on which I2C bus is connected compass as per Wiring library definition
#if defined(ARDUINO_TEENSY35) || defined(ARDUINO_TEENSY36)
#define NAVCOMPASS_I2C Wire1 // SDA1: 38 SCL1: 37
#else // Teensy 4.0 Configuration
#define NAVCOMPASS_I2C Wire // SDA0: 18 SCL0: 19
#endif

// CC1101/SPI pins
#if defined(ARDUINO_TEENSY35) || defined(ARDUINO_TEENSY36)
#define CS0_PIN 10
#define MOSI_PIN 11
#define MISO_PIN 12
#define SCK_PIN 14
#define GDO0_PIN 24
#else // Teensy 4.0 Configuration
#define CS0_PIN 10
#define MOSI_PIN 11
#define MISO_PIN 12
#define SCK_PIN 13
#define GDO0_PIN 9
#endif

// NMEA GNSS UART pins
#if defined(ARDUINO_TEENSY35) || defined(ARDUINO_TEENSY36)
#define GNSS_UBLOXM8N 1 // Set to one if your GNSS is a UBLOX M8N, 0 else. If set to one, GNSS will be automatically configured at startup
#define GNSS_SERIAL Serial1
#define GNSS_BAUDRATE 9600
#define GNSS_RX_PIN 0
#define GNSS_TX_PIN 1
#else // Teensy 4.0 Configuration
#define GNSS_UBLOXM8N 1 // Set to one if your GNSS is a UBLOX M8N, 0 else. If set to one, GNSS will be automatically configured at startup
#define GNSS_SERIAL Serial2
#define GNSS_BAUDRATE 9600
#define GNSS_RX_PIN 7
#define GNSS_TX_PIN 8
#endif

// USB UART params
#define USB_NMEA SerialUSB
#define USB_BAUDRATE 115200

// Wired UART params
#if defined(ARDUINO_TEENSY35) || defined(ARDUINO_TEENSY36)
#define WIRED_NMEA Serial5
#define WIRED_BAUDRATE 115200
#define WIRED_RX_PIN 34
#define WIRED_TX_PIN 33
#else // Teensy 4.0 Configuration
#define WIRED_NMEA Serial1
#define WIRED_BAUDRATE 115200
#define WIRED_RX_PIN 0
#define WIRED_TX_PIN 1
#endif

// The console to use for menu and NMEA output
// USB_NMEA -> USB-Serial link
// WIRED_NMEA -> Teensy's physical UART
#define CONSOLE USB_NMEA
#define NMEA_EXT USB_NMEA

// Defines which data comes from which link
// LINK_NMEA_EXT -> data comes from external NMEA link (WIRED_NMEA)
// LINK_NMEA_GNSS -> data comes from GNSS NMEA link (GNSS_SERIAL)
// LINK_MICRONET -> data comes from Micronet network
// LINK_COMPASS -> data comes from LSM303 (NAVCOMPASS_I2C)
#define NAV_SOURCE_LINK LINK_NMEA_EXT // Navigation data (RMB)
#define GNSS_SOURCE_LINK LINK_NMEA_GNSS // Positionning data (RMC, GGA, VTG)
#define WIND_SOURCE_LINK LINK_MICRONET // Wind data (MWV)
#define DEPTH_SOURCE_LINK LINK_NMEA_EXT // Depth data (DPT)
#define SPEED_SOURCE_LINK LINK_NMEA_EXT // Speed data (VHW, VLW)
#define VOLTAGE_SOURCE_LINK LINK_MICRONET // Battery voltage data (XDR)
#define SEATEMP_SOURCE_LINK LINK_MICRONET // Temperature data (MTW)
#define COMPASS_SOURCE_LINK LINK_COMPASS // Heading data (HDG)

// Navigation softwares can send a wrong RMB sentence and invert "FROM" and "TO" fields
// If you see your Micronet display showing the "FROM" waypoint name instead of the "TO"
// on the DTW & BTW pages, then change the following configuration switch to 1
#define INVERTED_RMB_WORKAROUND 0

// In case your displays would have difficulties to receive data from the Tacktick wind
// transducer because of a poor signal/noise ratio, you can ask MicronetToNMEA to repeat
// the values of AWA & AWS on the network by setting MICRONET_WIND_REPEATER to 1. Set it
// to 0 else.
#define MICRONET_WIND_REPEATER 0

// In case your Micronet system would not have SPD data (speed on water), you can set this
// compile switch to 1 to ask MicronetToNMEA to emulate SPD with SOG value from GNSS.
// This allows your display to calculate True Wind data, including VMG. This gives good results
// as long as there no current.
#define EMULATE_SPD_WITH_SOG 0

// Define which compass axis will be compared to magnetic north
// Set one of the (X, Y, Z) to 1.0 or -1.0
#define HEADING_AXIS
{
1.0f, 0.0f, 0.0f
}

//
/ Types /
//

//
/ Prototypes /
//

#endif /* BOARDCONFIG_H_ */

I would be really grateful if you could have a look at this and maybe suggest what else I could try.

Happy New Year,

Nick

[Rodemfr]

If Micronet RX is working, it is likely that TX is working also. Let's check it :

• Start your Micronet network
• Enable your Teensy in your final configuration (connected to avnav)
• Be sure that MTN is in "NMEA conversion mode"
• Go on your MN100-2 and go to setup menu (long press on "dot" button)
• Then go to Health sub-menu

In the health sub-menu, verify what device is connected to the network. You should have one named "NMEA" indicating the version of the SW

Let me know if you can see the device.

[nmeyne]

Thanks! Yes I can see the device: NMEA 02.2 with SIGNL values around 03 to 08 for it. The Version of the MN100-2 sw is 37.2. Below that it says 04 nodes (but I only have the MN100-2 and the Teensy in the network at the moment.)

I think I have a problem with sending my desktop test data to the Teensy using my python script: I notice that after disconnecting the tio session I open the serial port again for the test data and at this point NMEA seems to stop and drop out of conversion mode - the NMEA node disappears (no version, no signal). I will abandon the python script for now.

I then tried using AvNav running on an Android device (with internal GPS running) with the Teensy plugged in to the USB port (detected at /dev/bus/usb/001/002. In the AvNav handlers page I set up a USB connection at 115200 baud, no flow control and 'send out' enabled (no send filters or blacklist) hoping to send at least a GPS position and maybe a COG/SOG to the MN100-2 display. The connection looks OK, sending at 18.50/s and err 0/10s. The NMEA 02.2 device still shows on the MN100/2, but I don't see any data in the obvious places on the display. I tried the option to strip leading characters before $ or ! in the received lines, but that does not affect what is sent, I think.

[Rodemfr]

Good. It means the connection between MTN and the MN100 is ok. So the problem is on the other side : the NMEA link with the tablet.
I see two possibilities :
1 - The connection is OK but the NMEA sentences, for any reason are not understood by MTN.
2 - MTN/AvNav link is not operational, for any reason.

I can check the first possibility if you can send to me a log of 5-10 NMEA sentences sent by AvNav.
For the second possibilty, I will try to build a similar setup than you with AvNav on USB and the exact same config file.

[nmeyne]

Thanks Ronan.

Here are a few records from the top of the AvNav NMEA log plus some screenshots of AvNav settings.

$GPGSV,7,1,28,06,4,088,0,10,18,272,0,12,74,219,0,15,14,171,044
$GPGSV,7,2,28,17,14,035,0,19,34,059,0,23,4,233,0,24,66,113,042
$GPGSV,7,3,28,25,33,237,0,32,28,310,0,14,37,268,0,22,26,061,071
$GPGSV,7,4,28,13,67,028,0,12,24,063,0,05,10,338,0,23,16,111,072
$GPGSV,7,5,28,21,10,008,0,03,45,217,0,04,47,300,0,04,6,320,04A
$GPGSV,7,6,28,07,9,154,0,19,55,285,0,21,47,229,0,27,73,071,045
$GPGSV,7,7,28,29,54,188,0,30,21,057,0,34,8,054,0,36,5,007,073
$GPGSV,7,1,28,06,4,088,0,10,18,272,0,12,74,219,0,15,14,171,044
$GPGSV,7,2,28,17,14,035,0,19,34,059,0,23,4,233,0,24,66,113,042
$GPGSV,7,3,28,25,33,237,0,32,28,310,0,14,37,268,0,22,26,061,071
$GPGSV,7,4,28,13,67,028,0,12,24,063,0,05,10,338,0,23,16,111,0*72

NB I am using AvNav android on a phone here, using an OTG adaptor at the end of a USB to micro usb cable. (I would normally run it on an RPi 3B but I don't have that available with GPS at the moment). So another thing to try would be a different usb cable for the phone (a Fairphone 4) just in case the tx to the Teensy is failing there as well.

[Rodemfr]

Your log only shows $GPGSV sentence. This sentence only gives the number of sattelites in view which is not used by MTN.
MTN decodes RMC, GGA or GLL to get the position. I don't know well AvNav but I see in your configuration screenshots that "sendOwn" is not checked. Might this be to send your own position ?

[nmeyne]

Apologies. I took only a few lines from the top of the log where the GPS was still searching. Later on there are the occasional RMC sentences:

$GPRMC,110422.000,A,5050.843,N,00009.503,W,0.0,000.0,170125,,,D*7D

I could put a filter on the AvNav handler to suppress sending of the $GPGSV sentences. Maybe they are flooding out the connection somehow?

The "sendOwn" checkbox is to 'send data received over this connection' - a sort of duplex echo - not required I think. I tried it anyway but it made no difference. I also tried with other cables. Again no difference as far as I could see.

Note there is an option to strip out the leading 2 characters after the $ and before the RMC. I tried that too, but again no difference.

In the test data set I used earlier with my script I had a wider variety of sentences, but none of them were received by the Teensy.

Other thoughts:

• I have disconnected the compass sensor at the moment. The Teensy detects it is missing and skips it OK. Seems unlikely to be an issue for other sentence detection and passing, I think?

• The red light on the Teensy flashes every 1 second when the MN100 is on, but stops flashing when the MN100 is turned off. This seems to indicate a Micronet connection, but not necessarily any data transfer.

[nmeyne]

Thanks. Getting there now! Sorry I should have spotted that in the config!

Display now gets (and remembers) time and date.

It correctly displays bearing and distance to waypoint from AvNav.

However I do not have a position shown on the display (no lat / long) and no COG or SOG.

I think I have set the units correctly, but I'm not sure.

The nmea logfile from AvNav is attached. NB it should/may be that the GPGSV's in this are stripped before sending out

2025-01-20_nmea.txt

[Rodemfr]

I tested the RMC sentences you sent to me and it is working fine. I see Time/Date/Lat/Lon/cog/sog on my MN100. But I don't have the exact same setup than you. I'm manually sending RMC through USB with a terminal.
So it means that the RMC syntax is understood by MTN. So the problem comes from elsewhere on your setup. As you mentioned before, there are a lot of GSV sentences which may overflow in some way MTN. What I suspect now, is that "sometime", MTN sees and decode the RMC sentence from AVNAV. At this time, the display may display all the related values. But on Tacktick display, the timeout before invalidating a value is longer for time/date than for "faster" values like position or speed. This might explain what you saw : you see time & date because they have not reached the timeout, while COG/SOG/LAT/LON already hit timeout and are no more displayed.

This could be verified by filtering out GSV from AVNAV output.

A serial/usb link does not work like a standard UART : data flow is not regulated by a fixed clock. If AVNAV sends a burst of data with all the GSV sentences at once, MTN will receive it at the maximum USB rate : up to 480Mbit/s (!). Just writing this, let me think it is likely the issue. Also, we can imaging that RMC sentence is always sent at the same time than all GSV sentences, while RMB is sent asynchronously, explaining that it is properly decoded, outside from the data burst.

[Rodemfr]

Another possible source of the problem :
Ensure that you are using the latest version of the master branch (it should display 02.4 as version in the MN100 health menu).
Full RMC support was added in the latest versions.

[nmeyne]

Yes. That was it! Filtering out the GSV sentences and moving to 2.4 from 2.2 (sorry, should have updated master) seems to have fixed it. All that remains to test (when we put the boat back in the water) is the bridging of the boat's micronet speed log and depth sensors to NMEA and their decoding for AvNav and wifi.

I will now make up a more robust Teensy hardware build and keep the current rig as the test system. Also, I think I will include the ublox neo M8N, with an external antenna.

Note: I do have an esp 32 M5stack tough, so I'd be interested if you ever consider a port of MTN to ESP32 !

Thank you for all your support!

[Rodemfr]

Great news, let me know if you find issues with LOG & SPD.
For MTN on ESP32, you can check MicroNav. It a Micronet bridge made on a T-Beam 1.1. It is less mature than MTN but works not too badly on my board. I'm currently trying to design my own PCB on EasyEDA and I'm really thinking dropping Teensy for a cheap ESP32.

[nmeyne]

I think we owe you a beer / coffee!

I found this Neo M8N... but perhaps it looks like a knock-off Do you have any suggestions / link to a better one, or the one you use in your set-up?. I need to attach an external antenna too.

Micronav looks great for next time!

[Rodemfr]

This M8N looks fine. the antenna is a big one which will help reception inside the cabin. Practically, you can buy any M8N, it should work as long as you can connect VCC/GND/TX/RX. Also note that MTN is compatible with M6N. I also have one and it works fine. I advise a M8N however, it performs better w.r.t sattelite locking and podition/speed noise.

By the way, in the latest version of MTN, you now have two interesting parameters in BoardConfig.h :

#define SOG_COG_FILTERING 1
#define SOG_COG_FILTERING_DEPTH 7

This enables and configure a filter for COG and SOG which are often very noisy. this significantly improves COG & SOG stability at the cost of response time. SOG_COG_FILTERING_DEPTH 7 means that the filtering window is 7 seconds wide. Set SOG_COG_FILTERING to 0 to disable the filter.

[nmeyne]

Great. The club boat is a lovely old classic so it will be great to fix the neo-M8 and antenna under the wooden coachroof and still get a good signal. We can then remove one of the ugly old plastic antennas.

[Rodemfr]

Superb boat. My previous one was also a classic gaff cutter, a Billie Charlotte.
I made MicronetToNMEA for the exact same reason than you : having compass & GPS without awful plastic stuff & wires everywhere. Good luck with your DIY.

[nmeyne]

Hello again Ronan! All is working very well here... but only for about 5 - 25 minutes :-) before i see a recurrent error with my newly-built MTN hardware - some instability of Micronet to NMEA data passing/parsing, specifically with some HDG sentences, which seems to halt the processing altogether until reboot of the Teensy.

After a period of normal processing from start up, ranging from 5 to 35 minutes, MTN ceases to transmit valid GPS and heading information over the USB port and over the CC1101. MTN starts up in menu mode 4 (send data) correctly, transmitting INHDG, GNRMC, GNGGA and GNVTG over the serial port. After a period, usually between 5 and 35 minutes, the sending of GPS sentences stops, followed by the loss of heading data and finally loss of transmission of micronet data to the MN100 display. The NEO-M8 GPS shows a good fix throughout (flashing blue LED) and the Teensy 4.0 shows a pulsing red led, indicating a good connection to the Micronet network.

The last few lines of the log before a typical failure are shown below.

12:29:38.022 $INHDG,216.1,0,E,0.0,E*54
12:29:38.157 $GNRMC,122939.00,A,5050.84329,N,00009.48698,W,0.267,,100225,,,A*7F
12:29:38.166 $GNVTG,,T,,M,0.267,N,0.495,K,A*36
12:29:38.186 $GNGGA,122939.00,5050.84329,N,00009.48698,W,1,12,1.46,113.2,M,45.5,M,,*51
12:29:38.527 $INHDG,216.3,0,E,0.0,E*56
12:29:39.032 $INHDG,215.9,0,E,0.0,E*5f
12:29:39.154 $GNRMC,122940.00,A,5050.84329,N,00009.48723,W,0.345,,100225,,,A*71
12:29:39.163 $GNVTG,,T,,M,0.345,N,0.638,K,A*32
12:29:39.183 $GNGGA,122940.00,5050.84329,N,00009.48723,W,1,12,1.10,112.9,M,45.5,M,,*57
12:29:39.537 $INHDG,216.4,0,E,0.0,E*51
12:29:40.042 $INHDG,215.9,0,E,0.0,E*5f
12:29:40.192 $GNRMC,122941.00,A,5050.84332,N,00009.48755,W,0.370,,100225,,,A*7D
12:29:40.596 $INHDG,‑nan,0,E,0.0,E*32
12:29:41.310 $INHDG,‑nan,0,E,0.0,E*32
12:29:42.024 $INHDG,‑nan,0,E,0.0,E*32
12:29:42.739 $INHDG,‑nan,0,E,0.0,E*32
12:29:43.452 $INHDG,‑nan,0,E,0.0,E*32
12:29:44.166 $INHDG,‑nan,0,E,0.0,E*32
12:29:44.880 $INHDG,‑nan,0,E,0.0,E*32
12:29:45.594 $INHDG,‑nan,0,E,0.0,E*32

Note that the failure seems to be associated with a -nan value appearing in the HDG sentences, which seem to 'flood' the output from that point. There are only a few RMC, GGA and VTG sentences after that point, eventually none.

Although I guess there is a possibility of a hardware error on the LSM303 compass board, GY-511, I wonder if there is some error trapping missing, because the HDG -nan sentence flood "seems" to bring all the other message parsing / formatting down? But that's assuming the Teensy itself is still healthy, given the LED flashes OK. I have checked power levels and found nothing unusual

I am using MTN 2.4, compiled and uploaded with platformio to a Teensy 4.0. There is a CC1101, a NEOM8N and a LSM303 compass board attached as per standard configuration. Wiring table here.

The connection with AvNav on the Rpi is working well until the MTN processing fails. MTN is able to accept navigation sentences from AvNav and pass them on to the Micronet display so that we get bearing and distance to waypoint. AvNav accepts the HDG and GPS sentences from MTN and shows COG, SOG, and position fix. The problem seems unrelated to the connection.

There are some pictures of displays and the terminal output in the attached pdf document, which includes BoardConfig.h

Micronet HDG issue.pdf

Grateful for comments / suggestions. Meanwhile I am checking connections carefully and may replace the LSM303 board with a spare.

(By the way, those Billie Charlotte gaffer pics look great!)

[nmeyne]

Further information: I have a test/development Teensy 4 and LSM303 with the same version of MTN (2.4) on it, but this time compiled with the Arduino IDE. I would have used the Arduino IDE for the new hardware build above, but for the fact that I upgraded my desktop PC from Ubuntu 22.02 to 24.04 and was no longer able to use the IDE appimage. The fixes they suggest didn't work for me, so I moved to platformio, and found it worked - or so I thought? Maybe there are some library inconsistencies introduced when compiling MTN with platformio in VSCode? Floating point errors?

So - if the old build of old hardware still works (it has been running for 60 minutes so far!) 3 possibilities:
a) compilation error - get arduino IDE working on 24.04, or Windows, and try again - effort :-|
b) faulty LSM303 - replace + effort :-/
c) faulty Teensy 4.0 - replace - expensive + big effort :-(

[nmeyne]

Starting with a) compilation error

I re-compiled and uploaded the code with the Arduino IDE on Ubuntu (apparmor issue fixed).
I saw some warnings on compilation:

/home/nick/Development/Teensy2/MicronetToNMEA-master/src/DataBridge.cpp: In constructor 'DataBridge::DataBridge(MicronetCodec*)':
/home/nick/Development/Teensy2/MicronetToNMEA-master/src/DataBridge.cpp:89:11: warning: 'memset' used with length equal to number of elements without multiplication by element size [-Wmemset-elt-size]
   89 |     memset(sogFilterBuffer, 0, SOG_COG_FILTERING_DEPTH);
      |     ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/nick/Development/Teensy2/MicronetToNMEA-master/src/DataBridge.cpp:91:11: warning: 'memset' used with length equal to number of elements without multiplication by element size [-Wmemset-elt-size]
   91 |     memset(cogFilterBuffer, 0, SOG_COG_FILTERING_DEPTH);
      |     ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Opening Teensy Loader...
Memory Usage on Teensy 4.0:
  FLASH: code:98160, data:40996, headers:8296   free for files:1884164
   RAM1: variables:46496, code:95960, padding:2344   free for local variables:379488
   RAM2: variables:12416  free for malloc/new:511872

..but I am not sure if they are relevant? Otherwise successful upload, and processing started fine, until the error came again in both the terminal and when connected to AvNav. I guess that proves it is not the IDE difference and more likely to be a hardware problem.

so... moving on to

b) faulty LSM303 - replace

The swap of the module worked only slightly better: the old module gave about 2 hrs of processing before crashing, then after reboot, another 30 min. It is still not reliable on the live set-up. The new module was then soldered into the test rig where it seems to run fine. The only differences between the cabling in the live set-up and the test set-up are:

1. a longer cable (2.5m) from Teensy to the LSM303 in the live set-up
2. use of a different power and ground pins for the 3.3v

I have changed the pins on the live to match the test, but I am still getting instability (MTN stops sending valid data).

I disconnected power from the LSM303 from the live cable , so only GPS data going through the cable, and it seems much more stable, running for many hours without HDG, but without failure. Reconnecting the LSM303 seems to result in eventual failure.
I need to look at the cable and its screening.

However, this is not very robust. Perhaps there is something in the code that is vulnerable to data anomalies from the LSM303?
It's also a problem that the Teensy cannot be easily / automatically restarted to recover from the error when it is powered from the USB of the Rpi running AvNav. I may need to put a switch in the power line of the USB cable so that the Teensy can be stopped started independently. I'd rather not have to do this.

[nmeyne]

c) Replace the Teensy

I am reluctant to do this just yet. It is possible that the NEO-M8 is causing the parsing and processing to abort / malfunction, so I will look to see if it is possible to test that by turning it off in BoardConfig.h on re-compilation.

[Rodemfr]

Hello Nick,

Thanks for this detailed problem report. Your description makes me think there is an issue with LSM303 driver and heading filtering.
My MTN already ran properly in navigation for more than 24h, but I don't use LSM303. I already have a compass on my network. So, your suspicion on LSM303 handling is probably correct. Here is what I suppose : at some time LSM303 driver gets a invalid value and finishes with a nan heading. This nan heading can provoke a number of unknown consequences in MTN that I have to understand.
I read in LSM303DLH datasheet that the IC has a probability to give an invalid magnetic field value that could explain this nan value. however, GY-511 uses LSM303DLHC which is supposed to have fixed this issue.
I will have a look to this tonight. I will propose a fix which will make heading calculation robust to invalid values from LSM303. I cannot really test it because my MTN is now using LSM303AGR which uses a different driver but I will try to simulate a nan heading calculation.
Until I provide this fix, you can disable LSM303 by replacing line 115 of main.cpp :

if (!gNavCompass.Init())

by :

if (1)

It will disable calculation of heading and your MTN should run indefinitely without any problem/crash. It will confirm that the root cause of the issue is somewhere in heading calculation.

[nmeyne]

Great! Many thanks Ronan! I will also try that. Meanwhile I am also testing with power off the LSM303 and it seems stable so far. I am still suspicious that noise on the longer cable I have between the LSM303 and the Teensy may also be causing data errors, so I will try to improve shielding. I think I might also buy a LSM303AGR board like this one to match your set-up... and it's a better sensor package!

[Rodemfr]

Here is a more robust version of NavCompass code : NavCompass.zip
This code now have more serious checks of invalid magnetic & acceleration measurements. It should not be possible to have NaN heading anymore.
Let me know if it improves the situation.

[nmeyne]

New code has been recompiled and uploaded without errors, thanks! Meanwhile I had confirmed that the root cause of the problem was noise on the cable from the Teensy to the LSM303. Fixing the connection for better screening allowed it to run for 36 hours non-stop. Unfortunately for testing purposes that means I can't confirm your NaN validation traps the old errors, but I will have another proper test when I do more calibration next week. Just want to say thanks in the meantime for some great coding and support. Really appreciated. Nick

[Rodemfr]

Great !
Noise on I2C lines can cause really bad behaviors, especially on SCL line. It can generate a "fake" clock pulse seen by the slave and not by the master, causing the two device to loose synchronization. Only a reset can restore the synchronization. This fully explains the problems you have seen. It is good to know. I will add a warning in the next version of user manual.