Trent Piepho wrote:
On Sat, 22 Apr 2006, Manu Abraham wrote:
After some rework landed up with a patch like this.
Ok, I've got a few comments.
+typedef enum {
+ FE_TRANSPORT = 0x00000001,
+ FE_GENERIC_PACKET,
+ FE_GENERIC_CONTINUOUS,
+ FE_RESERVED,
+} fe_matype_t;
I take it this was the field that used to be a mirror of fe_delsys_t, but
really was the multiplex stream format? If FE_TRANSPORT is for MPEG / ISO
13818-1 Transport Streams, maybe it should have MPEG in the name? Or is
FE_TRANSPORT for any kind of transport stream?
no, transport is just one amongst. It can be MPEG or anything else even,
just a TRANSPORT, but transport is only one of the modes. I think we
discussed this one in the earlier post, which had this as
+ MOD_BPSK_1_4 = 0x40000000,
+ MOD_RESERVED_2 = 0x80000000
+} sat_modcod_t;
There are only two unassigned bits left. I can just picture one year from
now, three new modulation-FEC ratio combos need to be added. Maybe
splitting FEC and modulation, as is done for DVB-C and DVB-T, would make
more sense? I suppose that would make it hard to show the supported
_combinations_ of modulation and FEC ratio.
currently we have included all the modulation-codings on satellite
delivery, which includes DVB-S, DVB-S2 and DSS
and if in future more come in, need to define the relevant modcod types.
The current devices do not even support all those at present. (The
higher order modulations are still not supported by the current devices
yet) So it is still way to go and still free.
I also noticed that the same value is used for identical modulation-FEC
combinations for both DVB-S and DVB-S2. If something supported QPSK 1/2
for DVB-S but not DVB-S2, how would that work?
That's why delivery system is used delsys_t. The delivery system in
combination you can choose between DVB-S/DVB-S2
Since DVB-S2 is backwards compatible.
ok, going down i have an alternative thought on this..
+ MOD_QAM_256 = 0x00000010
+} cab_modcod_t;
+ MOD_COFDM = 0x00000001
+} ter_modcod_t;
I'm guessing 'mod' stands for modulation and 'cod' is for Forward Error
Correction Code Ratio? But these enums don't specify anything about FEC,
just modulation. Also, there are no AUTO modulations, but there is
hardware that can do this.
yeah, missed out on that .. :-) inner coding is needed as well
In the _params for DVB-S, the modulation and FEC ratio are specified as a
single field 'modcod'. For DVB-C, modulation isn't specified at all and
FEC ratio uses a fe_code_rate_t field fec_inner. For DVB-T, there is only
one modulation, but it doesn't use 'modcod' like DVB-S, instead it uses
fe_modulation_t. The FEC ratio isn't specified with 'modcod' like DVB-S,
but uses fe_code_rate_t fields named code_rate_{HP,LP}, instead of
fec_inner like in DVB-C. Or to summarize:
that's why there is only one modulation for DVB-T/H. Any better ideas ?
Modulation:
DVB-S sat_modcod_t modcod (modulation-FEC combo field)
DVB-C unspecified
DVB-T fe_modulation_t constellation
FEC ratio(s):
DVB-S sat_modcod_t modcod (modulation-FEC combo field)
DVB-C fe_code_rate_t fec_inner
DVB-T fe_code_rate_t code_rate_HP, code_rate_LP
Why not be consistent?
missed out on DVB-C, which make as all the enumerations with modulations
and code rates
except for COFDM. (Should reconsider posting at 4AM again) With that
change for DVB-C it should be consistent
it should be looking like
DVB-S sat_modcod_t
DVB-S cab_modcod_t
DVB-T ter_modcod_t (this is only the modulation)
The modulation is meant to get the modulation types in case of
multistandard devices
+struct dvb_frontend_params {
+ __u32 frequency;
+ fe_spectral_inversion_t inversion;
+ struct fe_cap caps;
Why is inversion not part of XXX_params?
+/**
+ * Cable frontend parameters
+ */
+/**
+ * Terrestrial frontend capabilities
+ */
+/**
+ * Satellite frontend parameters
+ */
This is very Eurocentric. The rest of the world has digital Cable,
Not eurocentric, i initially wanted to go only the DVB way rather than
anything else (lesser complexity)
As i wrote at the beginning i have not included ATSC and DSS for the
time being (to make it easier).
Currently
- the ATSC and DSS have not been included in the new implementation, to
make it look a bit simpler initially, if it is found okay we can add
them both in the same way.
Terrestrial and Satellite too, but it's not all DVB-C/T/S. Same with the
structure names, ter_params is for your terrestrial parameters, it has
nothing to do with MY terrestrial parameters.
ter_params include DVB-T and DVB-H. Whichever way you put it, it will
eventually reduce down to 3 delivery systems.
or would you prefer,
dvbs_t,
dvbs2_t
dvbc_t
dvbt_t
dvbh_t
atsc_t
dss_t
but this will cause some duplication, but still if the choice is for
this style, we can go this way as well.
but remeber that s2 is backward compatible to s, dvb-h as 2 additional
fields compared to dvb-t.
The advantage in this case is whatever duplication is there, when a new
standard/modulation/code rate etc comes up define a new type similarly.
ATSC and DSS are different. Digital cable is what you say "QAM" is
annex-b digital cable TV. Some people call it clean QAM.
+/**
+ * Case #1
+ * If we make a call FE_GET_PARAMS with modcod=0x00
+ * and do a FE_GET_PARAMS, it will simply return
+ * all the available modulation and coding types used.
+ *
+ * Case #2
+ * calling FE_GET_PARAMS with the corresponding
+ * MODCOD type will return the parameters
+ * available for the corresponding MODCOD
+ */
I don't get it, what is 'modcod'? There is one field named modcod,
(dvb_frontend_params).sat.modcod, that's only for DVB-S. Do you mean
(dvb_frontend_params).caps.delivery? So if you set .caps.delivery=0 then
you get the union of "all the available modulation and coding types" inside
.caps.modulation? That doesn't make sense either. Does it mean that
.caps.delivery will be set to the union of all available delivery systems?
modcod is according to the specs and in accordance to the devices. What
will you do if a device supports multiple delivery types and or
modulations ? Multistandard tuners will need to report back via a
relevant MODCOD only.
If you set modcod = 0, you will get supported modulations and code
rates, else complete info.
Does FE_GET_PARAMS return the current status of the FE, or does it return
the FE's capabilities? Or both? If both, is it wise to conflate the two
operations? The former requires querying the hardware while the later can
just return a pre-packaged const struct.
It has to get both, IMHO. Otherwise you will not be able to handle
multistandard tuners properly. There are tuners that can handle
DVB-S/DVB-S2/DSS. There could be other combinations as well.
Thanks,
Manu
_______________________________________________
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
