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.

Klaus

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

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

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

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

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

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

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.

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

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
• 99999 V 10600 t V W15 [E0 10 38 F1] W15 P
• 11700 H 9750 t V W15 [E0 10 38 F2] W15 P
• 99999 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 99999 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 99999 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 * 99999 V 10600 t V W15 [E0 10 38 FD] W15 P * 11700 H 9750 t V W15 [E0 10 38 FE] W15 P * 99999 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

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 * 99999 V 10600 t V W15 P W15 v T * 11700 H 9750 t V W15 P W15 V t * 99999 H 10600 t V W15 P W15 V T

valid for all tuners/cards will be enough.

Thanks,

Best Regards,

Ales