Two dev kits on one Spotter

Dev Kit Support
1

Question - why does a second dev kit, added to an existing dev kit + Spotter, write over the data posted to the “/api/sensor-data” site by the first dev kit?

Background - I have data flowing successfully, from a dev kit w two (and soon to be more) RS485 sensors, through the Spotter at 10 minute intervals, and I can pull the data down and plot is in the same manner as if the two sensors are directly connected to a local RasPi - all good. BUT, when I connected a second BMDK, with my same firmware image but without sensors, I see the same ‘no sensor’ data show up in the individual messages with the two unique BM_node_id’s:

image
image1105×175 25.4 KB

It looks like the second BMDK writes over the message buffer of the first, but removing BMDK #2 didn’t fix it, a power cycle then did. I imagine there may be a config setting somewhere I’m missing, has anyone else seen or successfully used this? This is similar to " Integration of two sensors at one node site", but w two BMDK’s actually connected.

2

Hey there. I talked with some folks on our dev team and there could be a few things going on. As far as we know there isn’t a bug or issue with sending multiple messages from different BMDK payloads. The best way to sort it out, we think, is to check the transmission logs on Spotter…this will let you know if your transmission routines are working as intended.

The section here describes how this part works:
Guide-5-Developing-a-Simple-Application: 03c Phone Home.

Specifically: The raw payload hex bytes are also logged to the [BM_TX] (Bristlemouth Transmit) log stream and SD card file. and the section below that detail how to look this up.

From here you can verify whether or not the messages were sent properly or not. Post your findings here and we can continue to help sort this out.

Thanks!
~Z

3

Update:
I looked at the BM_TX log, it confirmed the data disappears and the associated UTC time:
2025-03-11T01:20:41.199Z [BM_TX] [INFO] Submitted spotter/transmit-data message to sat/cell queue, Len: 17
2025-03-11T01:20:41.199Z [BM_TX] [DEBUG] Message:
a4 01 14 d0 8d 41 00 00
75 02 22 21 8f 41 00 00

2025-03-11T01:30:41.218Z [BM_TX] [INFO] Submitted spotter/transmit-data message to sat/cell queue, Len: 17
2025-03-11T01:30:41.218Z [BM_TX] [DEBUG] Message:
ff ff 00 00 a0 c1 ff ff
ff ff 00 00 a0 c1 ff ff

2025-03-11T01:31:18.292Z [BM_TX] [INFO] Submitted spotter/transmit-data message to sat/cell queue, Len: 17
2025-03-11T01:31:18.292Z [BM_TX] [DEBUG] Message:
ff ff 00 00 a0 c1 ff ff
ff ff 00 00 a0 c1 ff ff
But, it does not indicate which BM_node sent the message.

As it turns out, both BMDKs are logging their measurements into a file in their respective folders on the SD, and I can see BMDK#1 measurements stop when BMDK#2 starts up:

BMDK#1:

2025-03-11T01:19:41.191Z | tick: 417545596, ppm1: 420, ppm2: 628, temp1: 17.75, temp2 17.88, stat1: 0x000, stat2: 0x000
2025-03-11T01:20:41.195Z | tick: 417605596, ppm1: 420, ppm2: 629, temp1: 17.73, temp2 17.89, stat1: 0x000, stat2: 0x000
2025-03-11T01:20:41.207Z | tick: 417605598, Successful TX data request (last good TX from #1)
2025-03-11T01:21:41.195Z | tick: 417665596, ppm1: -1, ppm2: -1, temp1: -20.00, temp2 -20.00, stat1: 0xFFFFFFFF, stat2: 0xFFFFFFFF
2025-03-11T01:22:41.195Z | tick: 417725596, ppm1: -1, ppm2: -1, temp1: -20.00, temp2 -20.00, stat1: 0xFFFFFFFF, stat2: 0xFFFFFFFF

BMDK#2:

2025-03-11T01:22:18.292Z | tick: 65599, ppm1: -1, ppm2: -1, temp1: -20.00, temp2 -20.00, stat1: 0xFFFFFFFF, stat2: 0xFFFFFFFF
2025-03-11T01:23:18.292Z | tick: 125603, ppm1: -1, ppm2: -1, temp1: -20.00, temp2 -20.00, stat1: 0xFFFFFFFF, stat2: 0xFFFFFFFF
2025-03-11T01:24:18.289Z | tick: 185599, ppm1: -1, ppm2: -1, temp1: -20.00, temp2 -20.00, stat1: 0xFFFFFFFF, stat2: 0xFFFFFFFF
…
2025-03-11T01:31:18.300Z | tick: 605605, Successful TX data request (‘no sensor’ response)

Is there a way for BMDK#2 to change something, like baud rate or serial port mode, in #1, using a broadcast message or other topic that it is subscribing to? It would be nice to have & connect a debugger and examine these settings while BMDK#2 boots up, but we are also dealing with physical chemistry issues w our sensors etc…

4

Maybe final update - I connected everything again this am, and used the Spotter power switch to cold start it all, it appears to work correctly now. Evidently BMDK#2 glitched the power when hot plugged w BMDK#1 running, and partially corrupted its settings - odd that it didn’t completely crash #1. Anyway, given this and some of the forum issues, we will add some defensive code and try to implement some staggered power up sequence when our system finally out on its own. Thanks

1 Like