Hi @Taylor.gill - can you clarify your overall system architecture a bit more?
Do you have a Dev Kit with SAMI that will be sub-surface on the mooring, and also a custom SST probe that you are integrating into the Spotter buoy directly?
We have a subsurface SAMI connected to the dev kit on the bottom node and just received a sofar temp probe to put in the middle node without the dev kit.
Got it -
• The Sofar Bristlemouth Temperature Sensor will already be on Bristlemouth version 0.11, so you won’t need to update that.
• You’ll need to update your custom Dev Kit firmware to v0.11 by merging that tag into your working branch, then re-compiling your application and flashing the result to your Dev Kit.
- I’d recommend updating the Dev Kit over USB DFU or SWD, as that is simpler and faster than bootstrapping over incompatible Bristlemouth protocol versions.
• You’ll also need to update your Spotter Bridge and Main processors.
- I’d recommend updating the Spotter Bridge over USB DFU so you can update the bootloader.
However, we made a custom firmware that allows the buoy to receive information from our SAMI properly. I am worried that changing firmwares on the other parts of the buoy will cause a problem with the SAMI recordings.
There shouldn’t be any issues with this, but we do recommend testing it out, and if you discover any issues it will be possible to revert.
Hi @evan could you please explain your second bullet point a bit more?
I made sure that the bristlemouth dev kit, spotter brisge and spotter main processor have all been updated to the latest firmware versions.
I am now try to “merge that tag into the working branch, then re-compiling the application”.
I am not sure how to do this part. Is this as simple as replacing the bm_protocol 0.11.1 user code with our edited version and recompiling the app? Or is there a different process to do this part?
AWESOME! 
Did you program your Dev Kit with the ‘Hello World’ app at 0.11?
Before taking the next step of getting your custom Dev Kit firmware up to 0.11, I’d suggest:
- connecting all system elements (Spotter, Sofar Bristlemouth Temperature Sensor, and Hello World Dev Kit) and make sure you can discover all info via the Spotter CLI
- make sure you’re seeing sensor data (power etc) as expected from the Hello World Dev Kit and temperature readings from the Sofar Temperature Sensor.
I am not sure how to do this part. Is this as simple as replacing the bm_protocol 0.11.1 user code with our edited version and recompiling the app? Or is there a different process to do this part?
- If you’re comfortable with
gitor are interested in learning more, there are workflows in git that are designed for this. Essentially, you’dpullthe latest v0.11.0 release of bm_protocol into your working branch, and your custom app should just work or require minimal noodling to get it working. - Otherwise, you could follow the process in Guide 5 to setup a new app off of
bm_protocolv0.11.0, and copy your working code from v0.4 into that.
I believe you have office hours scheduled with @zachary tomorrow, and this is a perfect thing to work through during that.
1 Like
I am running a test today after meeting with @zachary yesterday. I see the SAMI is still producing the correct messages, but I am unsure if I am getting temp data through the spotter.
I set these parameters before the test:
bm cfg set 0 s u bridgePowerControllerEnabled 1
bm cfg set 0 s u sampleIntervalMs 3600000
bm cfg set 0 s u samplesPerReport 2
bm cfg commit 0 s
I am trying to get the temp probe to take a sample on the hour in a 5 minute window (similar to what our SAMI does) so I can test battery life in a deployment situation. Right now I am just testing data output (the spotter is plugged into a charger).
I dont see any temp data coming through the API, but might be doing it wrong. Can you please help me figure out how to see if temp data is coming through at the proper intervals.
Here is what the API looks like right now
{
“data”: {
“spotterId”: “SPOT-31260C”,
“spotterName”: “Cheeca Rocks (SPOT-31260C)”,
“payloadType”: “sensorData”,
“batteryVoltage”: 4.04,
“batteryPower”: 0.01,
“solarVoltage”: 4.78,
“humidity”: 31.2,
“track”: [
{
“latitude”: 25.73465,
“longitude”: -80.1622833,
“timestamp”: “2024-08-29T15:02:22.000Z”
}
],
“waves”: ,
“surfaceTemp”: ,
“frequencyData”:
}
}
We dont see any wave or temp data.
Hi @Taylor.gill - awesome progress.
These configs:
bm cfg set 0 s u sampleIntervalMs 3600000
bm cfg set 0 s u samplesPerReport 2
Will result in the Spotter collecting a sample from the Temperature Sensor every hour (3600000 ms), and putting 2 samples in each telemetry report, which would result in reports every 2 hours.
There might be other configurations that are preventing samples from being reported though.
I think the simplest thing to do would be:
- Connect all modules to the Spotter.
- Insert a blank SD card.
- Turn the system on and let it run for a few hours.
- zip up and share the SD card data here.
=> We can take a look at the data, and walk you and others through the specific things to look for in the logs for troubleshooting this.
Okay I am letting it run right now. It has been running for 3 hours and I still have not seen a temp recording. I also do not see the temp sensor on our dashboard and I was wondering how we can see it from there.
I will let it run and send the SD card data here in a few hours.
If we wanted to deploy the buoy without the temp node could we just take it out of the physical set up or would we have to do some additional coding to exclude it?
You could just take it out of the physical setup.
If you’re able, could you also share some pictures that show how the different elements are connected?
Yes! we have the sofar connected to the temp probe connected to the dev kit which is then connected to our SAMI.
Ahh, I think I see what’s going on @Taylor.gill. It looks like the configuration commands you sent did not take hold.
Your system (SPOT-31260C) is currently reporting its configuration as:
"sampleDurationMs": 300000,
"sampleIntervalMs": 12000000,
"samplesPerReport": 2,
"subsampleEnabled": 0,
"softReadingPeriodMs": 500,
"subsampleDurationMs": 30000,
"subsampleIntervalMs": 60000,
"ticksSamplingEnabled": 0,
"transmitAggregations": 1,
"alignmentInterval5Min": 1,
"currentReadingPeriodMs": 60000,
"rbrCodaReadingPeriodMs": 500,
"turbidityReadingPeriodMs": 1000,
"bridgePowerControllerEnabled": 0
The Power Controller being disabled will mean the bus power is always on, and the sampling control will be disabled.
The good news, is that I can also see that your system is detecting the Temperature Sensor. So you should see plenty of temperature data on the SD card after your test.
Can you retry the config commands again, and copy-paste the full command line output here?
I actually have an open office hours slot today at 3PM Pacific. If that time works for you, shoot me a DM with your email and I’ll send an invite.
That would be great just dmed you.
I just tried redoing the commands:
bm cfg set 0 s u bridgePowerControllerEnabled 1
bm cfg Succesfully sent config set msg
set 0 s u sampleIntervalMs 3600000
bm cfg set 0 s u samplesPerReport 1
bm cfg commit 0 Succesfully sent config set msg
Succesfully sent config set msg
s2024-08-29T17:50:26.898Z [BRIDGE_CFG] [INFO] Node ID: 0000000000000000 Partition: system Value: 1
2024-08-29T17:50:26.906Z [BRIDGE_CFG] [INFO] Node ID: 0000000000000000 Partition: system Value: 3600000
2024-08-29T17:50:26.914Z [BRIDGE_CFG] [INFO] Node ID: 0000000000000000 Partition: system Value: 1
Succesfull config commit send
2024-08-29T17:50:28.140Z [BRIDGE] [INFO] Reboot info received from 30378926282c6a5c - Reason: 5 gitSHA: 595e7745 Reboot cnt: 1 PC: 0x0 LR: 0x0
2024-08-29T17:50:30.140Z [BRIDGE_SYS] [INFO] Bridge State Init
2024-08-29T17:50:30.140Z [BRIDGE_SYS] [INFO] Bridge bus power: 1
2024-08-29T17:50:30.140Z [BRIDGE_CFG] [INFO] Response msg – Node Id: 0000000000000000, Partition: system, Commit Status: 0
2024-08-29T17:50:30.140Z [BRIDGE_CFG] [INFO] Num Keys: 14
2024-08-29T17:50:30.140Z [BRIDGE_CFG] [INFO] Key 0: bridgePowerControllerEnabled
2024-08-29T17:50:30.144Z [BRIDGE_CFG] [INFO] Key 1: sampleIntervalMs
2024-08-29T17:50:30.144Z [BRIDGE_CFG] [INFO] Key 2: sampleDurationMs
2024-08-29T17:50:30.144Z [BRIDGE_CFG] [INFO] Key 3: subsampleIntervalMs
2024-08-29T17:50:30.144Z [BRIDGE_CFG] [INFO] Key 4: subsampleDurationMs
2024-08-29T17:50:30.144Z [BRIDGE_CFG] [INFO] Key 5: subsampleEnabled
2024-08-29T17:50:30.144Z [BRIDGE_CFG] [INFO] Key 6: alignmentInterval5Min
2024-08-29T17:50:30.144Z [BRIDGE_CFG] [INFO] Key 7: ticksSamplingEnabled
2024-08-29T17:50:30.148Z [BRIDGE_CFG] [INFO] Key 8: samplesPerReport
2024-08-29T17:50:30.148Z [BRIDGE_CFG] [INFO] Key 9: transmitAggregations
2024-08-29T17:50:30.148Z [BRIDGE_CFG] [INFO] Key 10: currentReadingPeriodMs
2024-08-29T17:50:30.148Z [BRIDGE_CFG] [INFO] Key 11: softReadingPeriodMs
2024-08-29T17:50:30.148Z [BRIDGE_CFG] [INFO] Key 12: rbrCodaReadingPeriodMs
2024-08-29T17:50:30.148Z [BRIDGE_CFG] [INFO] Key 13: turbidityReadingPeriodMs
2024-08-29T17:50:30.148Z [BRIDGE_CFG] [INFO] Response msg – Node Id: 0000000000000000, Partition: user, Commit Status: 0
2024-08-29T17:50:30.148Z [BRIDGE_CFG] [INFO] Num Keys: 0
1724953830.148 0171761d2c37eb4c, soft | tick: 678, rtc: , temp: 24.509932
1724953830.152 0171761d2c37eb4c, soft | tick: 1198, rtc: , temp: 24.509932
2024-08-29T17:50:30.156Z [BRIDGE_CFG] [INFO] Response msg – Node Id: 0000000000000000, Partition: hardware, Commit Status: 0
That one did the trick!
Your system already checked in and is reporting the correct configuration.
Note this will result in your Dev Kit + SAMI node only being powered for 5 minutes every hour, which is a change from how it was operating before you sent this. If you have a 5 minute timer in that app to trigger data sending, you may want to add some padding to “sampleDurationMs” to make sure it has time to do whatever processing and transmitting is needed before being powered off.
To see what your system’s current configuration is, click on the SETTINGS button for the Spotter in the dashboard:
Then expand the “Spotter Configuration” section, and look at the Smart Mooring sub-section.
okay great! The SAMI takes about 2-3 minutes to sample so we should be good, but I will keep an eye on that.
What should I be seeing in the API when the temp probe information comes through? Should I expect to see something from the probe after the next hour passes?
Yep, you should see JSON dictionary records in the response data list with the key bm_soft_temperature_mean_13bits.
Let us know how it goes. 
Data looks good! I am going to run an energy consumption test over the week and will let you know how that goes.
Another question for you. I am trying to program another one of our buoys and I keep running into a Neighbor not connected or Neighbor lost pop up. I also received an Err 6 which means that the node might be offline. It looks like this is for the node holding our temp probe on the other buoys. How can I make sure to get that node online and communicating?
It may be that the bridge power controller is turning off the Bristlemouth bus. You may want to disable it while you’re updating things, like this.
bm cfg set 0 s u bridgePowerControllerEnabled 0
bm cfg commit 0 s
Just remember to re-enable it when you’re all finished, like this.
bm cfg set 0 s u bridgePowerControllerEnabled 1
bm cfg commit 0 s
Thank you I will try this!
I also realized that sending the same spotter config I sent for my first buoy did not change the sample rate to 5 minutes like the first one.
I sent this for my first spotter and it changed to 1 sample. 60 minutes, 5 minutes. I am not sure why its not having the same effect on the others.
bm cfg set 0 s u bridgePowerControllerEnabled 1
bm cfg set 0 s u sampleIntervalMs 3600000
bm cfg set 0 s u samplesPerReport 1
bm cfg commit 0 s
The only one that looks like it doesn’t match to me is the sample duration. Change that to 5 minutes with:
bm cfg set 0 s u sampleDurationMs 300000
bm cfg commit 0 s