On Sat, May 13, 2006, Manu Abraham wrote: > Johannes Stezenbach wrote: > >I didn't say MODCOD is unnecessary. > > > >I did say it is unnecessary *in the Linux DVB API*. > > Okay, How do you expect the apps to talk to the API for MODCOD ? > According to your suggestion, all DVB-S2 drivers will need to encode > MODCOD from modulation and coderates. The application does decode the > MODCOD and send it to the driver. No MODCOD necessary anywhere. E.g. dvb-apps dvbscan will parse satellite_delivery_descriptor and give you FEC and modulation type, and that's what you should pass to the FE_SET_PARAMS call. > Specs says MODCOD as an entity, not 2 different fields. The specs do not > say MODCOD is Modulation + Coderate eventhough it indeed *is*. Nor does > the devices either. Reading the device registers itself gibves you the > MODCOD, just like what you read FEC information. > > Even a quick glance on the specs will prove it. IMHO: MODCOD as it is defined in the spec is a field which is part of the physical layer signalling. It is a lowlevel encoding used to saved a bit in the PLHEADER, and not what you should use in the tuning API. > >And we might provide MATYPE for informational purposes, > >but decoding it is left to the application. You could > >put the code to decode it into dvb-apps/lib/ somewhere. > > Not yet reached there. Will do some utils as soon as it is finished. Yeah, here I mixed up MATYPE (from BBHEADER) with MODCODE (from PLSCODE). So assuming that the demo hw will give you the MODCOD from PLSCODE in a register and you want to query it via FE_GET_PARAMS, we should keep decode_dvbs2_modcod() in dvb_frontend. FE_GET_PARAMS will then return fec and modulation instead of modcod. Johannes _______________________________________________ linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
