[linux-dvb] [PATCH] Add missing S2 caps flag to S2API

Alex Betis alex.betis at gmail.com
Tue Nov 25 19:48:47 CET 2008

On Tue, Nov 25, 2008 at 8:34 PM, Morgan Tørvolt <morgan.torvolt at gmail.com>wrote:

> Regarding the actual problem, I have never been happy with the
> "FE_QPSK" and "FE_OFDM" enum fe_types. This imho does not make much
> sense. I would like to know what a card is supposed to receive. One
> modulation type is not locked to a transmission medium, nor frequency
> range, and QPSK can easily be used in a cable network if one wished to
> do so. I second the proposed solution of Artem, but I would do it with
> a twist.
> If possible, I would keep the old system for backwards compatibility,
> and create a different command where this confusing QPSK/OFDM/QAM gets
> removed altogether. I would have a enum frontend type that would
> indicate what standard is being followed, if any. An additional
> indication of all the different modulation types that is supported is
> a must. In addition to what Artem proposed, I would like to be able to
> read a supported frequency range ( i.e 950-2150 for satellite tuners
> ), and supported symbol rates. The last part there about symbol rate
> could be different for different modulation types. Most people would
> not need this, but some do. I don't think I have a good solution for
> how one would solve that, but one way would be if you could do as with
> the ca_types supported that is returned from different CAMs. One could
> return a list of stucts with modulation types and their respective
> limits and parameters. I don't know if this is really useful, but I
> remember that on some of the satellite modems we used, the symbol rate
> was limited by the center frequency of the carrier. If you got to
> close to the max and min, the carrier bandwidth would have to be
> reduced. There might be some equipment out there that has such
> limitations, and it could be worth adding support for that I guess.

If we're talking(writing) about enhanced capabilities, I'll throw my 2 cents
as well...
The driver has to return what settings it will accept in tune command (or
maybe other commands as well).
For example, there is a chipset (don't remember the name) that doesn't
support AUTO settings for modulation, FEC and rolloff.
If that info will be available to the application (such as scan I'm dealing
with), it will be very useful.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.linuxtv.org/pipermail/linux-dvb/attachments/20081125/372e68a7/attachment.htm 

More information about the linux-dvb mailing list