One thing we’ve heard that would make a really big difference is being able to easily set up the development kit to work in tandem with one of the well known prototyping microcontroller kit. There’s a lot of options out there that would work and the Dev Kit will pair well with most of them. With that said, if we can get some help from the community to narrow down to a single class or family of microcontrollers to treat as a “golden standard” to design with, that would be ideal. This will ensure that we are focusing on something that pairs well and as a result we can nail down a great starting place for anyone wanting to explore this avenue.
Some initial thoughts:
We’re leaning something in the Arduino family. We want to target something small and power efficient (compared to a RasPi for example). Going with an Arduino or close relative will also let us piggy back on the massive knowledge base and all the hardware goodies already out there.
Is it bad form to reply to your own post with your own suggestion? Maybe…but I’m just too excited about this idea to wait for someone else to break the ice. I am really intrigued by the Arduino Feather family. Back when I was teaching classes on Arduino we used the minis and the feathers are these plus more…tons of accessories, fully featured, and plenty of available memory.
@AndreH, any thoughts on what might be cool to see here, I feel like you’ve got a lot of experience beyond the prototyping/hobby kits but curious if you have strong feelings about what might be some of the things to consider.
I would certainly put a strong vote in for interfacing with something that runs Arduino excellently. The Arduino Feather family, like you mentioned, @zack_j certainly sounds good.
How do you picture these things interfacing with each other physically? I’ve been 3D printing enclosures for Bristlemouth devices I’d like to make that don’t use the normal Dev Kit enclosure, and getting the Mote and other electronics to fit in the minimal possible volume has been one of my biggest concerns.
I think the existing Bristlemouth Mote is about 50mm x 36mm, so if there could be a sort of backpack with an Arduino uC and some Arduino board features that plugs into it with a similar sized (or smaller) footprint, that would be awesome!
My dream backpack module would have an array of GPIO pads that are big enough to solder directly to, and are spaced to take standard 0.1" headers so the system can be plugged into a breadboard for prototyping. Since the Mote also provides power, there would also be header/solder pads for power output that could be configured as needed just like the Dev Kit.
Okay, maybe I’m getting too far ahead of myself, but I think something like this would be AMAZING.
That’s a bit of a loaded question @zack_j horses for courses and all that…
A couple of thoughts:
We’re huge fans of Adafruit for quick prototyping. The lab is littered with Feathers and StemmaQT breakout boards. So having the standard 4-pin JST on your board would allow access to all those existing tools.
Much of our small logger type projects run on Cortex M0’s, ATSAMD’s in our case, but I’ve heard good things about the STM equivalents if you want to stick to that tool chain.
So very high level requirements:
low power M0+ or similar
SPI for talking to the ADIN2111
I2C via 4-pin JST
Multiple UARTs (90% of our use cases, talks plain old serial)
Extra points for SDIO support (selfish request for streaming IMU data to disk…)
Another way to think about it is to have a Bristlemouth Hardware Feather without an onboard processor. So the ADIN2111 with support hardware and PoDL hardware. Then you can use whatever flavour of controller.
I dont have a ton of experience comparing the Nano to Feather family, so this concern may be unfounded - but I tend to prefer a higher logic level (5v for nano, 3.3v for feather) on principle, as in a busy or lengthy system, you tend to drop/miss less. I know that can largely be mitigated through due care, but just throwing it out there.
I think I would mainly use Arduino uC to send WOL packets (as a way to expand/add power switching), as well as expansion of GPIO for more/multiple SDI-12. If the family fits those needs, I can’t add any strong opinions on the ARM variant itself.
This is an admittedly self-serving recommendation, since the OpenCTD is based around the Adafruit Adalogger M0, but the feather ecosystem is stellar and there are already a lot of options available. There is a ton of plug-and-play adaptability there which makes prototyping and concept proofing a lot less of a headache, and Adafruit has invested a lot in their Learning platform, which means less work for you on the documentation/tutorial side of things.
Also, entirely separate from the “which platform is right solution for us” question, if a goal is to convince agencies like BOEM and NOAA to adopt the bristlemouth standard too, the fact the Adafruit is a US-based company certainly helps.
Somewhat related: @AndrewThaler@AndreH@VernaMize Do any of you guys have experience with VS CODE + Platform.io for firmware development? We’ve been looking at it as an alternative to Arduino IDE. Any thoughts?
I know this is very much a work in progress, but I’m about to place an order for a bucket load of Motes, do you have any idea on when you might hardware available for the new microcontroller board?
Trying to assess if I should hold off on the Motes for a bit or not.
Hi @AndreH this should be a firmware only change and will not include any additional Sofar provided hardware. Any physical parts will likely be 3d printable or orderable from someone like Sparkfun or Adafruit.
Just an FYI, Zack, that last year we did a bit of work using a Feather to collect data from a little sensor that we built to measure currents. It was basically a magnet on the end of a flexible shaft, with the movement of the magnet being measured by a magnetometer in the base of the sensor, and connected to the Feather. We took it far enough to know that some version of that could probably work. I moved on to starting work on fabricating our ROVs, as we’ve talked about. Our 1st very simple, manually controlled ROV is about complete, and I just placed an order with Adafruit to get parts to experiment with using a Rasp Pi to control thrusters, in our case bilge pump motors. Each will hook up to an I/O on the Pi and then through a circuit that can provide 12v power to the motors. If a development kit becomes available, it’d be interesting to see how we might accomplish the same type of thing through Bristlemouth, that is, addressing the thrusters across the common bus, etc. I imagine that we’d probably have to fabricate something to add to the thruster motors to make them identifiable. I understand, of course, that you guys are leaning in a different direction right now. Just thought I’d let you know where we are. Ron
Where I see this co-processor as being powerful and immediately useful is when there’s already a thing working on that or that could work on it very easily and it would be easier to tie that into the Bristlemouth network.
Ultimately / longer term we’d want to put a Bristlemouth “mote” on each component to handle the API and any business logic for that component…which if the chip meets the minimum specs maybe someday can run Bristlemouth natively and not need a co-processor.
Another way to think about it is to have a Bristlemouth Hardware Feather without an onboard processor. So the ADIN2111 with support hardware and PoDL hardware. Then you can use whatever flavour of controller.
