Hello, I am working on a deployment altimeter for my next rocket, which I am of course basing on NuttX. The plan is to use the ESP32C3 since the application will be relatively simple, but requires Bluetooth.
I have taken inspiration both from what InSpace did last year with uORB (simulating our flights on hardware using open source flight logs) and a brand of commercial altimeters called "Blue Jay 2" (https://www.featherweightaltimeters.com/blue-jay-altimeter.html). This brand of altimeters allows for ground-testing of the system by sending simulated altitude data from a companion app to the device over Bluetooth. This allows ejection testing (firing explosive charges to separate the rocket and release the parachute) to also verify that your configuration settings for deployment are correct. I want to take a similar approach with my altimeter, which I have been testing using the `sim` architecture by using the `fakesensor` API to publish barometer measurements from open source flight logs. The testing has allowed me to tune filters, deployment logic and flight stage detection logic. However, in order to achieve this on-hardware simulation for ground testing, I will need to do the same thing but with data over Bluetooth instead of coming from a CSV. This poses my question: would it be accepted to add two new uORB drivers to the NuttX kernel, similar to the fakesensor API? I would like one that is able to publish uORB data received over Bluetooth, and another which is able to publish uORB data received over the network (I would implement this with UDP). This would also create a semi-transparent method of having uORB sensor networks. These would of course require some kind of standardized uORB message format, similar to how the uORB CSVs for `fakesensor` have a required format. Considering the discussions about implementing an integer-based interface for uORB, I'm hesitant to use `float` values directly in the networked messages. Are there any suggestions for a format which would work well? Any thoughts/suggestions in general before I start working on the implementation for this? -- Matteo Golin
signature.asc
Description: PGP signature
