[linux-dvb] Mantis and MB86A16 (VP-1034) and DiseqC commands not working.

Manu Abraham abraham.manu at gmail.com
Tue May 1 22:48:16 CEST 2007


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;
}



More information about the linux-dvb mailing list