Manu Abraham schreef:
Zoilo Gomez wrote:
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.
The last part is almost correct except for a slight change. There is a
bug in there from my side, don't understand how it worked
DISEN = DiSEqC (Mode) enable
DISTA = DiSEqC Transaction Activate
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.
modified send_msg a bit (didn't compile test yet)
static int mb86a16_send_diseqc_msg(struct dvb_frontend *fe,
struct dvb_diseqc_master_cmd *cmd)
{
struct mb86a16_state *state = fe->demodulator_priv;
int i;
u8 regs = 0x18;
if (cmd->msg_len > 6 || cmd->msg_len < 3)
return -EINVAL;
// Enable DiSEqC Mode with 50% duty cycle
if (mb86a16_write(state, MB86A16_DCCOUT, MB86A16_DCCOUT_DISEN) < 0)
goto err;
// Select DiSEqC and Clock
if (mb86a16_write(state, MB86A16_TONEOUT1, 0x5b) < 0)
goto err;
if (mb86a16_write(state, MB86A16_TONEOUT2, 0x04) < 0)
goto err;
// Write to registers
for (i = 0; i < cmd->msg_len; i++) {
if (mb86a16_write(state, regs, cmd->msg[i]) < 0)
goto err;
regs++;
}
msleep_interruptible(10);
// Load length and transmit
if (mb86a16_write(state, MB86A16_DCC1, MB86A16_DCC1_DISTA | cmd->msg_len))
goto err;
return 0;
err:
dprintk(verbose, MB86A16_ERROR, 1, "I2C transfer error");
return -EREMOTEIO;
}
Manu,
Is the above version of mb86a16.c downloadable?
The current download locations
(http://thadathil.net:8000/cgi-bin/hgwebdir.cgi/mantis and
http://jusst.de/manu/mantis-v4l-dvb.tar.bz2) do not contain the above
version of the mb86a16_send_diseqc_msg function.
Michel.
|
