Hi Matteo, I think message queue could be a good candidate to communicate with fakesensor and you can use nuttx/graphics/nxmu/nxmu_server.c as a reference.
Maybe to fix producer-consumer decoupling problems (the fakesensor trying to read and the feeder still processing the data) it is better to have a pool (buffer, FIFO, circular buffer) where sensor data will accumulate and the fakesensor driver will take care of reading from it at the right cadence. I think that for latency to be minimal, double buffering is the best option. I think this way the feeders could be just normal applications, similar to how NX Graphics works, you don't need a driver for each type of interface, just an application that receives data and send to the fakesensor. Other approach is using fifo directly for IPC, when you and send data from computer to the board easily, like Phillippe demonstrated in this presentation: https://acassis.wordpress.com/2021/03/04/using-fifo-on-nuttx-to-send-data-from-your-board-to-computer/ BR, Alan On Tue, Jan 13, 2026 at 5:21 PM Matteo Golin <[email protected]> wrote: > 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 > > > > > >
