Integrating an RS-485 device (Rx-LIVE acoustic animal tag receiver) with Bristlemouth

[estackpole]

I’m working on integrating an acoustic marine animal tracking receiver with a Spotter Smart Mooring system using Bristlemouth and I thought it would be good to post about my processes publicly for anyone interested in doing something similar. I am looking to integrate the off-the-shelf Rx-LIVE acoustic animal tag receiver which I got from Innovasea.

These receivers detect signals coming from small acoustic transmitters that are often surgically embedded into marine animals for ecological studies. Once an animal tagged with a transmitter gets close enough to the receiver, the serial number of the transmitter is logged in the receiver, thereby collecting information about which animals visited that area, when they were there, and how long they stayed. Scientists use data collected from networks of these receivers dispersed across wide areas to gain understanding about animal behavior, migration patterns, and many other key elements for understanding complex marine ecosystems. Expanding the network of these receivers would allow us to understand behavior in higher fidelity and fill blind spots in our knowledge, allowing us to better understand (and protect) critical marine habitats.

The majority of existing tag receivers record data internally and that information only becomes available when someone physically goes to the deployment location, retrieves the receiver, and manually uploads the recorded data. This type of recovery and redeployment operation may only happen every few months, so information is usually delayed, costly to get, and hard to scale. Although there are existing models of receivers that can send data out in real-time (like the Rx-LIVE), getting the data from the field location to land requires long-range communication infrastructure that is often unavailable to scientists.

This project aims to convert the live serial data stream from an Rx-LIVE receiver into Bristlemouth so that its detections can be monitored in real-time through the Spotter Smart Mooring system. The collected information can be sent via Bristlemouth through the Smart Mooring cable to the Spotter buoy at the surface and then transmitted via satellite, allowing tag detections to be observed by scientists in real-time. If the integration works, it could allow real-time tracking of animals to be scaled in a way that would meaningfully impact and improve our ability to monitor coastal ecology.

The Rx-LIVE uses the RS-485 serial communication protocol which should be fairly straight-forward to integrate with a Bristlemouth Developer Kit since the Dev Kit already has provisions for communicating with that standard. One of the things I hope this series of posts provides is a solid example of how to do an integration with RS-485 generically on Bristlemouth. If you haven’t seen it already, there’s also already a post about integrating an RS-232 device with Bristlemouth which you can find here.

In upcoming posts, I’ll share my progress. I encourage anyone reading this to ask questions or make suggestions as I carry on. I will be learning as I go and getting help wherever I can, so this will likely be a journey many of us take together.

If you have similar project ideas, or if you’ve ever worked with this type of equipment, please let me know!

[julianblanco]

Hi there!

Excited to follow along. I am also planning on putting acoustics on the Spotter buoy we got via the pioneer programs.

Cheers
Julian

[estackpole]

@julianblanco Great! I imagine I’ll learn a lot along the way so I’m glad those lessons can be shared. I’m excited to hear more about your project!

-e

[estackpole]

The first part of this project involves getting familiar with the sensor we’ll be using and verifying that it works as expected. Before the system is ready to interface with Bristlemouth, I’ll verify that I can send and receive data with it via raw serial commands through RS-485 directly. I’ve broken that process down into several steps:

STEP 1: Understanding the interface

The first step in integrating a new system is understanding the specifications of its interface. We’ll want to know the voltage and power requirements of the system and we’ll need an understanding of which pins are needed for power and data connections. Here is a copy of the user manual for the Rx-LIVE. On page 3, one can find a wiring diagram for the receiver which I’ve also pasted as an image below.

The Rx-LIVE uses RS-485 to communicate, which uses two lines (D+ and D-, on pins 2 and 4 respectively) to communicate as a differential pair, and ground on pin 1. Additionally, we can see that the system is powered with between 10 and 24v DC delivered through pin 3. There’s also a pin for grounding the shielding in the cable to help protect from electrical interference.

Even though the connecter has 8 pins, only the five pins listed are used and the others are N/C (Not Connected).

The unit I received did not include this cable, so I contacted SubConn to get the cable needed. I also ordered an RS-485 to USB transceiver from Amazon so I’d be able to test the system directly before attempting to wire it to a Bristlemouth Development Kit.

STEP 2: Testing the stock hardware

After receiving the MCIL8F cable and RS-485 to USB Transceiver, I wired the system up as shown and used a bench power supply to give the system 12v. The ground pins of the receiver and the ground of the power supply had to be tied together as shown.

I downloaded InnovaSea’s software, Fathom Connect, for viewing data from the Rx-LIVE. Once wiring was complete, I confirmed that everything was properly connected, plugged the RS-485-to-USB adapter into my computer, turned the power supply on, and launched Fathom Connect. The device appeared on the software interface, and the connection process went smoothly without encountering any significant issues.

For testing purposes, InnovaSea also provided an acoustic tag designed to be detected by the receiver. Once the receiver was properly configured, we activated the transmitter by removing a magnet taped to its side. Almost immediately, we began receiving pings through the Fathom Connect app. We had expected that we would need to place the transmitter and receiver in a tub of water to work, yet we discovered that we were able to receive signals from the transmitter even while in the air.

