Hi Matteo, Yes, I think if you can use the existing uORB function to inject data from user space it will be better.
But I don't know if it is possible to have the same level of functionality provided by fakesensor driver, this is why I suggest modifying the fakesensor to accept data directly from userspace. If fakesensor could work like a data manager to receive data from user-space that fills a double buffer memory and then periodically send these data to the uORB framework it will be more reliable. Probably you know more about the uORB than me, so I think the best approach is testing your idea first and verifying if it works as intended, even for a high volume of data. BR, Alan On Tue, Jan 13, 2026 at 7:35 PM Matteo Golin <[email protected]> wrote: > 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 > > > > > > > > > > > > > > >
