[linux-dvb] Re: [RFC][ANNOUNCE] blindscan: auto search everything

[Holger Waechtler <holger@qanu.de>]

Roberto Ragusa wrote:
> On Mon, 02 Aug 2004 18:11:54 +0200
> Holger Waechtler <holger@qanu.de> wrote:
>
>
> > sounds hard to use. I would prefer the approach similiar to thy Zarlink 
> > Evalsoftware: pass the frequency and symbol rate ranges to the driver 
> > and then get interrupted/notified as soon something is found, thenafter 
> > continue there.
> >
> > A scan looks like this from the userspace application point of view:
> >
> > ioctl(PREPARE_SCAN, &setup_range_spec);
> > ioctl(START_SCAN);
> >
> > while (1) {
> > 	/* we get notified by poll() */
> > 	wait until status changes and read current parameters;
> > 	select(fe_fd, ...);
> > 	ioctl(fe_fd, FE_GET_STTAUS, &s);
> > 	ioctl(fe_fd, FE_GET_PARAMETERS, &p);
> >
> > 	if (end of range)
> > 		bail out;
> >
> > 	if (channel found)
> > 		store parameters;
> >
> > 	if (weak channel)
> > 		mark channel as weak;
> >
> > 	ioctl(CONTINUE_SCAN);
> > }
> >
> > an additional ioctl(CANCEL_SCAN) allows to interrupt running scans and 
> > to bring back the hardware into a sane state for normal tuning.
> >
> > discontinous scan ranges should be handled by the application. The 
> > setup_range_spec struct might look like this for DVB-S scans:
> >
> > struct dvb_fe_scan_spec {
> > 	unsigned freq_start;
> > 	unsigned freq_end;
> > 	unsigned srate_start;
> > 	unsigned srate_end;
> > }
> >
> > A similiar approach works for the mt352 DVB-T demod, there the srate 
> > fields are not required but bandwidth and the scan_weak_channels bit 
> > have to be configured. What do you think?
>
> The auto symbol rate capability is not exactly a scan.
why not?

> Between a start frequency and an end frequency you can find many signals.
> But in a sr range you can only find one signal.
From the hardware point of view it's the same, the internal demod state 
machine just tries the different combinations in order and halts as soon 
a valid combination is found.


> After rereading what you wrote... are you saying that the core of the
> blindscan program should be moved into the kernel?
It's running on the demod state machine in hardware, the ioctls are just 
passed through to set up the hardware.

> It is an interesting approach, but I'm not convinced.
> The scan should run in the background in the kernel space with
> a kernel thread changing frequencies because the hardware can not
> scan frequencies by itself.
I don't see a need for a kernel thread.

> Some functionality is lost: progress bar,
ioctl(FE_GET_FRONTEND) delivers the current frequency and parameter set, 
you can use this and the start/end frequency to calculate the current 
progress bar position.

> signal status,
ioctl(FE_READ_STATUS);

> arbitrary timeouts.
ioctl(FE_SCAN_CANCEL);


> I think that we should not approach the thing as a scan. It's a
> hit or miss: "is there a signal on this freq? tell me the parameters".
>
> I agree on the fact that discontinuos scan ranges have to be
> handled by the application. In theory if the hardware knows all the
> ranges at the same time it can use some parallel or adaptive
> method instead of the serial checking the application would have to
> do, but considering that:
> - searching discontinuous ranges is not common
> - the hardware seems to have problems: my vp310 doesn't like too
>   many ranges, and often frontends have some other parameter (polarization
>   currents, gain...) depending on the symbol rate
For DVB-S those parameters are typically independent. In our tests the 
scans using the Zarlink Evalsoftware worked pretty well -- only for very 
low symbol rates (were other frontends don't even get a lock) the scan 
is not always reliably, there you sometimes need to tune manually to be 
sure.

> So the problem is reduced to:
> - how do we specify a start and end sr?
I would suggest the FE_SCAN_START ioctl which passes the setup struct.


> We have one 32 bit field in the tuning struct.
> We can introduce a struct with 2 32 bit fields, but how do we
> link it to the tuning struct?
> Is it reasonable to extend the dvb_qpsk_parameters?
no, definitely not -- this would break binary compability.

> We could add a symbol_rate_uncertainty and specify center and width
> of the interval instead of start end, but that wouldn't be a real
> parameter (in fact there is nothing reasonable to return
> on FE_GET_FRONTEND).
FE_GET_FRONTEND should return the current parameter set even in scan 
mode, this is useful e.g. for the progress bar.

IIRC the current frequency and parameters are stored in different 
registers of the mt352 so maybe one needs to implement two different 
approaches for FE_GET_FRONTEND in scan and normal mode, the 
START_SCAN/CANCEL_SCAN commands can toggle a local variable to ease 
finding out which registers currently need to get read out. Maybe it's 
also possible to use one of the register bits to find out the current 
mode of the demod.

Holger