[dvblast-devel] Does DVBlast allow DiSEqC switching?

[Thomas Kernen]

Christophe Massiot wrote:
> On Mon, Oct 05, 2009, Thomas Kernen wrote:
> 
>> I've tried values 0, 1 and 2 with settings for a transponder that is on  
>> the default (first) position of the DiSEqC switch but it doesn't seem to  
>> trigger it. I always lock onto the TS I would expect for the default  
>> position.
>>
>> Double checked with dvbtune to make sure the card was behaving correctly  
>> which it appears to be.
> 
> It's very weird to me because IIUC, there is an obvious typo in
> dvbtune's (and szap's) diseqc code. I have a lot of suspicions with the
> SEC_MINI_* code, and I can't find much documentation about it.
> 
> Could you try each of the attached 3 patches, and report which of them
> work ?
> 
> Thanks,
> 
> 

No errors on patching or on compilation. Just 2 warnings:
"dvblastctl.c:106:2: warning: #warning expect brain-dead gcc warning 
about tmpnam here
<snip>
dvblastctl.o: In function `main':
<path>/dvblastctl.c:107: warning: the use of `tmpnam' is dangerous, 
better use `mkstemp'

I guess I must be doing something fundamentally wrong since none of the 
3 patches seem to work for me. So here is the test setup to help illustrate:

1 have a DiSEqC switch with position 0: 19.2E, position 1: 13E, position 
2: 28.2E (position 3 is free).

I'm testing against position 0 (or 1 in your syntax) with the following 
command line:
./dvblast -u -d 239.232.232.1:3000 -f 10743750 -a 1 -n 0 -e -t 3 -v 18 
-s 22000000 -S 1

This is a German FTA mux that is known to provide good reception in 
nearly all scenarios. (19.2E, 10743.75 H, 22000 srate)

Then I get this on the output:
warning: restarting
debug: frequency 10743750 is in Ku-band (lower)
debug: tuning QPSK frontend to f=10743750 srate=22000000 v=18 p=0 
modulation=legacy
debug: CA interface with 1 slot
debug:   CI link layer level interface type
debug:   0 available descramblers (keys)
debug: setting filter on PID 8192
error: can't fopen config file (null)
debug: frontend has acquired signal
debug: frontend has acquired carrier
debug: frontend has acquired stable FEC
debug: frontend has acquired sync
debug: frontend has acquired lock
debug: - Bit error rate: 0
debug: - Signal strength: 58872
debug: - SNR: 62184
<skipping the discontinuity warnings>
debug: new PAT ts_id=1051 version=3 current_next=1
debug:   * number=0 pid=16
debug:   * number=28721 pid=100
debug:   * number=28722 pid=200
debug:   * number=28723 pid=300
debug:   * number=28724 pid=400
debug:   * number=28725 pid=500
debug:   * number=28726 pid=600


If I try the same command line with -S 2 or -S 3 I get the exact same 
output. I'm working on the assumption that if it had switched DiSEqC 
input I would either get nothing (most likely) or another set of PIDs. A 
  video check of the outputted mcast stream confirms that it's the same 
signal (sanity check).

I'm running kernel 2.6.28 and using S2API. If I use szap or szap-s2 I 
can switch between DiSEqC positions without any issue. Currently tested 
against TT-1500 and KNC1 boards.

Thomas