Integration for a Mini CO2 sensor (RS232)

[Everardo]

After completing guide 5, I was tasked to integrate a Mini CO2 sensor (RS232) to the bristlemouth mote. I saw that there was a guide for a temperature sensor, I was curious if that is going to be a similar setup.

Here is the link for integrating an RS232 Serial Sensor ( (v0.6.0) Bristlemouth Dev Kit Guide: Integrating an RS232 Serial Sensor)

Going to that guide: I was stuck on the Electrical integration, I was able to create a copy of the serial_payload_example app and stuck with the serial_payload_guide name for the copy.

My problem is that I was failing to build the bin files within the new copied folder. Which doesn’t allow me to flash.

[zachary]

Hi @Everardo, sorry you’re having difficulty getting started. I think you’re going to have to provide more info on exactly what you’ve done, where you’ve copied files, what commands you’re running, and what error you’re receiving when you try to flash.

[Everardo]

Hi Zach, thank you for your response!

Here’s what I’ve done so far and where I’m stuck:

---

First Attempt

1. Copied Example App
   I duplicated serial_payload_example into:

~/code/bm_protocol/src/apps/bm_devkit/serial_payload_guide

It includes a CMakeLists.txt and user_code folder.

2. Build Attempt
   I ran:

rm -rf build
cmake \
  -DCMAKE_TOOLCHAIN_FILE=cmake/bm_toolchain.cmake \
  -DCMAKE_CROSSCOMPILING=TRUE \
  -DCMAKE_TRY_COMPILE_TARGET_TYPE=STATIC_LIBRARY \
  -DBSP=bm_mote_v1.0 \
  -DAPP=bm_devkit/serial_payload_guide \
  -B build -S .

3. CMake Error
   Got:

add_subdirectory given source "/home/vera/code/bm_protocol/src/bm_devkit/serial_payload_guide" which is not an existing directory.

That told me the build system expects the app at:

src/bm_devkit/serial_payload_guide

—not inside src/apps.

4. Make Error
   After that, running make returned:

make: *** No targets specified and no makefile found. Stop.

---

Second Attempt (More Successful)

To test a cleaner route, I instead placed the app here:

src/apps/bristleback/serial_payload_guide

Then I ran:

cmake -DCMAKE_TOOLCHAIN_FILE=cmake/bm_toolchain.cmake \
      -DCMAKE_CROSSCOMPILING=TRUE \
      -DCMAKE_TRY_COMPILE_TARGET_TYPE=STATIC_LIBRARY \
      -DBSP=bm_mote_v1.0 \
      -DCMAKE_APP_TYPE=bristleback \
      -DAPP=serial_payload_guide \
      -B build -S .

This time, the build progressed almost completely — but failed at 98% with the following errors (GPIO declarations not recognized):

My Questions:

1. Is src/apps/bristleback/ the correct place to put new apps for this BSP/toolchain combo?

2. Do I need to include or register GPIO pins somewhere else for this app to build correctly?

3. Are there any other gotchas I should be aware of when placing custom apps in the tree?

Thanks so much — just want to make sure I’m not going down a bad path!

[zachary]

Thanks, that helps!

If you’re using a Bristlemouth Dev Kit, then you should use the bm_devkit directory for apps, not the bristleback directory. “Bristleback” is a minimal internal adapter board we use for some projects, but there’s no public version of it.

In your first attempt, the main change you need to make is -DAPP=serial_payload_guide without the path in front of it — that’s what the error was telling you about.

I don’t recognize the first 3 cmake cache entries. Did you create a new bm_toolchain.cmake yourself? We’re building an executable here, not a static library.

The full recommended cmake configure command is listed in step 6 near the bottom of guide 4, under the heading Testing the dev environment. Here’s a screenshot, but you should go to the guide, carefully follow those steps and exactly copy the given cmake command with only the APP changed from hello_world to serial_payload_guide.

[Everardo]

Hi Zach,

Thank you for your response!

After going through our troubleshooting,
I realized my current repo it does have some custom or leftover files (like the custom bm_toolchain.cmake) and is missing the official cmake/toolchains/arm-none-eabi.cmake file.

To avoid further confusion and build issues, would you recommend I do a clean restart by resetting or recloning the repo, but keep my hello_world_guide_5 app code?

I want to make sure I have a clean environment aligned with the official setup so I can smoothly integrate the Mini CO₂ sensor and build the new app properly.

Thanks!

[zachary]

Yep! That would be a good place to start from. Once you have everything working and want to customize, that will be fine.

[Everardo]

Hey Zach
I successfully flashed the serial_payload_guide app to the Mote using the RS232 guide, but I’m not seeing any [payload-line] or [payload-bytes] output in the USB console like in the example.

Output Example from: Notion

