Re: [vdr] RFC: one or many positioners?
On 04/27/2013 04:58 PM, Klaus Schmidinger wrote: ... Of course with chance of source choosing (if more than one tuner is used). I don't understand what you mean here. I thought about the possibility from diseqc.conf: # A line containing space separated integer numbers, terminated with a ':', # defines that any following DiSEqC sequences apply only to the given list # of device numbers. But I'm afraid that this remark was not unnecessary, sry. My second wish is to have possibility to use the new syntax on all tuners available, so only gotoxx command will be send to the/all tuner, to allow simple cooperation with intelligent vtuner devices like NessieDVB. I'm afraid I don't understand this, either. Can you be more specific? I thought about possibility to send gotoxx command to all tuners/cards used, not only to the one which has positioner connected. In this case only gotoxx command should be used in all cases - I don't know if only one new entry in diseqc.conf like * 11700 V 9750 t V W15 P W15 v t * 9 V 10600 t V W15 P W15 v T * 11700 H 9750 t V W15 P W15 V t * 9 H 10600 t V W15 P W15 V T valid for all tuners/cards will be enough. Thanks, Best Regards, Ales ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RFC: one or many positioners?
On 22.04.2013 20:56, Lars Hanisch wrote:
Am 22.04.2013 14:28, schrieb Klaus Schmidinger:
...
or even
virtual void Drive(bool Left) {}// true = left, false = right
virtual void Step(int Steps) {} // <0 = left, >0 = right
virtual void SetLimit(bool Left) {} // true = left, false = right
?
If you would go this way, I would prefer an enum as parameter, because it's
easier to use and the code is easier to
understand. You don't have to remember if true is left or right. :)
"Step" would than have two parameters, the enum and an uint.
Well, I guess especially with the Step() function it could have been nice
to have the sign indicate the direction. But then again VDR itself probably
isn't going to use Step() with anything else but '1', so
enum ePositionerDirection { pdLeft, pdRight };
virtual void Step(ePositionerDirection Direction, uint NumSteps = 1);
should do just fine...
Klaus
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RFC: one or many positioners?
On 23.04.2013 13:34, Ales Jurik wrote: On 04/23/2013 01:08 PM, Klaus Schmidinger wrote: ... I'm also thinking of allowing something in the form of * 11700 V 9750 t V W15 [E0 10 38 F0] W15 P * 9 V 10600 t V W15 [E0 10 38 F1] W15 P * 11700 H 9750 t V W15 [E0 10 38 F2] W15 P * 9 H 10600 t V W15 [E0 10 38 F3] W15 P (note the '*' instead of, e.g., 'S19.2E'), which could be a shortcut for a (USALS) positioner that could receive any satellite (as long as it's above the horizon). Klaus Hi Klaus, please could it be possible to have functionality of diseqc.conf which allows simple combining of fixed LNB's and motorized dish, so the will it be possible to have in diseqc.conf standard entries like S19.2E 11700 V 9750 t v W15 [E0 10 38 F0] W15 A W15 t S19.2E 9 V 10600 t v W15 [E0 10 38 F1] W15 A W15 T S19.2E 11700 H 9750 t V W15 [E0 10 38 F2] W15 A W15 t S19.2E 9 H 10600 t V W15 [E0 10 38 F3] W15 A W15 T followed with the new syntax one * 11700 V 9750 t V W15 [E0 10 38 FC] W15 P * 9 V 10600 t V W15 [E0 10 38 FD] W15 P * 11700 H 9750 t V W15 [E0 10 38 FE] W15 P * 9 H 10600 t V W15 [E0 10 38 FF] W15 P and the standard entries will be prioritized? This will allow to use fixed LNB's as preferable ones in combined diseqc installation. I'm planning to do it that way. Of course with chance of source choosing (if more than one tuner is used). I don't understand what you mean here. My second wish is to have possibility to use the new syntax on all tuners available, so only gotoxx command will be send to the/all tuner, to allow simple cooperation with intelligent vtuner devices like NessieDVB. I'm afraid I don't understand this, either. Can you be more specific? Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RFC: one or many positioners?
On 04/23/2013 01:08 PM, Klaus Schmidinger wrote: ... I'm also thinking of allowing something in the form of * 11700 V 9750 t V W15 [E0 10 38 F0] W15 P * 9 V 10600 t V W15 [E0 10 38 F1] W15 P * 11700 H 9750 t V W15 [E0 10 38 F2] W15 P * 9 H 10600 t V W15 [E0 10 38 F3] W15 P (note the '*' instead of, e.g., 'S19.2E'), which could be a shortcut for a (USALS) positioner that could receive any satellite (as long as it's above the horizon). Klaus Hi Klaus, please could it be possible to have functionality of diseqc.conf which allows simple combining of fixed LNB's and motorized dish, so the will it be possible to have in diseqc.conf standard entries like S19.2E 11700 V 9750 t v W15 [E0 10 38 F0] W15 A W15 t S19.2E 9 V 10600 t v W15 [E0 10 38 F1] W15 A W15 T S19.2E 11700 H 9750 t V W15 [E0 10 38 F2] W15 A W15 t S19.2E 9 H 10600 t V W15 [E0 10 38 F3] W15 A W15 T followed with the new syntax one * 11700 V 9750 t V W15 [E0 10 38 FC] W15 P * 9 V 10600 t V W15 [E0 10 38 FD] W15 P * 11700 H 9750 t V W15 [E0 10 38 FE] W15 P * 9 H 10600 t V W15 [E0 10 38 FF] W15 P and the standard entries will be prioritized? This will allow to use fixed LNB's as preferable ones in combined diseqc installation. Of course with chance of source choosing (if more than one tuner is used). My second wish is to have possibility to use the new syntax on all tuners available, so only gotoxx command will be send to the/all tuner, to allow simple cooperation with intelligent vtuner devices like NessieDVB. Thanks, Best Regards, Ales ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RFC: one or many positioners?
Al 23/04/13 12:41, En/na Klaus Schmidinger ha escrit: >> >> So maybe it should be better called "SetCurrentPosition" > > The specs on the 0x6F command are a little vague. > What do you suggest should be sent to a DiSEqC rotor? > Something like > > 6F nn 00 00 > > where 'nn' is the number of the satellite position the dish currently > actually points to? I have no idea about DiSEqC rotors, sorry, I just drive a couple of relays and count the pulses myself (well, actually my device driver/plugin) but it seems such a basic functionality to me that I'd be surprised if it isn't there. A google search found this http://www.dvbviewer.tv/forum/topic/46086-positioner-console-re-calculate-command/ Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RFC: one or many positioners?
On 22.04.2013 18:12, Füley István wrote: On 2013.04.21. 15:54, Klaus Schmidinger wrote: (...) The question I have now is: will it be enough to have *one* single positioner in any given setup, or are there actually users who have more than one positioner? (...) Klaus Currently I have 4 tuners, each of them is connected to several satellite positions via Diseqc 10/1 switches (i have quad LNBs and one LNB on a motorized dish). The configuration is defined in diseqc.conf, and believe me, it wasn't easy to set it up :) Will the rotor implementation change the syntax of diseqc.conf and if yes, will the new syntax be backward compatible with the current one? The syntax of the diseqc.conf will of course remain compatible, so that existing setups will work unchanged. There will just be one additional control character (presumably 'P' for "Position"). If it is followed by a number, as in S19.2E 11700 V 9750 t V W15 [E0 10 38 F0] W15 P1 S19.2E 9 V 10600 t V W15 [E0 10 38 F1] W15 P1 S19.2E 11700 H 9750 t V W15 [E0 10 38 F2] W15 P1 S19.2E 9 H 10600 t V W15 [E0 10 38 F3] W15 P1 then GotoPosition() will be called with that number. If there is no number, GotoAngle() will be called with the satellite's longitude. I'm also thinking of allowing something in the form of * 11700 V 9750 t V W15 [E0 10 38 F0] W15 P * 9 V 10600 t V W15 [E0 10 38 F1] W15 P * 11700 H 9750 t V W15 [E0 10 38 F2] W15 P * 9 H 10600 t V W15 [E0 10 38 F3] W15 P (note the '*' instead of, e.g., 'S19.2E'), which could be a shortcut for a (USALS) positioner that could receive any satellite (as long as it's above the horizon). Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RFC: one or many positioners?
On 22.04.2013 13:30, Luca Olivetti wrote: Al 22/04/13 11:12, En/na Klaus Schmidinger ha escrit: virtual void Recalc(int Number) /// What would this actually be good for? Imagine that the dish moved but the counter didn't work, or simply there's some slack accumulated, so the actual position and the registered position differ. Without this method you should store each of the already stored position, with a Recalc method, positioning to one know good satellite would be enough, since the relatives positions would still be good. Actually, the description is wrong, as the effect would be "You, positioner, now are at this position", so it would be something like "Set as your current position the position specified by Number" (or longitude if you prefer) So maybe it should be better called "SetCurrentPosition" The specs on the 0x6F command are a little vague. What do you suggest should be sent to a DiSEqC rotor? Something like 6F nn 00 00 where 'nn' is the number of the satellite position the dish currently actually points to? Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RFC: one or many positioners?
Better to support multi-positioners. Makes options much more flexible. On 4/21/2013 5:54 AM, Klaus Schmidinger wrote: I'm currently implementing support for steerable dishes, loosely based on https://linuxtv.org/patch/12911. In doing so, I'm defining a virtual base class cPositioner, which defines all the functions necessary to control the positioner. An implementation of cDiseqcPositioner will allow control of "DiSEqC 1.2" and "USALS" motors. A plugin can derive from cPositioner and implement its very own way of controlling a positioner (like through a serial or USB port or whatever). The question I have now is: will it be enough to have *one* single positioner in any given setup, or are there actually users who have more than one positioner? Supporting only a single positioner (as is done in the aforementioned patch) of course simplifies things quite a bit. So I wouldn't want to add this level of complexity unless there is a real need for it. Any opinions? Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RFC: one or many positioners?
Am 22.04.2013 14:28, schrieb Klaus Schmidinger:
>...
> or even
>
> virtual void Drive(bool Left) {}// true = left, false = right
> virtual void Step(int Steps) {} // <0 = left, >0 = right
> virtual void SetLimit(bool Left) {} // true = left, false = right
>
> ?
If you would go this way, I would prefer an enum as parameter, because it's
easier to use and the code is easier to
understand. You don't have to remember if true is left or right. :)
"Step" would than have two parameters, the enum and an uint.
Regards,
Lars.
>
> Klaus
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RFC: one or many positioners?
On 2013.04.21. 15:54, Klaus Schmidinger wrote: (...) The question I have now is: will it be enough to have *one* single positioner in any given setup, or are there actually users who have more than one positioner? (...) Klaus Currently I have 4 tuners, each of them is connected to several satellite positions via Diseqc 10/1 switches (i have quad LNBs and one LNB on a motorized dish). The configuration is defined in diseqc.conf, and believe me, it wasn't easy to set it up :) Will the rotor implementation change the syntax of diseqc.conf and if yes, will the new syntax be backward compatible with the current one? thanks, István ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RFC: one or many positioners?
On Mon, Apr 22, 2013 at 5:33 AM, Klaus Schmidinger wrote: >> I think I would be interested to have possibility for multiple positioners >> later, if VDR would only support it. > > There doesn't seem to be such a big demand for multiple positioners, > so I guess I'll take the easy way and assume there is only one. For the sake of future-proofing, maybe the motor stuff can be added in such a way that it wouldn't take a total rewrite to support multi-motor setups in the event it's decided later on such support would be advantageous. Since motor support is finally arriving, we don't want to undershoot (although single motor setups certainly seem like the easy majority). Another consideration is what setups will look like once VDR advances into server/client design. Will those setups be more likely to have multiple motors? I dunno, but it's worth asking imo. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RFC: one or many positioners?
Al 22/04/13 14:28, En/na Klaus Schmidinger ha escrit:
> So what do you folks think?
I don't have any preference wrt Left/Right East/West.
My last (and only) set top box with integrated positioner was analogue
and used East/West, but I don't remember if it had any provision for the
southern hemisphere (I suppose you could just reverse the polarity of
the motor). Hey, it also had skew control :-)
But..
> virtual void Drive(bool Left) {}// true = left, false = right
> virtual void Step(int Steps) {} // <0 = left, >0 = right
> virtual void SetLimit(bool Left) {} // true = left, false = right
I do like this one (less cluttered interface)
Bye
--
Luca
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RFC: one or many positioners?
On 22.04.2013 13:38, Antti Hartikainen wrote: ... I think I would be interested to have possibility for multiple positioners later, if VDR would only support it. There doesn't seem to be such a big demand for multiple positioners, so I guess I'll take the easy way and assume there is only one. Currently I have only one dish, which is motorised. There I have a Quad LNB. VDR has three DVB-S2 tuners (+ unrelated DVB-T(2) tuners). Tuner 1: Connected directly to LNB Tuner 2: Connected directly to LNB Tuner 3: Connected to LNB via motor I'll see what I can do to make it work with several devices connected to the same movable dish. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RFC: one or many positioners?
On 22.04.2013 13:35, Luca Olivetti wrote: Al 22/04/13 11:11, En/na Klaus Schmidinger ha escrit: I'd suggest a parameter with the number of steps to move (and for "step" I mean a "pulse", not the next/previous stored satellite position). I don't see the need for a "number of steps". Well, I use it from time to time. Say I move step by step to the west and, after e.g. 5 steps, I discover the signal is getting worse. Instead of hitting 5 times StepEast, I position over the "x steps east" soft button, push 5 on the remote, push ok and I'm at the starting position. Better yet, I move 10 steps east at once to try if going to the other side improves things or not. OK, I'll change the interface accordingly. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RFC: one or many positioners?
On 22.04.2013 12:37, Mike Booth wrote:
I have two positioners one for a ku dish and a second for a C Band dish.
The general desire for multiple positioners appears to be rather
low, so I guess I won't do the extra work to handle such cases.
Would it be possibles to cater for the southern hemispere by a switch.
Your East is my West.
It was probably a bad idea of the rotor manufacturers to use the terms
"east" and "west" in the first place ;-) They should rather have used
"left" and "right" (as seen from behind the dish). However, if VDR starts
using left/right instead of east/west, it might just cause more confusion
than it helps. On the other hand, at the cPositioner level left/right
sure would make much more sense, because it is independent of the site's
latitude.
So what do you folks think?
Should I change
virtual void DriveEast(void) {}
virtual void DriveWest(void) {}
virtual void StepEast(int Steps = 1) {}
virtual void StepWest(int Steps = 1) {}
virtual void SetLimitEast(void) {}
virtual void SetLimitWest(void) {}
to
virtual void DriveLeft(void) {}
virtual void DriveRight(void) {}
virtual void StepLeft(int Steps = 1) {}
virtual void StepRight(int Steps = 1) {}
virtual void SetLimitLeft(void) {}
virtual void SetLimitRight(void) {}
or even
virtual void Drive(bool Left) {}// true = left, false = right
virtual void Step(int Steps) {} // <0 = left, >0 = right
virtual void SetLimit(bool Left) {} // true = left, false = right
?
Klaus
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RFC: one or many positioners?
On Mon, Apr 22, 2013 at 11:46:34AM +0300, Teemu Suikki wrote:
> 2013/4/21 Klaus Schmidinger :
> > I'm currently implementing support for steerable dishes, loosely based
> > on https://linuxtv.org/patch/12911. In doing so, I'm defining a virtual
> > base class cPositioner, which defines all the functions necessary to
> > control the positioner. An implementation of cDiseqcPositioner will
> > allow control of "DiSEqC 1.2" and "USALS" motors. A plugin can derive
> > from cPositioner and implement its very own way of controlling a
> > positioner (like through a serial or USB port or whatever).
> >
> > The question I have now is: will it be enough to have *one* single
> > positioner
> > in any given setup, or are there actually users who have more than one
> > positioner?
> > Supporting only a single positioner (as is done in the aforementioned patch)
> > of course simplifies things quite a bit. So I wouldn't want to add this
> > level of complexity unless there is a real need for it.
Thank you Klaus for working on the positioner support. :)
> Hmm, I guess most only have single positioner. But this might change
> if VDR actually supported more than one. :)
>
> However, it would be nice to be able to use twin or quad LNB in
> positioner, even if using diseqc switches.. I have no idea how to
> configure this. :)
>
> An example, my system has four tuners. Each one has 4-to-1 diseqc
> switch. They are configured like this:
>
> ...
>
> My positioner actually has twin LNB. I'd like to connect the other
> output to tuner2 input 2, but there is no way this would work even
> with heavy patching of VDR..
I think I would be interested to have possibility for multiple positioners
later, if VDR would only support it.
Currently I have only one dish, which is motorised. There I have a Quad LNB.
VDR has three DVB-S2 tuners (+ unrelated DVB-T(2) tuners).
Tuner 1: Connected directly to LNB
Tuner 2: Connected directly to LNB
Tuner 3: Connected to LNB via motor
Tuner 3 is used for motor control only, no actual signal is being received
there, even it would be and is possible, but this tuner is horrible with weak
transponders, yet it's the only tuner I have that can supply 18V to motor+LNB.
I have made VEEERY ugly patching to VDR (as I'm not really a software developer
and don't know how things should be done, and I have done some unnecessary
things
"just in case"), but I think sharing it will give some people some ideas. But
atleast it is working perfectly in my environemnt. :) I don't know what kind of
unwanted things it may cause elsewhere.
So basicly what I did, I took fd_frontend of tuner 3 (identified by
subsystemId), and use it as dfd_frontend. Then I made some changes to device
bonding, to
restrict devices to same satellite source, instead of same band/polarisation.
All devices are set in VDR configuration to "connected to cable 1".
And there I have it, somehow working motorised multi-tuner setup. :)
Patch assumes that VDR is patched with GOTOXX patch.
--- vdr-2.0.0/dvbdevice.c 2013-03-31 13:13:32.081458741 +0300
+++ vdr-1.7.40/dvbdevice.c 2013-03-31 13:26:33.260190854 +0300
@@ -23,6 +23,9 @@
#include "menuitems.h"
#include "sourceparams.h"
+int dfd_frontend=0;
+int adap=0;
+
#if (DVB_API_VERSION << 8 | DVB_API_VERSION_MINOR) < 0x0508
#define DTV_STREAM_ID DTV_DVBT2_PLP_ID
#define FE_CAN_MULTISTREAM 0x400
@@ -344,8 +347,19 @@
device = Device;
fd_frontend = Fd_Frontend;
adapter = Adapter;
+ printf("adapter: %i\n",adapter);
+
+// if(adapter==4&&dfd_frontend<=0) { dfd_frontend=fd_frontend;
printf("dfd_frontend set to %i\n",dfd_frontend); }
frontend = Frontend;
subsystemId = cDvbDeviceProbe::GetSubsystemId(adapter, frontend);
+// printf("device: %d\n",device);
+// printf("subsystemId: %08X\n",subsystemId);
+// if(0x13C2300A==subsystemId) {
+ if(0xD4649022==subsystemId) {
+//adap++;
+//if(adap==2)
+ dfd_frontend=fd_frontend; printf("dfd_frontend set to %i\n",dfd_frontend);
+ }
tuneTimeout = 0;
lockTimeout = 0;
lastTimeoutReport = 0;
@@ -414,7 +428,10 @@
cDvbTransponderParameters dtp(Channel->Parameters());
if (Setup.DiSEqC) {
if (const cDiseqc *diseqc = Diseqcs.Get(device->CardIndex() + 1,
Channel->Source(), Channel->Frequency(), dtp.Polarization(), NULL))
-return diseqc->Commands();
+ printf("returning %i\n",Channel->Source());
+return cString::sprintf("%i",Channel->Source());
+//return 0;
}
else {
bool ToneOff = Channel->Frequency() < Setup.LnbSLOF;
@@ -765,6 +777,8 @@
{
if (!lnbPowerTurnedOn) {
CHECK(ioctl(fd_frontend, FE_SET_VOLTAGE, SEC_VOLTAGE_13)); // must
explicitly turn on LNB power
+ if(dfd_frontend!=fd_frontend)
+ CHECK(ioctl(dfd_frontend, FE_SET_VOLTAGE, SEC_VOLTAGE_18)); // must
explicitly turn on LNB power
lnbPowerTurnedOn = true;
}
static cMutex Mutex;
@@ -773,6 +787,7 @@
struct dvb_diseqc_master_cmd cmd;
const char *Curr
Re: [vdr] RFC: one or many positioners?
Al 22/04/13 11:11, En/na Klaus Schmidinger ha escrit: >> I'd suggest a parameter with the number of steps to move (and for "step" >> I mean a "pulse", not the next/previous stored satellite position). > > I don't see the need for a "number of steps". Well, I use it from time to time. Say I move step by step to the west and, after e.g. 5 steps, I discover the signal is getting worse. Instead of hitting 5 times StepEast, I position over the "x steps east" soft button, push 5 on the remote, push ok and I'm at the starting position. Better yet, I move 10 steps east at once to try if going to the other side improves things or not. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RFC: one or many positioners?
Al 22/04/13 11:12, En/na Klaus Schmidinger ha escrit: >> virtual void Recalc(int Number) >>///> Number >>/// > What would this actually be good for? Imagine that the dish moved but the counter didn't work, or simply there's some slack accumulated, so the actual position and the registered position differ. Without this method you should store each of the already stored position, with a Recalc method, positioning to one know good satellite would be enough, since the relatives positions would still be good. Actually, the description is wrong, as the effect would be "You, positioner, now are at this position", so it would be something like "Set as your current position the position specified by Number" (or longitude if you prefer) So maybe it should be better called "SetCurrentPosition" Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RFC: one or many positioners?
I have two positioners one for a ku dish and a second for a C Band dish. Would it be possibles to cater for the southern hemispere by a switch. Your East is my West. Mike ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RFC: one or many positioners?
On 21.04.2013 20:36, Luca Olivetti wrote:
Al 21/04/13 15:52, En/na Klaus Schmidinger ha escrit:
One more observation
virtual void StepEast(void) {}
///< Move the dish one step to the east.
virtual void StepWest(void) {}
///< Move the dish one step to the west.
I'd suggest a parameter with the number of steps to move (and for "step"
I mean a "pulse", not the next/previous stored satellite position).
I don't see the need for a "number of steps".
This function will be used to fine-tune the position of the dish, so it
shall make a very small move.
I'll add this to the description:
virtual void StepEast(void) {}
///< Move the dish one step to the east.
///< A "step" is the smallest possible movement the positioner can
make, which
///< is typically 0.1 degrees.
virtual void StepWest(void) {}
///< Move the dish one step to the west.
///< A "step" is the smallest possible movement the positioner can
make, which
///< is typically 0.1 degrees.
Klaus
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RFC: one or many positioners?
On 21.04.2013 20:17, Luca Olivetti wrote:
Al 21/04/13 15:52, En/na Klaus Schmidinger ha escrit:
Any visual feedback will be done via the channel display of the skin, by
comparing
CurrentLongitude() to TargetLongitude(). And of course any section
filtering will
start only after the target position has been reached.
Mmh, how will the system decide between "GotoAngle" and "GotoPosition"?
That will be done in diseqc.conf. There may still be another function
through which the positioner can tell VDR about its "capabilities".
I have a linear actuator and I can only work with pulses. While in
theory calculating the angle is possible, it'd be difficult to do and it
will vary based on the geometry of the mount.
The cPositioner class is an abstract model of a device that can steer
a dish to a given orbital position (longitude), or a previously stored
position (number). How a particular positioner does this is totally up
to its implementation.
Also, I don't like the use of "Number" in StorePosition, mainly because
I've been using Source up until now, but I guess I can live with that.
You can still use "source", because that's just what is given as the
"Longitude" parameter in GotoAngle() (without the 'S').
From the complete interface it seems that everything regarding
positioning will be managed by vdr itself, so the main screen of my
plugin[*] will be made redundant (good! I'm lazy),
That's the plan ;-).
one thing I see
missing is some way to show error conditions (I have "Limit reached" and
"Motor error", which means the motor isn't moving even if it should).
OK, I'll add
virtual cString Error(void) { return NULL; }
///< Returns a short, single line string indicating an error
condition.
///< NULL means there is no error.
[*] http://ventoso.org/luca/vdr/screenshot.jpg
Klaus
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RFC: one or many positioners?
On 21.04.2013 20:43, Luca Olivetti wrote:
Al 21/04/13 20:36, En/na Luca Olivetti ha escrit:
Al 21/04/13 15:52, En/na Klaus Schmidinger ha escrit:
One more observation
virtual void StepEast(void) {}
///< Move the dish one step to the east.
virtual void StepWest(void) {}
///< Move the dish one step to the west.
I'd suggest a parameter with the number of steps to move (and for "step"
I mean a "pulse", not the next/previous stored satellite position).
And, I hope, the last one:
virtual void Recalc(int Number)
///
What would this actually be good for?
Oh, and there's a DisableLimits but there's no corresponding EnableLimits
Unfortunately the DiSEqC specs leave a lot of liberty in this area,
so you can never really be sure when the limits will be (re)enabled.
I'll add this, though:
virtual void EnableLimits(void) {}
///< Enables the soft limits for the dish movement.
Klaus
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RFC: one or many positioners?
2013/4/21 Klaus Schmidinger : > I'm currently implementing support for steerable dishes, loosely based > on https://linuxtv.org/patch/12911. In doing so, I'm defining a virtual > base class cPositioner, which defines all the functions necessary to > control the positioner. An implementation of cDiseqcPositioner will > allow control of "DiSEqC 1.2" and "USALS" motors. A plugin can derive > from cPositioner and implement its very own way of controlling a > positioner (like through a serial or USB port or whatever). > > The question I have now is: will it be enough to have *one* single > positioner > in any given setup, or are there actually users who have more than one > positioner? > Supporting only a single positioner (as is done in the aforementioned patch) > of course simplifies things quite a bit. So I wouldn't want to add this > level of complexity unless there is a real need for it. Hmm, I guess most only have single positioner. But this might change if VDR actually supported more than one. :) However, it would be nice to be able to use twin or quad LNB in positioner, even if using diseqc switches.. I have no idea how to configure this. :) An example, my system has four tuners. Each one has 4-to-1 diseqc switch. They are configured like this: # tuner 1: # 1: 27.5W # 2: 7W/8W # 3: 1W # 4: motor # # tuner 2: # 1: 27.5W # 2: 4W/5W # 3: 1W # 4: 16E # # tuner 3: # 1: 1W # 2: 13E # 3: 19.2E # 4: 4.8E # # tuner 4: # 1: 1W # 2: 13E # 3: 19.2E # 4: 4.8E My positioner actually has twin LNB. I'd like to connect the other output to tuner2 input 2, but there is no way this would work even with heavy patching of VDR.. I think the current diseqc.conf is a bit too complicated. I think it should be better to use some approach where you select LNB type (universal Ku, C band etc), then add Diseqc switches (1.0 or 1.1), and positioners.. Diseqc 1.0 and 1.1 switches can be cascaded. Perhaps just a text file with lines similar to this: S16E: T1 C1 U1 G (tuner 1, committed switch input 1, uncommitted switch input 1, use GotoX positioner) The file could be scanned in order when finding tuner for given satellite. That way you could have priorities, so a tuner with positioner is not "wasted" if some other tuner can tune.. Just my thoughts.. :) -- Teemu Suikki http://www.z-power.fi/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RFC: one or many positioners?
Al 21/04/13 20:36, En/na Luca Olivetti ha escrit:
> Al 21/04/13 15:52, En/na Klaus Schmidinger ha escrit:
>
> One more observation
>
>> virtual void StepEast(void) {}
>> ///< Move the dish one step to the east.
>> virtual void StepWest(void) {}
>> ///< Move the dish one step to the west.
>
> I'd suggest a parameter with the number of steps to move (and for "step"
> I mean a "pulse", not the next/previous stored satellite position).
And, I hope, the last one:
virtual void Recalc(int Number)
///http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RFC: one or many positioners?
Al 21/04/13 15:52, En/na Klaus Schmidinger ha escrit:
One more observation
> virtual void StepEast(void) {}
> ///< Move the dish one step to the east.
> virtual void StepWest(void) {}
> ///< Move the dish one step to the west.
I'd suggest a parameter with the number of steps to move (and for "step"
I mean a "pulse", not the next/previous stored satellite position).
Bye
--
Luca
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RFC: one or many positioners?
Al 21/04/13 20:17, En/na Luca Olivetti ha escrit: > Al 21/04/13 15:52, En/na Klaus Schmidinger ha escrit: > >> >> Any visual feedback will be done via the channel display of the skin, by >> comparing >> CurrentLongitude() to TargetLongitude(). And of course any section >> filtering will >> start only after the target position has been reached. > > Mmh, how will the system decide between "GotoAngle" and "GotoPosition"? > I have a linear actuator and I can only work with pulses. While in > theory calculating the angle is possible, it'd be difficult to do and it > will vary based on the geometry of the mount. > Also, I don't like the use of "Number" in StorePosition, mainly because > I've been using Source up until now, but I guess I can live with that. > From the complete interface it seems that everything regarding > positioning will be managed by vdr itself, so the main screen of my > plugin[*] will be made redundant (good! I'm lazy), one thing I see > missing is some way to show error conditions (I have "Limit reached" and > "Motor error", which means the motor isn't moving even if it should). FYI, I use these states in the driver, shown here with the corresponding message in the plugin: ACM_IDLE (no message since it's doing nothing) ACM_WEST, ACM_EAST "Dish target %d, position %d" ACM_REACHED "Position reached" ACM_STOPPED, ACM_CHANGE "Motor wait" ACM_ERROR "Motor error" Limit control is not done by the driver but by the plugin, and the messages are "Dish at limits" (in manual mode) "Position outside limits" (in positioning mode) There's also a "Position not set" if the new channel is in it's in a source that's not been memorized (I'm currently implementing a cStatus to detect channel switch). Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RFC: one or many positioners?
Al 21/04/13 15:52, En/na Klaus Schmidinger ha escrit: > > Any visual feedback will be done via the channel display of the skin, by > comparing > CurrentLongitude() to TargetLongitude(). And of course any section > filtering will > start only after the target position has been reached. Mmh, how will the system decide between "GotoAngle" and "GotoPosition"? I have a linear actuator and I can only work with pulses. While in theory calculating the angle is possible, it'd be difficult to do and it will vary based on the geometry of the mount. Also, I don't like the use of "Number" in StorePosition, mainly because I've been using Source up until now, but I guess I can live with that. >From the complete interface it seems that everything regarding positioning will be managed by vdr itself, so the main screen of my plugin[*] will be made redundant (good! I'm lazy), one thing I see missing is some way to show error conditions (I have "Limit reached" and "Motor error", which means the motor isn't moving even if it should). [*] http://ventoso.org/luca/vdr/screenshot.jpg Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RFC: one or many positioners?
I currently only have one dish with motor, but if the VDR allows it I might consider a second one. Although in that setup I'm not sure that I would use them on just one system. I would definitely add another receiver, maybe with a possibility to share between the two motorized dishes. On Sun, Apr 21, 2013 at 4:39 PM, VDR User wrote: > I don't have a dish motor myself but FWIW I know a few people who do > and they all have only one in their setup. > > ___ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RFC: one or many positioners?
I don't have a dish motor myself but FWIW I know a few people who do and they all have only one in their setup. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RFC: one or many positioners?
21.04.2013 15:54, Klaus Schmidinger kirjutas: The question I have now is: will it be enough to have *one* single positioner in any given setup, or are there actually users who have more than one positioner? Hi and thanks for bringing this feature to the job list! One is enough for me. -- br, Arthur ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RFC: one or many positioners?
On 21.04.2013 15:40, Luca Olivetti wrote:
Al 21/04/13 14:54, En/na Klaus Schmidinger ha escrit:
I'm currently implementing support for steerable dishes, loosely based
on https://linuxtv.org/patch/12911. In doing so, I'm defining a virtual
base class cPositioner, which defines all the functions necessary to
control the positioner.
Is there a preview of the API to comment on?
At the very least it should have a "GotoSource" method an
"IsPositionedAt" method and something to give visual feedback while the
dish is moving, but then my views may be biased by my own implementation.
Here's the current interface:
class cPositioner {
private:
int speed; // the rotation speed of the positioner (degrees * 10 per second)
int lastLongitude;
int targetLongitude;
cTimeMs movementStart;
protected:
int CalcHourAngle(int Longitude);
///< Takes the longitude and latitude of the dish location from the system
///< setup and the given Longitude to calculate the "hour angle" to which
to drive
///< the dish to in order to point to the satellite at orbital position
Longitude.
///< An hour angle of zero means the dish shall point directly towards the
///< celestial equator (which is south on the northern hemisphere, and
north on
///< the southern hemisphere). Negative values mean that the dish needs
to be
///< moved to the left (as seen from behind the dish), while positive
values
///< require a movement to the right.
///< See GotoAngle() for the sematics of angles.
public:
cPositioner(void);
virtual ~cPositioner();
virtual void DriveEast(void) {}
///< Continuously drive the dish to the east, until Halt() is called
or it hits the
///< soft or hard limit.
virtual void DriveWest(void) {}
///< Continuously drive the dish to the west, until Halt() is called
or it hits the
///< soft or hard limit.
virtual void StepEast(void) {}
///< Move the dish one step to the east.
virtual void StepWest(void) {}
///< Move the dish one step to the west.
virtual void Halt(void) {}
///< Stop any ongoing motion of the dish.
virtual void SetLimitEast(void) {}
///< Set the east soft limit of the dish movement to the current
position.
virtual void SetLimitWest(void) {}
///< Set the west soft limit of the dish movement to the current
position.
virtual void DisableLimits(void) {}
///< Disables the soft limits for the dish movement.
virtual void StorePosition(int Number) {}
///< Store the current position as a satellite position with the
given Number.
///< Number can be in the range 1...255. However, a particular
positioner
///< may only have a limited number of satellite positions it can
store.
virtual void GotoPosition(int Number, int Longitude);
///< Drive the dish to the satellite position stored under the given
Number.
///< Number must be one of the values previously used with
StorePosition().
///< The special value 0 shall drive the dish to a "reference
position",
///< which usually is due south (or north, if you're on the southern
hemisphere).
///< Longitude will be used to calculate how long it takes to drive
the dish
///< from its current position to the given Longitude.
///< A derived class must call the base class function to have the
target
///< longitude stored.
virtual void GotoAngle(int Longitude);
///< Drive the dish to the given angular position. Longitude can be
in the range
///< -1800...+1800. A positive sign indicates a position east of
Greenwich,
///< while western positions have a negative sign. The absolute value
is in
///< "degrees * 10", which allows for a resolution of 1/10 of a
degree.
///< A derived class must call the base class function to have the
target
///< longitude stored.
virtual int CurrentLongitude(void);
///< Returns the longitude the dish currently points at. If the dish
is in motion,
///< this may be an estimate based on the angular speed of the
positioner.
///< See GotoAngle() for the sematics of angles.
///< The default implementation takes the last and target longitude
as well as
///< the rotation speed of the positioner to calculate the estimated
current
///< longitude the dish points to.
int TargetLongitude(void) { return targetLongitude; }
///< Returns the longitude the dish is supposed to be driven to. Once
the target
///< longitude has been reached, this is the same as the value
returned by
///< CurrentLongitude(). See GotoAngle() for the sematics of angles.
};
Any visual feedback will be done via the channel display of the skin, by
comparing
CurrentLongitude() to TargetLongitude(). And of course any section filtering
will
sta
Re: [vdr] RFC: one or many positioners?
Al 21/04/13 14:54, En/na Klaus Schmidinger ha escrit: > I'm currently implementing support for steerable dishes, loosely based > on https://linuxtv.org/patch/12911. In doing so, I'm defining a virtual > base class cPositioner, which defines all the functions necessary to > control the positioner. Is there a preview of the API to comment on? At the very least it should have a "GotoSource" method an "IsPositionedAt" method and something to give visual feedback while the dish is moving, but then my views may be biased by my own implementation. > The question I have now is: will it be enough to have *one* single > positioner > in any given setup, or are there actually users who have more than one > positioner? > Supporting only a single positioner (as is done in the aforementioned > patch) > of course simplifies things quite a bit. So I wouldn't want to add this > level of complexity unless there is a real need for it. Personally I have just one positioner, so my plugin only allows one instance (even worse, my kernel driver only allows one device). I think there are no more than 3 users of the plugin (including myself), so that's not a statistically relevant sample, sorry. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
