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 > > > > >
