I like the idea of being able to choose the "lower-half" (i.e. transport method) for fakesensor. I guess my concerns are:
- Adding an abstraction over the transport layer may add performance overhead that prevents this from being useful on smaller embedded devices. As in, I don't want to add a shared memory middle-layer or anything. I think maybe just having a couple different register() functions for the different lower-halves would work? And based on the register function called, a different transport layer is used in the kthread? - These network-based sensors aren't strictly for testing (i.e. not necessarily "fake sensors"). They can be used in a real application to send sensor data across devices. That's really a nitpick based on naming though. Matteo On Tue, Jan 13, 2026 at 4:28 PM Tomek CEDRO <[email protected]> wrote: > Yup I agree with Alan maybe FakeSensor could be extended to have also > different transports (osed over universal socket?), that sounds best, > if possible with elegant implementation, then it could be all-in-one > swiss army knife for experimenting :-) > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > On Tue, Jan 13, 2026 at 9: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 > > > > > > > >
