Andrew de Quincey wrote: > On Monday 21 Nov 2005 13:06, Johannes Stezenbach wrote: > >>Have you had a look at the data sheet of demodulators which >>support scanning in firmware, like the mt352 and mt312? >>(Are there others?) >> >>I believe the mt3xx data sheets are available from the Zarlink website. >> >>I wanted to check them myself and comment on your API proposal, but >>again failed to find the time to do so. :-( > > > yeah - I did. That was why I agreed with having frequency range scanning in > the kernel since the mt352 can do that entirely in hardware. But the mt312 can not. It can find the symbol rate, but not the frequency (excluding a small "tolerance" range). With the proposed dvb_fe_scan_spec, how would things work? I think we should have a _CAN_SCAN_FREQ_RANGE, _CAN_SCAN_SR_RANGE and _CAN_SCAN_FREQ_AND_SR_RANGES and each of these capabilities can be true or false for a specific frontend as it is certainly possible that some hardware is able to scan both freq and sr, but not together. According to these capabilities, the app will take care of asking a zero-sized range for freq or srate. Another more extensible (will we ever scan on more than 2 parameters?) approach is to just return an error when there are too many unknowns. This way the app can know what the harware is able to do. Another approach would be to simulate in the kernel the missing scan modes, but I don't like it. As regards the multiple sr ranges issue from Wolfgang, his proposal is certainly useful for the vp310/mt312. The hardware has some restrictions on rate ranges but the driver can use the minimum union of ranges covering what the app asked. That is, if asked (5600-5650) and (13200-13300) it would for example scan with (5000-6000) and (12000-15000). This also means the app should not be surprised to lock a signal not respecting the parameters it asked. (well, currently if you ask freq=11920 you can lock on freq=11919, so what?) Best regards. -- Roberto Ragusa mail at robertoragusa.it