[payload-bytes] | tick: 67556, rtc: 0, bytes:36 32 30 30 30 2C 20 32 33 2E 34 30 35 37 0D 0A
[payload-line] | tick: 67566, rtc: 0, line: 62000, 23.4057
[payload-bytes] | tick: 68048, rtc: 0, bytes:36 32 35 30 30 2C 20 32 33 2E 34 30 36 37 0D 0A
[payload-line] | tick: 68068, rtc: 0, line: 62500, 23.4067

Here’s what I’ve confirmed:

The .bin file was built at:
~/code/bm_protocol/cmake-build/serial_payload_guide/src/

My user_code.cpp is in:
~/code/bm_protocol/src/apps/bm_devkit/serial_payload_guide/

I’m using a Mini CO₂ Pro sensor via RS232. Everything flashes fine, but it looks like user_code.cpp isn’t running.

Dev kit (mote) running with mini co2 sensor connected:

I double checked my wiring following the manual:

My guess is that maybe user_code.cpp isn’t actually being compiled into the app? Or maybe I missed a step?

[zachary]

The fact that you see the power, humidity, temperature, and pressure logged from the mote means it’s running fine. Your dfu-util screenshot certainly shows that the mote was erased and flashed. It’s just not receiving any data from the RS232 sensor.

[Everardo]

Update on Mini CO₂ Sensor Integration

• I’m getting about 12.1 V out of VOUT, so the power supply voltage looks solid.
• Wiring has been verified, and all ports are confirmed working properly.
• When using a PC → USB → RS232 converter, with the Dev Kit powered by a wall outlet, we can successfully access and communicate with the sensor.
• Measured RS232 lines on the Dev Kit side show:
  • TX ≈ 5.9 V
  • RX = 0 V
• However, when powering the sensor strictly from the Dev Kit, the sensor does not power on or function correctly.

Additional update:
I double-checked the flashing process by building and deploying a simple test code that blinks LED1 and LED2 on the Dev Kit. That worked perfectly, confirming flashing is successful and the Dev Kit is running custom code as expected.

(I have a video showing this if anyone wants to see it — happy to share!)

Configuration update:
I set the baud rate on the mote to 19200 to match the Mini CO₂ sensor’s baud rate, but every time I re-open the port, it resets back to the default 9600, so I have to manually change it each time.

Debug info:
After enabling debug output on the mote, here is a snippet of the received serial data:

[RX:'h'] h [RX:'um_temp | tick: 1182189, rtc: 0, hum: 49.318054, temp: 22.932268\n'] 
um_temp | tick: 1182189, rtc: 0, hum: 49.318054, temp: 22.932268

[RX:'p'] p [RX:'ressure | tick: 1184198, rtc: 0, temp: 22.942606, pressure: 989.518982\n'] 
ressure | tick: 1184198, rtc: 0, temp: 22.942606, pressure: 989.518982

[RX:'p'] p [RX:'ower | tick: 1184205, rtc: 0, addr: 67, voltage: 23.681601, current: -0.000250\n
power | tick: 1184207, rtc: 0, addr: 65, voltage: 23.681601, current: 0.006250\n'] 
ower | tick: 1184205, rtc: 0, addr: 67, voltage: 23.681601, current: -0.000250
power | tick: 1184207, rtc: 0, addr: 65, voltage: 23.681601, current: 0.006250

This confirms data is streaming through the mote’s serial interface.

Questions:
How can I verify that the Dev Kit is actively sending RS232 data to the sensor when powered solely by the Dev Kit?
Is there something that I am missing or overlooking? Any help is much appreciated!

[zack_j]

Hey here @Everardo

I spoke with @zachary (there are two Zac’s!) and we’ve got some advice.

First step – configure the sensor so it’s outputting data constantly. We can add a write function later but for now we want it just running when powered. This is something we can’t really help you with as we don’t have the sensor here. The trick we did earlier could work and you can check this by reading directly from the sensor using a USB-RS232 adapter + terminal.

Using the sensor’s native program can be helpful but we want to validate this works when powered.

Once you’ve validated your sensor is doing this all the time when powered we can move on.

Next step – let’s roll back the set up to something easier to troubleshoot and more predictable. This will give us confidence that we’re getting data from the sensor, and that your code is parsing the data correctly.

CO2 sensor > dev kit (powered w/ wall wart) > USB > computer (no Spotter)

• Update your code to use printf, which will be printed out the USB cable to the serial terminal. For now, don’t worry about bm_printf and bm_fprintf which send messages to Spotter.
• With PLUART, we recommend using lines not bytes. Call PLUART::setUseByteStreamBuffer(false); in setup, note the false
• Start by reading a line from PLUART and printing it directly with printf

Once you’re able to get the PLUART printing to USB as anticipated we can move on to more complexity with confidence.

Our recommendation is then to add printf lines at critical junctions for the next parts of your code (e.g. tx or SD save).

Does this make sense? Let us know where you get stuck with this and if it’s all working as expected–great we can move onto other more complicated things.