Re: [linux-dvb] Mantis and MB86A16 (VP-1034) and DiseqC commands not working.
Hi Manu,
Any chance we can finish this issue soon?
Please let me know how I can help; without proper chip-set documentation
it seems to me that I can only wait for you to fix it for me ... but I
can test your patches of course.
Thank you and best regards,
Zoilo.
=
Zoilo Gomez wrote:
Manu Abraham wrote:
Zoilo Gomez wrote:
Manu Abraham wrote:
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)
Thank you for your help Manu.
In this form it does not seem to work yet.
Or perhaps one of the other functions (burst, set_tone), that sometimes
use the same registers, is overwriting one of the register settings?
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))
This OR with 0x80 (DISTA); in the previous version it was 0x90 ?
goto err;
return 0;
err:
dprintk(verbose, MB86A16_ERROR, 1, I2C transfer error);
return -EREMOTEIO;
}
May 1 23:42:15 localhost mb86a16_set_tone: SEC TONE OFF
May 1 23:42:15 localhost mb86a16_write: writing to
[0x08],Reg[0x20],Data[0x04]
May 1 23:42:15 localhost mb86a16_write: writing to
[0x08],Reg[0x16],Data[0x80]
May 1 23:42:15 localhost mb86a16_write: writing to
[0x08],Reg[0x1e],Data[0x00]
May 1 23:42:15 localhost vp1034_set_voltage (0): Polarization=[18v]
May 1 23:42:15 localhost mb86a16_write: writing to
Re: [linux-dvb] Mantis and MB86A16 (VP-1034) and DiseqC commands not working.
Zoilo Gomez wrote:
Hi Manu,
Any chance we can finish this issue soon?
What i don't understand is.. Michel has diseqc working. Quite a bit lost.
Please let me know how I can help; without proper chip-set documentation
it seems to me that I can only wait for you to fix it for me ... but I
can test your patches of course.
The doc isn't great either. Just register addresses and bitfield names
and a one line description
with regards to the mantis, there is absolutely no documentation at all.
Thank you and best regards,
Zoilo.
=
Zoilo Gomez wrote:
Manu Abraham wrote:
Zoilo Gomez wrote:
Manu Abraham wrote:
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)
Thank you for your help Manu.
In this form it does not seem to work yet.
Or perhaps one of the other functions (burst, set_tone), that sometimes
use the same registers, is overwriting one of the register settings?
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))
This OR with 0x80 (DISTA); in the previous version it was 0x90 ?
goto err;
return 0;
err:
dprintk(verbose, MB86A16_ERROR, 1, I2C transfer error);
return -EREMOTEIO;
}
May 1 23:42:15 localhost mb86a16_set_tone: SEC TONE OFF
May 1 23:42:15 localhost
Re: [linux-dvb] Mantis and MB86A16 (VP-1034) and DiseqC commands not working.
Manu Abraham schreef: Zoilo Gomez wrote: Hi Manu, Any chance we can finish this issue soon? What i don't understand is.. Michel has diseqc working. Quite a bit lost. Please let me know how I can help; without proper chip-set documentation it seems to me that I can only wait for you to fix it for me ... but I can test your patches of course. The doc isn't great either. Just register addresses and bitfield names and a one line description with regards to the mantis, there is absolutely no documentation at all. Zoilo, Which program are you using and does the setting of your switch? I only have a rotor and not a switch,yet ;) , so I'm not able to test this part either. I will ask a friend if I can borrow one of his. This can take some time but will let you know. Regards Michel Thank you and best regards, Zoilo. = Zoilo Gomez wrote: rest removed because of size This my 3rd try but had the to address wrong the first two times. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Mantis and MB86A16 (VP-1034) and DiseqC commands not working.
Zoilo Gomez wrote: I am also at loss now Michel: can you confirm that DiSEqC is working for you using the Mantis driver? Are you 100% that it is DiSEqC that is doing the work, and not some conventional compatibility function like 18/13V+22kHz etc (which initially fooled me to believe that DiSEqC was working)? Manu: a couple of emails ago, you wrote that you were puzzled how the code could ever have worked, and came up with some changes ... ? What I made from this is that you had found some quirks in the register settings (but perhaps i completely misunderstood you). Yep. I was really confused 22k modulation got me confused a bit first, on top of that i thought something was wrong too, but not very sure.. But still, i am a bit confused even now Looks like I must go and borrow an oscilloscope somehow, so I can measure what is going on at the coax level ... If you can do that would be great ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Mantis and MB86A16 (VP-1034) and DiseqC commands not working.
Hi Michel, Michel Verbraak wrote: Zoilo Gomez schreef: I am also at loss now Michel: can you confirm that DiSEqC is working for you using the Mantis driver? Are you 100% that it is DiSEqC that is doing the work, and not some conventional compatibility function like 18/13V+22kHz etc (which initially fooled me to believe that DiSEqC was working)? Manu: a couple of emails ago, you wrote that you were puzzled how the code could ever have worked, and came up with some changes ... ? What I made from this is that you had found some quirks in the register settings (but perhaps i completely misunderstood you). Looks like I must go and borrow an oscilloscope somehow, so I can measure what is going on at the coax level ... The driver does send diseqc commands. Because I control my rotor with DiseqC 1.2 gotox commands. Have a look at my gotox program. I posted a bit earlier about it. It uses the dvb api which is in dvb-apps at linuxtv.org So I understand that what you are saying is that your driver is sending DiSEqC commands, *but you are not using them, so you cannot sure that they work*, correct? Instead you are controlling your rotor with a separate program, that is not using the Mantis driver, correct? Z. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Mantis and MB86A16 (VP-1034) and DiseqC commands not working.
I am also at loss now
Michel: can you confirm that DiSEqC is working for you using the Mantis
driver? Are you 100% that it is DiSEqC that is doing the work, and not
some conventional compatibility function like 18/13V+22kHz etc (which
initially fooled me to believe that DiSEqC was working)?
Manu: a couple of emails ago, you wrote that you were puzzled how the
code could ever have worked, and came up with some changes ... ? What I
made from this is that you had found some quirks in the register
settings (but perhaps i completely misunderstood you).
Looks like I must go and borrow an oscilloscope somehow, so I can
measure what is going on at the coax level ...
Manu Abraham wrote:
Zoilo Gomez wrote:
Hi Manu,
Any chance we can finish this issue soon?
What i don't understand is.. Michel has diseqc working. Quite a bit lost.
Please let me know how I can help; without proper chip-set documentation
it seems to me that I can only wait for you to fix it for me ... but I
can test your patches of course.
The doc isn't great either. Just register addresses and bitfield names
and a one line description
with regards to the mantis, there is absolutely no documentation at all.
Thank you and best regards,
Zoilo.
=
Zoilo Gomez wrote:
Manu Abraham wrote:
Zoilo Gomez wrote:
Manu Abraham wrote:
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)
Thank you for your help Manu.
In this form it does not seem to work yet.
Or perhaps one of the other functions (burst, set_tone), that sometimes
use the same registers, is overwriting one of the register settings?
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
Re: [linux-dvb] Mantis and MB86A16 (VP-1034) and DiseqC commands not working.
Michel Verbraak wrote: Zoilo, Which program are you using and does the setting of your switch? dvbtune (slightly modified because DiSEqC implementation of dvbtune-0.5 contains a bug, see my emails about this a couple of days ago) and also szap. With KNC1 DVB-S (stv2099 driver) these utils work perfectly, but VP1034 (mb86a16 driver) does *not* work. Z. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Mantis and MB86A16 (VP-1034) and DiseqC commands not working.
Zoilo Gomez schreef:
Hi Michel,
Michel Verbraak wrote:
Zoilo Gomez schreef:
I am also at loss now
Michel: can you confirm that DiSEqC is working for you using the
Mantis driver? Are you 100% that it is DiSEqC that is doing the
work, and not some conventional compatibility function like
18/13V+22kHz etc (which initially fooled me to believe that DiSEqC
was working)?
Manu: a couple of emails ago, you wrote that you were puzzled how
the code could ever have worked, and came up with some changes ... ?
What I made from this is that you had found some quirks in the
register settings (but perhaps i completely misunderstood you).
Looks like I must go and borrow an oscilloscope somehow, so I can
measure what is going on at the coax level ...
The driver does send diseqc commands. Because I control my rotor with
DiseqC 1.2 gotox commands. Have a look at my gotox program. I posted
a bit earlier about it. It uses the dvb api which is in dvb-apps at
linuxtv.org
So I understand that what you are saying is that your driver is
sending DiSEqC commands, *but you are not using them, so you cannot
sure that they work*, correct?
Instead you are controlling your rotor with a separate program, that
is not using the Mantis driver, correct?
No, my gotox program is using an API and the API is using the Mantis
driver to send out the DiseqC message. I also have another program which
does not use the API but talks directly to the Mantis driver. It talks
to the /dev/dvb/adapter0/frontend0 device with ioctl calls. The
following is an example:
int TDVBSDevice::SendRotorMoveCommand(float angle)
{
int ret = 0;
struct dvb_diseqc_master_cmd diseqc_message;
int integer = (int) angle;
uint8_t data[] = { *0xE0, 0x31, 0x6e, 0x00, 0x00*};
// transform the fraction into the correct representation
int fraction = (int) (((angle - integer) * 16.0) + 0.9) 0x0f;
switch(fraction) {
case 1:
case 4:
case 7:
case 9:
case 12:
case 15:
fraction--;
break;
}
// generate the command
if (integer 0.0) {
data[3] = 0xD0; // West is a negative angle value
} else if (integer = 0.0) {
data[3] = 0xE0; // East is a positive angle value
}
integer = abs(integer);
data[3] |= ((integer / 16) 0x0f);
integer = integer % 16;
data[4] |= ((integer 0x0f) 4) | fraction;
diseqc_message.msg_len = 5;
memcpy(diseqc_message.msg, data, 5);
ret = *ioctl(vfrontendfd, FE_DISEQC_SEND_MASTER_CMD, diseqc_message);*
if (ret == -1)
syslog(LOG_ERR, rotor_goto_bearing: IOCTL failed);
else
ret = 0;
return ret;
}
I really use the Mantis driver and as you can see I specify the complete
DiseqC command, see uint8_t data[] = { *0xE0, 0x31, 0x6e, 0x00,
0x00*};, to send not the driver. The example above is the same as used
by the API internally.
Michel
Z.
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Mantis and MB86A16 (VP-1034) and DiseqC commands not working.
Zoilo Gomez schreef: Michel Verbraak wrote: Zoilo, Which program are you using and does the setting of your switch? dvbtune (slightly modified because DiSEqC implementation of dvbtune-0.5 contains a bug, see my emails about this a couple of days ago) and also szap. With KNC1 DVB-S (stv2099 driver) these utils work perfectly, but VP1034 (mb86a16 driver) does *not* work. Z. Will have a look into this. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Mantis and MB86A16 (VP-1034) and DiseqC commands not working.
Zoilo Gomez schreef: Manu Abraham wrote: Zoilo Gomez wrote: Manu Abraham wrote: Zoilo Gomez wrote: Manu Abraham wrote: Michel Verbraak wrote: Manu, list, SNIP Freq+symrate is correct; I tried several freqs / pols / symbol rates on sat=2. I am quite sure that the problem is simple and diseqc related, for the several reasons: = my normal sat receiver is working fine on all 16 sat feeds (4*4) = KNC1 DVB-C is also working fine on all sats / pols / bands; the fact that it is capable to select different sats proves that its diseqc commands are working. = however VP1034 is working only on first satellite (out of 4). This seems to be caused by 18/13V+22kHz signaling (not diseqc), which is applied simultaneously with the diseqc command. However, switching to a different sat is impossible, because diseqc is not working. In fact, if I use the very same freq+pol+symrate, but only change the sat number (f.e. sat=2 of sat=3), I get the exact same transport stream from sat=1. So no sat switching occurs, hence diseqc is apparently not working, and 18/13V+22kHz must be responsible for pol+band selection. Can't see the bug from a quick glance, will take a look at it, these days. Please let me know where I can help. Z. Zoilo and Manu, DiseqC is working for me with my own programs and the patch i made for libdvbsec. I only use the GotoX function. Not preprogrammed positions. When I have time again I will have a look into this. When I tried the latest version of kaffeine, it now supports rotors, it was not able to rotate my rotor with kaffeine. I did not yet spend time to look into this because my own software still works. I can send you a small c-program which I made to rotate the rotor, by angle, I can send it or make it available trough a website. Please let me know. It uses my patched libdvbsec. As far as I know my patch is not implemented yet (do not know why). Regards, Michel. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Mantis and MB86A16 (VP-1034) and DiseqC commands not working.
Michel Verbraak wrote: Zoilo Gomez schreef: Manu Abraham wrote: Zoilo Gomez wrote: Manu Abraham wrote: Zoilo Gomez wrote: Manu Abraham wrote: Michel Verbraak wrote: Manu, list, SNIP Freq+symrate is correct; I tried several freqs / pols / symbol rates on sat=2. I am quite sure that the problem is simple and diseqc related, for the several reasons: = my normal sat receiver is working fine on all 16 sat feeds (4*4) = KNC1 DVB-C is also working fine on all sats / pols / bands; the fact that it is capable to select different sats proves that its diseqc commands are working. = however VP1034 is working only on first satellite (out of 4). This seems to be caused by 18/13V+22kHz signaling (not diseqc), which is applied simultaneously with the diseqc command. However, switching to a different sat is impossible, because diseqc is not working. In fact, if I use the very same freq+pol+symrate, but only change the sat number (f.e. sat=2 of sat=3), I get the exact same transport stream from sat=1. So no sat switching occurs, hence diseqc is apparently not working, and 18/13V+22kHz must be responsible for pol+band selection. Can't see the bug from a quick glance, will take a look at it, these days. Please let me know where I can help. Z. Zoilo and Manu, DiseqC is working for me with my own programs and the patch i made for libdvbsec. I only use the GotoX function. Not preprogrammed positions. When I have time again I will have a look into this. Michel, Thanks. Ok, so DiSEqC with regards to the MB86A16 works When I tried the latest version of kaffeine, it now supports rotors, it was not able to rotate my rotor with kaffeine. I did not yet spend time to look into this because my own software still works. I can send you a small c-program which I made to rotate the rotor, by angle, I can send it or make it available trough a website. Please let me know. It uses my patched libdvbsec. As far as I know my patch is not implemented yet (do not know why). You did send your patch ? ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Mantis and MB86A16 (VP-1034) and DiseqC commands not working.
Zoilo Gomez wrote: Manu Abraham wrote: Zoilo Gomez wrote: Manu Abraham wrote: Zoilo Gomez wrote: Manu Abraham wrote: Michel Verbraak wrote: Manu, list, I was testing DiseqC to control my rotor (Palm H-H 2100A) and because i could not get a scan done I finally pulled my rotor from my roof top and placed it next to the pc. I found the following results: - When I boot my pc and modprobe the mantis module the card powers on. I see a green light lighting up on my rotor. - When I tried the goto position 0 diseqc command I saw my light change from green to red to green. This normal when the command string is send to the rotor ( I do have another card which show the same effect). But the rotor does not change position. - When I tried the goto X diseqc command saw my light change from green to red to green. But the rotor does not change position. The only difference I could see is that the change in colour is faster for the VP-1034 card than my other card a VP-1020a (which is working as it should). I think probably the MB86A16 driver could use some delays in between for communicating with SEC devices. SEC devices are not taht fast in response and hence could possibly be an answer for the problem. Was this ever resolved? I think so, I think Michel got his positioner working a while back. Today I tried to get diseqc running with my VP-1034, to control my Spaun switch, but no success. With a KNC1 DVB-S card diseqc is working fine, switching correctly between different feeds/sats etc. So this seems to point in the direction of a problem with the diseqc implementation in the Mantis driver ... I tried to introduce some msleep_interruptible(100) calls, in particular before and after the 4-byte diseqc command is being sent, but no positive results. Do you get any I2C transaction errors ? No. The diseqc message itself is OK; I verified the message content as it is being written into the registers 0x18-0x1b. Can you paste the logs ? Here you go; I am trying to tune to 10832 H 22000 on the second satellite out of 4, so F6 seems to be the correct diseqc byte. May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x20],Data[0x04] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x16],Data[0x80] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x1e],Data[0x00] May 1 02:12:26 localhost vp1034_set_voltage (0): Polarization=[18v] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x16],Data[0x80] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x1e],Data[0x00] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x20],Data[0x04] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x18],Data[0xe0] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x19],Data[0x10] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x1a],Data[0x38] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x1b],Data[0xf6] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x16],Data[0x94] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x1e],Data[0x01] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x16],Data[0x98] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x1e],Data[0x01] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x20],Data[0x04] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x16],Data[0x80] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x1e],Data[0x00] May 1 02:12:27 localhost mb86a16_set_fe: freq=1082 Mhz, symbrt=22000 Ksps May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x32],Data[0x02] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x06],Data[0xdf] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x0a],Data[0x3d] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x2b],Data[0x00] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x2c],Data[0x00] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x58],Data[0x00] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x59],Data[0x00] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x08],Data[0x16] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x2f],Data[0x21] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x39],Data[0x38] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x3d],Data[0x00] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x3e],Data[0x1c] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x3f],Data[0x20] May 1 02:12:27 localhost mb86a16_write: writing to
Re: [linux-dvb] Mantis and MB86A16 (VP-1034) and DiseqC commands not working.
Hi Manu, Manu Abraham wrote: Zoilo Gomez wrote: Manu Abraham wrote: Zoilo Gomez wrote: Manu Abraham wrote: Zoilo Gomez wrote: Manu Abraham wrote: Michel Verbraak wrote: Manu, list, I was testing DiseqC to control my rotor (Palm H-H 2100A) and because i could not get a scan done I finally pulled my rotor from my roof top and placed it next to the pc. I found the following results: - When I boot my pc and modprobe the mantis module the card powers on. I see a green light lighting up on my rotor. - When I tried the goto position 0 diseqc command I saw my light change from green to red to green. This normal when the command string is send to the rotor ( I do have another card which show the same effect). But the rotor does not change position. - When I tried the goto X diseqc command saw my light change from green to red to green. But the rotor does not change position. The only difference I could see is that the change in colour is faster for the VP-1034 card than my other card a VP-1020a (which is working as it should). I think probably the MB86A16 driver could use some delays in between for communicating with SEC devices. SEC devices are not taht fast in response and hence could possibly be an answer for the problem. Was this ever resolved? I think so, I think Michel got his positioner working a while back. Today I tried to get diseqc running with my VP-1034, to control my Spaun switch, but no success. With a KNC1 DVB-S card diseqc is working fine, switching correctly between different feeds/sats etc. So this seems to point in the direction of a problem with the diseqc implementation in the Mantis driver ... I tried to introduce some msleep_interruptible(100) calls, in particular before and after the 4-byte diseqc command is being sent, but no positive results. Do you get any I2C transaction errors ? No. The diseqc message itself is OK; I verified the message content as it is being written into the registers 0x18-0x1b. Can you paste the logs ? Here you go; I am trying to tune to 10832 H 22000 on the second satellite out of 4, so F6 seems to be the correct diseqc byte. May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x20],Data[0x04] (... log file cut ...) May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x36],Data[0x06] May 1 02:12:27 localhost mb86a16_set_fe: ! No signal !, try again... If the frequency/symbol rate is correct, this does look like a bug (of course this is not relevant to diseqc switching, but can also result from switching positions) Freq+symrate is correct; I tried several freqs / pols / symbol rates on sat=2. I am quite sure that the problem is simple and diseqc related, for the several reasons: = my normal sat receiver is working fine on all 16 sat feeds (4*4) = KNC1 DVB-C is also working fine on all sats / pols / bands; the fact that it is capable to select different sats proves that its diseqc commands are working. = however VP1034 is working only on first satellite (out of 4). This seems to be caused by 18/13V+22kHz signaling (not diseqc), So in fact DiSEqC is not failing for you, but 22k tone for SEC_A/B I think that you are referring to the use of a 22 kHz tone to operate a switch to select between 2 satellite inputs (22 kHz ON/OFF)? I am not using 22k tone, not for SEC_A/B, and also not for band selection. I am using (and in fact must use) DiSEqC 1.0 for my switch to operate properly (OK, DiSEqC uses 22 kHz pulse width modulation, but that is different). Perhaps I haven't explained my setup very well. I have a dish with 4 Quattro LNBs, ie. 16 cables. I use a Spaun 17089NF switch, with 16 inputs and 8 outputs. The switch is controlled by DiSEqC 1.0, and allows to select from 4 sats, 2 pols and 2 bands, i.e. 16 possible combinations = 16 inputs. Inputs are aligned as follows: 1: sat=1 band=low pol=V 2: sat=1 band=low pol=H 3: sat=1 band=high pol=V 4: sat=1 band=high pol=H 5: sat=2 band=low pol=V 6: sat=2 band=low pol=H ... 16: sat=4 band=high pol=H In order to select eg. sat=2/band=low/pol=H (i.e 10832H/22000 on second satellite) the VP1034 should send the following DiSEqC string: e0 10 38 f6, which will select input#6 from the switch as the source (see http://www.eutelsat.com/satellites/pdf/Diseqc/associated%20docs/applic_info_turner-receiver.pdf). I have verified that this the VP1034 is in fact sending (or trying to send) the correct string (see log file in previous email). As mentioned: all of this works fine with KNC1 DVB-S. Also working perfect with any normal sat receiver. But with VP1034 DVB-S it does
Re: [linux-dvb] Mantis and MB86A16 (VP-1034) and DiseqC commands not working.
Manu Abraham wrote:
Freq+symrate is correct; I tried several freqs / pols / symbol rates on
sat=2.
I am quite sure that the problem is simple and diseqc related, for the
several reasons:
= my normal sat receiver is working fine on all 16 sat feeds (4*4)
= KNC1 DVB-C is also working fine on all sats / pols / bands; the fact
that it is capable to select different sats proves that its diseqc
commands are working.
= however VP1034 is working only on first satellite (out of 4). This
seems to be caused by 18/13V+22kHz signaling (not diseqc),
So in fact DiSEqC is not failing for you, but 22k tone for SEC_A/B
I think that you are referring to the use of a 22 kHz tone to operate a
switch to select between 2 satellite inputs (22 kHz ON/OFF)? I am not
using 22k tone, not for SEC_A/B, and also not for band selection.
I am using (and in fact must use) DiSEqC 1.0 for my switch to operate
properly (OK, DiSEqC uses 22 kHz pulse width modulation, but that is
different).
Perhaps I haven't explained my setup very well.
I have a dish with 4 Quattro LNBs, ie. 16 cables. I use a Spaun 17089NF
switch, with 16 inputs and 8 outputs. The switch is controlled by DiSEqC
1.0, and allows to select from 4 sats, 2 pols and 2 bands, i.e. 16
possible combinations = 16 inputs. Inputs are aligned as follows:
1: sat=1 band=low pol=V
2: sat=1 band=low pol=H
3: sat=1 band=high pol=V
4: sat=1 band=high pol=H
5: sat=2 band=low pol=V
6: sat=2 band=low pol=H
...
16: sat=4 band=high pol=H
In order to select eg. sat=2/band=low/pol=H (i.e 10832H/22000 on second
satellite) the VP1034 should send the following DiSEqC string: e0 10 38
f6, which will select input#6 from the switch as the source (see
http://www.eutelsat.com/satellites/pdf/Diseqc/associated%20docs/applic_info_turner-receiver.pdf).
I have verified that this the VP1034 is in fact sending (or trying to
send) the correct string (see log file in previous email).
As mentioned: all of this works fine with KNC1 DVB-S. Also working
perfect with any normal sat receiver.
But with VP1034 DVB-S it does not work; although the driver is logging
the correct DiSEqC string. But in fact it switches to input#2, which has
same pol and band, but is on sat=1. So I wondered how this was possible
if DiSEqC wasn't working at all ... then I found out the reason: the
VP1034 is sending both the appropriate DiSEqC command, and using the
conventional 18/13V+22kHz signaling at the same time. So although DiSEqC
is not working, my switch responds to 18V to select Horizontal
polarization, and the absence of 22 kHz tone to select the lower band.
Selection of the satellite however fails then of course, and apparently
defaults to sat=1. So I end up being connected to input#2 instead of
input#6.
To further verify my assumptions, I connected the VP1034 directly to
input#6 feed (sat=2,low,H) of my Spaun switch, and it works immediately.
This points to a selection problem, and shows that the freq+symrate etc
is correct.
So it seems to me that either DiSEqC functionality is not switched on
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 ...
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. The modulation method
happens to be PWM / 22 kHz, but that is different from 22 kHz tones or
22 kHz bursts.
So in my opinion, it is the 22 kHz PWM that is not working, for whatever
reason. Either there is no DiSEqC output at all, because it is somehow
disabled, or there is a timing problem.
Do you happen to have an oscilloscope? It should be easy to see if a
proper 22 kHz enveloped pulse train is actually being generated, as
defined in the bus_spec.pdf document.
Z.
static int mb86a16_send_diseqc_burst(struct dvb_frontend *fe,
fe_sec_mini_cmd_t burst)
{
struct mb86a16_state *state = fe-demodulator_priv;
switch (burst) {
case SEC_MINI_A:
if (mb86a16_write(state, MB86A16_TONEOUT1, 0x5b) 0)
goto err;
if (mb86a16_write(state, MB86A16_TONEOUT2, 0x00) 0)
goto err;
if (mb86a16_write(state, MB86A16_DCC1, MB86A16_DCC1_DISTA |
MB86A16_DCC1_TBEN |
MB86A16_DCC1_TBO) 0)
Re: [linux-dvb] Mantis and MB86A16 (VP-1034) and DiseqC commands not working.
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) 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 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 ? ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Mantis and MB86A16 (VP-1034) and DiseqC commands not working.
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@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Mantis and MB86A16 (VP-1034) and DiseqC commands not working.
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;
}
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Mantis and MB86A16 (VP-1034) and DiseqC commands not working.
Manu Abraham wrote:
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)
Thank you for your help Manu.
In this form it does not seem to work yet.
Or perhaps one of the other functions (burst, set_tone), that sometimes
use the same registers, is overwriting one of the register settings?
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))
This OR with 0x80 (DISTA); in the previous version it was 0x90 ?
goto err;
return 0;
err:
dprintk(verbose, MB86A16_ERROR, 1, I2C transfer error);
return -EREMOTEIO;
}
May 1 23:42:15 localhost mb86a16_set_tone: SEC TONE OFF
May 1 23:42:15 localhost mb86a16_write: writing to
[0x08],Reg[0x20],Data[0x04]
May 1 23:42:15 localhost mb86a16_write: writing to
[0x08],Reg[0x16],Data[0x80]
May 1 23:42:15 localhost mb86a16_write: writing to
[0x08],Reg[0x1e],Data[0x00]
May 1 23:42:15 localhost vp1034_set_voltage (0): Polarization=[18v]
May 1 23:42:15 localhost mb86a16_write: writing to
[0x08],Reg[0x1e],Data[0x01]
May 1 23:42:15 localhost mb86a16_write: writing to
[0x08],Reg[0x1f],Data[0x5b]
May 1 23:42:15 localhost mb86a16_write: writing to
[0x08],Reg[0x20],Data[0x04]
May 1 23:42:15 localhost mb86a16_write: writing to
[0x08],Reg[0x18],Data[0xe0]
May 1 23:42:15 localhost mb86a16_write: writing to
[0x08],Reg[0x19],Data[0x10]
May 1
Re: [linux-dvb] Mantis and MB86A16 (VP-1034) and DiseqC commands not working.
Zoilo Gomez wrote:
Manu Abraham wrote:
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)
Thank you for your help Manu.
In this form it does not seem to work yet.
Or perhaps one of the other functions (burst, set_tone), that sometimes
use the same registers, is overwriting one of the register settings?
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))
This OR with 0x80 (DISTA); in the previous version it was 0x90 ?
goto err;
return 0;
err:
dprintk(verbose, MB86A16_ERROR, 1, I2C transfer error);
return -EREMOTEIO;
}
May 1 23:42:15 localhost mb86a16_set_tone: SEC TONE OFF
May 1 23:42:15 localhost mb86a16_write: writing to
[0x08],Reg[0x20],Data[0x04]
May 1 23:42:15 localhost mb86a16_write: writing to
[0x08],Reg[0x16],Data[0x80]
May 1 23:42:15 localhost mb86a16_write: writing to
[0x08],Reg[0x1e],Data[0x00]
May 1 23:42:15 localhost vp1034_set_voltage (0): Polarization=[18v]
May 1 23:42:15 localhost mb86a16_write: writing to
[0x08],Reg[0x1e],Data[0x01]
May 1 23:42:15 localhost mb86a16_write: writing to
[0x08],Reg[0x1f],Data[0x5b]
May 1 23:42:15 localhost mb86a16_write: writing to
[0x08],Reg[0x20],Data[0x04]
May 1 23:42:15 localhost mb86a16_write: writing to
[0x08],Reg[0x18],Data[0xe0]
May 1 23:42:15 localhost mb86a16_write: writing to
[0x08],Reg[0x19],Data[0x10]
May 1 23:42:15 localhost mb86a16_write: writing to
Re: [linux-dvb] Mantis and MB86A16 (VP-1034) and DiseqC commands not working.
Manu Abraham wrote:
Zoilo Gomez wrote:
Manu Abraham wrote:
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)
Thank you for your help Manu.
In this form it does not seem to work yet.
Or perhaps one of the other functions (burst, set_tone), that sometimes
use the same registers, is overwriting one of the register settings?
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))
This OR with 0x80 (DISTA); in the previous version it was 0x90 ?
goto err;
return 0;
err:
dprintk(verbose, MB86A16_ERROR, 1, I2C transfer error);
return -EREMOTEIO;
}
May 1 23:42:15 localhost mb86a16_set_tone: SEC TONE OFF
May 1 23:42:15 localhost mb86a16_write: writing to
[0x08],Reg[0x20],Data[0x04]
May 1 23:42:15 localhost mb86a16_write: writing to
[0x08],Reg[0x16],Data[0x80]
May 1 23:42:15 localhost mb86a16_write: writing to
[0x08],Reg[0x1e],Data[0x00]
May 1 23:42:15 localhost vp1034_set_voltage (0): Polarization=[18v]
May 1 23:42:15 localhost mb86a16_write: writing to
[0x08],Reg[0x1e],Data[0x01]
May 1 23:42:15 localhost mb86a16_write: writing to
[0x08],Reg[0x1f],Data[0x5b]
May 1 23:42:15 localhost mb86a16_write: writing to
[0x08],Reg[0x20],Data[0x04]
May 1 23:42:15 localhost mb86a16_write: writing to
[0x08],Reg[0x18],Data[0xe0]
May 1 23:42:15 localhost mb86a16_write:
Re: [linux-dvb] Mantis and MB86A16 (VP-1034) and DiseqC commands not working.
Zoilo Gomez wrote: Manu Abraham wrote: Michel Verbraak wrote: Manu, list, I was testing DiseqC to control my rotor (Palm H-H 2100A) and because i could not get a scan done I finally pulled my rotor from my roof top and placed it next to the pc. I found the following results: - When I boot my pc and modprobe the mantis module the card powers on. I see a green light lighting up on my rotor. - When I tried the goto position 0 diseqc command I saw my light change from green to red to green. This normal when the command string is send to the rotor ( I do have another card which show the same effect). But the rotor does not change position. - When I tried the goto X diseqc command saw my light change from green to red to green. But the rotor does not change position. The only difference I could see is that the change in colour is faster for the VP-1034 card than my other card a VP-1020a (which is working as it should). I think probably the MB86A16 driver could use some delays in between for communicating with SEC devices. SEC devices are not taht fast in response and hence could possibly be an answer for the problem. Was this ever resolved? I think so, I think Michel got his positioner working a while back. Today I tried to get diseqc running with my VP-1034, to control my Spaun switch, but no success. With a KNC1 DVB-S card diseqc is working fine, switching correctly between different feeds/sats etc. So this seems to point in the direction of a problem with the diseqc implementation in the Mantis driver ... I tried to introduce some msleep_interruptible(100) calls, in particular before and after the 4-byte diseqc command is being sent, but no positive results. Do you get any I2C transaction errors ? The diseqc message itself is OK; I verified the message content as it is being written into the registers 0x18-0x1b. Can you paste the logs ? ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Mantis and MB86A16 (VP-1034) and DiseqC commands not working.
Manu Abraham wrote: Zoilo Gomez wrote: Manu Abraham wrote: Michel Verbraak wrote: Manu, list, I was testing DiseqC to control my rotor (Palm H-H 2100A) and because i could not get a scan done I finally pulled my rotor from my roof top and placed it next to the pc. I found the following results: - When I boot my pc and modprobe the mantis module the card powers on. I see a green light lighting up on my rotor. - When I tried the goto position 0 diseqc command I saw my light change from green to red to green. This normal when the command string is send to the rotor ( I do have another card which show the same effect). But the rotor does not change position. - When I tried the goto X diseqc command saw my light change from green to red to green. But the rotor does not change position. The only difference I could see is that the change in colour is faster for the VP-1034 card than my other card a VP-1020a (which is working as it should). I think probably the MB86A16 driver could use some delays in between for communicating with SEC devices. SEC devices are not taht fast in response and hence could possibly be an answer for the problem. Was this ever resolved? I think so, I think Michel got his positioner working a while back. Today I tried to get diseqc running with my VP-1034, to control my Spaun switch, but no success. With a KNC1 DVB-S card diseqc is working fine, switching correctly between different feeds/sats etc. So this seems to point in the direction of a problem with the diseqc implementation in the Mantis driver ... I tried to introduce some msleep_interruptible(100) calls, in particular before and after the 4-byte diseqc command is being sent, but no positive results. Do you get any I2C transaction errors ? No. The diseqc message itself is OK; I verified the message content as it is being written into the registers 0x18-0x1b. Can you paste the logs ? Here you go; I am trying to tune to 10832 H 22000 on the second satellite out of 4, so F6 seems to be the correct diseqc byte. May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x20],Data[0x04] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x16],Data[0x80] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x1e],Data[0x00] May 1 02:12:26 localhost vp1034_set_voltage (0): Polarization=[18v] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x16],Data[0x80] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x1e],Data[0x00] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x20],Data[0x04] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x18],Data[0xe0] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x19],Data[0x10] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x1a],Data[0x38] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x1b],Data[0xf6] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x16],Data[0x94] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x1e],Data[0x01] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x16],Data[0x98] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x1e],Data[0x01] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x20],Data[0x04] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x16],Data[0x80] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x1e],Data[0x00] May 1 02:12:27 localhost mb86a16_set_fe: freq=1082 Mhz, symbrt=22000 Ksps May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x32],Data[0x02] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x06],Data[0xdf] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x0a],Data[0x3d] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x2b],Data[0x00] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x2c],Data[0x00] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x58],Data[0x00] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x59],Data[0x00] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x08],Data[0x16] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x2f],Data[0x21] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x39],Data[0x38] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x3d],Data[0x00] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x3e],Data[0x1c] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x3f],Data[0x20] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x40],Data[0x1e] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x41],Data[0x23] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x54],Data[0xff] May 1 02:12:27 localhost mb86a16_write: writing to
Re: [linux-dvb] Mantis and MB86A16 (VP-1034) and DiseqC commands not working.
Zoilo Gomez wrote: Manu Abraham wrote: Zoilo Gomez wrote: Manu Abraham wrote: Michel Verbraak wrote: Manu, list, I was testing DiseqC to control my rotor (Palm H-H 2100A) and because i could not get a scan done I finally pulled my rotor from my roof top and placed it next to the pc. I found the following results: - When I boot my pc and modprobe the mantis module the card powers on. I see a green light lighting up on my rotor. - When I tried the goto position 0 diseqc command I saw my light change from green to red to green. This normal when the command string is send to the rotor ( I do have another card which show the same effect). But the rotor does not change position. - When I tried the goto X diseqc command saw my light change from green to red to green. But the rotor does not change position. The only difference I could see is that the change in colour is faster for the VP-1034 card than my other card a VP-1020a (which is working as it should). I think probably the MB86A16 driver could use some delays in between for communicating with SEC devices. SEC devices are not taht fast in response and hence could possibly be an answer for the problem. Was this ever resolved? I think so, I think Michel got his positioner working a while back. Today I tried to get diseqc running with my VP-1034, to control my Spaun switch, but no success. With a KNC1 DVB-S card diseqc is working fine, switching correctly between different feeds/sats etc. So this seems to point in the direction of a problem with the diseqc implementation in the Mantis driver ... I tried to introduce some msleep_interruptible(100) calls, in particular before and after the 4-byte diseqc command is being sent, but no positive results. Do you get any I2C transaction errors ? No. The diseqc message itself is OK; I verified the message content as it is being written into the registers 0x18-0x1b. Can you paste the logs ? Here you go; I am trying to tune to 10832 H 22000 on the second satellite out of 4, so F6 seems to be the correct diseqc byte. May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x20],Data[0x04] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x16],Data[0x80] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x1e],Data[0x00] May 1 02:12:26 localhost vp1034_set_voltage (0): Polarization=[18v] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x16],Data[0x80] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x1e],Data[0x00] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x20],Data[0x04] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x18],Data[0xe0] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x19],Data[0x10] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x1a],Data[0x38] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x1b],Data[0xf6] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x16],Data[0x94] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x1e],Data[0x01] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x16],Data[0x98] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x1e],Data[0x01] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x20],Data[0x04] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x16],Data[0x80] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x1e],Data[0x00] May 1 02:12:27 localhost mb86a16_set_fe: freq=1082 Mhz, symbrt=22000 Ksps May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x32],Data[0x02] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x06],Data[0xdf] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x0a],Data[0x3d] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x2b],Data[0x00] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x2c],Data[0x00] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x58],Data[0x00] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x59],Data[0x00] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x08],Data[0x16] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x2f],Data[0x21] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x39],Data[0x38] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x3d],Data[0x00] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x3e],Data[0x1c] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x3f],Data[0x20] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x40],Data[0x1e] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x41],Data[0x23] May 1 02:12:27 localhost mb86a16_write:
Re: [linux-dvb] Mantis and MB86A16 (VP-1034) and DiseqC commands not working.
Manu Abraham wrote: Zoilo Gomez wrote: Manu Abraham wrote: Zoilo Gomez wrote: Manu Abraham wrote: Michel Verbraak wrote: Manu, list, I was testing DiseqC to control my rotor (Palm H-H 2100A) and because i could not get a scan done I finally pulled my rotor from my roof top and placed it next to the pc. I found the following results: - When I boot my pc and modprobe the mantis module the card powers on. I see a green light lighting up on my rotor. - When I tried the goto position 0 diseqc command I saw my light change from green to red to green. This normal when the command string is send to the rotor ( I do have another card which show the same effect). But the rotor does not change position. - When I tried the goto X diseqc command saw my light change from green to red to green. But the rotor does not change position. The only difference I could see is that the change in colour is faster for the VP-1034 card than my other card a VP-1020a (which is working as it should). I think probably the MB86A16 driver could use some delays in between for communicating with SEC devices. SEC devices are not taht fast in response and hence could possibly be an answer for the problem. Was this ever resolved? I think so, I think Michel got his positioner working a while back. Today I tried to get diseqc running with my VP-1034, to control my Spaun switch, but no success. With a KNC1 DVB-S card diseqc is working fine, switching correctly between different feeds/sats etc. So this seems to point in the direction of a problem with the diseqc implementation in the Mantis driver ... I tried to introduce some msleep_interruptible(100) calls, in particular before and after the 4-byte diseqc command is being sent, but no positive results. Do you get any I2C transaction errors ? No. The diseqc message itself is OK; I verified the message content as it is being written into the registers 0x18-0x1b. Can you paste the logs ? Here you go; I am trying to tune to 10832 H 22000 on the second satellite out of 4, so F6 seems to be the correct diseqc byte. May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x20],Data[0x04] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x16],Data[0x80] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x1e],Data[0x00] May 1 02:12:26 localhost vp1034_set_voltage (0): Polarization=[18v] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x16],Data[0x80] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x1e],Data[0x00] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x20],Data[0x04] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x18],Data[0xe0] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x19],Data[0x10] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x1a],Data[0x38] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x1b],Data[0xf6] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x16],Data[0x94] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x1e],Data[0x01] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x16],Data[0x98] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x1e],Data[0x01] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x20],Data[0x04] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x16],Data[0x80] May 1 02:12:26 localhost mb86a16_write: writing to [0x08],Reg[0x1e],Data[0x00] May 1 02:12:27 localhost mb86a16_set_fe: freq=1082 Mhz, symbrt=22000 Ksps May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x32],Data[0x02] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x06],Data[0xdf] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x0a],Data[0x3d] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x2b],Data[0x00] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x2c],Data[0x00] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x58],Data[0x00] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x59],Data[0x00] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x08],Data[0x16] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x2f],Data[0x21] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x39],Data[0x38] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x3d],Data[0x00] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x3e],Data[0x1c] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x3f],Data[0x20] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x40],Data[0x1e] May 1 02:12:27 localhost mb86a16_write: writing to [0x08],Reg[0x41],Data[0x23] May 1 02:12:27 localhost
