Came across this at the Marine Tech Mixer yesterday. Very fascinating a 2wire 802.3 - fascinating phy driver into the power line 
I’m wondering though about the power specs. Couldn’t figure out other places to discuss this?
What is the quiescent current for no comms?
Looking at the initial docs for a development kit - is this likely to manage a power backbone?
From the specs Notion – The all-in-one workspace for your notes, tasks, wikis, and databases.
seems like there is nominal voltage of 24V - and then settable voltage on the output bristlemouth terminals. Which presumably goes to another development kit - but its now not 16-32V?
I’m interested in the RS485(modbus 12V)/SDI-12 ~ which is typically 12V. Again for power savings these typically need to be switched to the instrument.
so just curious as to what is the thinking for power distribution along a line of sensors, possibly daisty chained.?
1 Like
Hey Neil! Welcome! Great chatting with you last week!
Great questions — I don’t have good answers off the cuff, but I’ll ask around and get an expert to reply soon.
Quiescent current
As I’m sure you well know, the first answer is, “It’s complicated and depends on a lot of factors.” 
A more useful answer is that we’ve seen roughly 40 mW in our recent testing for the devkit with no low power modes. We’re actively working on improving this.
Power domains
The Bristlefin bus is 24V. Our devkit provides 24V, 12V (re-configurable for 9-19V), 5V, and 3.3V power buses, for customers’ use in powering sensor payloads
For a daisy chain configuration, you could choose either to have each node be attached to the Bristlemouth bus, communicating over Bristlemouth, or you could build one entire subsystem that you manage with a single connection to the Bristlemouth bus.
Have I answered your questions, or have I missed something?
Hello Zach, thanks for response. Low power measurement/estimates are challenging and of course building in the base battery capacity, especially over the battery capacity reducing over its lifetime.
The context is of course is the sampling rate of the data logger and external solar harvesting. So using a 15min (900seconds) sampling rate - and that all the work gets done very quickly (say 10seconds) - while the dynamic power range requires that for 10seconds sufficient power needs to be supplied for the application. In the other 890 seconds is all at quiescent.
So for a 24V system, quiescent power at 40mW (1.67mA@24V) the base quiescent load on the battery is 1.6mA*24Hrs - 38mAhrs/day or for two weeks of bad weather - 0.5AHr@24V = 12WHrs. Per node/board.
So now working forwards - for a solar panel and IF the spec is to charge the battery in 8hrs - 1.5W (*8hrs=12WHrs) of the solar panel is attributable for the quiescent current.
Probably also suggests, for the battery with reduced capacity from the theoretical - that 1AHr be allocated for quiescent.
Does my reasoning sound good. ?
So then the power budget/profile gets to be the power demand of the sensors, 802.3 communication and then also the cost of pushing the data off into the wider internet.
Seems reasonable. 
The Sofar Spotter provides a Bristlemouth bus, the internet connection over cellular and satellite, the battery, and the solar panels all in one packaged product. So if you want to make one or more Bristlemouth sensor nodes and have those other things taken care of, then that’s a product we work on every day. Our devkit only needs to consume power, not store or generate power.
However, of course, Bristlemouth is very much an open spec that we hope lots of people and companies build for. If you’re thinking of handling the power generation, battery storage, and internet connection side of things yourself, go for it! Looking forward to seeing what you build! This ecosystem will thrive when lots of vendors offer Bristlemouth compatible products.
1 Like
Good to know . I’m looking at land based surface water/stream measurement systems, so not quite the configuration of the Spotter. Just chewing on the basics.
I like the look of the STM32U5 - though the challenge is the overall system - power harvesting, mechanics, sensor powering and internet comms/modem. The M5.Stack Core-S3 is looking to have a modular electronic and software. So just chewing on the technology parts. Thanks for the answers
1 Like
Oh yeah that’s right! I remember you talking about stream measurement last week. Excellent! More power (heh) to you!
And yeah, I’ve really enjoyed working with the Cortex-M33.
Cheers!