Manu Abraham wrote:
sounds like you don't have the tone burst working. Looking in there..
Can you please try the modified burst callback ? You may/may not need to
play a bit with a bit of sleep after the break in each case.
Sorry Manu, but this is not about diseqc-burst either ...
There are 4 things
1) 13v/18v (LNB Polarization control) (vp1034_set_voltage)
2) 22k tone control (it has OFF/ON) (mb86a16_set_tone)
3) burst (A/B unmodulated/modulated) uses 22k modulation
(mb86a16_send_diseqc_burst)
4) diseqc functions (mb86a16_send_diseqc_msg)
Exactly.
Unless our mutual terminology is inconsistent, "diseqc-burst" is a
simple enhancement method of controlling an individual 2-state switch,
in addition to existing conventional control by 18/13V for pol selection
and 22kHz for band selection (see:
http://www.eutelsat.com/satellites/pdf/Diseqc/Reference%20docs/bus_spec.pdf).
What I need is DiSEqC 1.0 support, as specified in the above document,
where the entire control information (sat,pol,band) is being passed by
means of a digital message. No voltages or tones.
that one you are looking at send_diseqc_msg. You just managed to confuse
me with the additional "22kmodulation" in there
... sorry ...!
IIRC, send_msg had been working. need to see what's wrong. (Maybe diseqc
bus is busy ?)
Can you add a dumb short sleep (~10 ms) before the for loop and try a
larger sleep within the for loop (~100 - 200mS) and see whether any
change in behaviour ?
Assuming that you mean the for-loop in send_diseqc_msg: makes no difference.
Anyway, it would have surprised me if this had any effect, because the
loop seems to be merely filling a 4-byte hardware buffer with the
message to be sent, and I assume that only when writing 0x90 + msg
length into MB86A16_DCC1, followed by a writeof DISEN (DiSEqC enable?)
to MB86A16_DCCOUT, the hardware is actually being triggered to dispatch
the message.
I notice that all other signaling methods are running in parallel
(18/13V, tone bursts etc). Could it be that message dispatch for DiSEqC
is being set up correctly, but then accidentally disabled while in
progress, by one of the other functions? Settings are being poked
straight into the registers as constants, instead of reading back the
actual setting and modifying only the appropriate bit(s). Just a thought.
Without an oscilloscope and a datasheet this seems tough to debug, at
least for me. At this point I cannot even see if the software is at
least trying to dispatch a DiSEqC message. Is there any way I can sign
an NDA as well?
Z.
_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
