Hi Alan, That's good idea! I will see if I can re-use any of the fakesensor code in these implementations and if they are a candidate to turn into one driver. Right now, it looks like they will differ in terms of the executing kthread mostly and not much is re-used besides the boilerplate registration. I will experiment with that idea.
Thank you, Matteo On Tue, Jan 13, 2026 at 2:40 PM Alan C. Assis <[email protected]> wrote: > 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 > > >
