[linux-dvb] DEC3000-s

Bander Ajba bander.ajba at gmail.com
Tue Dec 6 06:18:51 CET 2005


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 at gmx.net]
Sent: Monday, December 05, 2005 8:42 PM
To: bander ajba
Cc: linux-dvb at linuxtv.org
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


More information about the linux-dvb mailing list