As part of Meta Morph/EigenLite testing, I’ve digging around EigenD code quite deeply to check accuracy of key data.
This led me down a rabbit hole (dont ask!) looking it key calibration, and Ive come up with interesting information that I think is useful to capture.
Important Note
Im only reporting this as information, a way to capture this knowledge whilst it’s fresh in my mind.
I have NO plans to do anything in this area, I do have the time, and also am still concerned about the damage that could be done to an Eigenharp pursuing this.
(also at this point it is incomplete/untested… though I believe its largely accurate, and can be proven)
but I believe its important to capture the information JUST in case esp. as EigenD is open source.
Background - what we know about the keys
basically each key has an led, which is reflected in to four sensors.
from the video it looks like these are mounted NESW.
we also know these are 11 bit accuacy - so 0…2047
Key calibration - ‘reverse engineering’
before we start, one very important part of this is
the PICO stores this calibration , it does NOT use it - this calibration data is used by a software driver.
whereas the basestation (alpha/tau) firmware makes use of this calibration.
THUS…
the pico firmware has the ability to READ and WRITE the calibration data,
whereas the tau/alpha firmware only supports WRITE new calibration data
(as calibration is done in firmware there is no reason for the software to need/see this data)
from look at code we have a available Ive been able to work out quite a bit about how all the eigenharps work with the calibration data. thankfully we have more info from the pico, but I can see that the same techniques are used for the alpha/tau, its just where the code is ‘executed’ (hardware vs software)
calibration data
anyway down to the calibration data itself.
each key has 4 sensors, referred to as corners.
not sure, why they are corners, as video, appears to imply they are NESW, so aligned with an axis rather than at corners of a key. this would be very easy to verify by looking at raw mode data.
from this, we can calculate a total pressure (even pressure across all corners), and axis - bias of corners.
for each key - 30 data points are stored per corner, at what we can assume to be 30 different pressure levels - as increase, and go from 0…4095 - so these describe a pressure ‘curve’ for each corner.
(which Im sure will then be interpolate to give a calibrated response)
also there is a min/max stored per key
I need to check, but I suspect this is min/max of total pressure (for Z?)
calibration process
this also tells us something about the calibration process , though not everything.
we know that EigenLabs have a machine which can precisely calibrate an eigenharp.
so the way I believe how this works is.
eigenharp calibration data is cleared
eigenharp is put into raw data mode.
for each key it exerts 30 different pressures, raw mode reports all 4 corner pressures.
we can then compare what we expect for the response vs actual response, and so derive calibration value.
presumably then the harp could be then set back on the machine, and tested with calibration active, so that it could check to see that with calibration its reporting as expected.
(this would also allow for an eigenharp to be tested for ‘bad calibration’ - perhaps after servicing)
now what we don’t know for sure…
(as we don’t have the code used to drive this calibration machine)
a) are the pressure points linear?
this is easy enough to check, as I could capture the calibration points on my pico,
and a simple graph would show me the response rate.
b) does the machine rock the key to each corner or just apply even pressure across the key?
I highly suspect each just pushes the key evenly since it’s only after corner pressures rather than trying to calibrate ‘the action’.
c) raw vs cooked
I need to do some digging here.
raw reports corners , where as cooked/processed returns p/r/y
but does raw report without calibration or with calibration?
( I do know how to recheck this… but I just need to allocate a chunk of time to dig in)
d) why calibration data is 4095 (12bit) , yet sensor is said to be 11bit?t
we know the sensors are 11 bit, so this should be 2047? (11bit)
interestingly, this is a common theme in the code base that we see 12bit… and oddly 11bit in the pico in places.
ultimately, I don’t think it matters. it could be simply that the Eigenharp uses 12bit sensors but the 12th bit is too noisy to be useful, and so is stripped. so in the video it was simplified to it has 11 bit resolution. seems reasonable from a technical viewpoint.
OK, the above is all a bit simplified, and I do have access to some more code that would reveal exactly how the calibration data is then utilised (aka raw->cooked data conversion). but I don’t have time to dig into this now.
Id also need to dig into the exact sequence of firmware messages used to write the calibration data.
it looks like its probably something like
start write calibration
(possibly) clear calibration
write calibration per key.
end write calibration
obviously tis is ‘critical’ … as getting it wrong could have disastrous consequences!
what does this mean for ‘diy calibration’.
a) no ability to read calibration data for Alpha/Tau
ok, this I’ve reported before, but its worth remembering!
as it means to calibrate an alpha/tau you always have to start from a ‘blank’ canvas.
whereas a pico, you could read the calibration data and ‘modify’ it, since it can be read.and importantly restored !.
b) user calibration machine
the calibration machine has to be able to
- exert 30 pressure precisely
- pressure must be exerted evenly across the key, so corners get exactly the same pressure.
Hardware wise this would not be ‘easy’, but it’s probably ‘doable’ esp for doing one key.
it would also required software to be written that could control it (to step thru pressures), and also software for reading the corners, and then writing calibration data (etc)
that said, it’d be simpler than the EigenLabs machine, since it would not need to be as automated doing all keys at once etc.
c) manual calibration (software only)
for the pico, as we can read the calibration data, you could imagine a piece of software running on PC/Mac that would display the corner curves and allow users to tweak them.
e.g perhaps to cope with a slight ‘drift’ of values.
for the alpha/tau.
so you cannot get the calibration data, and starting from a ‘perfect’ (uncalibrated) starting point, would unlikely be useful. so you would need some way of getting even pressures onto a key at a number of good data points. preferably 30, but you could interpolate from fewer if necessary.
anyway, difficult to do without some means to accurately exert pressure on a key.
(if you have that, then you could probably ‘calculate’ the factory calibration data)
this tool would also need a bit of reverse engineering, to establish the relationship between raw and cooked numbers… e.g. so you could infer how a sight yaw drift, would translate to corner changes.
also it looks like calibration can be be done for a single key, which would be super useful - though this would need to be verified. (ie that starting calibration does not auto clear the whole dataset)
anyway, as I said above is just ‘information’, just in case it every becomes necessary to dig deeper into this topic … and just for a better understanding of how eigenharps work.
