A short update on my whale song project: I fell down a few technical rabbit hole!
Back in May I posted that my whale song project was delayed to change the underlying technology. Whew! It’s been an adventure to learn a bunch of new things.
This is all in my spare time, so progress has been much slower than I would like.
Why Not Arduino?
Some folks might wonder why I wouldn’t just use arduino - even use micropython. I could. I might even get a fully working single buoy out made. It probably would be a fine way to prototype it all, since nearly every sensor has drivers. I didn’t want to do that for two reasons:
- I want to learn how the lower level technology works - my goal is not to get something working as fast as possible
- even if I did get a fast prototype done, I would STILL have to do the work later to make it scalable
So, off I went down the technical rabblit hole.
TinyGo?
I like golang - a lot. So I wanted to try TinyGo. It was ridiculously easy to get started. The community around seems strong. But very quickly I found that many of the sensor chips I wanted to use were not supported yet.
OK, maybe too new. What ecosystem has a lot of support? Enter Zephyr.
Zephyr?
All the buzz is around the Zephyr RTOS ecosystem. Huge. Like, it’s overtaking FreeRTOS (which makes me wonder if Amazon made a mistake buying FreeRTOS).
Everyone told me it had a very steep learning curve. My initial research dove into device trees (different than Linux device trees) and kconfig (seems to be pretty much like linux kconfig) and a dizzying array of configuration options. Yes, the learning curve feels like a steep mountain peak in the winter.
So I set Zephyr aside and looked for something I could approach more quickly.
Raspberry Pi Pico
I fell in love with this controller. I have decided not to use it for this project, but damn I love it. Here’s some things I really like about it:
- incredible documentation
- FAST - 133MHz
- dual core
- European company
- widely adopted
- programmable with another pico or the cheap picoprobe
- did I mention the great docs?
I really got into this part. I even built a template repository on github that makes it much easier to set up a new project for this board. I’m specifically referring to using this with the Pico SDK. This is a bare-metal C/C++ SDK that is simply amazing.
I really, really love this part. So why did I set it aside?
It’s the Ecosystem, Stupid (it’s me that’s stupid)
I’ve come to learn that the most important thing you should consider about choosing microcontrollers is the ecosysystem - specifically, how many drivers exist for it, and how much energy is in the system by chip vendors. I spent a pile of time trying to port drivers to the Pico and… well, darn. It takes a LOT of time, and frankly is not what I most like to do. Digging around in the registers of a new chip isn’t my cup of tea.
I tried integrationg an IMU and also a LoRa radio. I found myself spending all my time - what very small time I have for this project - doing things that are simply not core to the project.
I also discovered that many of the drivers easily available are from chips from 2-5 years ago. And some (many?) of those are “not recommended for new designs.” Some are flat out no longer being made (though are actively cloned). The chips I would want to put into a product I’d make next year are simply not supported yet. Makes sense, if you think about it. The open source ecosystem supports what is already mainstream, and the drivers mature enough to be in the SDK examples are going to be for older stuff.
So I decided, reluctantly, to shift directions. Despite loving the SDK, the lack of drivers had me using all my time trying to create them. But it’s almost November and that means it’s almost time for the whales to migrate south again and… I don’t have a thing to put in the water. I can’t even talk to the sensor chips I want to use.
Oh, this rabbit hole gets deeper. It’s not just a change in SDK!
Zephyr!
The things slowing me down were lack of drivers for newer chips. Zephyr has support for many of those newer chips. So I bit the bullet and did enough experimenting that I got a variety of “hello world” and “blinky” working on the Pico. Yay! Super fun. The things that were simple in the SDK took some work in Zephyr - like making the Pico Probe work. But I plowed ahead and made it work.
Now that I had a way to tak to sensors, I needed a radio. Specifically, I need a radio link that I can use to (eventually) take a boat to get near a whale recording bouy and download the song. Ideally it could tell me over a long-range radio that it actually had data for me to collect. So I was looking at a LoRa radio for alerting and either WiFi or Bluetooth for data transfer. The Pico W has a radio on the board already integrated and my casual testing showed it worked well.
And that’s when I hit a brick wall.
To do anything that isn’t super basic with the Pico radio under Zephyr was going to be either impossible, or take a lot of time. I was back at that same point I was at with the Pico SDK.
I can definitely understand why folks trying to “move up” to more professional tooling for embedded systems give up and just go back to Arduino. Damn, this stuff is hard.
Enter Nordic
This should have been obvious to me from day one, but Nordic Semiconductor is THE vedor that has the best support in Zephyr. They integrated it into their entire toolchain. They have whole swaths of training videos. All aimed at their chips, of course.
Well, in for a penny in for a pound! I bought a 3 pack of nRF52840-based boards by Seeed Studio and got to work.
An things worked pretty much out of the box. Of course, by this time I was already a lot more familiar with Zephyr and that helped. I did have to dig around in my parts bin for a J-Link probe, and I had to buy a Seeed Studio Expansion Base Board to expose the SWD pins. More learning.
And now an entire universe of radio options opens up to me, include Bluetooth Mesh. It’s possible that over water, with some directional antennas I could string a set of bouys together in a mesh. If that works, I would not even need to go out in a boat to get the wale song recordings. I might solve a Phase 2 problem in Phase 1!
It does sometimes feel like I’m just sprialling, but as long as I a getting closer and closer to a solution it’s fine! And as long as I’m learning, it’s totally fine.
Is there a bottom to this rabbit hole? We can only move forward and fine out!
Playing with TinyGo Aagain?
Yes, I am in a spiral of sorts. In the months I was learning all this a whole bunch of new sensors/drivers were added to TinyGo. If I get some time I may go back and play there, just for fun!
This is what happens when you are more interested in learning than actually completing a project. But the whales only migrate once a year, so at some point I need to get something in the water!
