Overview

<aside> 🎏 NOTE: Currently you need to be on the develop branch of bm_protocol to follow this guide. The supporting firmware will be included in the bm_protocol v0.6.0 release**.**

</aside>

In this guide we’re going to integrate a marine sensor into our Bristlemouth Dev Kit using the RS232 serial protocol. We’ll use an RBRcoda³ T temperature sensor, but the process in this guide applies to the many existing marine sensors that support RS232 serial communications.

By the end of this guide you will:

• Know how to physically configure your Bristlemouth Development Board to connect to an RS232 sensor.
• Get familiar with the “Payload UART” serial interface in the Dev Kit firmware application framework.
• Build an end-to-end proof of concept application that integrates a marine sensor into the Dev Kit, reads and parses data from this sensor, and publishes this data over the Bristlemouth network to your Spotter.

<aside> 📖 For more technical detail and open source schematics of the Dev Board hardware, checkout the Downloads ****section of our Technical Documentation.

</aside>

<aside> ⏳ Expect to take at least 1 hour to complete this guide, and possible more depending on how familiar you are with your sensor of choice.

</aside>

Before starting this guide, make sure you have completed Getting Started Guides 1 through 5.

If you want to follow along with the exact hardware integration in this guide, in addition to your Bristlemouth Dev Kit you’ll need:

• An RBRcoda³ T temperature sensor [link to RBR’s product page].
• A Micro Circular 6-pin Female cable assembly to connect to the sensor. We’re using one from MacArtney [link to MacArtney product page], but there are several vendors who provide compatible cable assemblies.

Table of Contents

General Approach

The general approach we’ll be taking in this guide is to incrementally build the minimal necessary functionality for integration, taking the time to test at every step along the way. Once we have a fully integrated MVP / proof-of-concept, only then is it time to incrementally add features and complexity to the system - again testing at every step of the way.

This approach is informed by our collective centuries of experience as embedded engineers working on complex integrated systems like robots, cars, planes, drones, submersibles, satellites and remote sensing stations. This approach is generally (but not universally) accepted as “the way” to do this. If you are an experienced engineer and have your own tried and tested methods - please carry on and disregard this section.

If, however, you are relatively new to this kind of embedded systems integration, we strongly recommend you follow the approach laid out in this guide and resist one of two common temptations that tend to lead to mayhem and despair:

1. “Hook everything up in one go and see if it all works”.
2. “Completely implement the perfect module before integrating it into the rest of the system”.

01. Before The Integration