Re: [vdr] RFC: one or many positioners?

2013-04-28 Thread Ales Jurik

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?

2013-04-27 Thread Klaus Schmidinger

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?

2013-04-27 Thread Klaus Schmidinger

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?

2013-04-23 Thread Klaus Schmidinger

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)
///Store the current position in a satellite position with the given
Number
///and recalculate all other positions relative to this one


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?

2013-04-23 Thread Klaus Schmidinger

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?

2013-04-23 Thread Luca Olivetti
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?

2013-04-23 Thread Ales Jurik

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?

2013-04-22 Thread Teemu Suikki
2013/4/21 Klaus Schmidinger klaus.schmidin...@tvdr.de:
 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?

2013-04-22 Thread Klaus Schmidinger

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)
   ///Store the current position in a satellite position with the given
Number
   ///and recalculate all other positions relative to this one


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-04-22 Thread Klaus Schmidinger

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?

2013-04-22 Thread Klaus Schmidinger

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?

2013-04-22 Thread Mike Booth
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?

2013-04-22 Thread Luca Olivetti
Al 22/04/13 11:12, En/na Klaus Schmidinger ha escrit:

 virtual void Recalc(int Number)
///Store the current position in a satellite position with the given
 Number
///and recalculate all other positions relative to this one
 
 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?

2013-04-22 Thread Luca Olivetti
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?

2013-04-22 Thread Antti Hartikainen
On Mon, Apr 22, 2013 at 11:46:34AM +0300, Teemu Suikki wrote:
 2013/4/21 Klaus Schmidinger klaus.schmidin...@tvdr.de:
  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==4dfd_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 *CurrentAction = NULL;
   for (;;) {
+  printf(dfd_frontend: 

Re: [vdr] RFC: one or many positioners?

2013-04-22 Thread Klaus Schmidinger

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?

2013-04-22 Thread Klaus Schmidinger

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?

2013-04-22 Thread Klaus Schmidinger

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?

2013-04-22 Thread Luca Olivetti
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?

2013-04-22 Thread VDR User
On Mon, Apr 22, 2013 at 5:33 AM, Klaus Schmidinger
klaus.schmidin...@tvdr.de 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?

2013-04-22 Thread Füley István

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?

2013-04-22 Thread Lars Hanisch
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?

2013-04-22 Thread Timothy D. Lenz

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?

2013-04-21 Thread Luca Olivetti
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


Re: [vdr] RFC: one or many positioners?

2013-04-21 Thread Klaus Schmidinger

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
start only after the target position has been reached.


Re: [vdr] RFC: one or many positioners?

2013-04-21 Thread Arthur Konovalov

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?

2013-04-21 Thread VDR User
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?

2013-04-21 Thread Dimitar Petrovski
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 user@gmail.com 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?

2013-04-21 Thread Luca Olivetti
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?

2013-04-21 Thread Luca Olivetti
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?

2013-04-21 Thread Luca Olivetti
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?

2013-04-21 Thread Luca Olivetti
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)
  ///Store the current position in a satellite position with the given
Number
  ///and recalculate all other positions relative to this one


Oh, and there's a DisableLimits but there's no corresponding  EnableLimits

Bye
-- 
Luca


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr