Hello Matteo :-) Sounds like a great and very useful idea to have "virtual" uORB sensors over the Bluetooth and TCP/IP :-)
Maybe it would be possible to provide some generic way for it to simulate any other uORB defined sensor and their data strucure? I mean to have single BLE uORB sensor that would allow to emulate any other sensor. That way there would be no need to mirror other sensors as per type but just transport other types in one single virtual sensor? Maybe some extension to existing sensors in the uORB whatever allows best implementation :-) Regarding data format int vs float I guess your priority is more on accuracy rather than computing power right? Especially when simulating? Thus float seems probably better choice.. and one day when the integer rework is ready it could be also used with integers? Thanks! :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info On Tue, Jan 13, 2026 at 4: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
