On Tue, Nov 25, 2008 at 8:34 PM, Morgan Tørvolt <morgan.torvolt@xxxxxxxxx> 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.
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.
_______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
