Rotor(Motor) Support Latest Information.
Rotor(Motor) Support Latest Information.
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 version 3.9.1139 and later but stopped for me after an update from git (not sure which update as was doing it remotely for parents)
OPENELEC's version of tvheadend is behind this commit. please let them know you want it updating before attempting this on that OS.
MY SETUP:
OS:Ubuntu Server 14.04.1 LTS (GNU/Linux 3.13.0-32-generic x86_64)
Tvheadend: v3.9.1499
dvb-s card: Mystique SaTiX-S2 Sky PCI (http://www.amazon.co.uk/Mystique-SaTiX-S2-Sky-PCI-DiseqC/dp/B005IFWDIY)
rotor: Alsat Superior Dark Motor
dish: Alsat 1m mesh dish
GUIDE (needs an update for recent master:
1.first set some networks and give them names ( I use individual satellites but you could add more and do it by providers if you wanted to)
2.in tv adaptors, in your card select advanced for satconf 
3.in advanced enter your amount of satellites you want to receive in orbital positions. 
4.for each orbital position you enable usals by selecting it in the rotor drop down box. 
5.fill in the data in that new page.
0.8w
18w
13e Hotbird
POINTERS:
positive numbers for east and negative for west.
Don't Rely on GPS or Google for your site latitude or longitude use the values from your receiver or older program. (compare mine to to Sunderland, England SR4 and see the difference in mine.)
Rate:
in the Rate Column it needs a value of ms per each .1 of a degree. the text needs fixing to say that. I have the following rotor http://www.amazon.co.uk/SUPREME-MOTOR-METAL-DiSEqC-USALS/dp/B005THZL30/ref=pd_sxp_grid_i_0_1
it runs at Max. Speed: 1.9 / sec (at 13V) ; 2.5 / sec (at 18V) by the specs and manual.
tvheadend sets to 18v so 2.5 degrees each second.
1 / 25 = 0.4 seconds per degree multiplied by 1000 to change to miliseconds giving me a value of 400 to use in rate and it's perfect. when I wrote the code I made sure it always rounds up the result to seconds to allow extra time for the rotor to settle.
If you leave Rate empty or 0 it will wait 120 seconds between each move.
ANY QUESTIONS PLEASE ASK IN THIS THREAD AND PLEASE ANSWER THESE QUESTIONS TO SPEED UP HELP.
what version/build of tvheadend are you using? (look in the about section and paste the bold top line ie. "HTS Tvheadend 3.9.1499~g97999e4")
on what system is tvheadend running? linux pc 32bit or 64bit or other (nas/openelec etc)
what is your tuner card?
what is the rotor your using?
what is the rate set at?
PEOPLES QUESTIONS
if I use the latest stable Openelec version and tvheadend from it will I have the proper versions?
I've just asked in there IRC chat room and was told they are running version 3.9.1083 you need at least version 3.9.1139 have a look at the following link if your brave enough to update it yourself.
http://openelec.tv/forum/79-tvheadend/67708-update-to-newest-tvheadend
I also have a cline I use from a friend. Can you please help me how to configure tvh and oscam to use the cline I have?
Please ask questions about OSCAM in Descrambling section as This thread is for the rotor only.
I'm also not sure how to scan for all the channels on a sat by following your guide.
once you have configured the information above you do it the same way as normal (Pre-defined Muxes in Networks or by adding the muxes individually making sure to choose the correct network when it asks for it)
What OSCam am I Using
it's irrelavent but OSCam r9792 but please note If people are trying to use an encrypted channel then the problem may not be with the rotor but your oscam setup. please check with unencrypted channels to see if the rotor is the problem.
Replies (140)
RE: Rotor(Motor) Support Latest Information.
-
Added by o o about 10 years ago
I did a very quick test (tvheadend 3.9.1526~g4bce3dc) but the stream status is still 'testing'. The rotor seems to work ok tough. At least it moves correctly between 0.8W and 4.8E and scanning for services works.
Hard to say if the timeout logic works without printing out the timeout value (I guess you have already done that 
)
Tvheadend work perfectly when I configure "Universal LNB only".
It makes me wonder if there is some kind of race condition going on?
Isn't the same "tuning" function as in the "LNB only case" used after the dish has been moved to the correct position?
If it is, tuning should work as long it is guaranteed that no other thread/process is trying to tune before the grace period has expired.
I will try to debug during the weekend when the wife is sleeping.
But one thing that puzzles me is that Gary Browns setup works perfectly. It makes me wonder if I have done a stupid configuration mistake. On the other hand, scanning for services works.
RE: Rotor(Motor) Support Latest Information.
-
Added by Gary Brown about 10 years ago
o o if you take screenshots of the pages I've posted to change and upload them I can check.
My setup also includes a switch before the rotor as i've got a dedicated dish for Astra 28.2e and it works for everything but feeds but i think thats either my dish size or dvb-s2 card.
RE: Rotor(Motor) Support Latest Information.
-
Added by Philip Reynolds about 10 years ago
Hi again,
so I tested with VLC to stream the channels once everything was setup. Last evening I was using build 1500.
When a channel was selected, the dish would move to the correct position, but the stream state stayed in 'testing', there was no data '0Kbs', and nothing showing in the SNR/Signal strength. Then tvheadend reported 'lost live feed' and XBMC lost the connection. VLC reported 'connection timed out'.
Missus was happy, as she was watching a recorded show from the DVB-C card (screams of rage from the bedroom:)).
This morning I noticed there was an update to build 1526, and installed that. Tried once again with VLC, same behaviour as above but without 'lost live feed', so that was good (though XBMC wasn't connected). I then tried a channel from the DVB-C card, which worked fine. Again tried a satellite channel, dish moved, but stream state stayed in 'testing', there was no data '0Kbs', and nothing showing in the SNR/Signal strength. VLC timed out. Tried the DVB-C channel, all ok.
I guess I'm in the same boat as o o , probably making an error in the config, as my symptoms are the same.
Scanning the channels went fine last night, though I think i know why it takes so much time. I've learn't to delete all unused or weak strength transponders when scanning, as once tvheadend tries to tune into one, it can take up 15 minutes to drop it and move on the next. Also, I read in another thread that the reason why the 'pre-defined muxes' couldn't be saved was because they were in DVB5 format. I ran the make file to convert them to DVB3 they started to work. That was build 1500.
Anyway, thanks Gary and Jaroslav for you efforts.
Best regards,
Phil.
RE: Rotor(Motor) Support Latest Information.
-
Added by Gurabli Gurabli about 10 years ago
What is very promising, that Gary (and probably Jaroslav) got this working and they do have a fine working system. This would mean that it is working fine.
Strange is, that both Phil and o o have the same problems. I hope I will have some time to do the tests this weekend and post my experience too.
I guess it would be helpful if screenshots of each steps are uploaded as Gary asked already.
@Gary: can you please let us know which versions are you using (XBMC, TVH, Oscam) so that we could emulate exactly your setup?
And although not related to rotor, but can you tell me if timeshifting is working fine for you? Pause/resume, and skip xx seconds back/ff, which is a must for me? Or there are problems with this feature too?
I guess our logs will be helpful too, but I do not know how to post logs from Openelec.
BTW, I will use Openelec latest beta with the latest available TVH from their unofficial addon (version 4.1.2.1 that is based on tvheadend-3.9.681, or tvheadend-3.9.1083 if this is newer, confused).
Will see what will happen.
RE: Rotor(Motor) Support Latest Information.
-
Added by Gary Brown about 10 years ago
Gurabli rotor support was only working since commit from 4th August 2014 version 3.9.1139 and later Openelec version is to early to contain the fixes
for anyone asking I Use
OS:Ubuntu Server 14.04.1 LTS (GNU/Linux 3.13.0-32-generic x86_64)
Tvheadend: v3.9.1499
dvb-s card: Mystique SaTiX-S2 Sky PCI (http://www.amazon.co.uk/Mystique-SaTiX-S2-Sky-PCI-DiseqC/dp/B005IFWDIY)
rotor: Alsat Superior Dark Motor
dish: Alsat 1m mesh dish
irrelavent but OSCam r9792 (as asked for by gurabli)
If people are trying to use an encrypted channel then the problem may not be with the rotor but your oscam setup. please check with unencrypted channels to see if the rotor is the problem.
RE: Rotor(Motor) Support Latest Information.
-
Added by Gurabli Gurabli about 10 years ago
Thank you Gary! I will try to ask for a newer dev version of TVH for OE, maybe someone will compile one.
I intend to use Free to Air channels for testing, I asked OSCAM only to prevent further issues (I know it is not related to rotor).
OFF
As you are really a professional, can you please confirm if timeshifting is working properly, as it should?
OFF
RE: Rotor(Motor) Support Latest Information.
-
Added by Jaroslav Kysela about 10 years ago
Note for predefined muxes (linuxdvb v5 format): It's fixed in v3.9-1519-g34cb850 . Just, test the latest :-)
Note that for USALS rotor, we have issue:
https://tvheadend.org/issues/2298
But I believe, it's fixed in v3.9-1520-g03af723 .
For further analysis, the logs are necessary..
RE: Rotor(Motor) Support Latest Information.
-
Added by Jaroslav Kysela about 10 years ago
o o wrote:
I did a very quick test (tvheadend 3.9.1526~g4bce3dc) but the stream status is still 'testing'. The rotor seems to work ok tough. At least it moves correctly between 0.8W and 4.8E and scanning for services works.
Hard to say if the timeout logic works without printing out the timeout value (I guess you have already done that
Note that you may determine the timing from the log file - just look to 'diseqc' traces...
If scan works, the services should work too.. It looks like another problem (descrambling or so)...
RE: Rotor(Motor) Support Latest Information.
-
Added by Gary Brown about 10 years ago
Jaroslav I just want to ask a few questions on your code.
why did you replace the abs function with a custom version of it (deltaU32)?
the +999 before dividing by 1000 makes sure it rounds up no matter what so why did you add 1 second to the returned time function? what is this rounding issue?
RE: Rotor(Motor) Support Latest Information.
-
Added by Jaroslav Kysela about 10 years ago
Gary Brown wrote:
Jaroslav I just want to ask a few questions on your code.
why did you replace the abs function with a custom version of it (deltaU32)?
It's much undestandable for me to stay in the integer range than to convert the negative integer to unsigned and compare + substract it then. I know it works, but....
the +999 before dividing by 1000 makes sure it rounds up no matter what so why did you add 1 second to the returned time function? what is this rounding issue?
The timer is scheduled by seconds, so if you schedule in time 100.6 and the timer requests one second, it may run in time 101.0 .. So for safety, it's required to add extra second to make sure, that the delay is not less than expected.. It's different thing that 999/1000 rouding you're using..
RE: Rotor(Motor) Support Latest Information.
-
Added by Gary Brown about 10 years ago
Ah no problem I get it now. cheers for clearing it up I'll update to latest now
RE: Rotor(Motor) Support Latest Information.
-
Added by o o about 10 years ago
Jaroslav Kysela wrote:
o o wrote:
I did a very quick test (tvheadend 3.9.1526~g4bce3dc) but the stream status is still 'testing'. The rotor seems to work ok tough. At least it moves correctly between 0.8W and 4.8E and scanning for services works.
Hard to say if the timeout logic works without printing out the timeout value (I guess you have already done thatNote that you may determine the timing from the log file - just look to 'diseqc' traces...
If scan works, the services should work too.. It looks like another problem (descrambling or so)...
It might very well be a descrambling problem. If I wait long enough (10-15 minutes), I sometimes get a picture! The signal status is good even if stream is in the "testing" state.
Is there a difference in the descrambling function when rotor is used?
Sometimes I can see unknown CAID:SRVID in the oscam log even if they are correct.
Everything works perfectly when rotor is not used (universal LNB only). It takes 1-2 seconds to switch between encrypted HD channels in xbmc. I use a capmt connection to oscam.
If over the air EPG is enabled, it is not possible to zap to a channel on another satellite, the epggrab makes tvheadend hang.
RE: Rotor(Motor) Support Latest Information.
-
Added by Philip Reynolds about 10 years ago
Hi o o,
I thought that it may be a descrambling error as well, so I just tried BBC World News on Thor, which is clear. Same thing again - status 'testing'.
To make sure I'm not going mad, 15 minutes ago I tried Viasat Hockey with rotor support enabled (status testing:() and then disabled rotor support, just universal lnb while the dish was in the same position. Worked perfectly.
Bugger.
If it's any use, here is the data from syslog for the two events- the first connection was with rotor support, the second without.
Sep 19 18:59:31 JungleServer tvheadend4702: HTTP: 192.168.1.41: /stream/channel/7e25d1a468aee6762ac281d9000a458b -- 401
Sep 19 18:59:41 JungleServer tvheadend4702: mpegts: 11919H in Sirius - tuning on TurboSight TBS 6923 DVBS/S2 frontend : DVB-S #0
Sep 19 18:59:41 JungleServer tvheadend4702: subscription: "HTTP" subscribing on "Viasat Hockey Finland", weight: 100, adapter: "TurboSight TBS 6923 DVBS/S2 frontend : DVB-S #0", network: "Sirius", mux: "11919H", provider: "<N/A>", service: "Viasat Hockey Finland", hostname="192.168.1.41", username="philip", client="VLC/2.1.4 LibVLC/2.1.4"
Sep 19 19:00:01 JungleServer tvheadend4702: webui: Stop streaming /stream/channel/7e25d1a468aee6762ac281d9000a458b, timeout waiting for packets
Sep 19 19:00:01 JungleServer tvheadend4702: subscription: "HTTP" unsubscribing from "Viasat Hockey Finland", hostname="192.168.1.41", username="philip", client="VLC/2.1.4 LibVLC/2.1.4"
Sep 19 19:00:01 JungleServer tvheadend4702: mpegts: 11919H in Sirius - tuning on TurboSight TBS 6923 DVBS/S2 frontend : DVB-S #0
Sep 19 19:00:01 JungleServer tvheadend4702: subscription: "HTTP" subscribing on "Viasat Hockey Finland", weight: 100, adapter: "TurboSight TBS 6923 DVBS/S2 frontend : DVB-S #0", network: "Sirius", mux: "11919H", provider: "<N/A>", service: "Viasat Hockey Finland", hostname="192.168.1.41", username="philip", client="VLC/2.1.4 LibVLC/2.1.4"
Sep 19 19:00:02 JungleServer tvheadend4702: mpegts: 12169H in Thor - not enabled
Sep 19 19:00:02 JungleServer tvheadend4702: mpegts: 12322H in Thor - not enabled
Sep 19 19:00:02 JungleServer tvheadend4702: mpegts: 12607V in Thor - not enabled
Sep 19 19:00:02 JungleServer tvheadend4702: mpegts: 12130H in Thor - not enabled
Sep 19 19:00:02 JungleServer tvheadend4702: mpegts: 11881V in Thor - not enabled
Sep 19 19:00:02 JungleServer tvheadend4702: mpegts: 11434V in Thor - not enabled
Sep 19 19:00:02 JungleServer tvheadend4702: mpegts: 11823H in Thor - not enabled
Sep 19 19:00:02 JungleServer tvheadend4702: mpegts: 12399H in Thor - not enabled
Sep 19 19:00:02 JungleServer tvheadend4702: mpegts: 12245H in Thor - not enabled
Sep 19 19:00:02 JungleServer tvheadend4702: mpegts: 11958V in Thor - not enabled
Sep 19 19:00:02 JungleServer tvheadend4702: mpegts: 11823H in Thor - not enabled
Sep 19 19:00:02 JungleServer tvheadend4702: mpegts: 11862H in Thor - not enabled
Sep 19 19:00:21 JungleServer tvheadend4702: webui: Stop streaming /stream/channel/7e25d1a468aee6762ac281d9000a458b, timeout waiting for packets
Sep 19 19:00:21 JungleServer tvheadend4702: subscription: "HTTP" unsubscribing from "Viasat Hockey Finland", hostname="192.168.1.41", username="philip", client="VLC/2.1.4 LibVLC/2.1.4"
Sep 19 19:00:21 JungleServer tvheadend4702: HTTP: 192.168.1.41: /stream/channel/7e25d1a468aee6762ac281d9000a458b -- 401
Sep 19 19:00:22 JungleServer tvheadend4702: mpegts: 12169H in Thor - not enabled
Sep 19 19:00:22 JungleServer tvheadend4702: mpegts: 12322H in Thor - not enabled
Sep 19 19:00:22 JungleServer tvheadend4702: mpegts: 12607V in Thor - not enabled
Sep 19 19:00:22 JungleServer tvheadend4702: mpegts: 12130H in Thor - not enabled
Sep 19 19:00:22 JungleServer tvheadend4702: mpegts: 11881V in Thor - not enabled
Sep 19 19:00:22 JungleServer tvheadend4702: mpegts: 11434V in Thor - not enabled
Sep 19 19:00:22 JungleServer tvheadend4702: mpegts: 11823H in Thor - not enabled
Sep 19 19:00:22 JungleServer tvheadend4702: mpegts: 12399H in Thor - not enabled
Sep 19 19:00:22 JungleServer tvheadend4702: mpegts: 12245H in Thor - not enabled
Sep 19 19:00:22 JungleServer tvheadend4702: mpegts: 11958V in Thor - not enabled
Sep 19 19:00:22 JungleServer tvheadend4702: mpegts: 11823H in Thor - not enabled
Sep 19 19:00:22 JungleServer tvheadend4702: mpegts: 11862H in Thor - not enabled
Sep 19 19:01:26 JungleServer tvheadend4702: mpegts: 12169H in Thor - not enabled
Sep 19 19:01:26 JungleServer tvheadend4702: mpegts: 12322H in Thor - not enabled
Sep 19 19:01:26 JungleServer tvheadend4702: mpegts: 12607V in Thor - not enabled
Sep 19 19:01:26 JungleServer tvheadend4702: mpegts: 12130H in Thor - not enabled
Sep 19 19:01:26 JungleServer tvheadend4702: mpegts: 11881V in Thor - not enabled
Sep 19 19:01:26 JungleServer tvheadend4702: mpegts: 11434V in Thor - not enabled
Sep 19 19:01:26 JungleServer tvheadend4702: mpegts: 11823H in Thor - not enabled
Sep 19 19:01:26 JungleServer tvheadend4702: mpegts: 12399H in Thor - not enabled
Sep 19 19:01:26 JungleServer tvheadend4702: mpegts: 12245H in Thor - not enabled
Sep 19 19:01:26 JungleServer tvheadend4702: mpegts: 11958V in Thor - not enabled
Sep 19 19:01:26 JungleServer tvheadend4702: mpegts: 11823H in Thor - not enabled
Sep 19 19:01:26 JungleServer tvheadend4702: mpegts: 11862H in Thor - not enabled
Sep 19 19:01:32 JungleServer tvheadend4702: HTTP: 192.168.1.41: /api/mpegts/input/network_list -- 400
Sep 19 19:01:32 JungleServer tvheadend4702: message repeated 4 times: [ HTTP: 192.168.1.41: /api/mpegts/input/network_list -- 400]
Sep 19 19:01:39 JungleServer tvheadend4702: HTTP: 192.168.1.41: /stream/channel/7e25d1a468aee6762ac281d9000a458b -- 401
Sep 19 19:01:48 JungleServer tvheadend4702: mpegts: 11919H in Sirius - tuning on TurboSight TBS 6923 DVBS/S2 frontend : DVB-S #0
Sep 19 19:01:48 JungleServer tvheadend4702: subscription: "HTTP" subscribing on "Viasat Hockey Finland", weight: 100, adapter: "TurboSight TBS 6923 DVBS/S2 frontend : DVB-S #0", network: "Sirius", mux: "11919H", provider: "<N/A>", service: "Viasat Hockey Finland", hostname="192.168.1.41", username="philip", client="VLC/2.1.4 LibVLC/2.1.4"
The only differnce I can see is at the bottom - /api/mpegts/input/network_list -- 400.
RE: Rotor(Motor) Support Latest Information.
-
Added by Gary Brown about 10 years ago
o o I forgot about the epggrab function. even changing channel it seems to have priority over a channel and this is with and without rotor.
RE: Rotor(Motor) Support Latest Information.
-
Added by o o about 10 years ago
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"
RE: Rotor(Motor) Support Latest Information.
-
Added by o o about 10 years ago
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.
RE: Rotor(Motor) Support Latest Information.
-
Added by Philip Reynolds about 10 years ago
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.
RE: Rotor(Motor) Support Latest Information.
-
Added by Jaroslav Kysela about 10 years ago
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..
RE: Rotor(Motor) Support Latest Information.
-
Added by Jaroslav Kysela about 10 years ago
Some new commits in the tvh master source tree:
USALS grace time calculation fix (sorry, thinko):
Add Max Rotor Movement (seconds) to the DVB-S frontend configuration:
The initial grace timeout is not fixed yet..
RE: Rotor(Motor) Support Latest Information.
-
Added by o o about 10 years ago
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
RE: Rotor(Motor) Support Latest Information.
-
Added by o o about 10 years ago
Jaroslav Kysela wrote:
Some new commits in the tvh master source tree:
USALS grace time calculation fix (sorry, thinko):
Add Max Rotor Movement (seconds) to the DVB-S frontend configuration:
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.
RE: Rotor(Motor) Support Latest Information.
-
Added by o o about 10 years ago
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
RE: Rotor(Motor) Support Latest Information.
-
Added by Jaroslav Kysela about 10 years ago
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..
RE: Rotor(Motor) Support Latest Information.
-
Added by o o about 10 years ago
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?
RE: Rotor(Motor) Support Latest Information.
-
Added by Philip Reynolds about 10 years ago
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'. 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!
I just tried something
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.