Hi Matteo, That sounds like a great idea!
Maybe instead of creating two new sensors, you could extend fakesensor_uorb to have different types of fakesensor_read_* interfaces. So, the user could decide if he wants to get the data from CSV, Bluetooth, Network UDP, etc. Another more flexible approach should be having a kind of simple POSIX IPC (shared memory, message queue, etc) to feed the data to fakesensor, where the separated feeders read from CSV files, Bluetooth, Network, etc, and send the data to fakesensor. This approach could allow multiple interfaces to work simultaneously. BR, Alan On Tue, Jan 13, 2026 at 12:43 PM Matteo Golin <[email protected]> wrote: > 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 >
