Re: [vdr] [ANNOUNCE] vdr-rotor support patches for VDR-1.5.16
Hi,
I haven't been able to make rotor plugin work with the multiproto
driver. I created dummy channel entries that have tone off (f 11700)
into beginning of each satellite position group in my channels.conf and
now zapping with rotor plugin by pressing ok and then and keys works
with 100% success. I have been looking at rotor plugin and didn't get
idea how switching off tone could be syncronized to tuning and
diseqc.conf sequences without possible negative influence to tuning. Or
is there a guarantee for some order of execution? I wonder if it worked
with the existing Linux kernel DVB-S driver with just good luck.
Wouldn't it be better to have in diseqc.conf possibility for this kind
of setup
S19.2E 11700 V 9750 t V W15 G W15 v t
S19.2E 9 V 10600 t V W15 G W15 v T
S19.2E 11700 H 9750 t V W15 G W15 V t
S19.2E 9 H 10600 t V W15 G W15 V T
where the continuous tone is first switched off, then LNB voltage is set
to 18V for better rotor speed and then GotoX is sent with internal
computation based on new position and geographic location, etc (to be
added to vdr setup, e.g. LNB diseqc config page). There could blind be
waiting of positioning inside G operation with estimate about rotor
speed to avoid temporary tuning to intermediate positions. Finally the
proper tone and voltage is set. This way there would be exact control
when GotoX is issued. It would be possible to enable EIT scan and
channel/multiplex updates with rotor without fear that it messes up
channels.conf. With some more thinking the t V W15 and W15 should
perhaps be put inside G.
This could be done by utilizing code from rotor plugin this into dvbdevice.c
if (frontendType (DVBFE_DELSYS_DVBS | DVBFE_DELSYS_DVBS2)) {
unsigned int frequency = channel.Frequency();
if (Setup.DiSEqC) {
cDiseqc *diseqc = Diseqcs.Get(channel.Source(),
channel.Frequency(), channel.Polarization());
if (diseqc) {
if (diseqc-Commands() (!diseqcCommands ||
strcmp(diseqcCommands, diseqc-Commands()) != 0)) {
cDiseqc::eDiseqcActions da;
for (char *CurrentAction = NULL; (da =
diseqc-Execute(CurrentAction)) != cDiseqc::daNone; ) {
switch (da) {
case cDiseqc::daNone: break;
case cDiseqc::daToneOff: CHECK(ioctl(fd_frontend,
FE_SET_TONE, SEC_TONE_OFF)); break;
case cDiseqc::daToneOn:CHECK(ioctl(fd_frontend,
FE_SET_TONE, SEC_TONE_ON)); break;
case cDiseqc::daVoltage13: CHECK(ioctl(fd_frontend,
FE_SET_VOLTAGE, SEC_VOLTAGE_13)); break;
case cDiseqc::daVoltage18: CHECK(ioctl(fd_frontend,
FE_SET_VOLTAGE, SEC_VOLTAGE_18)); break;
case cDiseqc::daMiniA: CHECK(ioctl(fd_frontend,
FE_DISEQC_SEND_BURST, SEC_MINI_A)); break;
case cDiseqc::daMiniB: CHECK(ioctl(fd_frontend,
FE_DISEQC_SEND_BURST, SEC_MINI_B)); break;
case cDiseqc::daGotoX: {
...
int gotoXTable[10] = { 0x00, 0x02, 0x03, 0x05, 0x06, 0x08,
0x0A, 0x0B, 0x0D, 0x0E };
int satlong = (Source ~0xC800);
if ((Source 0xC000) != 0x8000)
return;
if (Source 0x0800)
satlong = satlong * (-1);
int Long=data.GotoxEW ? -data.GotoxLong : data.GotoxLong;
int Lat=data.GotoxSN ? -data.GotoxLat : data.GotoxLat;
double
azimuth=M_PI+atan(tan((satlong-Long)*M_PI/1800)/sin(Lat*M_PI/1800));
double
x=acos(cos((satlong-Long)*M_PI/1800)*cos(Lat*M_PI/1800));
double elevation=atan((cos(x)-0.1513)/sin(x));
double
SatHourangle=180+atan((-cos(elevation)*sin(azimuth))/(sin(elevation)*cos(Lat*M_PI/1800)
-cos(elevation)*sin(Lat*M_PI/1800)*cos(azimuth)))*180/M_PI;
int tmp=(int)(fabs(180-SatHourangle)*10);
tmp=(tmp/10)*0x10 + gotoXTable[ tmp % 10 ];
int p2=(tmp%0x0100);
int p1=(tmp/0x0100);
if (SatHourangle 180)
p1 |= 0xe0;
else
p1 |= 0xd0;
DiseqcCommand(Gotox,p1,p2);
}
...
break;
But as vdr illiterate I couldn't figure how to check if the zapped
source (diseqc-source?) is a new one to avoid generating unnecessary
DiSEqC traffic and delays, and wondered to get a global variable for
storing the previous position... help!
Or does this make sense?
Cheers,
Seppo
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-rotor support patches for VDR-1.5.16
On Friday 07 of March 2008, Seppo Ingalsuo wrote: But as vdr illiterate I couldn't figure how to check if the zapped source (diseqc-source?) is a new one to avoid generating unnecessary DiSEqC traffic and delays, and wondered to get a global variable for storing the previous position... help! This seems to be already checked in status.c. I've used debug message to show all diseqc commands send and it seems to work fine (for me). BR, Ales ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-rotor support patches for VDR-1.5.16
On Wednesday 05 of March 2008, Seppo Ingalsuo wrote: I couldn't repeat that but I didn't find exactly that multiproto driver. Hi, I'm testing it with this one - http://jusst.de/hg/multiproto/archive/4df151d5b3fe.tar.bz2. I've only changed some print and debug options in my tests. But I noticed that zapping works reliably with between channels in different positions with LNB tone off (frequency 11700, if I got this right...). V/H polarization didn't matter (13V or 18V LNB voltage). There should be 15 ms tone off between DiSEqC messages and continuous tone that might not happen with rotor plugin and this DVB driver. I wonder if that could be the reason? Yes, my fault - I've switched between satellites only on lower band. But with newest version of multiproto also this was not possible. But I'm using it with cascade switch/motor, so my tests could have different results. BR, Ales ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-rotor support patches for VDR-1.5.16
Ales Jurik wrote: My result is that the problem with stucked motor appears with new multiproto driver. When I'm using multiproto from 21.12. no problem appears at all. I couldn't repeat that but I didn't find exactly that multiproto driver. But I noticed that zapping works reliably with between channels in different positions with LNB tone off (frequency 11700, if I got this right...). V/H polarization didn't matter (13V or 18V LNB voltage). There should be 15 ms tone off between DiSEqC messages and continuous tone that might not happen with rotor plugin and this DVB driver. I wonder if that could be the reason? I wish the GotoX would be better integrated to vdr's DiSEqC architecture. Now it looks a bit flaky, rotor plugin seems to monitor channel switch events in status.c. I wonder if additing tone off controls around gotox transmission would have impact to tuning where tone and voltage are set? BR, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-rotor support patches for VDR-1.5.16
Hi, Seppo Ingalsuo schrieb: the attached patch replaces the previously released but incomplete patch for VDR-1.5.14, which was part of my recent rotor support patches. You have to apply this patch after patching VDR-1.5.16 with DVB-S2+H.264 support. Do you get this error when compiling rotor plugin (vdr-rotor-0.1.4-vdr1.5.7.tgz)? As mentioned above, you'll need an updated vdr-rotor too (see attachment), which makes use of the new API. As a brutal fix I added dummy parameters (zeros, copy language strings, etc.) for SetSatTransponderData() and SetPids() calls to get it compiled. I appreciate a real correction if such exists ;^) Well, 0 is not a good dummy value in case of the multiproto tree, but the attached vdr-rotor should solve this issue. I'm having problems in getting my diseqc motor positioner to work with multiproto+h.264 patched vdr 1.5.16. It is at the moment very unreliable. Most of the time it just stays stuck into the old position so possibly the commands get corrupted. Is a Technotrend S2-3200 capable to control a positioner? My old budget-s Tecnotrend was very reliable in driving the same positioner. Hhm, as I do not own a positioner myself, I cannot test vdr-rotor in practice. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] vdr-rotor-0.1.4-vdr-1.5.14.tgz Description: GNU Unix tar archive ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-rotor support patches for VDR-1.5.16
First, thanks for your vdr patches and all the work with xine-lib! Reinhard Nissl wrote: the attached patch replaces the previously released but incomplete patch for VDR-1.5.14, which was part of my recent rotor support patches. You have to apply this patch after patching VDR-1.5.16 with DVB-S2+H.264 support. Do you get this error when compiling rotor plugin (vdr-rotor-0.1.4-vdr1.5.7.tgz)? g++-4.3 -O2 -Wall -Woverloaded-virtual -Wno-parentheses -fPIC -c -D_GNU_SOURCE -DPLUGIN_NAME_I18N='rotor' -I/home/seppo/src/dvb/multiproto-0448e5a6d8a6/linux/include -I../../..//include -I/home/seppo/src/dvb/multiproto-0448e5a6d8a6/linux/include menu.c menu.c: In member function 'virtual eOSState cMainMenuRotor::ProcessKey(eKeys)': menu.c:304: error: no matching function for call to 'cChannel::SetSatTransponderData(int, int, char, int, fe_code_rate)' ../../..//include/vdr/channels.h:226: note: candidates are: bool cChannel::SetSatTransponderData(int, int, char, int, int, int, int, int) menu.c:316: error: no matching function for call to 'cChannel::SetSatTransponderData(int, int, char, int, fe_code_rate)' ../../..//include/vdr/channels.h:226: note: candidates are: bool cChannel::SetSatTransponderData(int, int, char, int, int, int, int, int) menu.c: In member function 'void cMenuScan::AddChannel(int)': menu.c:429: error: no matching function for call to 'cChannel::SetPids(int, int, int [33], char [33][8], int [17], char [17][8], int)' ../../..//include/vdr/channels.h:232: note: candidates are: void cChannel::SetPids(int, int, int*, char (*)[8], int*, char (*)[8], int*, char (*)[8], int) menu.c: In member function 'void cMenuScan::SetPids(int, int, int, int*, char (*)[8], int*, char (*)[8], int)': menu.c:467: error: no matching function for call to 'cChannel::SetPids(int, int, int*, char (*)[8], int*, char (*)[8], int)' ../../..//include/vdr/channels.h:232: note: candidates are: void cChannel::SetPids(int, int, int*, char (*)[8], int*, char (*)[8], int*, char (*)[8], int) make[1]: *** [menu.o] Error 1 As a brutal fix I added dummy parameters (zeros, copy language strings, etc.) for SetSatTransponderData() and SetPids() calls to get it compiled. I appreciate a real correction if such exists ;^) I'm having problems in getting my diseqc motor positioner to work with multiproto+h.264 patched vdr 1.5.16. It is at the moment very unreliable. Most of the time it just stays stuck into the old position so possibly the commands get corrupted. Is a Technotrend S2-3200 capable to control a positioner? My old budget-s Tecnotrend was very reliable in driving the same positioner. BR, Seppo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
