Hi
Just a few comments/questions.
bander ajba schrieb:
[snip]
>>Finding 1: My last searches on the dec3000s driver on this forum pointed
>>that the scanning for channels sometime works and some does not. The reason
>>for this is in ttusbdecfe.c:
>>
>>[ state->hi_band ]
>>
>>in function
>>
>>[static int ttusbdecfe_dvbs_set_frontend(...)] is always set to zero.
>>
>>Which sets the variable [band] to the constant [LOF_LO] causing the dec3000
>>to fail.
>>
>>I tried to sets the variable when the diseqc command is sent but it does not
>>work. So I set it to 1 because most of the channels I tuned to are in the
>>high band anyway. I believe the error lies in passing the variable from the
>>dvb_demux -> ttusbdecfe.c
>>
>>So setting the [hi_band] correctly will cause the DEC3000 to tune okay.
>>(critical)
I can't really follow you here:
in ttusbdecfe_dvbs_set_frontend:
Let's look at the usb message that is send to the device:
u8 b[] = { 0x00, 0x00, 0x00, 0x01,
0x00, 0x00, 0x00, 0x00, <--- gets the frequency
0x00, 0x00, 0x00, 0x01,
0x00, 0x00, 0x00, 0x00, <---- gets the symbol rate
0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, <---- gets the band setting
0x00, 0x00, 0x00, 0x00, <---- gets the lnb_voltage
0x00, 0x00, 0x00, 0x00, <---- the one you changed
0x00, 0x00, 0x00, 0x00 };
So the parameter you needed to change was never touched before by the driver.So it
probably hasn't got to do anything with the band setting but with some other tuning
parameter that was previously simply not correctly set by the driver(like inversion
setting for example).
Maybe you can compare the channel parameters from a channel who tunes without this change
with one which needs this change?
Or maybe the change below simply broke your tuning.
@@ -106,7 +116,7 @@ static int ttusbdecfe_dvbs_diseqc_send_m
0x00, 0x00 };
memcpy(&b[4], cmd->msg, cmd->msg_len);
-
+ state->hi_band = (cmd->msg[9] & 0x01);
why doing that?
Besides iirc the diseqc message length is <= 6, so this sets the the hi_band setting to a
completely random value from somewhere in the memory.
>>Finding 2: some applications fail (like mplayer, and mythtv) when Sending
>>Burst tone to the DEC. Apparently the DEC does not care about the burst tone
>>(I think automatically detected) so I always return success.
>>
>>So ignoring the [Burst_tone] and returning success will case the application
>>to work correctly.(annoyance)
hm looking into your patch i don't find the place where you did that?
>>Finding 3: adding the range for min_symbolrate, and max_symbolrate will stop
>>some applications to complain about symbolrate being out of range
>>(Annoyance)
Where did you take the values from?
>Finding 5: I reached this finding just yesterday when I successfully was
>>able to watch encrypted channels in Mythtv.
pretty cool to hear that encrypted channels are working ;)
Though I am not familiar at all with the ci/cam stuff so I can't help you much with this :(
