[linux-dvb] Debugging tuning timing problems

[Andrew de Quincey <adq_dvb@lidskialf.net>]

Hi, I now _think_ most of the major bugs are out of the new frontend code 
(THUD: the sound of the next major bug appearing :)

Anyway, I've added instrumentation to help with diagnosing the remaining 
issues.

If you enable debug on dvb_frontend, it'll print out what values were used 
every time a tune attempt occurs during tune or zigzag. 
(BTW for people who don't know, you put "options dvb_core 
dvb_frontend_debug=1" in /etc/modules.conf to enable debug).

You'll see lines like the following in dmesg:
dvb_frontend_autotune: drift:0 bending:0 inversion:0 auto_step:0 
auto_sub_step:0 started_auto_step:0

You'll  likely see several of these for each tune as different combinations of 
parameters are tried. This is entirely normal, especially for low symbol rate 
channels, which often require quite a lot of seeking about to lock on.

However, if tuning is _always_ slow, and you _always_ see lots of these 
outputs, the tuning delay _might_ be incorrect for your frontend. You can 
override this with the dvb_override_tune_delay module parameter.. this takes 
a delay in milliseconds. Each dvb_frontend_autotune attempt will sleep for at 
least this length of time to let the frontend lock. The default delay is 
50ms.

It should be noted that dvb_override_tune_delay is really only for debugging; 
changes to tuning delays for a particular frontend should really be 
incorporated back into the frontend driver in CVS (by implementing the new 
FE_GET_TUNING_PARAMS ioctl in the frontend driver)


e.g. for the tda1004x frontend, I found I always saw:
Mar 12 11:26:22 burble kernel: dvb_frontend_autotune: drift:0 bending:0 
inversion:0 auto_step:0 auto_sub_step:0 started_auto_step:0
Mar 12 11:26:23 burble kernel: dvb_frontend_autotune: drift:166667 bending:0 
inversion:0 auto_step:1 auto_sub_step:0 started_auto_step:0
Mar 12 11:26:24 burble kernel: dvb_frontend_autotune: drift:-166667 bending:0 
inversion:0 auto_step:1 auto_sub_step:2 started_auto_step:0
Mar 12 11:26:24 burble kernel: dvb_frontend_autotune: drift:333334 bending:0 
inversion:0 auto_step:2 auto_sub_step:0 started_auto_step:0
Mar 12 11:26:25 burble kernel: dvb_frontend_autotune: drift:-333334 bending:0 
inversion:0 auto_step:2 auto_sub_step:2 started_auto_step:0
Mar 12 11:26:26 burble kernel: dvb_frontend_autotune: drift:0 bending:0 
inversion:0 auto_step:0 auto_sub_step:0 started_auto_step:0
(the last message was the one when a LOCK was reported by the userspace code)

In the above, it has tried the user-supplied frequency and failed to get a 
lock. So its then tried frequencies around that, eventually ending up locking 
on the orginal frequency that failed the first time! Clear indication of a 
timing problem (assuming the frontend code itself is correct).


I have adjusted the timings for the su1278-tsa5059, tda10045, and tda10046 
frontends.


-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe linux-dvb" as subject.