Hello,
You wrote:
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 };
I'm sorry if I confused you. The one I changed was just to follow the same
structure of the message sent from the windows driver to the device. But
what I meant is the hi_band variable in the if statement gets the wrong
value, thus setting the band value to the wrong parameter. Please note the
byte I changed to one does not affect any thing so if it is removed then its
okay, or leave it to let the driver behave as the windows driver.
Try this simple test, tune to a low band frequency (i.e. < 11700MHz) and
print the hi_band value. then tune to a high band frequency (i.e. >
11700MHz) and print the hi_band value. in my case the value was not
changing. Please let me know what you find out.
---------------------------------------------------------------------------------------------------
You Wrote:
@@ -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.
Okay, many thanks I should read it from the b[] array not the cmd[] array. I
will change it today and see If I can tune correctly in both bands.
And the reason why I'm doing this is because I'm trying to set the hi_band
variable to the correct value since its not set to the correct value in my
case. And because the diseqc msg is always sent before setting the frequency
and it also contains the hi_band value.
------------------------------------------------------------------------------------------------
You Wrote:
>>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?
I do not do it in the driver level, I'm doing it in the application level.
-------------------------------------------------------------------------------------------------
You Wrote:
>>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?
Somewhere from my brain :) :) ? Do you know what the correct values are? I
just wanted mythtv not to spit out the warning of the symbolrate being out
of range!!
-------------------------------------------------------------------------------------------------
You Wrote:
>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 :(
please do not be disappointed, I do not know anything about CAM/CI neither
;o) . The way I found this out was completely out of luck. I just followed
the sequence of the windows msgs to the deivce using usbsnoop.
The trick here is to send the Program_id of the channel using the same
sequence of commands I added in the code and the device will spit out
unscrambled video and audio. As simple as this. However, I do not know when
or where to get the program_id from the application, this is why I have the
switch case in my code.
Does adding another ioctl to set the program Id require huge change in the
driver??
-------------------------------------------------------------------------------------------------
Please let me know if you need more clarification.
_____________________________________________________
Best Regards,
Bander
-----Original Message-----
From: Peter Beutner [mailto:p.beutner@xxxxxxx]
Sent: Monday, December 05, 2005 8:42 PM
To: bander ajba
Cc: linux-dvb@xxxxxxxxxxx
Subject: Re: [linux-dvb] DEC3000-s
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 :(
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.linuxtv.org/pipermail/linux-dvb/attachments/20051206/178a1861/attachment-0001.htm
