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

[Roberto Ragusa <mail@robertoragusa.it>]

On Mon, 2 Aug 2004 14:06:38 +0200
Johannes Stezenbach <js@convergence.de> wrote:

> It's amazing what one can do with proper frontend hardware :-)

To be honest, my first approach was even more ambitious, I wanted
the ability to detect even analogue channels. I tried to use the mt312
as a spectrum analyzer and got some moderately interesting plots,
but the bandwidth before the power meter is too large, so weak
signals near strong signals are easily masked out. After investigating
if I could disable the AGC, run the QPSK demodulator in unlocked mode,
and get some useful results from the I-Q sample register, which was
designed to draw a scatter diagram, I decided to let it go.

> > The patch has a few small improvements easily acceptable for inclusion,
> > but there are two issues:
> > 1) added a new ioctl (as other frontends may support the same
> > functionality, I don't think it should be very controversial)
> > 2) brutally hacked the symbol_rate parameter; I use low values
> > (0-0xfff, well below symbol_rate_min) to ask for auto symbol rate;
> > I don't see an easy and elegant way to achieve abstraction from
> > hardware (this is very mt312 specific) without sacrifying
> > functionality (such as multi frequency ranges) or seriously extending
> > the API (set min and max symbol rate separately, at minimum).
> 
> If we could come up with a proper API I would add this
> to CVS immediately. However, I don't know about the scanning
> features of the mt312, mt352 or other frontends.
> Is there someone who does?

As regards the API, I'd like to see some discussion on this list
to find the best solution.

As regards other frontends, mt312 is OK: I used a mt312 datasheet for
my vp310, as until yesterday I didn't even know that I had a vp310 and
not a mt312 (!). In fact, I've added a printk to avoid confusion.

The frequency offset is probably available on many frontends.
The auto sr is missing sometimes, IIRC the Skystar2 2.6
(so stv0299) can't do it.
Here I'm talking about hardware capabilities, because nothing is
implemented in other frontends, at first look.

The sr ranges are really complicated, some details follow (more or
less what I've written in the code).
The mt312 has 12 bits, each one representing a range.
These ranges are decimations of the system clock, for example the
first range is SYSCLK/2 to SYSCLK/3, the second SYSCLK/3 to SYSCLK/4.
So, they don't have the same linear or logarithmic size.
Add to that that the SYSCLK is not well known, as the vp310 is switched
between 60MHz and 90MHz, with 90MHz used only if sr>30Mbaud for power
reasons. I decided to always switch to 60MHz when sr=auto and so
the bands are fixed and blindscan can assume it's 60MHz
(this means that auto sr works only up to 30Mbaud, I thought it
was acceptable, as signals >27.5Mbaud are rare and definitively not
transient).
You put a 1 in the bit to activate searching in that range. Having
too many bits on and activating distant ranges should work, but
doesn't work in my tests (why? please test and report results).

At the moment the userspace directly decides the 12 bits by asking
for symbol rate 0x001-0xfff. This sucks because we're very hw specific
and using values below the advertised symbol_rate_min.

What I'm doing now is not uncorrect or dangerous, just not elegant.
The frontend should refuse our sr, but the mt312 decides to accept
it as it "understands the message".

But if there is a different autosr frontend with an obviously
different range selection, what happens? Userspace has to detect
the frontend and switch its "language".
If userspace has to be modified to support new hardware, the
kernel is not doing his work.

First idea: pass an approximation of the symbol rate and signal
that we want auto search, for example using a negative number
(-5000000 means around 5Mbaud). We could validate the absolute value
against sr_min and sr_max and turn on one or maybe three ranges
around the suggestion. This would be not hw specific, but functionality
is lost. And sr is currently unsigned.

Second idea: pass an interval (4-8Mbaud) and let the fe driver choose
the bits. But pass how? By calling set frontends multiple time with
a special pattern? Extending the API? Ugly, and functionality is
lost in this case too. Better if multiple ranges could be specified,
but how pass a list of intervals, or a list of symbol rates (each
representing a +- x% interval)?

Third idea: create our own hw independent ranges and define the
meaning of the bits (we could use 16 bit, for example).
Better, let decide that bit 31 means auto-sr and use 16 or 24
or 30 bits for ranges.That is:
  if (bit31==0) (bit29-bit0)=symbol rate in baud
  if (bit31==1) (bit29-bit0)=symbol rate range mask
  bit30 reserved for future use, must be 0

Yes, I like it.
We could define the ranges directly or in relation to sr_min and
sr_max, but with 30 bits I'd avoid this extra complication.

We could have ranges coded this way
  SR_SEARCH_RANGES      1<<31
  SR_RESERVED_MUST_BE_0 1<<30
  SR_RANGE_30M_25M      1<<29
  SR_RANGE_25M_20M      1<<28
...
  SR_RANGE_6M_5M        1<<12
  SR_RANGE_5M_4M        1<<11
...
  SR_RANGE_500k_300k    1<<0
and use (SR_AUTO|SR_30M_25M|SR_6M_5M) in apps.

We could also specify that:
- the frontend CAN refuse particular combinations of ranges
- the frontend SHOULD ALWAYS accept a 1bit range which is
not entirely out of sr_min-sr_max interval.
- the frontend CAN lock on signals out of the specified ranges
(the mt312 can't search between 25M and 30M without locking on
a 22M)

Obviously we'd have to define FE_CAN_SR_AUTO.

No compatibility broken, good hardware independence.

I'm open to comments on this matter.
BTW, is there any other frontend on which auto sr can be achieved?
I suspect we could let the mt312 write the rules and stop worrying.

Regards.
-- 
   Roberto Ragusa    mail at robertoragusa.it