# Integration for a Mini CO2 sensor (RS232) **URL:** \ **Category:** Application Dev\ **Created:** [June 10, 2025, 7:55pm UTC](https://bristlemouth.discourse.group/t/integration-for-a-mini-co2-sensor-rs232/518 "2025-06-10T19:55:12Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![Everardo](https://avatars.discourse-cdn.com/v4/letter/e/278dde/32.png) [@Everardo](https://bristlemouth.discourse.group/u/Everardo)\ **Post date:** [June 10, 2025, 7:55pm UTC](https://bristlemouth.discourse.group/t/integration-for-a-mini-co2-sensor-rs232/518/1 "2025-06-10T19:55:12Z")
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](https://bristlemouth.notion.site/v0-6-0-Bristlemouth-Dev-Kit-Guide-Integrating-an-RS232-Serial-Sensor-abb7d4c9dd38454f941cbec92182142b)) 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. ---
**Author:** ![zachary](https://yyz1.discourse-cdn.com/flex029/user_avatar/bristlemouth.discourse.group/zachary/32/31_2.png) [@zachary](https://bristlemouth.discourse.group/u/zachary)\ **Post date:** [June 13, 2025, 3:46pm UTC](https://bristlemouth.discourse.group/t/integration-for-a-mini-co2-sensor-rs232/518/2 "2025-06-13T15:46:50Z")
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. ---
**Author:** ![Everardo](https://avatars.discourse-cdn.com/v4/letter/e/278dde/32.png) [@Everardo](https://bristlemouth.discourse.group/u/Everardo)\ **Post date:** [June 16, 2025, 2:38pm UTC](https://bristlemouth.discourse.group/t/integration-for-a-mini-co2-sensor-rs232/518/3 "2025-06-16T14:38:35Z")
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: ```auto ~/code/bm_protocol/src/apps/bm_devkit/serial_payload_guide ``` It includes a `CMakeLists.txt` and `user_code` folder. 1. **Build Attempt** I ran: ```auto 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 . ``` 1. **CMake Error** Got: ```auto 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: ```auto src/bm_devkit/serial_payload_guide ``` —not inside `src/apps`. 1. **Make Error** After that, running `make` returned: ```auto make: *** No targets specified and no makefile found. Stop. ``` * * * ### **Second Attempt (More Successful)** To test a cleaner route, I instead placed the app here: ```auto src/apps/bristleback/serial_payload_guide ``` Then I ran: ```auto 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): ![Screenshot 2025-06-16 095427](https://canada1.discourse-cdn.com/flex029/uploads/bristlemouth/original/1X/3052913b636ae76031f71dded7663ddb9ea178d3.png) ![Screenshot 2025-06-16 095500](https://canada1.discourse-cdn.com/flex029/uploads/bristlemouth/original/1X/ef5352ab547e902753d4327ba731c2516311cf3a.png) 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! ---
**Author:** ![zachary](https://yyz1.discourse-cdn.com/flex029/user_avatar/bristlemouth.discourse.group/zachary/32/31_2.png) [@zachary](https://bristlemouth.discourse.group/u/zachary)\ **Post date:** [June 16, 2025, 4:12pm UTC](https://bristlemouth.discourse.group/t/integration-for-a-mini-co2-sensor-rs232/518/4 "2025-06-16T16:12:24Z")
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](https://bristlemouth.notion.site/Bristlemouth-Dev-Kit-Guide-4-Setting-Up-the-Firmware-Development-Environment-f34c4afd9019414284e4605da4b402d0#5a354103695f4674aee108deaf541c74). 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`. ![Screenshot 2025-06-16 at 9.09.53 AM](https://canada1.discourse-cdn.com/flex029/uploads/bristlemouth/original/1X/bbb503d8b57b3a2e2ea3cc9666a9ca107b969300.png) ---
**Author:** ![Everardo](https://avatars.discourse-cdn.com/v4/letter/e/278dde/32.png) [@Everardo](https://bristlemouth.discourse.group/u/Everardo)\ **Post date:** [June 16, 2025, 5:29pm UTC](https://bristlemouth.discourse.group/t/integration-for-a-mini-co2-sensor-rs232/518/5 "2025-06-16T17:29:14Z")
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! ---
**Author:** ![zachary](https://yyz1.discourse-cdn.com/flex029/user_avatar/bristlemouth.discourse.group/zachary/32/31_2.png) [@zachary](https://bristlemouth.discourse.group/u/zachary)\ **Post date:** [June 16, 2025, 6:30pm UTC](https://bristlemouth.discourse.group/t/integration-for-a-mini-co2-sensor-rs232/518/6 "2025-06-16T18:30:58Z")
Yep! That would be a good place to start from. Once you have everything working and want to customize, that will be fine. ---
**Author:** ![Everardo](https://avatars.discourse-cdn.com/v4/letter/e/278dde/32.png) [@Everardo](https://bristlemouth.discourse.group/u/Everardo)\ **Post date:** [June 24, 2025, 7:59pm UTC](https://bristlemouth.discourse.group/t/integration-for-a-mini-co2-sensor-rs232/518/7 "2025-06-24T19:59:26Z")
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](https://bristlemouth.notion.site/Bristlemouth-Dev-Kit-Guide-Integrating-an-RS232-Serial-Sensor-8d5658a0b51a4b238a716ed8ef10539d) `[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/` ![Screenshot 2025-06-24 154348](https://canada1.discourse-cdn.com/flex029/uploads/bristlemouth/original/1X/6ac7167a3ff8a579672f0f71770b0e1ddc37a38a.png) My user\_code.cpp is in: `~/code/bm_protocol/src/apps/bm_devkit/serial_payload_guide/` ![Screenshot 2025-06-24 150644](https://canada1.discourse-cdn.com/flex029/uploads/bristlemouth/original/1X/773f32a2221a64a15a53a2c0047dd535f1d02cf6.png) 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: ![Screenshot 2025-06-24 155324](https://canada1.discourse-cdn.com/flex029/uploads/bristlemouth/original/1X/8e7abee1e9a131bc4a1d5c4e628d7b8c9258f036.png) I double checked my wiring following the manual: ![Screenshot 2025-06-24 155447](https://canada1.discourse-cdn.com/flex029/uploads/bristlemouth/original/1X/d1a8f7b9ff2f02469215a489b1899311e792851d.png) My guess is that maybe `user_code.cpp` isn’t actually being compiled into the app? Or maybe I missed a step? ---
**Author:** ![zachary](https://yyz1.discourse-cdn.com/flex029/user_avatar/bristlemouth.discourse.group/zachary/32/31_2.png) [@zachary](https://bristlemouth.discourse.group/u/zachary)\ **Post date:** [June 25, 2025, 6:21pm UTC](https://bristlemouth.discourse.group/t/integration-for-a-mini-co2-sensor-rs232/518/8 "2025-06-25T18:21:21Z")
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. ---
**Author:** ![Everardo](https://avatars.discourse-cdn.com/v4/letter/e/278dde/32.png) [@Everardo](https://bristlemouth.discourse.group/u/Everardo)\ **Post date:** [June 27, 2025, 4:30pm UTC](https://bristlemouth.discourse.group/t/integration-for-a-mini-co2-sensor-rs232/518/9 "2025-06-27T16:30:43Z")
**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: ![Screenshot 2025-06-27 122355](https://canada1.discourse-cdn.com/flex029/uploads/bristlemouth/original/1X/fd57ef1b901b16668064beba2ac1c017d571f0d0.png) ```auto [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! ---
**Author:** ![zack\_j](https://yyz1.discourse-cdn.com/flex029/user_avatar/bristlemouth.discourse.group/zack_j/32/13_2.png) [@zack\_j](https://bristlemouth.discourse.group/u/zack_j)\ **Post date:** [July 7, 2025, 10:32pm UTC](https://bristlemouth.discourse.group/t/integration-for-a-mini-co2-sensor-rs232/518/10 "2025-07-07T22:32:11Z")
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. ---
**Author:** ![Everardo](https://avatars.discourse-cdn.com/v4/letter/e/278dde/32.png) [@Everardo](https://bristlemouth.discourse.group/u/Everardo)\ **Post date:** [July 21, 2025, 4:22pm UTC](https://bristlemouth.discourse.group/t/integration-for-a-mini-co2-sensor-rs232/518/11 "2025-07-21T16:22:48Z")
Hi Z’s, just wanted to follow up with an update on the Mini CO₂ sensor integration after completing Guide 5. **TL;DR:** The Mini CO₂ sensor is now successfully integrated with the Bristlemouth Dev Kit (mote), including timed sampling, CSV parsing, logging to the Spotter, and support for user-configurable baud rate and line termination. I’ve also shared the full working code and an LED flash demo on GitHub. * * * ### Progress Summary - I copied `serial_payload_example` to a new app called `serial_payload_guide`, resolved build and directory issues, and successfully flashed using `dfu-util`. - Set the PLUART baud rate to `19200` using: `cfg usr set plUartBaudRate u 19200` - The Mini CO₂ sensor (Pro-Oceanus) is configured in **continuous mode**. Once powered from the Dev Kit’s `vout` pin, it starts streaming data — no runtime command needed. (unsure if this is the best way) - I’ve added support to pull both `baud rate` and `line termination` from the user config partition, allowing configurable deployments without recompiling. * * * ### App Behavior - Every 5 minutes, the Mote powers the sensor for 1 minute. - During that window: - The sensor streams CSV data over RS232. - I read and parse corrected CO₂, sensor temp, pressure, IR temp, and supply voltage. - Samples are averaged, and min/max values are tracked. - Data is logged via `bm_printf` as `[payload]` to ensure Spotter compatibility. - Raw payloads are also saved to the SD card with timestamps. * * * ### LED Flash Demo I also wrote a simple LED flash app (unrelated to the sensor) just to: - Verify that firmware flashing was working correctly - Confirm that GPIO and hardware behavior were as expected Helpful during early troubleshooting. * * * ### Spotter Logging - CO₂ data is now being logged correctly to the Spotter’s SD card. - The RTC time seems ~4 hours ahead — might be timezone or clock sync-related. - The Spotter currently powers on for 10 minutes every hour. This gives the Mote and sensor time to sample and transmit. - I’ll likely update this to 3-hour intervals with 10-minute power windows to match deployment requirements. * * * ### GitHub Repo All code and demos are here: \*\* [Vera-Bristle/Mini\_Co2-Integration-LED-Flash: These can be beneficial for flashing your mote (dev kit)](https://github.com/Vera-Bristle/Mini_Co2-Integration-LED-Flash)\*\* Repo includes: - Final `user_code.cpp` with: - Configurable baud rate & line termination - CSV parsing - Sample window averaging - `[payload]` logging - LED flashing test app - Build + flashing instructions * * * ### Next Steps - Finalize sampling intervals and timing logic to ensure the sensor, Mote, and Spotter are all time-aligned - Investigate and correct the RTC offset so logged timestamps match actual local time Thanks again for all the help —Everardo