[vdr] RFC: one or many positioners?

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

Any opinions?

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


[vdr] ERROR: video data stream broken with DVB-T, AVC and ITE9135 device?

2013-04-21 Thread Michael Smith
Hi,

I've switched from DVB-S to DVB-T usb dongle with ITE9135 chipset and I'm
trying to record an AVC channel.
I'm using VDR-1.7.27.

Every thing OK when I use VDR with streamdev plugin. In fact I've set my
system to stream channels for more than 10 days. But after I create a timer
to record my stream, VDR gives following messages and jumps out.

ERROR: video data stream broken
initiating emergency exit
emergency exit requested - shutting down

I'm sure signal is fine, as I said there is no problem with streamdev. Also
I tried EPGScanTimeout=0 and EmergencyExit=0. Although it prevents VDR to
jump out, but nothing is recorded.

I've tested VDR-1.7.37 and problem persists.

Any idea?

Thanks.
Mike Smith.
___
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