Rotor(Motor) Support Latest Information.

Gary Brown · 2014-05-27T18:36:03+00:00

PLEASE READ ALL OF THIS POST AND THEN BEFORE POSTING HERE AND DON'T EMAIL ME CURRENT STATUS OF ROTOR SUPPORT: Working since commit from 4th August 2014 vers...

o o

The rotor moves the dish to the correct position, but then tvheadend is stuck in an infimite loop. Here is an example of moving from 4.8E to 0.8W and the back again.


tvheadend.txt:2014-09-20 08:33:11.865 [  TRACE]:diseqc: rotor USALS goto 0.8W (motor 20.50 counter-clockwise)
tvheadend.txt:2014-09-20 08:33:11.865 [  TRACE]:diseqc: sending diseqc (len 5) E0 31 6E D1 48 
tvheadend.txt:2014-09-20 08:33:11.992 [  TRACE]:diseqc: waiting 120 seconds to finish setup for USALS
tvheadend.txt:2014-09-20 08:33:33.205 [  TRACE]:diseqc: rotor USALS goto 0.8W (motor 20.50 counter-clockwise)
tvheadend.txt:2014-09-20 08:33:33.205 [  TRACE]:diseqc: sending diseqc (len 5) E0 31 6E D1 48 
tvheadend.txt:2014-09-20 08:33:33.332 [  TRACE]:diseqc: waiting 120 seconds to finish setup for USALS
tvheadend.txt:2014-09-20 08:33:54.517 [  TRACE]:diseqc: rotor USALS goto 0.8W (motor 20.50 counter-clockwise)
tvheadend.txt:2014-09-20 08:33:54.517 [  TRACE]:diseqc: sending diseqc (len 5) E0 31 6E D1 48 
tvheadend.txt:2014-09-20 08:33:54.644 [  TRACE]:diseqc: waiting 120 seconds to finish setup for USALS
tvheadend.txt:2014-09-20 08:34:15.985 [  TRACE]:diseqc: rotor USALS goto 0.8W (motor 20.50 counter-clockwise)
tvheadend.txt:2014-09-20 08:34:15.985 [  TRACE]:diseqc: sending diseqc (len 5) E0 31 6E D1 48 
tvheadend.txt:2014-09-20 08:34:16.112 [  TRACE]:diseqc: waiting 120 seconds to finish setup for USALS
tvheadend.txt:2014-09-20 08:34:37.318 [  TRACE]:diseqc: rotor USALS goto 0.8W (motor 20.50 counter-clockwise)
tvheadend.txt:2014-09-20 08:34:37.318 [  TRACE]:diseqc: sending diseqc (len 5) E0 31 6E D1 48 
tvheadend.txt:2014-09-20 08:34:37.448 [  TRACE]:diseqc: waiting 120 seconds to finish setup for USALS


tvheadend.txt:2014-09-20 08:36:39.101 [  TRACE]:diseqc: rotor USALS goto 4.8E (motor 14.46 counter-clockwise)
tvheadend.txt:2014-09-20 08:36:39.101 [  TRACE]:diseqc: sending diseqc (len 5) E0 31 6E D0 E7 
tvheadend.txt:2014-09-20 08:36:39.228 [  TRACE]:diseqc: waiting 120 seconds to finish setup for USALS

The I disabled the check for rate and orbital_dir in: src/input/mpegts/linuxdvb/linuxdvb_rotor.c


    139 #if 0
    140   if (!ls->ls_orbital_dir || lr->lr_rate == 0)
    141     return 120;

And I got:


tvheadend.txt:2014-09-20 08:45:23.549 [  TRACE]:diseqc: rotor USALS goto 4.8E (motor 14.46 counter-clockwise)
tvheadend.txt:2014-09-20 08:45:23.549 [  TRACE]:diseqc: sending diseqc (len 5) E0 31 6E D0 E7 
tvheadend.txt:2014-09-20 08:45:23.676 [  TRACE]:diseqc: waiting 202 seconds to finish setup for USALS

Then I reduced the rate to 1ms, changed position of the dish to 0.8W all channels on 0.8W works!

However, now it is not possible to move the dish back to 4.8E.

tvheadend.txt:2014-09-20 08:55:25.657 [ DEBUG]:diseqc: rotor already positioned to 0.8W

