[linux-dvb] stb0899 troubles

[Manu Abraham]

On 2/25/07, Bernhard Rosenkraenzer <bero at arklinux.org> wrote:
> On Saturday, 24. February 2007 23:56, Bernhard Rosenkraenzer wrote:
> > Actual DVB-S2 channels don't seem to work either -- szap with the patches
> > tunes there and claims to have a lock, but the dvr0 device remains empty.
>
> I found some oddities in the patched szap code -- fixing them doesn't seem to
> change anything, but maybe they cause odditites elsewhere (or maybe I'm
> misreading things?):
>

the very same szap was used on dvb-s/dvb-s2 for a couple of people, so
the probability of szap not working is lesser.

> 1. do_tune() sets fe_params.delsys.*.fec = FEC_AUTO;
>    but the type of the fec member is dvbfe_fec rather than fe_code_rate_t --
>    shouldn't it be set to DVBFE_FEC_AUTO instead, especially because the value
>    is not the same?
>

We use FEC_AUTO, with the API update DVBFE_FEC_AUTO.

> 2. Similarily, there's INVERSION_* vs. DVBFE_INVERSION_* --
>    dvb_frontend_parameters takes a fe_spectral_inversion_t which matches
>    the use of INVERSION_* in patched szap, but DVBFE_INVERSION_* is
>    introduced by the multiproto patch and is set inside the kernel module
>    if dvb_force_auto_inversion is on.
>

Inversion also doesn't matter.


> 3. Nothing in do_tune() sets fe_params.delsys.*.modulation -- but
>    0 is DVBFE_MOD_NONE. Shouldn't it be set to DVBFE_MOD_AUTO
>    (or DVBFE_MOD_QPSK/DVBFE_MOD_8PSK depending on dvbs vs. dvbs2)?
>    If the modulation parameter is there for DVBFE_GET_PARAMS only, it should
>    probably be pointed out in a comment in the header (the way it is done for
>    e.g. dvbs2_params.rolloff)
>

Modulation also doesn't matter.

The only things that do matter

1) frequency
2) symbol rate
3) delivery system

As ralph said, probably wrong pids ?

regards,
manu