I have some questions regarding the power cycling capabilities of Spotter, to control the power provided to the Smart Mooring. I am aware that in guide 5 of Bristlemouth a brief explanation is provided, however it is not very comprehensive considering the number of variables that the user can change.
Specifically, I was trying to explore daily cycles, where the Smart Mooring would be powered on during sunlight hours, and off during the rest of the day (e.g. using a dumb cycle of 10h ON, 14h OFF).
During my attempts I noticed that after setting the sample variables, or turning on the Spotter, the Smart Mooring is ON during ~2 minutes, then OFF. Thus, my first question is if it is possible to invert this behaviour, and start the power cycle with the ON part of the cycle, instead of the OFF one?
Another question is related with controlling the start of the cycle. Right now, it is quite dependent on the time one turns on the Spotter, so to sync the daily cycle with the sunlight hours, a user needs to manually turn on the Spotter at a specific time of the day. Is there any way of adding a time delay to it, so one can have more flexibility as to when to activate the Spotter?
Hi @tiagog - this is an interesting use case, and one we have designed support for. I don’t think there’s a way to workaround this just from the Spotter side of things, but it should be feasible to achieve this by using your module as a controller in the system.
The general approach would look something like this:
Configure your Spotter with default low-duty cycle configurations, something like powering the Bristlemouth bus for 1 minute every hour (or whatever minimum control resolution you need).
Your module would wait to receive a UTC time update from the Spotter (these are published every 10 seconds to spotter/utc-time pubsub topic.
On receiving the current time, your module decides whether it’s in or nearing daylight hours. If so, it programmatically sends a Bristlemouth configuration change command to Spotter to disable the Bridge Power Controller.
Repeat the process heading into night time hours, reenabling the Bridge Power Controller when it’s time.
Complications:
Every time your system commits a configuration change to Spotter, it will result in the Bristlemouth bus power cycling, which will cause your system to be powered off. So you’d want to make sure this is the very last thing your system needs to do for any ongoing tasks/operations.
Spotter does not yet have the ability to publish location or battery status data to the Bristlemouth bus. Both of these would be really useful for this kind of application. Both of these are tracked feature requests, but we don’t have them scoped into a specific sprint + deadline yet (cc @zachary@Dan for visibility).
I am aware that in guide 5 of Bristlemouth a brief explanation is provided, however it is not very comprehensive considering the number of variables that the user can change.
Yes, next on our documentation list is a comprehensive guide on Spotter configuration management for Bristlemouth applications. I’ll update this thread when that is published.
During my attempts I noticed that after setting the sample variables, or turning on the Spotter, the Smart Mooring is ON during ~2 minutes, then OFF. Thus, my first question is if it is possible to invert this behaviour, and start the power cycle with the ON part of the cycle, instead of the OFF one?
One configuration to be aware of is the alignmentInterval5Min. This aligns the Bridge Power Controller to the UTC wall clock, with configuration increments of 5 minutes.
So the default setting of 1 means a sampling will start on the next :00Z, :05Z, :10Z, :15Z, etc. A setting of 12 would align hourly to start on the next :00Z. If it’s set to 0, sampling starts on turn-on.
The specific turn-on behavior when the Bridge Power Controller is enabled is:
Power stays on for a 2 minute initialization period.
Enter the first “OFF” period when an RTC (Real Time Clock) time fix is established (happens on first GPS signal acquisition).
After the first “OFF” period is complete, enter the “ON” period (waiting for UTC alignment if that feature is enabled).
We don’t have any flexibility to swap the ON/OFF after startup, or to use tick time in absence of an RTC fix. I’ll capture these as feature requests though!
Sounds good @tiagog - keep me in the loop with any issues or questions, but also when you get it to work and test it out - I’m very interested in this use case.