Reading Defining Openness , UNA draws a clear boundary. What I want to raise sits, I think, comfortably inside it. The post said the aim is to keep low-level complexity contained so developers can build good things in the application layer, and UNA will keep documenting and exposing the interfaces developers need.
I’m requesting some interfaces. It’s also, I think, the firmware side of what UNA has already published in una-hardware (
by the way!). Basically the same argument but one layer of abstraction up.
What I’m running into
Some sensor settings are destructive at the point of capture. If the accelerometer is pinned at a range that clips on impact (e.g., racquet swing), or the IMU’s internal low-pass filter is tuned for step counting, the high-frequency content is gone in hardware and no SDK level process can recover it.
Concretely, the BMI270 is clipping in ways that undermine my desired use of it, see (una-sdk issue #258) at its current range. ±16 g may well still clip on hard impacts, but it doubles the headroom and tells me whether the limit is configuration limit or hardware.
The asks
- publish the current sensor configuration (I mentioned this in Defining Openness)
- An API for bounded alternative configuration (e.g., high-rate) sessions. This might look like an app requesting elevated sampling for a defined window, the firmware grants or refuses however the firmware wants to decide that, then configuration is reclaimed after. Arbitration and power budgeting stay within the firmware. This might, in practice, give an app exclusive control of the requested sensor which would imply other consumers would necessarily pause or degrade.
- Making it more complicated, this would also need to cover the read path
- Most pie-in-the-sky: an opt-in developer mode, explicitly void of warranty or support but enabling direct sensor configuration. Note: Sensors only, I would expect the radios to stay locked for certification reasons and have no interest in touching them
- this is the Android “unlocked bootloader” spirit
- no qualms if a “is in dev mode?” is query-able and apps refuse to run
Each I think stands on its own, #1 and #2 are about making it easier to build apps independently. #3 is #2 with the guard rails off and is a strong personal desire to exert as much control as I can over hardware I’ve purchased. Being able to treat the UNA as a general purpose development target is extremely appealing to me. With the source closed, I have no idea how large of an ask more configuration control is when it comes to the data path out, but figured it was worth broaching.
I’m loving my UNA so far and always looking for new and interesting ways to love it more. I’m more than happy to help brainstorm solutions.