Hi Tomek, I think you and I have the same idea (?) Right now, fakesensor can emulate any uORB sensor and that is also my plan with these networked sensors. The fakesensor implementation actually needs a function for each sensor type which allows it to parse a CSV line into a struct. This wouldn't be a problem with the networked fakesensors so long as the data being sent has the same form as the uORB structs themselves. There is a complication there if supporting ints/floats, but you're right that focusing on floats first is probably a better idea.
My idea right now is to set up the network sensor the same way as fakesensor (the desired TYPE is provided up front), just with some network interface information/BLE lowerhalf instead of a CSV filepath. The TYPE is used to a) register the sensor under the right topic (i.e. sensor_baro) and b) to reject any incoming data of the wrong type. It would also be possible to naively assume all data over the network interface will be of the correct type to avoid prefixing each measurement with a `TYPE` header, I'm not sure which is preferred. I think checking is more robust. Is that what you were thinking? Matteo On Tue, Jan 13, 2026 at 11:13 AM Tomek CEDRO <[email protected]> wrote: > 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 >