Off to a good start!

In my next post, I’ll work on sending and receiving commands with the Rx-LIVE directly with a serial terminal. Once we’re able to do that, we’ll be ready to start integrating the system with a Bristlemouth Development Board.

[tosca]

@rmcgurrin check out this thread, too.

[estackpole]

Connecting directly with a Serial Terminal

Now that I’ve verified that the whole system is functioning using the Fathom Connect software, I can start working on how to communicate with the receiver directly through a serial terminal without needing to use the Fathom Connect app.

To send and receive serial data, I used a serial interface application called CoolTerm. CoolTerm has a user interface that I like and it packs a lot of great features in a clean package. Many other serial interfaces could also work, such as PuTTY or the built in Terminal app that comes on a Mac. I’m using a Windows laptop for this now, so you’ll notice some differences if you’re on Mac or Linux but hopefully not that much of a difference.

With the system plugged in and CoolTerm open, I was able to connect to the RS-485 adapter through the appropriate COM terminal, in my case, COM7, by selecting that port in the lower left corner of the UI, and pressing “Connect” on the top bar. The handling of COM ports and USB devices is one place where it will look different for Mac or Linux users.

Based on information provided in the data sheet, there were a handful of configuration settings I needed to change in CoolTerm to make sure everything worked properly. The data sheet describes how to enter these settings using PuTTY, but the interface in CoolTerm is similar.

As you can see, these settings included:

Baud Rate (I chose 9600 baud which is the default for the Rx-LIVE, although other speeds would also work)

Data bits= 8

Stop bits= 1

Parity = None

Flow Control = None

Here’s how that looks in CoolTerm:

One thing I found confusing with CoolTerm that is worth noting is that the command line at the bottom of the screen that allows you to type and send commands is not visible by default when you install the program. To display that window, I clicked on the “Terminal” heading on the left side of the options menu, and selected “Line Mode” instead of “Raw mode” which the system was set up as by default.

A nice thing about CoolTerm is that once you get it configured how you like, you can save the configurations in a file that you (or others) can load. In case you want to try them out, I’ve uploaded my settings here.

Now that the communication configuration is set up properly, we should be able to send our first command to the Rx-LIVE.

Any device one might want to connect to will have its own format for sending and receiving serial messages, so to figure out how to exchange data with the Rx-LIVE, I looked through the datasheet for the format information. I found the pages shown below with information on command/response formats.

As you can see, the format requires me to input the serial number of the device (which is shown on a sticker on the side of the receiver), a checksum, and one of the possible commands listed on another page of the data sheet. In this first test, I’ll use the command, “INFO”, to return information about the system. You can see where I entered that below (circled in red) and the response I got back after sending that message to the unit (circled in blue)

*457042.0#22,INFO

Note that the example line they give in the datasheet has a format ending with “\r”. That is notation indicating a carriage return, and we don’t actually need to type that part. Because I’m a newb with this sort of thing, that part screwed me up until I figured it out. And, because I’m bad at reading manuals, only later on did I notice that the manual describes that “/r” is not needed on the next page.

Wahooo! Looks like this is working!

In the response, you can see the following:

*457042.0#22[0052], RXLIVE-BLU: 457042,’ ‘, MAP-115, FW=1.1.6, HW=0, OK, #9A

Page 14 of the manual describes how to interpret this response. For this system, I can see that the unit has Firmware version 1.1.6 and Hardware version 0.

The Rx-LIVE is already set up to send information about the number of pings and detections it’s received, as well as other status information periodically, so even without typing anything into the terminal, I received these messages every minute.

Now let’s use the STATUS command to get information about what the receiver is currently observing. To do this, I typed in *457042.0#22,STATUS, and here’s what I got:

Pages 14 and 15 of the manual show how to interpret this information.

The transmitter I have was turned off while I did this STATUS inquiry, so the Detection Count (DC) of 28 and Ping Count (PC) of 1370 shown are saved from previous times I had the receiver and transmitter both on. To make sure the system is working, I turned the transmitter on and placed it next to the receiver, then issued another STATUS command a few moments later.

I can see that DC (detection count) and PC (ping count) have both increased from 27 to 35 and from 1370 to 1443 respectively, so everything seems to be working well!

Now that I’ve been able to send and receive data directly through a terminal window, I’m ready to start writing code to interact with the Rx-LIVE through the Bristlemouth Development Board. This phase of development will require some software development I’ve still yet to learn, so I’ll need a bit of help from some friends. Once we get that working, the system should be ready to use with the Spotter and Smart Mooring!

[estackpole]

Okay, this is where things start getting interesting!

Now that we’ve verified we can format and interpret instructions for the Rx-LIVE directly with a serial terminal, it’s time to start doing those things through the Bristlemouth Developer Board.

