Signal range and value problems

[bboettcher3]

Notes from testing signals with webmapper:

• battery: needs ranges, values not correct
• brush: range is too large, should be -1-1
• count: why is this a signal?
• double_tap: no signal values aside from 0
• jab: should be instanced, hard to detect
• multibrush: range too big
• multirub: should only be positive
• tap, triple tap: should be instanced
• accel: should make a normalized version, unknown ranges
• capsense: another normalized centroid signal
• fsr: needs normalized signal
• mag: values stay around zero

[edumeneses]

Answering some:

• battery: Should be an estimate converted into percent (0 to 100). It will never be 100% (pun intended) accurate as the pin measures instantaneous battery voltage. Hence the values are passed only sporadically. One possible option is to pass only "high", "medium", and "low" as battery values. Also, changing batteries also changes max/min voltage values and requires manual tweaking of range
• brush and multibrush: it should not have a max/min as the theoretical ceiling is the sensor and function's refresh rate, which is higher than any human ca brush. The idea here is to have a type of gesture that is limited only by human capabilities rather than a hard coded limit
• count: people can count and map this in interesting ways. E.g., you keep taping and at the end it generates sound based on how high the count went, or can be used to jump to different sections, etc.
• double and triple tap: those are interesting Puara gestures, but since we're using the double tap to enter deep sleep, maybe they should not be exposed. to be discussed. Also, people can use count to extract any number of taps from buttons
• jab: works fine on the green T-Stick I have here, maybe we can expose some sensitivity parameters?
• multirub (and rub): you're referring to the range right? I think it outputs only positive values, so we only need to fix the range of the libmapper signal (also, should not be a ceiling, just like brush)
• tap, triple tap: I would only create a tap signal (check my double/triple tap answer)
• accel: AFAIK, it outputs m/s^2 (please check the comments at https://github.com/IDMIL/T-Stick/blob/master/firmware/src/lsm9ds1.h). In a discussion with @malloch, we agreed we should output "real-life" units as much as possible. So we have uTesla, radians per second, and m/s^2 for the IMU. The math could be double-checked as I made those pseudo-libraries more than 4 years ago.
• capsense: "another normalized centroid signal" means you want to add an extra gestural descriptor? If I understood correctly,I think what you want is already given by touch.All. It gives you a float between 0 and 1 according to the "amount of touch". Now, if you want a positional value, we could add this to the Puara.gestures library
• fsr: sure, why not a normalized signal? It's already there (getNormValue() at fsr.h/.cpp). Just replace the function at main.cpp line 413.
• mag: "values stay around zero" has probably something to do with the units (It should be uTeslas), so I would start checking at the unit conversion or if we have a filter. If we plan to work on the sensor fusion soon, it might be a good time to check those units as we need to input them correctly at the functions

[aburt2]

@edumeneses Is there a way for the tinypico to automatically change those ranges for battery life, it is a pain when fixing t-sticks that I can't trust the battery life signal to give me an accurate value

[edumeneses]

Not that I know. The max and min voltage values depend on the battery.

What we can do is maybe measure the voltage of the battery from empty to full and back to empty a couple of times (+ with different batteries) and plot a profile for it. Then we can apply the profile to get a more accurate percentage, or maybe have 3 or 4 different levels.

[DocSunset]

Is there a way for the tinypico to automatically change those ranges for battery life, it is a pain when fixing t-sticks that I can't trust the battery life signal to give me an accurate value

In principle, if we wanted to have an accurate battery life estimate, we would need specific battery hardware (a fuel gauge I think it's called) in order to accurately measure the electrical current while charging and discharging.

[DocSunset]

I notice there seem to be some issues with the accel range on my recently updated T-Stick (thanks again for that edu). The device correctly outputs 9.8 m/s^2 when stationary, reflecting approximately 1 g of acceleration as expected. So the math scaling from the raw readout of the sensor to m/s^2 is good. However, the following observations conflict:

• When shaken vigorously along one axis to try to saturate the sensor, it outputs almost exactly ±19.6 m/s^2, or 2 g
• In main.cpp:109 the min/max for libmapper is ±50 m/s^2, which would be 5.1 and some change g.
• In lsm9ds1.cpp:71 it appears as though the full scale range for the sensor should be 16 g, or 156.8 m/s^2

[DocSunset]

There's a similar story with the gyro:

• the data output saturates at about ±5
• the stated range is ±25 rad/s (1432 deg/s)
• the supposed scale is 2000 deg/s (34.9 rad/s)

[edumeneses]

This is most likely a problem with the SparkFunLSM9DS1 library. I put a note to myself at https://github.com/IDMIL/T-Stick/blob/db5db96958b0cc35d567e9623f4d9122b5e7fa7b/firmware/src/lsm9ds1.h (lines 3-6) referring to this known bug: sparkfun/SparkFun_LSM9DS1_Arduino_Library#27

A possible workaround is to follow my note and manually change the SparkFunLSM9DS1.cpp file. I believe can also be done permanently using platformio.ini and python to create a script to edit the file during compilation.

Another possible solution is to clone the library and hardcode the sensitivity values, we can then refer to our clone at the platformio.ini file. Of course, we can also properly fix their init function and open a PR to upstream our fix.

As I'm currently focusing on the MPU image, I can't check that right now, but the workarounds should work fine.

[edumeneses]

Thanks, @DocSunset, to replace the IMU library. Suppose it honours the user settings we have at the lsm9ds1.cpp file, I suggest we close this issue and open a specific one for the battery reading if needed.

All other values are explained in my message above. If needed, I also suggest opening another issue to change the range values for libmapper.