Hi Matteo, Yes, I think adding the support to control the sample rate and other parameters from your application side will be very helpful.
BR, Alan On Sat, Jan 17, 2026 at 3:31 PM Matteo Golin <[email protected]> wrote: > Hello, I've opened a draft PR with a mockup of what I was thinking for the > `netsensor` integration: https://github.com/apache/nuttx-apps/pull/3341 > Any feedback would be appreciated! > > Now that I've written the sample though, I'm starting to think about what > would be a better extension. Right now this is very simple, with one > program to read UDP data and publish it to uORB; another to read a uORB > topic and stream it over UDP. What I'm wondering is if it wouldn't be more > interesting to allow complete interaction with a `netsensor`, like being > able to request a different sampling rate, enable/disable, subscribe, etc > over the network. More like a complete abstraction that allows an > application to interact with a netsensor over the network _exactly_ as > though it were a local sensor. Something very reminiscent of QNET on QNX if > anyone has worked with that. That change would probably require the sensor > to be developed in the kernel instead of userspace though, and would > require some actual thinking to set up. I think I may go the route of > extending fakesensor like Alan suggested. > > Let me know if you have any other ideas! > Matteo > > On Wed, Jan 14, 2026 at 6:18 AM Alan C. Assis <[email protected]> wrote: > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > >
