Hi,
Oliver Endriss wrote:
>>when VDR switches to a different transponder the device driver is sent
>>the above two ioctl()s with appropriate data.
>>
>>Just in case the multiswitch get's a damaged DiSEqC message, it won't
>>choose for example a different polarisation and VDR won't ever get the
>>expected signal without tuning again.
>>
>>I've patched VDR to repeat the DiSEqC message every 500 ms after
>>FE_SET_FRONTEND until the device's tuner reports LOCKED. An oszilloscope
>>shows me that the message get's sent on the cable about every 568 ms so
>>the code seems to be correct.
>
> Hm - it should be enough to send the message 2 or 3 times using
> diseqc.conf. If this does not work there is a severe problem.
Yes, I read something like that in the VDR ML. But if VDR repeats the
sequence on it's own, it is more tolerant to connecting the antenna
cable at run time (at least in the case of DVB-S with a DiSEqC
multiswitch the DiSEqC command must be resent in order to give the card
a chance to retune automatically). But I don't know whether this issue
is of any concern.
>>But for any reason, the tuning doesn't succeed. I've further added a
>>timeout of 3000 ms after which FE_SET_FRONTEND is issued again, which
>>typically tunes successfully then.
>>
>>So, it seems that I'm wrong with my assumption that the device keeps on
>>tuning for at least 2000 ms (BTW: I've never seen the flag TIMEOUT while
>>tuning) and that repeating the DiSEqC messages should lead to successful
>>tuning.
>>
>>Is it therefore necessary to repeat FE_SET_FRONTEND too at an interval
>>of 500 ms?
>>
>>Would it be ok to shorten the time further (e. g. 300 ms) without
>>messing up FE_SET_FRONTEND's design (i. e. the current tuning operation
>>is aborted and a new one is triggered)?
>>
>>Is it likely that retuning that fast turns out to be bad on DVB-T or
>>DVB-C systems?
>
> If the first tuning attempt failes the frontend thread starts zip-zag
> scan. It will take some time until the center frequency is tried again.
> For details see dvb_frontend.c.
A had a look at it and see, that sending the DiSEqC message stops the
zip-zag mode. So I have to do a FE_SET_FRONTEND too to continue tuning.
>>BTW: I'm using DVB-S (NOVA-S), dvb-kernel CVS snapshot of March 2005.
>
> Hm - which Nova exactly? Sub-system type from 'lspci -vn' output?
0000:03:05.0 Class 0480: 1131:7146 (rev 01)
Subsystem: 13c2:100f
Flags: bus master, fast Back2Back, medium devsel, latency 123,
IRQ 11
Memory at d3110000 (32-bit, non-prefetchable) [size=512]
0000:03:07.0 Class 0480: 1131:7146 (rev 01)
Subsystem: 13c2:100f
Flags: bus master, fast Back2Back, medium devsel, latency 123,
IRQ 9
Memory at d3110400 (32-bit, non-prefetchable) [size=512]
> The bit-banging diseqc implementation in budget.c cannot work in a
> reliable way. Interrupts or preemption will distort the diseqc message.
>
> Disabling interrupts would probably fix this but imho it is not
> acceptable to disable interrupts for 54ms!
So the idea of retuning (= FE_DISEQC_SEND_MASTER_CMD + FE_SET_FRONTEND)
is not that bad, isn't it?
It's at least what other receivers do.
> Recently I noticed that problem with an old 13c2:1003 Nova.
> For my card I have a perfect solution but I'm not sure whether it will
> work for all Novas with BSRU6 tuner.
Regarding your follow up: what's the idea behind not setting for example
budget->dvb_frontend->ops->diseqc_send_master_cmd?
I must admit that I didn't apply the patch (as my hardware doesn't match
and my tuning issue is hardly reproduceable), but as far as I understand
the code (just had a glance at dvb_frontend.c), it is then no longer
possible to send any DiSEqC messages.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rnissl@xxxxxx