Well, then I decided to patch away the check for orbital position in src/input/mpegts/linuxdvb/linuxdvb_rotor.c:


    257 #if 0
    258   if (linuxdvb_rotor_check_orbital_pos(lm, ls))
    259     return 0;
    260 #endif

There will be a timeout between switching channels on the same satellite now (of course), but, it works!!!!!!!!!!!!!!!!!!

All channels on all satellites works just fine.

This is of course a horrible hack and it would be good if the code for the timeout and the check for the orbital position is adapted so it works also for my configuration.

If I get time I will add my own orbital check function and timeout calculation function that I used together with JSMs patch. Very simple functions that don't cover all the corner cases that your functions do i.e not for "commercial use" :)

o o

Hi Philip,

I have made a horrible patch that you can try if you dare :-)

Replace the attached file with /tvheadend/src/input/mpegts/linuxdvb/linuxdvb_rotor.c and recompile.

Change the define at line 37 with the value (in degrees) of the sat that is most far away from 0.0.

#define MAX_FAR_AWAY_SAT 5.0

The code is most certainly full of bugs, but it works ok for my setup (two sat positions, -0.8 and 4.8).

A drawback with my hack solution is that the old position is not stored in a file, so it make take some time to tune in to the first channel after startup (especially if the new position is far away from MAX_FAR_AWAY_SAT).

If it doesn't work straight away, try to switch channels back and forth.

NB! The hack is for USALS configuration only.

Philip Reynolds

Hi o o,
thanks for the info. I'm in the middle of setting up Ubuntu server at the mo, when I get to the stage for testing tvheadend USALS, if it still doesn't work, I'll try your patch.

I embarrassed myself a bit last night on the IRC channel trying to ask for advice, perexg was very kind though.

I'm just going to set up Thor and Sirius too. Let's see what happens.

Best regards,
Phil.

Jaroslav Kysela

o o wrote:
> The rotor moves the dish to the correct position, but then tvheadend is stuck in an infimite loop. Here is an example of moving from 4.8E to 0.8W and the back again.
>

> [...]

I wouldn't go in this direction. The first 120 second delay was set, because tvh does not know to which position dish points.. After this big delay, it's expected to use lower timeouts..

The problem seems that this value is not propagated to src/subscriptions.c:783..

And this ends that the "job" is timeouted (see the 20 second distance in your log) before the first sat pos is set..

Try to fix this at first..

Jaroslav Kysela

Some new commits in the tvh master source tree:

USALS grace time calculation fix (sorry, thinko):

https://tvheadend.org/projects/tvheadend/repository/revisions/fa1ce0aa2f6ec11e4f7d5e639342e471503a4759/diff/

Add Max Rotor Movement (seconds) to the DVB-S frontend configuration:

https://tvheadend.org/projects/tvheadend/repository/revisions/24b1818e431b51bb9b49d321abc6f50c7624a00e/diff/

The initial grace timeout is not fixed yet..

o o

Thanks for your effort Jaroslav!

Unfortunately it is not possible to read out the current position from the rotor at startup.

Some possible methods to calculate the initial grace timeout.
# Calculate the max possible east to west movement from the configuration. E.g. -0.8 to 4.8 gives max 5.6 movement at startup

# Always store the "last" satellite position in a file (after the rotor movement is finished).

+ many more probably better solutions :)

o o

Jaroslav Kysela wrote:
> Some new commits in the tvh master source tree:
>
> USALS grace time calculation fix (sorry, thinko):
>
> https://tvheadend.org/projects/tvheadend/repository/revisions/fa1ce0aa2f6ec11e4f7d5e639342e471503a4759/diff/ >
> Add Max Rotor Movement (seconds) to the DVB-S frontend configuration:
>
> https://tvheadend.org/projects/tvheadend/repository/revisions/24b1818e431b51bb9b49d321abc6f50c7624a00e/diff/ >

> The initial grace timeout is not fixed yet..

All the channels on 0.8W works well now. I have set the max rotor timeout to 5 seconds. However, when I try to switch to a channel on 4.8E, I get connection lost in xbmc. I'll debug the problem later today. Either the dish does not move correctly (or not at all), or there are still problems with the timeouts.

o o

The rotor does not move from 0.8W to 4.8E.

Here is the log:


