Hi Alan, Hmmm, that seems like a good idea. In terms of the IPC, I think uORB does it's own internal producer-consumer handling for the published data. So moving data directly from the receiving interface (UDP, BLE, etc) to uORB via `sensor->lower.push_event(...)` should be fine in terms of synchronization. I don't know if having another pool in between would add anything.
However, you raise a good point about having these be applications instead of kernel drivers. In fact, uORB lets users advertise their own topics from userspace and it provides the buffering/pooling that you mentioned for free (you can choose the buffering size). Maybe I can achieve the same functionality just from within an app and let the user run multiple instances that way. I've been using apps so far for custom uORB topics so I'll see if it's possible to "masquerade" as a sensor device easily that way, too. I agree with you that it would be much better than a driver for each interface type, and I think it's probably a better idea to keep network stuff like creating a socket out of kernel code. Let me know what you think, Matteo On Tue, Jan 13, 2026 at 5:10 PM Alan C. Assis <[email protected]> wrote: > 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 > > > > > > > > > >
