so I have spent an afternoon on this using a simplified program, which can be found here, along with a short matlab/Octave script which plots the data: https://github.com/giuliomoro/record-trill (this requires you to update the Bela code to the latest dev
branch). Findings:
I cannot reproduce the non-monotonic behaviour you found here https://forum.bela.io/d/1544-trill-ring-sampling-issue/20 . I have no idea how you produced that. Can you try and generate something like that from my program?
anna (without the prescalar, as this did not seem to change anything?)
Confusingly, the sensor keeps the prescaler value until it's rebooted, so it may be confusing to test it unless you are setting it explicitly to 1 or 2 or 3 every time. A prescaler of (1) is going to cause trouble. You should definitely use setPrescaler(2)
or even setPrescaler(3)
(followed by updateBaseline()
. Otherwise you will be saturating the pads and get clipped readings and unreliable position detection (see below).
anna . You can see that there are somewhat regular discontinuities from ~0-.3 and then the coordinates change more smoothly:
How many times and how fast did you go around the circle with the finger to produce that plot? If I go slow enough or enough times (and with the correct prescaler), I don't get any visible gaps. So, it's not like some values cannot be achieved. However I do get occasional discontinuities if I plot the values in temporal order, e.g.:
and when you zoom in, you see that they are not always in the same place:
My intuition is that these gaps could be due to the irregularities in the surface of the PCB. It is not flat, as the copper pads (which are evenly spaced) can be felt through the silkscreen. Either the finger speed changes when it encounters a gap, or what changes is its contact surface, and therefore the estimated touch position. It's also possible that a better position detection algorithm (see below) may improve this.
anna change in an oscillatory pattern at specific locations on the sensor
I think this can be explained by the fact that the "centroid" detection algorithm is fairly simple, suitable for running on the small microcontroller which powers Trill. Try using this other project https://github.com/giuliomoro/trill-ring-diff-gui to get a sense of what's going on with the raw pad readings. Open the GUI. Set it to RAW to see the raw pad reading. You'll see that with a prescaler of 1 or 2 the pads are actually saturating. With a prescaler of 3 they don't. Then set it to DIFF mode and do "update baseline" and observe the pad activations and the position of the detected touch. The algorithm is doing a weighted average of the activations to find the "centroid" of the activation.
The first program I posted ( https://github.com/giuliomoro/record-trill ), when LOG_RAW
is defined, is reading the DIFF values from the Trill and then passing them to the CentroidDetection
class, a replica of the centroid detection algorithm used on the device itself. You can tweak it a bit by setting the multBits
variable to a value between 7 and 11. 7
is what is on the board. 11
should make it a bit more accurate by giving it more bits in a fixed-point multiplication. A more sophisticated location detection algorithm would probably work better, you can read the raw data from the sensor (setting it to DIFF
mode as done in the other project) and implement your own finger location detection. I guess parabolic interpolation could be a good starting point.