Re: [linux-media] Re: [linux-media] Re: [PATCH] Add FE_CAN_PSK_8 to allow apps to identify PSK_8 capable DVB devices

2010-04-18 Thread Klaus Schmidinger
On 18.04.2010 16:51, Manu Abraham wrote:
 On Sun, Apr 18, 2010 at 5:19 PM, Klaus Schmidinger
 klaus.schmidin...@tvdr.de wrote:
 On 15.04.2010 22:21, Manu Abraham wrote:
 Hi Klaus,

 On Sun, Apr 11, 2010 at 1:12 PM, Klaus Schmidinger
 klaus.schmidin...@tvdr.de wrote:
 The enum fe_caps provides flags that allow an application to detect
 whether a device is capable of handling various modulation types etc.
 A flag for detecting PSK_8, however, is missing.
 This patch adds the flag FE_CAN_PSK_8 to frontend.h and implements
 it for the gp8psk-fe.c and cx24116.c driver (apparently the only ones
 with PSK_8). Only the gp8psk-fe.c has been explicitly tested, though.

 The FE_CAN_PSK_8 is a misnomer. In fact what you are looking for is
 FE_CAN_TURBO_FEC
 Well, when processing the NIT data in VDR, for instance, the possible
 modulation types that can be used according to the driver's frontend.h
 are
QPSK,
QAM_16,
QAM_32,
QAM_64,
QAM_128,
QAM_256,
QAM_AUTO,
VSB_8,
VSB_16,
PSK_8,
APSK_16,
APSK_32,
DQPSK,

 There is nothing in frontend.h that would be in any way related to
 turbo fec (whatever that may be).

 Of course we can rename FE_CAN_PSK_8 to FE_CAN_TURBO_FEC, but wouldn't
 something like

  if (Modulation == PSK_8  !(frontendInfo.caps  FE_CAN_TURBO_FEC))
return false;

 be even more irritating than a straight forward

  if (Modulation == PSK_8  !(frontendInfo.caps  FE_CAN_PSK_8))
return false;

 After all it's

  if (Modulation == QAM_256  !(frontendInfo.caps  FE_CAN_QAM_256))
return false;

 Please advise. Whatever you prefer is fine with me.
 All I need in VDR is a flag that allows me to detect whether a device
 can handle a given transponder's modulation. I don't really care how
 that flag is named ;-).
 
 
 Maybe I wasn't clear enough, why I stated that ...
 
 consider any DVB-S2 frontend: stb0899, cx24116, stv090x, ds3000 or any
 other any frontend ..
 All these devices are capable of demodulating 8PSK. Now, if people
 start adding capabilities that which the devices are capable, then it
 will cause a lot of problems for the applications themselves, since
 you don't get the differentiation between the frontends that you were
 originally looking for.
 
 Now looking at another angle ..
 
 consider the Genpix frontend, can it tune to 8PSK ? Yes, it can..
 
 Eventually, it implies that, all DVB-S2 devices are 8PSK capable, but
 not all 8PSK capable devices are DVB-S2 capable.

Since there are already FE_CAN_* flags for all but PSK_8, I guess
it would make sense that all devices that support PSK_8 set the
related FE_CAN_PSK_8 flag (or FE_CAN_8PSK, if you insist in continuing the
suboptimal naming scheme), independent of the Turbo FEC thing.

 Now, assume the FE_CAN_PSK8 or FE_CAN8PSK flag; Does it really make
 any sense, when it is applied to the whole group of 8PSK frontends ? I
 guess not. You would require a flag that is capable of distinguishing
 between the S2 8PSK category and the other category.

There already is such a flag: FE_CAN_2G_MODULATION.

 Looking back at history, originally France Telecom introduced the
 superior Error Correction scheme called Turbo Mode or so called
 Concatenated FEC mode on a 8PSK modulated carrier. This was a great
 approach, but they wanted to people to pay them a royalty and hence
 the general acceptance for it went down. In the initial phase, it was
 implemented in the Americas and for small clients alone. Eventually,
 the rest of the world wanted a royalty free approach and thus came
 LDPC which is just as good.
 
 So eventually while the difference between these 2 carriers is that
 while both are 8PSK modulated stream, the Error correction used with
 France Telecom's proprietary stream is Concatenated Codes, while for
 S2 and DVB.org it became LDPC.
 
 As you can see, the discriminating factor is the FEC, in this
 condition and nothing else. You will need a flag to discriminate
 between the FEC types, rather than the modulation, if things were to
 look more logical.

