Got it @mike_j - that is indeed an unusual line schema. None of the existing parsers will handle this schema, but if you’re comfortable in C++ I might encourage you to implement a subclass of LineParser like FixedWidthLineParser and open a Pull Request! But, I’m not sure how much use this would see as it’s a very uncommon pattern for a sensor interface.
Your approach of just collecting the bytes and sending them all home sounds totally reasonable.
Note – there’s currently a 300 byte payload limit on Spotter messages (This is not enforced in the Motes and is not well documented anywhere currently, so you would just see an error in your Spotter if you tried to send something larger than this - cc @zachary). So you’ll either need to shed some of the data you’re not interested in, or send the 466 bytes in multiple parts. This is a hard limit for Iridium satellite messages, but we have it on the list to remove this restriction for cellular messages.
if I want temp and humidity from the BM devkit, do I need to write explicit code for that like in the early DevKit Guides?
All of the demo apps in apps/bm_devkit use the main file from bmdk_common. This includes the polling and logging of on-board sensors (hum/temp, pressure, and power montiors). You can adjust the polling rates using the system configs from the guide examples. I’d suggest star
is there a reason that DevKit Guide #5 insists on using v0.5.0 or can I develop new mote firmware with the most recent versions available on github?
You can use the most recent release, but you’ll need to update your Bridge and main Spotter firmware for Spotter compatibility as well. This is the next guide we’ll be releasing - eta 2 weeks (cc @zack_j @timjoh). If you want to test comms with the Spotter before then, I’d suggest sticking to 0.5.0 then updating to the latest when that guide + binaries are available. If you’ll be focusing on Mote integration and don’t need to test Spotter comms yet, I’d suggest developing on the latest bm_protocol released version (0.9.1).
can I have the BM DevKit listening for my sensor’s output continuously – vs, in your examples, turning on for 10 mins per hour or something – or is this going to exhaust somebody’s power budget?
Exactly - the main consideration is energy budget. Predicting whether a solar powered system will be power sustainable in a particular environment is fairly complicated. We’re working on tools to support this, but those are a ways out this year.
The energy consumption of the Spotter in default configuraitons + a single Dev Kit that is constantly on will be ~300mW (150mW for the Dev Kit, and 150mW for the Spotter), and will operate sustainably off of Spotter’s solar panels in most places between 50º N and S year round. If you double that to 600mW, we’re now likely only year round sustainable up to 25º. You can duty cycle your sensor directly from the Dev Kit, use the Spotter sampling configurations to duty cycle the entire Dev Kit, dig into the under-the-hood low power modes in the STM32u5 platform, disable the Spotter visibility LED, or reduce GPS sampling if long dwell power sustainability is a concern for your application.
hope this helps!