Bristlemouth uses a small electric circuit board called a “Mote ‘’ to convert the combined power and data connections provided by Bristlemouth into separate power and data interfaces. There is a Mote at each interface in a Bristlemouth network. Each Mote has an onboard processor that does all the networking between Bristlemouth Nodes and can be programmed to interact with the device it is attached to. The Mote supports a large variety of interfaces (including serial for RS-485, like we’ll want to use) through an array of pins in the board-to-board connector located at the center of the Mote PCB. Some protocols (like RS-485) will still require an external chip to do voltage level conversions from the Mote’s raw serial. That is easily done with commonly available circuitry, and the Development Board has most of the common options covered.

The board-to-board connector on the Mote is a compact way of exposing lots of pins for various types of interfaces all in one connector, but it’s not practical for attaching wires to directly- that’s what the Development Board is for. The Development Board breaks the pins of those headers out into discrete, easy-to-wire to spring terminals, has all the necessary level conversion electronics for various types of communication protocols like RS-232 and RS-485, and also has a variety of other features that are helpful for quickly developing and testing new integrations with the Sofar Smart Mooring system.

Here are some of the features the Development Board offers:

• Breakouts for communications over RS232, RS422, RS485, SDI-12, SPI, I2C, UART, and GPIO
• Regulated power outputs for 3.3V, 5V, 9V 12V, 19V and (unregulated) bus voltage (generally 24V)
• Power monitoring
• Integrated sensors for barometric pressure, temperature, humidity, and an Inertial Measurement Unit (IMU) with 3-axis gyrometer, 3-axis magnetometer, and 3-axis accelerometer.

For more detail about the Development Board, checkout the technical documentation [here] and a sneak peek of the user guide [here].

To configure the Dev Board for our device, we’ll need to set the board up for the correct (12v) voltage and (RS-485) communication protocol, and then wire the device into the correct spring terminals. The development board makes this pretty easy using jumpers that can be placed onto headers for whatever configuration is needed.

There will be more documentation about jumper placement on the Bristlemouth Dev Board in the future, but just by looking at the silkscreen labels near the header pins on the Dev Board, I was able to see where to connect jumpers to set the board up for RS-485.

First I connected the Microcontroller Unit Receive (MCU RX) and Transmit (MCU TX) pins to the RS-485 transceiver electronics by placing jumpers in the MCU RX and MCU TX sections of the header area to the respective rows labeled “RS485”.

For the rest of the RS-485 serial settings I needed to get some help from the Bristlemouth firmware developers, but they’re working on some detailed documentation for the Bristlemouth website so others won’t have to figure all this out on their own.

Some RS-485 devices use an inverted polarity, but from my bench testing I know the Rx-LIVE uses the standard convention, so I inserted jumpers under the TXP and RXP (“Transmit Polarity” and “Receive Polarity”) sections to select standard polarity instead of inverted polarity.

In that same area as the polarity headers, there is also a section labeled “SRL” which allows you to select which Serial communication speed you’d like to set the RS-485 transceiver to. The Rx-LIVE is set up for 9600 baud, so I left the SRL jumper off. The “NC” stands for “Not Connected”, and indicates that the system will work at 115 kbps and below when no jumper is connected.

Finally, there is a section with header pins labeled “RTS”, “RE”, “CTS”, and “DE”. These pins are used for different driver settings depending on the specifics of the serial device you’re connecting to. In the case of the 2-wire RS-485 the Rx-LIVE uses, we’ll install the jumpers for “DE” and “RE” - “Drive Enable” and “Receive Enable” which allow the system to alternatively transmit and receive data to the Rx-LIVE.

Now all we need to do is configure the Dev Board to output the necessary supply voltage to power the Rx-LIVE. This can be done by placing wires or resisters between designated pads on the Dev Board as described by this table I found on sheet 5 of the Dev Board schematics.

“DNP” stands for “Do Not Populate”, and I can see that 12V is the default. Note - adjusting the voltage would require some hand soldering.

As a quick sanity check, I powered the Dev Board up with a 24v supply attached to the Bristlemouth input pins and verified that Vout was showing 12v.

Now the system should be set up for supplying 12v output and communicating with the correct format of RS-485. All we need to do with the Dev Board now is attach the Rx-LIVE!

I attached the four wires for the Rx-LIVE: The two RS-485 data wires (D+ and D-) went to their respective ports, “RS485 Y” and “RS485 Z” (I can describe why we use Y and Z instead of A and B in a later post), Ground went to “GND”, and the power wire which needs 12v was attached to the voltage output pin, “Vout” which we know is configured for 12v.

Now the hardware should be ready to use!

I connected a USB-C cable between the Dev Board and my computer, then plugged in a 24v power supply to one of the two Bristlemouth input connectors on the Dev Board, programmed my Mote with a pre-release RS-485 serial demo app I got from the Bristlemouth core firmware team (I’ll add a link and information about this later), opened CoolTerm on my computer, selected the newly connected port, then typed the command “pluart write *457042.0#22,STATUS”, and Voila! – data from the Rx-LIVE sent data through the RS-485 connection on the Dev-Board to my computer.

Next, we’ll start programming the microcontroller on the Mote so that it can interface with the RX-Live on its own and send data over the Bristlemouth network to my Spotter.