Work on the SOFAR Spotter with Development Kit is slower than I hoped.
Status
Work has been especially busy and stressful and I have not had anywhere near enough time to work on my Whale Project. This is basically where it sits:
Still where it was at the beginning of the month. Two trips the UK in Q1 took a huge bite out of my time. April will be slow too, since I have long-planned visits from far-away family. There won’t be much time in April for personal projects.
Thoughts on the Terms of Use
I got it set up and configured and set up the build environment before I paused. And that gives me some time to really think.
I want to be clear that what I am about to say is not a criticism of SOFAR at all. They kindly gave me this hardware and I am not one to look a gift horse in the mouth. This dev kit is AMAZING and will defiitely move the state of the art forward.
AND…
For many people and organizations, the SOFAR Terms of Use may have a mine hidden in it. Section 5.4 says:
5.4 Spotter Data. You hereby grant Sofar an unrestricted, perpetual, irrevocable, worldwide, non-exclusive, fully-paid, royalty-free right and license (with right to sublicense) to obtain Spotter Data, and to host, store, transfer, display, perform, reproduce, modify, adapt, and distribute Spotter Data, in whole or in part, in any format and through any channels now known or hereafter developed, and to exploit the Spotter Data in any manner and for any purpose, including to improve the Service and to create other products or services.
This means that if you use their cloud service to collect data from a Spotter then they can use your data however they want - including letting others use the data however they want. They could even allow someone to use the data to write a scientific paper or build a product based around it. If you use the Spotter, your data is NOT your data.
For many folks that’s not a problem. And it’s their right to put those terms in there. But it does make one wonder if those terms are acceptable. It does make me think.
I also wonder if satellite data is really a necessary option for my project. Everywhere I see whales I’m in a spot where my phone works. I don’t think it’s practical yet to really transfer large audio files even over cell. It may be better to use a slower, long range radio and trickle the data in, or even use WiFi and just go collect data by boat. That doesn’t lend itself to the “phone system for whales” idea but to get started lower data costs are key.
And I think more processing power on the device may be needed. I’m inspired by the book AI at the Edge. I’m pondering applications of edge AI in my day job and it’s made me think more about how I would really build a whalesong system. More on that below.
Thoughts on the Bristlemouth Standard
Bristlemouth is a proposed standard that solves several problems for harsh environment data systems:
- combined power distribution and networking across a strong cable system
- the cable system is waterproof with standard connectors that are field installable
- provides a standard communication and node management/data management protocol
The SOFAR kit also provides:
- a build platform that enables development of platforms that require low-power, connected systems
- all the data collection infrastructure provided - developers can focus ONLY on the sensor
This is amazing, and will be huge for most of the marine science ecosystem.
Thoughts on the MCU Choice
Most of the SOFAR Dev Kit design is predicated on the low-power, autonomous aspects. This drove the design for a low-power embedded board - the Mote that connects to the Dev Board over a mezzanine connector usually used in mobile phones. You can see the schematic here.
The Mote itself uses an STM32 board. The schematic is here.
I can see a lot of applications where I would not necessarily want to use such a low powered MCU. Choosing that puts one into the realm of using an RTOS. The SOFAR kit does a GREAT job of hiding that complexity away. It might actually work. But in my experience at some point the complexity comes back to bite you and you need to really understand it in depth. And for a lot of developers that will be an issue.
Things I am Considering
If you look at the schematic the number of connections needed to implement a node are not all that many:
It’s basically I2C, some SPI, and some GPIO. This is not that different than what I was trying to do with my RBOT Project. And I hit walls there too, trying to use FreeRTOS when developing on Linux would have been much faster.
I think a Linux solution for Bristlemouth would enable development much faster too. But this means not leveraging all the amazing work that SOFAR has already done. That’s a lot of platform to just set aside.
On the other hand, the key reason I do these things is to learn. And developing a Linux-based implementation of the Bristlemouth protocol is certainly a learning opportunity.
Low-power consumption Linux has been with us for a long time in the form of Android phones. But not all marine (or harsh environment) applications have such a low-power requirement. The Spotter has a relatively small number of square inches of solar panels. More panels and a larger battery could support a Linux solution (though I have not done the power budget analysis).
The key thing about this is that it would enable MUCH EASIER development and testing. Keeping everything in Linux-space would enable easy mocking, development and especially testing.
So… it’s something I am thinking about. But probably not doing anything in April. I have family visiting!
