FAQ.md

FAQ

1. Why use 2 ESP32s? Why not 2 CAN bus interfaces on a single ESP32? I tried for months to get a second interface working on the ESP32. The nmea2000_mcp library is usually used with Arduino, Teensy and other microcontrollers because they don't have an internal CAN controller. Unfortunately, I could not get the mcp driver to work on the ESP32...it crashed the controller on initialization. And since this is such an incredibly specialized corner case and I don't have the expertise to debug FreeRTOS kernel panics, I didn't have a lot of options. Parsing the raw wind packets wasn't particularly complicated, but I was never able to get the MCP module to read valid data from the second CAN bus. I could see data on the bus, but it was garbage. I probably had some signal problem that again is beyond my ability to debug, and I'm not about to buy an oscilloscope. So I fell back on using a second ESP32 and forwarding the data over a serial link (using UART), which works fine and has the side effect of using the HAT Labs USB bridge code almost unmodified. And since @mairas is a much more qualified developer than I am, this is a good thing.
2. Do I need an external ADC? RandelO uses an ADS1015 ADC. I decided to use one of the internal ADCs on the ESP32. Either will work.
3. What's the circuit on the Sailor HAT doing? The Honeywell position sensor runs on 12VDC like other boat electronics. Its output is a variable voltage from 0-12 volts based on the position of the magnet (attached to the mast). However, the ESP32 runs at 3.3V logic level, so trying to convert 12 volts to a digital reading would probably damage the microcontroller. The circuit is a simple voltage divider to change the input range from 0-12V to 0-3V.
4. Why do I need the GND10? Garmin purchased Nexus. Nexus instruments use a proprietary protocol called FDX, which runs over RS485. The wire from your masthead wind transducer to the GND10 isn't carrying N2K data, it's carrying FDX data (and on many boats the masthead is too far for an N2K drop cable anyway, hence RS485 which can run a couple kms). The GND10 simply translates FDX packets into N2K. I was able to read and parse FDX data from the USB interface on the GND10, but I was not able to read data from the transducer wire itself. If someone else figures this out, please let me know. I would love to eliminate one more piece of equipment and streamline the system. (Actually, parsing FDX on the ESP32 would allow me to eliminate two microcontrollers, the GND10 as well as the second ESP32, since uncorrected wind data would never be on the N2K bus). Note that you could do all of this on a single Raspberry Pi, since you can wire an ADC to a Pi and the Pi can run the fdxread parsing repo. However, I didn't want a dependency on a full-blown operating system in my instruments.
5. How does the nmea2000 library work? The nmea2000_mcp library reads and parses NMEA 2000 data. It sounds so simple, but there's a lot of complexity behind it. For non-engineers, "parsing" is the process of figuring out what the bits in a stream of data represent. For example, I'm from the US, so if I see a string of numbers and symbols like "03/08/2024" my mind automatically interprets that as a date, March 8th, 2024. However, if you're from Europe, your brain probably parses that string differently, and you see "August 3rd, 2024". NMEA2000 data is just a sequence of bits on a CAN bus, and the library can figure out what the bits mean and do meaningful, useful things with the data. Like dates, position of the bits matters, and the library takes care of figuring that out.
   The simplest use case is sending NMEA2000 data to a different device that's not directly connected to the NMEA network (or more properly, "bus"). When you set up the N2K parser in your code, you have the option of specifying a "forward stream". This is essentially a target where you're going to send the parsed data. In most cases it's going to be a USB connection to a computer such as a laptop or Raspberry Pi. So the simplest use for the library is to observe the data packets that your boat instruments are passing around, such as GPS position, speed detected from a paddlewheel, perhaps engine temperature and RPMs, etc. and send that data to a USB connection. You can even forward the stream in "plaintext" so you can simply watch the data go by on your laptop. But a much more interesting use is to send the data to an app (and protocol) called SignalK.
   The second interesting use case for the library is not to simply forward the data, but to process it somehow and do something interesting with it. This is what the mast rotation compensator does: it reads NMEA2000 wind data from the bus, modifies it, and re-transmits it on another bus to be picked up by the Garmin wind display. For this use case, you configure a "handler", or a function that is called when the library observes a specific kind of data on the bus (in my case, packet that contains wind data).