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.

[estackpole]

In this post, I’ll go over the steps taken to prepare software on the Bristlemouth Mote to interact directly with the Rx-LIVE, and communicate that data with the Spotter buoy through Bristlemouth.

Writing software to interact with an external embedded system can be tricky. There are often lots of little “gotchas” to be figured out in order to get everything to work properly, and those details can be buried deep in a data sheet or sometimes not documented at all.

The first step to writing software like this is usually to establish a general idea of what tasks will need to be done, given the objectives and constraints of the system.

In our case, here’s what we’ll want to do:

• Connect with the particular Rx-LIVE receiver we’re using given is unique serial number
• Select the best suited message exchange mode that we want the receiver to use given our needs
• Retrieve the information we want from the receiver (e.g. tag detection information)
• Organize collected data into a format that is optimized for being sent over satellite telemetry
• Send the collected data out with the right cadence to balance information resolution, power consumption, and telemetry costs
• Create a scheme for periodically doing all of the above in perpetuity

I should note, my own software development skills are pretty limited, so for this next section, I got a lot of help from the development team at Sofar. If you need help too, don’t hesitate to reach out on the forums!

We started by looking at the ways data could be retrieved from the Rx-LIVE. On page 17 of the manual, we could see that there are three profile options for getting data:

Profile 0 - sends detection records the moment they occur

Profile 1 - sends detection records periodically based on a user-set schedule

Profile 2 - sends detection records upon request

After considering these options, we decided to design our software to work with Profile 0 which sends detection records the moment they occur. This option would be simple, reliable, adaptable to many types of mission profiles, and would not require any more power than the other options since the Rx-LIVE would need to be powered through the Mote as it monitors continuously anyway. Using this method would also save us from having to set the time on the Rx-LIVE whenever we power the system on.

Upon connecting the Rx-LIVE for the first time, this and other configuration settings would need to be set up once, but would then be retained in the Rx-LIVE non-volatile memory for future operation. We started by writing this initial setup software. Here are the steps we took:

1. Read serial number from physical sensor (we looked on the side of the sensor and entered those numbers into the code)

2. Sum all individual decimal digits in the ID to get the CC code (also done manually, not in code)

3. Store the CC code as a Bristlemouth configuration on our Mote

4. Set the baud rate (as described on page 13 of the manual):

   *457042.0#22,BAUDRATE=115200

5. STOP, ERASE, and RESTART an experiment.

   *457042.0#22,STOP

   *457042.0#22,ERASE

   *457042.0#22,TIME=2024-04-22 00:10:00

   *457042.0#22,START

6. Set the RTMPROFILE

   *457042.0#22,RTMPROFILE=0

That’s it for set-up. Now we would just need to start RTMP (“Real-Time Monitoring Profile”) whenever the system is turned on to begin streaming detections as they happen. Per the manual, we can use a command like the following to do this:

 *457042.0#22,RTMNOW

Along the way, we noticed some weird behavior that took us a while to figure out. For example, it takes some time for the system to boot up and be responsive to commands after being powered on. At first, we implemented a 100ms delay before sending the RTMNOW command, but we later found that it was better to instead just send a STATUS request periodically (as shown in the previous post), and wait to send RTMNOW until the system responds to that.

We also noticed that the data formats for a version of acoustic tag that just pings vs a tag equipped with an additional sensor are different. Tags with just pingers have one less field for data, so it has to be parsed differently than a tag with a sensor. For this reason, we also needed to create a way to differentiate between the two types of tags. Examples of detecting either type of tag are shown in section 2.8.2.1 and 2.8.2.2 of the manual on Page 24.

With these bits in place, we wrote some pseudo code for what would need to happen once new data is received from an RTMNOW request:

After receiving data from RTMNOW:

1. Validate checksum (not strictly necessary for the system to work, we can add this after initial proof of concept is functional)

2. Write the raw line to the bm/rxlive-raw SD card file on the Spotter (the ultimate goal is remote telemetry, but storing all the raw data on the SD card will greatly aid development and field testing)

3. Determine if the raw line is a valid Sensor tag detection [section 2.8.2.1 from the datasheet]:

   1. 10 comma-separated values.
   2. integer ID, 3 digit 0-padded line counter, date time ISO8601, transmitter code space - mixed alphanumeric string, int transmitter ID, integer? sensor ADC value, float signal, float noise, int channel, #checksum.

4. If it’s not a valid tag detection, don’t do anything else.

5. If it is a valid tag detection, parse the data fields and add them to a running buffer of [[codespace, transmitter id, detection count],…]

6. periodically, on a configured interval, transmit the running buffer over Spotter’s satellite telemetry, and clear the buffer.

We’ll write this code and talk about that in the next post, but in the meantime, we tested if the flow of this pseudo code would work by putting an animal tag next to the Rx-LIVE and using ‘pluart write’ in the Command Line Interface to manually test out the startup and data processing flow. Things seemed to work well!