[fprint] Improving the etes603 driver

[Patrick Marlier]

On 08/27/2015 01:07 AM, Jason Gerard DeRose wrote:
> 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

Humm strange. I was expecting at least that the DCoffset=0x32 or more to 
be tested before to go back to 0x32 but I forgot a bit the details. At 
least the value sounds reasonable.

> 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

This one could be probably improved a bit but the overall balance is ok.


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

Sounds really reasonable.


>>> 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.

Outch. Too bad :( You don't even got an kind of fingerprint?


> 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

Yeah... Keep me posted on how we could make it work together. I can try 
to get access to the fingerprint device, we can try to schedule a 
debugging session, we can try to disable auto tuning and check how to 
fix the tuning...

Maybe we should talk offlist from now and only CCed the list when we 
have something useful to the list.
--
Pat