2014-09-21 15:14:06.577 [  DEBUG]:diseqc: rotor already positioned to 1.0W
2014-09-21 15:14:06.577 [  TRACE]:diseqc: set voltage 13V
2014-09-21 15:14:06.595 [  TRACE]:disqec: set diseqc tone on
2014-09-21 15:14:27.642 [  DEBUG]:diseqc: rotor already positioned to 0.8W
2014-09-21 15:14:27.642 [  TRACE]:diseqc: set voltage 13V
2014-09-21 15:14:27.660 [  TRACE]:disqec: set diseqc tone off
2014-09-21 15:14:47.809 [  DEBUG]:diseqc: rotor already positioned to 0.8W
2014-09-21 15:14:47.809 [  TRACE]:diseqc: set voltage 13V
2014-09-21 15:14:47.827 [  TRACE]:disqec: set diseqc tone off

Jaroslav Kysela

o o wrote:
> The rotor does not move from 0.8W to 4.8E.
> Here is the log:
>

> [...]

It looks very suspicious. If you look to a mux details (edit) in the 4.8E network, which position is reported ? The value for the comparison is taken from this structure.
Perhaps, your database is invalid, so I suggest to remove 4.8E and create it again..

o o

Jaroslav Kysela wrote:
> o o wrote:
> > The rotor does not move from 0.8W to 4.8E.
> > Here is the log:
> >
> > [...]
>
> It looks very suspicious. If you look to a mux details (edit) in the 4.8E network, which position is reported ? The value for the comparison is taken from this structure.

> Perhaps, your database is invalid, so I suggest to remove 4.8E and create it again..

The mux details are correct, 5.0E and 1.0W.
The dish moved from 0.8W to 4.8E once after startup, then it does not move back.


2014-09-21 16:45:06.904 [  TRACE]:diseqc: rotor USALS goto 4.8E (motor 14.46 counter-clockwise)
2014-09-21 16:45:06.904 [  TRACE]:diseqc: sending diseqc (len 5) E0 31 6E D0 E7 
2014-09-21 16:45:07.033 [  TRACE]:diseqc: waiting 29 seconds to finish setup for USALS
2014-09-21 16:45:30.571 [  TRACE]:diseqc: rotor USALS goto 4.8E (motor 14.46 counter-clockwise)
2014-09-21 16:45:30.571 [  TRACE]:diseqc: sending diseqc (len 5) E0 31 6E D0 E7 
2014-09-21 16:45:30.700 [  TRACE]:diseqc: waiting 29 seconds to finish setup for USALS
2014-09-21 16:45:40.692 [  DEBUG]:diseqc: rotor already positioned to 0.8W
2014-09-21 16:45:40.692 [  TRACE]:diseqc: set voltage 18V
2014-09-21 16:45:40.710 [  TRACE]:disqec: set diseqc tone off

I also get this strange log when I try to select a channel on 0.8W.

subscription: "127.0.0.1 [ tvh | XBMC Media Center ]" subscribing on "Nat Geo Wild HD", weight: 150, adapter: "STV0900 frontend : DVB-S #0", network: "Thor_1W", mux: "11785H", provider: "Telenor", service: "Nat Geo Wild HD", hostname="127.0.0.1", username="tvh", client="XBMC Media Center" 2014-09-21 16:52:51.624 mpegts: 11823V in Sirius_5E - no tuners enabled

Why does it say no tuners enabled for 11823V in Sirius_5E when tuning to a channel on 0.8W?

Philip Reynolds

Hi o o,
did you have any luck? I'm now using build 1560, and couldn't get the it switching between -0.8 and 4.8. Dish moved but stayed in 'testing'.

I just tried something- for my rotor the rate should of been 400- I just set it to half of that and now it switches between positions every time!

Any idea why this seems to have got it working?

Best regards,

Phil.

P.S- I don't know why there's lines through the text. I'ts working anyway:)
P.P.S- But didn't work from 28.2 to 4.8. Bugger. Oh well, thanks for everybodys hard work so far.

o o

Philip Reynolds wrote:
> Hi o o,
> did you have any luck? I'm now using build 1560, and couldn't get the it switching between -0.8 and 4.8. Dish moved but stayed in 'testing'.
> I just tried something- for my rotor the rate should of been 400- I just set it to half of that and now it switches between positions every time!
>
> Any idea why this seems to have got it working?
>
> Best regards,
> Phil.
>
> P.S- I don't know why there's lines through the text. I'ts working anyway:)

