[linux-dvb] Re: [RFC][ANNOUNCE] blindscan: auto searcheverything

[Roberto Ragusa <mail@robertoragusa.it>]

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.
Between a start frequency and an end frequency you can find many signals.
But in a sr range you can only find one signal.

So, the idea of suspending and resuming is not applicable.
Having freq and sr together in a struct doesn't look right, as freq
is tipically fixed.

After rereading what you wrote... are you saying that the core of the
blindscan program should be moved into the kernel?
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.
Some functionality is lost: progress bar, signal status, arbitrary
timeouts.

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
we can avoid the trouble.

So the problem is reduced to:
- how do we specify a start and end sr?
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?
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).

We want to fit two 32 bit values into a 32 bit space, that's
the core of the problem, IMHO.

The best I can think is
  bit 31-30 00: normal sr, 01: interval, 10:rsvd, 11:rsvd
  bit 29-15 15 bit, start sr
  bit 14-0  15 bit, end sr

Regards.
-- 
   Roberto Ragusa    mail at robertoragusa.it