[fprint] Improving the etes603 driver

[Jason Gerard DeRose]

Patrick,

On 08/26/2015 02:53 PM, Patrick Marlier wrote:
> Jason,
>
> On 08/26/2015 05:57 PM, Jason Gerard DeRose wrote:
>> Patrick,
>>
>> A little update on where I'm at with this.  Through many iterations of
>> adding extra debug logging and removing logging that was too noisy and
>> wasn't helpful to me, I've discovered a problem that at least seems to
>> exist with the particular hardware I'm testing on.
>
> Maybe some debugging output is not meaningful. Please keep track of it
> so that we can remove it from the driver. No need to pollute logs.

Okay, will do. From what I recall, it was the USB traffic logging that 
was difficult to deal with, but I could certainly see a use for it.

Right now my branch is a big mess of experiments I've done in trying to 
understand the driver. But when I can I'll step back and study my diff 
from master, see if there is anything actually useful that I've done.

> About your hardware, let's suppose this is due to calibration. Can you
> send me the full log? I can have a look and tell you what I think.

Here's the logging bits on calibration:

etes603:debug [m_tunedc_state] Tuning DCoffset
etes603:debug [m_tunedc_state] Testing DCoffset=0x1A Gain=0x23
etes603:debug [m_tunedc_state] Testing DCoffset=0x27 Gain=0x23
etes603:debug [m_tunedc_state] Testing DCoffset=0x2E Gain=0x23
etes603:debug [m_tunedc_state] Testing DCoffset=0x31 Gain=0x23
etes603:debug [m_tunedc_state] Testing DCoffset=0x2F Gain=0x23
etes603:debug [m_tunedc_state] Testing DCoffset=0x30 Gain=0x23
etes603:debug [m_tunedc_state] -> DCoffset=0x32 Gain=0x23
drv:debug [fpi_ssm_mark_completed] 0xbb1350 completed with status 0
etes603:debug [m_tunevrb_state] Tuning of VRT/VRB
etes603:debug [m_tunevrb_state] Testing VRT=0x0A VRB=0x10
etes603:debug [process_hist] fullb=0.779948 black=0.212240 grey=0.220052 
white=0.007812 fullw=0.000000
etes603:debug [m_tunevrb_state] Testing VRT=0x09 VRB=0x0F
etes603:debug [process_hist] fullb=0.580729 black=0.325521 grey=0.411458 
white=0.085938 fullw=0.007812
etes603:debug [m_tunevrb_state] -> VRT=0x09 VRB=0x0F

Does that seem reasonable, or do you spot anything off there?

>
>> The initial finger detection in m_finger_state() via reading raw frames
>> in REG_MODE_SENSOR till a non-empty frame is read works flawlessly well
>> prior to the first scan.  However, if the first scan fails (because not
>> enough minutiae could be detected), on the next go m_finger_state() will
>> *always* get a non-empty frame on the first frame it reads, even though
>> my finger isn't on the sensor.
>
> Yep I was trying to make the driver clever but the bad calibration makes
> the detection really bad. :(
>
>
>> My hunch is the sensor is returning the frames used in the hardware-
>> assembled image read in REG_MODE_FP, though I haven't confirmed that yet
>> for sure.  But if I ignore the first X frames (currently I'm using
>> X=125, which seems to work well), and only then have m_finger_state()
>> interpret a non-empty frame as meaning your finger is on the sensor, I
>> can work around this.
>
> Not sure to follow here...

To be honest, I'm not sure I follow me here either :P

This was my theory early this morning, but now I'm thinking it was 
probably nonsense, probably best to ignore it.

>
>> However, in my experience thus far, the hardware-frame-assembly seems
>> pretty low quality, at least with my finger.  That or REG_MODE_FP and
>> REG_MODE_SENSOR fundamentally don't interact well for whatever reason.
>
> Humm. The quality was not too bad for me for this REG_MODE_FP. I don't
> have sample but I will try to get access to the fingerprint device and
> send a capture to you.

I think instead of "poor quality" I probably should have said "seems 
totally broken", at least on the hardware I'm testing on.

Like you said, probably a tuning issue. Perhaps the revision of etes603 
I'm testing on needs a somewhat different tuning strategy.

The other thing I've wondered about is timing issues, wondered where 
exactly my finger is at on the sensor when it gets around to reading in 
REG_MODE_FP, whether my finger is still actually on the sensor at that time.

It's a bit difficult to match up the outgoing logging output temporally 
with what I'm doing physically, but from the images I'm getting from 
fprint_demo, my gut reaction is, "that's not a fingerprint, it must have 
just been capturing the air!". Like you said, tuning, tuning :D

>
>> So my currently plan is to switch the etes603 driver to using software
>> frame assembly, basically what you were doing prior to the driver being
>> merged into libfprint.
>
> Ok. You can have a look at my development repository if you did not yet
> because this was already there.
> Damn it I think Google Code screwed my dev repository! :(
> (https://code.google.com/p/etes603/source/checkout?repo=dev)
> I will try to find it and send it to you.

Right after I sent this email, I did pull down your repo.

I've been looking at etes603.c at commit 
b9e787f034ba24f5c931e407283905f35cb54690: Add support for EgisTec ES603 
(first public version).

>> Chatting with Vasily (anarsoul) on IRC, I learned that the internal
>> libfprint aes_assemble() function in aeslib.c currently isn't generic
>> enough for the etes603 driver to use, so I'll work up one patch to
>> make aes_assemble() more generic (and update all its consumers), and
>> then a 2nd patch to switch etes603 to reading only in REG_MODE_SENSOR,
>> assembling the frames in software.
>
> In this dev repo, I had also my own assemble function that worked pretty
> well for this device (obviously, you need to swipe in a reasonable time).

Yes, I've been looking these over as well, thanks!

>> Does this plan seem reasonable to you?
>
> It sounds good but I would advise you also to take time and have a look
> at this calibration because it is a key point.
>
>
>> Also, in your initial reverse engineering, how close did you get to
>> figuring out how to make REG_MODE_CONTACT work (finger detection via
>> capacitance)?  Do you think that's a route worth pursuing?
>
> Testing, testing, testing over and over... and finally worked pretty
> well with my device. Again calibration is key.
>
>
>> In my experience thus far, it seems REG_MODE_SENSOR is probably totally
>> workable for finger detection when doing software frame assembly, and I
>> get the impression that was your experience too.  What do you think?
>
> Yep I used REG_MODE_SENSOR for a while but I changed to REG_MODE_CONTACT
> to reduce energy consumption and increase lifetime of the device if it
> has to wait a long time before something happen.

Can you provide any insight into why libfprint is currently using 
REG_MODE_SENSOR for finger detection when you were able to get 
REG_MODE_CONTACT working?

 From what you've described, it sounds like REG_MODE_CONTACT is probably 
a better approach for finger detection, so I'm curious as to why it's 
not being used.

>
>> Also, your blog post was fantastically useful, thanks!
>
> Thanks a lot :) I am glad it finally helped someone!
>
> Keep me posted.

Will do, thanks!

> --
> Pat