> P.P.S- But didn't work from 28.2 to 4.8. Bugger. Oh well, thanks for everybodys hard work so far.

Hi Philip,

I have divided the rotor rate by 10 (value 42), and build 3.9.1567~gde634dd works well. At least for moving between 0.8W and 4.8E.

I can't really understand the following code in /tvheadend/src/input/mpegts/linuxdvb/linuxdvb_rotor.c


146 newpos = (lr->lr_sat_lon + 0.05) * 10;   /* USALS */
147	
148 curpos = ls->ls_orbital_pos;
149 if (ls->ls_orbital_dir == 'W')
150 curpos = -(curpos);
151 delta = abs(deltaI32(curpos, newpos));
152	
153	
  /* ignore very small movements like 0.8W and 1W */
154  if (delta <= 2)
155  return 0;
156	
157  /* add one extra second, because of the rounding issue */
158 return ((lr->lr_rate*delta+999)/1000) + 1;

If the timeout value is in seconds and the rate in milliseconds, why the multiplication by 10 at line 147?

I'm also very happy that the rotor functionality is getting better and better.
A big thanks to Jaroslav and Gary for their great contribution to tvheadend.

Philip Reynolds

Hello o o,

thanks, I'll give it a go.

Best regards,

Phil.

- Tested 1567 last night. I just tested for a couple of hours, but it seems to work perfectly.

This was with three orbital positions, rotor rate set to 42. Each channel selected on a different position streamed first time (after the delay in dish positioning of course).

Thanks Gary and Jaroslav, amazing job.

o o

Hi Philip,

The latest build works perfectly for me too.
I hope that Jarsolav can have a quick look at the rate issue

https://tvheadend.org/d/1935-rotor-motor-support-latest-information?r=13343#message-13343

Another thing that would be nice to know is if Garys system is working well with the latest build.

Jaroslav Kysela

Note that delta is in tenths of degrees like 151 = 15.1 degrees. It looks like that the last expression should be (only for USALS):


  return ((lr->lr_rate*delta+9999)/10000) + 1;

Could you test?

BTW: The multiplication on line 146 is correct, because it's expected to enter the degrees (like 19.2 for 19.2E, or -5.1 for -5.1W) or so.

Jaroslav Kysela

Jaroslav Kysela wrote:
> Note that delta is in tenths of degrees like 151 = 15.1 degrees. It looks like that the last expression should be (only for USALS):
>
> [...]
>
> Could you test?
>

> BTW: The multiplication on line 146 is correct, because it's expected to enter the degrees (like 19.2 for 19.2E, or -5.1 for -5.1W) or so.

The fix is in the master repository:

https://tvheadend.org/projects/tvheadend/repository/revisions/d57a53110b431800c01693c8bbbff664d13c2a90/diff/

o o

Hi Jaroslav,

The fix works!
I have tested to switch from 0.8W to 13E back and forth many times in a row. No issues what so ever.

Brilliant!

You can close my "USALS does not work" issue.

Thank you very much.

Gurabli Gurabli

Greetings to everybody!

It is so nice to hear that USALS is finally working as it should! If I get this right, it means that we have now a fully working USALS motor setup, no problems of any kind with moving, scanning, changing channels between eg.: 0.8W and 34E. I'm sorry for not being able to do some testing, but I just do not have time besides wife and kids to build a new system at the moment. It is on a To Do list for me for sure in the near future if I find at least a half a day in one of the weekends.

Previously there was a comment about some other issues, like lost connection, etc, (that I believe was not related to USALS support), but I hope those are already or will be soon resolved.

Can you please let me know starting from which version of TVH build is the USALS working resolved? I will try to get somehow to ask for update to this or later version from the OpenELEC community.

I wish to thank truly to everybody for their hard work on this issue!

Philip Reynolds

Hi Gurabli,

I've been using build 1573 for the last couple of days, so far it's perfect.

Have a good weekend,
Phil.

Gurabli Gurabli

Hi Phil,
many thanks, so nice to hear this! I'm looking forward to try this out, as soon as I will have some free time.
OFF: can you tell me is timeshifting working properly, as it should, skip ff/rw xx seconds and pause? I know it is OFF here, but there is just no response to my questions related to timeshifting in other forums, and you are all using live TV. Many thanks!

« Previous Page Next Page »