Here some of the software components I imagine you would need to build in order to accomplish this.
On the Pi:
- code to write to and read from the Pi’s SD card
- code for communicating with the dev kit
On the Bristlemouth dev kit:
- code for communicating with the Pi
- expose a service with a topic string and a handler function by calling
bm_service_register. See the echo service as an example, and we’ll be creating a guide on services in the coming months.
You know your own use case best, but if I’m guessing, maybe the request data could be commands like “count” to get the number of wav files, “list” to get a list of the filenames, “get [filename]” to retrieve the file contents. You’ll have to manage the file transfer in chunks of 1024 bytes which is the current limit on a service response.
One of the things we’d like accomplish this year toward the goal of making Bristlemouth firmware more accessible is making an easy-to-use high-level file transfer protocol. When we get there, this part of your project becomes easier. I discussed this yesterday in the community update. @zack_j will post the recording soon.
The last thing you’d need would require product development here at Sofar Ocean to enable arbitrary Bristlemouth pub-sub communication via Spotter’s USB console. It’s certainly in our sights but not on the short term roadmap. An alternative would be a separate Bristlemouth node, even just an unmodified dev kit, that is close enough to the surface to pull onto the deck and connect USB while leaving the mooring anchored. From there you could make requests to the service exposed on the downstream dev kit.
I hope that helps you envision what would be required to accomplish your goal! Good luck!