Skip to content

Sensor Depth

Jump to bottom
webbhm edited this page Oct 11, 2018 · 10 revisions

Sonar

We are going with the AirMar DT800 NMEA 0183 transducer. Much of the documentation below was the justification for this choice.

Types of Sonar

  • Simple down signal
  • Side scanning Side scanning sonar project a beam (or multiple beams) sideways from the boat and are designed to show underwater structures: rocks, sunken boats, tree snags, etc. The processing of this data is complex, often resulting in a 3-D map. While it is good for creating a three dimensional image, it is less precise for actual distances.

A down-signal sonar projects a single beam straight down and gives a simple depth reading (though may also give information about the hardness of the bottom). This type of sonar is ideal for bathymetry mapping.

Sonar and Fish-finders

A lot of people on Lake Monroe have fish-finders that record depth. Lowrance and Humminbird being the two main brands. These however are not suitable for our needs as the transducers are designed to work with specific displays and often have low level electric pulse signals and proprietary data. We need something that has an 'open' standard and communicates at a higher level.

Sailboats and yacht have more complex needs; desiring to combine sonar, GPS, radar and engine data into a single console display and auto-pilots. Equipment for these boats is designed to be integrated into a system composed of parts from potentially different vendors. As such, it is usually built around NMEA networking standards.

NMEA has two standards, the older 0183 and the newer 2000. The boating industry is following the car, tractor and other vehicle direction of using a CAN network bus for sensors. While this standard is better for sensor integration networks, it is a proprietary, binary standard; and actually harder to connect directly into a computer. The older 0183 standard has an ASCII message and runs on a serial bus - something ideal for hooking into a Raspberry Pi. Rather than an expensive 'bridge' module, the 0183 only requires a simple serial/USB connector.

The problem with the NMEA 0183 standard was networking, it communicated at 48K baud on a limited serial bus and had fat (ASCII) data packets; modern cars and motors need to exchange more data faster - hence the newer standard.

NMEA 0183 Options

The problem we are having with the Airmar DT800 NMEA 0183 transducer is finding a vendor that plays well with IU; it is not available on Amazon. We may need to see if we can get a donation through FLM to get around this. NMEA 0183 has some simple hardware and software solutions, and is preferable for these reasons.

NMEA 2000 Options

NMEA 2000 sonar devices are readily available on Amazon, but getting them to speak to a Raspberry Pi (and Python) is the trick. These devices work on a CAN bus. Both NMEA and CAN are proprietary standards, a proprietary byte message and a proprietary physical network. In addition to the sonar unit, there is also the need for:

  • A stub of a CAN network to connect power to the sonar
  • A CAN to USB physical interface
  • Software to read the CAN messages, and pick out the NMEA messages.
  • Software to translate the NMEA DBT (Depth Below Transducer) DPT (DePTh) into meaningful information (ie, likely a NMEA 0138 message).

CAN USB interface

Several options are available here from $25 cards (CANable) and Raspberry Pi shields (PiCAN2) to bridges running several hundred dollars. These will output CAN message to the USB serial.

Software

There is a good bit of CAN sniffing software, but it handles CAN data (which may or may not be binary, depending on the sensor), but we need NMEA specific software. canboat is the primary software (they reverse engineered many NMEA sentences), but it is command line driven PHP code, and appears to still be work in process (ie. the github has a PHP file that is an 'attempt' to talk to an Airmar sensor - last updated 3 years ago). I don't know what it would take to get this up and running. Many of these solutions are attempts by boaters to replace their sensor networks with an open-source interface; this may be a network solution, not a single sensor solution.

Hardware

Wiring

NMEA-0183: RS-232 or RS-422 or RS-485? This part is really easy. If you have a single transmit wire from your device (most likely labeled TX or NMEA OUT or something like that), then it uses the RS-232 protocol, and you need the respective converter. If your device has two wires coming out (typically labeled NMEA OUT+ and NMEA OUT- or TX+ or TX-), then you have RS-422. What about RS-485? For our purposes, it's the same thing as RS-422. The difference is that with 485, you can connect a bunch of different devices that can all talk to each other, which is cool and all, but not applicable for our NMEA device. For our purposes, treat RS-485 the same as RS-422, since the protocal is identical (just RS-485 can support a lot more devices than RS-422, like on the order of 80 or so more). The AirMar DT800 is a RS-422 (Two data wires) NMEA 0183 sensor.

  • Red wire - 12-24VDC power (+)
  • Black wire - Ground (-)
  • Blue wire - NMEA -
  • White wire - NMEA +

Wire the red and black to a 12V power source Wire the blue to the + of the RS-422/USB converter (NOTE: you are swapping polarities: + goes to -) Wire the white to the - of the RS-422/USB converter

Plug the converter into a USB port of the Raspberry.

NMEA Sentences

  • $SDDBT
  • $SDDPT - depth
  • $YXMTW - water temperature

Software

Sonar software is similar, but different to the GPS. While a lot of people program for a GPS, fewer people make use of sonar; as such the GPS software almost works for sonar, but normally fails to account for the unique sonar NMEA sentences. For this reason a simpler, and more basic approach is being used. For both sensors, the USB port is treated as a serial port and the data is directly read via the Python serial class. Since this will be the only program accessing the sonar's USB, there will be no problems with needing to share the port. Custom parsing of the sentences is then applied. Fortunately, these sentences do not have any complex translation. Since USB assignment may change, Monitor.py loops through the open ports checking for NMEA sentences (SDDPT and GPRMC), and based on this logic assigns the appropriate port to the appropriate sensor.

Resources

  • NMEA (National MarAine Electronic Association)
  • Open Chart Plotter Navigation This takes in GPS data and displayes it on open-source navigation charts. Unfortunately the available charts are for major rivers or costal waters (not Lake Monroe). I don't see any interface for sonar (it assumes the depth information is on the map). It does have interfaces for CAN bus, but I didn't see any NMEA 2000 translation.

Clone this wiki locally