I guess the problem, as I can see now, is that there is now way
of telling from the SI data that a transponder uses 8psk turbo fec,
or is there?

Would it make sense to differentiate this in the following way:

- an 8psk transponder on DVB-S is turbo fec
- an 8psk transponder on DVB-S2 is  *not* turbo fec

? So an 8psk/DVB-S transpoder will require a device that has
FE_CAN_TURBO_FEC set, while an 8psk/DVB-S2 transpoder simply
requires a DVB-S2 device (since there is no FE_CAN_PSK_8).

Klaus
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [linux-media] Re: [linux-media] Re: [PATCH] Add FE_CAN_PSK_8 to allow apps to identify PSK_8 capable DVB devices

2010-04-18 Thread Manu Abraham
On Sun, Apr 18, 2010 at 10:34 PM, Klaus Schmidinger
klaus.schmidin...@tvdr.de wrote:

 Eventually, it implies that, all DVB-S2 devices are 8PSK capable, but
 not all 8PSK capable devices are DVB-S2 capable.

 Since there are already FE_CAN_* flags for all but PSK_8, I guess
 it would make sense that all devices that support PSK_8 set the
 related FE_CAN_PSK_8 flag (or FE_CAN_8PSK, if you insist in continuing the
 suboptimal naming scheme), independent of the Turbo FEC thing.

 Now, assume the FE_CAN_PSK8 or FE_CAN8PSK flag; Does it really make
 any sense, when it is applied to the whole group of 8PSK frontends ? I
 guess not. You would require a flag that is capable of distinguishing
 between the S2 8PSK category and the other category.

 There already is such a flag: FE_CAN_2G_MODULATION.


I guess, in the long run, FE_CAN_8PSK or FE_CAN_PSK8 or whatever scheme; might
not make any difference between FE_CAN_2G_MODULATION for a satellite delivery
system in the long run.

Additionally, Turbo FEC is not restricted to 8PSK modulation scheme alone ..
http://www.comtechefdata.com/datasheets/ds-cdm600-600L.pdf
http://www.datasheetdir.com/CX24114+download

That said, I don't really care about the exact naming of the flag, was
just a logical thought
that came to me between the difference in the error correction mode
alone, with no difference
to the modulation schema ...



 Looking back at history, originally France Telecom introduced the
 superior Error Correction scheme called Turbo Mode or so called
 Concatenated FEC mode on a 8PSK modulated carrier. This was a great
 approach, but they wanted to people to pay them a royalty and hence
 the general acceptance for it went down. In the initial phase, it was
 implemented in the Americas and for small clients alone. Eventually,
 the rest of the world wanted a royalty free approach and thus came
 LDPC which is just as good.

 So eventually while the difference between these 2 carriers is that
 while both are 8PSK modulated stream, the Error correction used with
 France Telecom's proprietary stream is Concatenated Codes, while for
 S2 and DVB.org it became LDPC.

 As you can see, the discriminating factor is the FEC, in this
 condition and nothing else. You will need a flag to discriminate
 between the FEC types, rather than the modulation, if things were to
 look more logical.

 I guess the problem, as I can see now, is that there is now way
 of telling from the SI data that a transponder uses 8psk turbo fec,
 or is there?

 Would it make sense to differentiate this in the following way:

 - an 8psk transponder on DVB-S is turbo fec
 - an 8psk transponder on DVB-S2 is  *not* turbo fec

 ? So an 8psk/DVB-S transpoder will require a device that has
 FE_CAN_TURBO_FEC set, while an 8psk/DVB-S2 transpoder simply
 requires a DVB-S2 device (since there is no FE_CAN_PSK_8).

(I have no real life experience with the Turbo FEC stream),
with regards to the satellite_delivrey_system_descriptor:
modulation_system will be always DVB-S  with regards to Turbo FEC
streams and not DVB-S2
while
modulation_type will be 8PSK or QPSK for the Turbo FEC capable devices.
Maybe someone having a Turbo FEC device can verify this ?


Eventually, you would be able to use the flags or a combination of it
at the driver side;

and with regards to the SI: modulation_system and modulation_type it's
possible to handle a 8PSK Turbo FEC stream, but it might be a bit more
trickier to handle a QPSK Turbo FEC stream.


Regards,
Manu
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html