In message <1a297b360703180030j22e7c780g810e60d46b8efc0f@xxxxxxxxxxxxxx>, "Manu Abraham" wrote: hi >On 3/18/07, Darron Broad <darron@xxxxxxxx> wrote: >> In message <1a297b360703171245g2ffb04dfh6872a855cfc1a578@xxxxxxxxxxxxxx>, "Manu Abraham" wrote: >> >> lo >> >> >On 3/17/07, Darron Broad <darron@xxxxxxxx> wrote: >> >> In message <45FAB175.6090803@xxxxxxxxxxxxx>, Steven Toth wrote: >> >> >Darron Broad wrote: >> >> > >> >> >Has anyone had a chance to try the stoth/hvr4000 tree after the recent >> >> >fixes? It's certainly going through the correct motioned for tuning now. >> >> >(I don't have a feed available for testing right now). >> >> > >> >> >Remember, DiSEqC is not implemented. >> >> >> >> Hi Steve. >> >> >> >> I have more news to report. >> >> >> >> I have hacked some extra args to the kromtek multiproto szap and am able >> >> to tune to a DVB-S2 channel. >> >> >> > >> >szap (http://kromtek.com/dvb/szap.c) should work as it is with multiproto >> >> this is the base of the hack. there are three reasons it doesn't work >> with the hvr4000 demod driver. >> > >Hmm.. I was able to test it only with the STB0899 - STB6100/TDA8261 >(KNC1, Satelco, Azurewave cards) > >> 1. the modulation type needs to be explicit >> > >The STB0899 can do modulation type detection from the physical layer. >I thought that other demods also could do the same. > >> 2. fec_auto isn't available as stated in driver: >> > >the same as above, but the MODCOD is extracted from the Pilot tones. >So it is just default AUTO like the current "existing drivers". though >there could be a bug, probably. > > switch (delsys) { > case DVBS: > fe_params.delsys.dvbs.symbol_rate = sr; > fe_params.delsys.dvbs.fec = FEC_AUTO; > printf("%s: Frequency = %d, Srate = %d\n", > __func__, fe_params.frequency, fe_params.delsys.dvbs.symbol_rate); > break; > case DSS: > fe_params.delsys.dss.symbol_rate = sr; > fe_params.delsys.dss.fec = FEC_AUTO; > printf("%s: Frequency = %d, Srate = %d\n", > __func__, fe_params.frequency, fe_params.delsys.dss.symbol_rate); > break; > case DVBS2: > fe_params.delsys.dvbs2.symbol_rate = sr; > fe_params.delsys.dvbs2.fec = FEC_AUTO; > printf("%s: Frequency = %d, Srate = %d\n", > __func__, fe_params.frequency, fe_params.delsys.dvbs2.symbol_rate); > break; > > >> "Not all S2 mmodulation schemes are support and not all rates with >> a scheme are support. Especially, no auto detect when in S2 mode" >> > > >The CX24116 doesn't support identifying the modulation from the >Physical layer ? Sounds a bit strange. The capabilities of the cx24116 and it's firmware are completely unknown to me, if anyone has any details please pass them on. Your assumptions are based on a known spec, with the cx24116 there is no known spec. Steve's hacks depend on a number of parameters in order to configure the cx24116 firmware. Those parameters must come from userland and although the cx24116 may be able to detect if told to, it's not known how to tell it to do that. The code fragment to configure the DVB-S2 tuning in my mod is as follows: case DVBS2: fe_params.delsys.dvbs2.symbol_rate = sr; fe_params.delsys.dvbs2.fec = fec; fe_params.delsys.dvbs.modulation = modulation; fe_params.delivery= DVBFE_DELSYS_DVBS2; Steve's driver needs delivery, fec and modulation in order to program the device for tuning and no wildcards are allowed for DVB-S2. >> 3. the delivery field has to be set >> > > >delivery system is set using DVBFE_SET_PARAMS, without which you >wouldn't be able to tune to anything, because of the switch statement. the delivery type is indeed taken from the command line and used for logic in the code, however, it's not passed to the driver. cya -- // / {:)==={ Darron Broad <darron@xxxxxxxx> \\ \ _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
