RGBtoHDMI icon indicating copy to clipboard operation
RGBtoHDMI copied to clipboard

Possible Mode 7 Calibration Bug

Open hoglet67 opened this issue 4 years ago • 4 comments

This may not be a bug, but there is room for improvement.

This calibration came from Lurkio: https://stardot.org.uk/forums/viewtopic.php?p=340203#p340203

I've attached the whole file: Log.txt

It's the final calibration run in the file that's a sub-optimal:

INFO:                            A      B      C      D      E      F   total
INFO: value = 0: metrics =       0      0   2627     96      0    290    3013
INFO: value = 1: metrics =       0      0     95      0   2310     16    2421
INFO: value = 2: metrics =    4156      0     15      0    209      0    4380
*PLL
INFO: value = 3: metrics =     253      0   7876      0     19      0    8148
INFO: value = 4: metrics =       0      0    313      0      0      0     313
INFO: value = 5: metrics =       0      0     15      0      0      0      15
Optimizing calibration
phases = 5 5 5 5 5 5; half = 0; pix h offset = 0; mult = 3; rate = 0
Calibration pass complete, retested errors = 20
Current minimum: Phase = 5, Half = 0
INFO:                            A      B      C      D      E      F   total
INFO: value = 6: metrics =       0      0      0      0      0      0       0
INFO: value = 7: metrics =       0      0      0      0      0      0       0
INFO: value = 8: metrics =       0      0      0      0      0      0       0
INFO: value = 9: metrics =       0      0     64      0      0      0      64
INFO: value = 10: metrics =    1535     50      0    970     46      0    2601
INFO: value = 11: metrics =      20      0      0      0      0     36      56
phases = 7 7 7 7 7 7; half = 0; pix h offset = 0; mult = 3; rate = 0
Calibration pass complete, retested errors = 0
Current minimum: Phase = 7, Half = 0
INFO:                            A      B      C      D      E      F   total
INFO: value = 0: metrics =     152      0    348      0      5      0     505
INFO: value = 1: metrics =       0      0    319      0      0      0     319
INFO: value = 2: metrics =       0      0     57      0      0      0      57
INFO: value = 3: metrics =       0      0      0      0      0      0       0
INFO: value = 4: metrics =      17      0      0      0      0      0      17
INFO: value = 5: metrics =       0      0      0      0      0      0       0
phases = 3 3 3 3 3 3; half = 1; pix h offset = 0; mult = 3; rate = 0
Calibration pass complete, retested errors = 0
Current minimum: Phase = 3, Half = 1
INFO:                            A      B      C      D      E      F   total
INFO: value = 6: metrics =       0      0    161      0      0      0     161
INFO: value = 7: metrics =     268      2      0   4821     73      0    5164
INFO: value = 8: metrics =      19      0      0      0      0      3      22
INFO: value = 9: metrics =       0   1166     45      0      0      0    1211
INFO: value = 10: metrics =   10000  10024  10000  10000  10000  10000   60024
INFO: value = 11: metrics =       0      0      0     15      0     49      64
Optimizing calibration
phases = 9 8 8 8 8 8; half = 1; pix h offset = 0; mult = 3; rate = 0
Calibration pass complete, retested errors = 42
Testing mode 7 alignment
counter  0 = 3666
counter  1 = 648
counter  2 = 648
counter  3 = 3832
counter  4 = 4077
counter  5 = 3737
counter  6 = 3621
counter  7 = 4117
counter  8 = 4108
counter  9 = 3562
counter 10 = 3699
counter 11 = 3923
minima at index: 1
Characters aligned to word boundaries
phases = 3 3 3 3 3 3; half = 1; pix h offset = 11; mult = 3; rate = 0
Calibration complete, errors = 0

In this calibration, there is a three position wide error free band at half=0 phase= 6,7,8 but this is not used as the final calibration. Instead, a one position wide error free band at half=1 phase=3 is picked instead.

Somehow we should include the width of the error free band, when there are multiple choices that appear error free.

hoglet67 avatar Nov 05 '21 19:11 hoglet67

I think I've fixed this in this commit: https://github.com/IanSB/RGBtoHDMI/commit/61494c94a40296ca715c24a39ef45cb21404d21a If a three wide zero error window is detected, the error count is set to -1 instead of 0 and as that is lower than zero it will be selected in preference to a single 0 error count. The error value shows as -1 in the logs but is displayed as "0,0,0" in the calibration summary so you can tell at a glance if you have a good three sample window or just a single zero count.

I haven't been able to confirm this works in the above example as I can't reproduce the specific results but is does display the 0,0,0 for normal calibrations that have a three wide zero error band.

IanSB avatar Nov 07 '21 00:11 IanSB

I'm wondering if this is this making too much of a special case of 0,0,0.

Wouldn't it be better to make use of the three-wide window metric value to resolve ties like this?

hoglet67 avatar Nov 07 '21 22:11 hoglet67

I'm wondering if this is this making too much of a special case of 0,0,0. Wouldn't it be better to make use of the three-wide window metric value to resolve ties like this?

Yes, I already decided to improve it by incorporating the 3 sample window in the decision and it's in https://github.com/IanSB/RGBtoHDMI/commit/c9690050e7cd1a940ebfab092c9297c0cb7885e3

so 12,0,34 will be selected in preference to 2345,0,1234

Also the 3 sample window total is included in the calibration display

IanSB avatar Nov 07 '21 22:11 IanSB

Great, thanks Ian.

hoglet67 avatar Nov 08 '21 08:11 hoglet67