Add support for controlling DiSEqC GOTOX/USALS rotors #238

wants to merge 3 commits into


None yet
10 participants

jsm174 commented Jan 27, 2013

This adds support for controlling DiSEqC GOTOX/USALS rotors. If a rotor type is defined in the "Satellite config" table, dvb_fe_tune logic will be altered, ie appropriate DiSEqC commands will be executed (to control the rotor), a rotor_delay timer is armed, and after the timer is executed, the remaining dvb_fe_tune logic will continue.

jsm174 added some commits Jan 27, 2013

Fix htsmsg_json_write() to write HMF_DBL values correctly. Update hts…
…msg_get_dbl() to handle string and int values
Added Rotor latitude, longitude, and delay to Adapter configuration. …
…Added Rotor type and position to Satellite config. Latitude and longitude values are in decimal degrees. (Use negative values for south and west). Split dvb_fe_tune into two functions to support controlling rotor and waiting for rotor delay.

adamsutton commented Jan 27, 2013

@jsm174 thanks for this, I think we'll have to delay merging this for a bit as we're stabilising for 3.4 and also @andoma is working on a rewrite of the DVB internals so there could be some work in putting these together. Also I think there may be a few points that need looking into, but I've not got the time to do a decent job of reviewing the submission at the moment.

You can't change this as it will become locale dependent. For example in Sweden it will print as "3,1415" instead of "3.1415"

Same with strtod().

Any reason why misc/dbl.h won't work?


jsm174 commented on 0e8b006 Jan 27, 2013

Hello. I was using dbl to store latitude and longitudes. There is a precision issue occurring. If I enter a value of 1.4, it gets sent back to the webui (via htsmsg_json) as 1.3999999901.

I asked about this on IRC:


jsm174 replied Jan 28, 2013

I'm wondering if I should change my internal values to be strings.

Was TVH supposed to be locale independent, ie always decimal points for doubles?

Yeah well that's why I added the dbl.[ch] code in the first place to avoid locale issues (in particular in JSON)

Passing values as strings is probably OK i guess.


jsm174 replied Jan 28, 2013

Just asking the question.

I personally hate the idea of storing numbers as strings.

Looks like other c libraries (json-c) face the same locale issues.

I guess if my_double2str gets fixed, we'll be good. The HMF_STR case I added to htsmsg.c isn't really needed. I did however need the HMF_S64 case so integer values would be converted and not return HTSMSG_ERR_CONVERSION_IMPOSSIBLE.


adamsutton commented Feb 1, 2013

@jsm174 @andoma I guess there are two ways of tackling this. 1. Fix the conversion routines to be more accurate or 2. Just use integer storage to whatever significance is relevant and convert internally.


u32 x = round(dblval * 1000);
htsmsg_add_u32(m, "number", x);

if (!htsmsg_get_u32(m, "number", &u32))
float f = u32 / 1000.0;

  1. would obviously be cleaner and better going forward, 2. might be quicker to remove the rounding issues.

Just my 2 pence.

ovidiu31 commented Mar 2, 2013

Small request to this nice patch , please make it possible to work through diseqc switches.... also if is possible a larger description of how can be moved the motor

ovidiu31 commented Mar 9, 2013


Dear Jason please give us some basic tips of how its working this motor be more specific how do i issue commands to the motor to move the dish.


jsm174 commented Mar 9, 2013


Hello. This branch is based on the DiSEqC logic found in several different apps such as MythTV, VDR, rotor-control, and tune-s2. IMHO, tune-s2 was the most complete and correct solution. (I believe MythTV is currently broken.)

Anyway, to use this, go to the adapter configuration and enter the latitude and longitude of where your rotor is set up. (Use Google Maps to determine the latitude and longitude values -- negative for south and west values). You should also enter a rotor delay value -- how long to wait for rotor to get from start to finish before attempting to tune.

Next in the Satellite Config table, create a satellite (or select an existing one), select a rotor type, and enter the rotor position. If you use GOTOX for the rotor type, enter a value of 1-99 in rotor position. If you use USALS enter the latitude such as 98.0 (again negative values being west)

We've tested this in North America and it seems to be working properly.

I plan on making another branch with all the latest TVH updates -- I've seen a few sat conf mux fixes go in the past day or so.

Anyone else who reads this, if you experience any issues with the branch, please let me know. I would really like to fix it. I've seen an IRC mention where a user's adapter config was disabled when using this branch. I'd need more information to help.

Cjcr commented Mar 10, 2013

@jsm174 Hi,

I have got that problem. I have two dvb-devices and one dvb-t device. When I go to the "Adapters" tab, the config section is disabled for both dvb-s2 devices.

Please let me know what info you need for it and sent it.

Or if you want, can wait for a new branch with the latest tvh updates + diseqc1.2...



jsm174 commented Mar 10, 2013


Hello. We'll get this fixed. It has to be something minor. Could you tell me what browser you are using. If it's Chrome could you see if there are any JavaScript error messages in the console? Thanks

Cjcr commented Mar 10, 2013

That seems the problem. Look at this screenshot:

Same problem with Opera Browser (lubuntu)

Cjcr commented Mar 11, 2013

@jsm174 you have got any solution for it? seems a problem with regional chars (decimal parts or something)

@jsm174 Hi,

Thanks for this awesome patch!

I'm testing it in the UK, and it seems to work quite nicely, but there is an issue with initial scanning order...

I'm using GOTOX rotor type, and I've created a sat config for each of the sats I want to scan. This worked fine when I was initially setting it up as I let each one finish before adding the next one. However, as soon as I restart tvheadend (e.g. after a reboot), it starts scanning the muxes in a non-sat order... i.e. it's hopping from sat to sat instead of doing all the muxes on one sat, then the next, which makes it extremely slow and inefficient (and putting a lot of extra wear onto my rotor!).

Is there a way to define the sats so it does them one sat at a time, or does the mux scanning code need tweaking?



adamsutton commented Apr 8, 2013

@AdamLaurie The problem is that the mux scanner was not written with this in mind, it simply assumes all muxes can be treated equally. Now you could argue that might now be efficient even for a setup with a simple diseqc switch , but it is what it is (at the moment).

Since this won't be merged into master until after the DVB rewrite is complete (sorry still being worked on) you probably won't see a fix there to help for a while. But maybe @jsm174 or someone else could add the necessary code on top of this PR.

I don't think it would be that big a job.


@adamsutton thanks for the reply...

I took a look at the code and thought that maybe the solution was to simply sort tda_initial_scan_queue by satconf, but not being familiar with the code structure I have no idea if that's a sensible approach... Of course, we'll have the same problem when we hit 'Map DVB services to channels'...

I'm happy to have a go if @jsm174 is too busy, and if someone can give me a steer on this.



adamsutton commented Apr 9, 2013

@AdamLaurie yes and no, you really need to sort all the scan queues by satconf, else if someone enables idle scan they'll hit the same issue. Of course this causes the problem that you need to somehow stop it from creating a loop that leaves it only scanning the current satconf (i.e. you re-insert the scanned mux at the end of that satconf set, and thus before the rest).

So I think for SAT based tuners a different scanning mechanism will be needed entirely, I don't think its massive, but its not trivial either.

I think as a "hack" you could indeed just sort the initial scan Q and disable idle scanning, that would solve you're immediate issues.


jsm174 commented Apr 9, 2013

@AdamLaurie I'm actually working on creating another branch of this patch with the latest tvheadend code since it's been so long.

I'm also trying to rework the storage of latitude, longitude, and rotor position because of the json / double / locale issues. Hopefully that will fix @Cjcr's issues.

I will add code to sort the initial scan Q.

There should also be code to remember the last sat position, so it doesn't try to resend the diseqc commands and wait for the rotor delay during tuning.

-- Jason

@jsm174 excellent!

I'll try to keep an eye on the project so I can test it when you do the next push...


@jsm174 btw, I've found another little issue:

in diseqc_rotor_gotox (and presumably diseqc_rotor_usals) the delay of 15ms between powering up and issuing the steering command is insufficient for some dvb cards. I've only got two to test with, but I have a test rig in my office connected to a motor drive on a desk so I can see immediately if the commands are working or not...

The card that fails is a Hauppauge WinTV-NOVA-SE2 (it's FE identifies itself as "Conexant CX24116/CX24118"). The symptom is it will fail to steer for the first transponder scan, but will successfully steer for the second as by then it's been powered up for long enough to be 'alive' and notice the steering command. The fix is to up the 15ms sleep to 2500ms. Yes, that's not a typo! 2.5 seconds! I've done multiple tests and that's the shortest reliable period. :(

I hope this helps.



jsm174 commented Apr 10, 2013


Hello. Can you please check out:

It is the latest tvheadend (as of writing this) with rotor support. As per the JSON spec, I've added code to replace locale decimal points with periods.

If this works, I'll move on to @AdamLaurie with the sorting and delay.

Cjcr commented Apr 10, 2013

@jsm174 well, let me take a look ...

Cjcr commented Apr 10, 2013

Hi @jsm174,

I can confirm that this now works fine. I tested it with two satellite (Astra 19.2 and hotbird 13 e) with GotoX function and 10 seconds delay.

Well, another thing can be improved is the delay time. I think you can calculate a aproximate time based on the orbital position ... but again, the way is designed tvheadend maybe it's confusing for adding something like this (tvheadend seems isn't used satellite id like 0192, 0130, etc like other programs). But ok, this is a good start point!

Thank you! 👯


jsm174 commented Apr 11, 2013


Thank you. I'm glad it now works.

As for the delay, when I was looking at MythTV source to find DiSEqC rotor code, I remember seeing logic to estimate delay based on current and ending positions. I just need a way to store the current position. On startup I would just use the existing delay because the dish could be pointing anywhere.

To be honest, I'm not sure how far to take this patch with all the upcoming DVB changes. I'm hoping that rotor support is considered during the redesign.

Cjcr commented Apr 11, 2013


Yes, initial delay would be good for first tvheadend start because the dish will be pointing anywhere, as you said, but when change from one satellite to another would be great to optimize the time to wait adding a smart delay.

For example, currently, you need to set a long delay (like 20-30 seconds) if you want to change from Hispasat 30ºOest to 28º2East, but you need to wait the same time if you changed from Hotbird 13ºEast to Eutelsat 10ºEast and that's not good :)

To do this properly, you'd need to know:

Motor startup time
Time per step
Number of steps per degree
Motor settle time (some motors drive past the desired location and then reverse slowly onto spot)

I would think that to figure this all out will be impractical for most installation scenarios. I would suggest, to keep it simple, that you want two delays: one for start/stop, i.e. a 'master' delay and then one for 'per degree', which doesn't have to be super accurate but will still be better than having just one overall delay.

We'd then also need a field to specify the location in degrees for GOTOX types.

Cjcr commented Apr 12, 2013

@AdamLaurie And also need to know the current polarization (13v/18v) because with 18v the motor drives 2 times more fast than with 13v :)

@Cjcr actually he sets it to 18v in the goto command.

Cjcr commented Apr 12, 2013

@AdamLaurie Oh, excellent.


adamsutton commented May 10, 2013

I've been plodding along with DVb rewrite and I'm starting to think about the whole DVb-s hw setup inc switches and motors. If you have rotor behind switch does it matter what order you send commands in? Is diseqc broadcast through all ports of switch? Does that mean if you had multiple rotors they'd all get the same control commands?

Don't know if this kind of setup is likely or even possible? Still getting my head around diseqc.

I don't have any experience of switches so I can't comment on that specific issue.

I have found one new problem though - if you have a setup that has both Terrestrial and Satellite tuners, there is an issue with prioritisation. By that I mean that we should be prioritising channel delivery based on the 'flexibility' of the source. A satellite receiver can only provide one channel at a time so should be the lowest priority when serving a channel, whereas a Terrestrial receiver can provide any channel from a particular MUX, so channels on a MUX that it's already tuned to should be the highest priority.

For example, on my setup I have 4 Terrestrial receivers and one Satellite. Sky News is available on all five sources, but the first client to request it will currently be allocated a feed from the Satellite receiver, thereby blocking all other Satellite channels.

Cjcr commented May 12, 2013

Do the diseqc config in a list and allow to the user decides the order of the diseqc commands for everything. Is the best way to do it, I'm sure. If you want to know more, let me know.


adamsutton commented May 12, 2013

Well that is of course nonsense ;) all dvb systems work the same in that
respect. One tuner receives a mux and thus all channels within it, and tvh
will always use a tuner already receiving mux with necessary service before
looking elsewhere.

If you have a reason to prefer your t tuner you can just prioritize it.

On May 12, 2013 2:57 PM, "Adam Laurie" wrote:

I don't have any experience of switches so I can't comment on that
specific issue.

I have found one new problem though - if you have a setup that has both
Terrestrial and Satellite tuners, there is an issue with prioritisation. By
that I mean that we should be prioritising channel delivery based on the
'flexibility' of the source. A satellite receiver can only provide one
channel at a time so should be the lowest priority when serving a channel,
whereas a Terrestrial receiver can provide any channel from a particular
MUX, so channels on a MUX that it's already tuned to should be the highest

For example, on my setup I have 4 Terrestrial receivers and one Satellite.
Sky News is available on all five sources, but the first client to request
it will currently be allocated a feed from the Satellite receiver, thereby
blocking all other Satellite channels.

Reply to this email directly or view it on GitHub

Sorry, I explained that very badly - what I was really getting at is with a satellite system (particularly steerable ones) you tend to have hundreds of MUXes and the channels you're interested in tend to be dispersed amongst them, and since the dish can only be pointed at one sat and tuned to one frequency/polarity at a time then you only have the choice of a small set of channels at any given time. A terrestrial system, on the other hand, will have a fixed antenna that is receiving all channels all the time so it's just a question of having enough tuners to cover all MUXes. In my area that number is 5. If I have 5 terrestrial tuners then any number of clients can tune to ANY of the terrestrial channels.

If you're saying I can already prioritise the terrestrial tuner over the satellite then we're good! Is that the "Extra priority" field in the "TV Adapters/General/Adapter Configuration" tab?


adamsutton commented May 13, 2013

@AdamLaurie yes that makes more sense :) Though ofc (ignore the rotor issue) with a multiswitch+lots of tuners you can get the same situation with DVB-S. The main issue with DVB-S is the shear number of services that are carried (most of which are admittedly crap!). And that does indeed lead to often finding that the total number of muxes you need to get decent coverage of required services is quite high. Use of a rotor obviously adds another dimension (or two) since you now get even more services, but also the time to start them is not just down to tuning times, you've actually got to wait for physical movement of the dish.

Yep that's the one, the only thing that's a tad confusing is it works in reverse. You need to set a higher number on the tuners you want to de-prioritise.

Hello. I am a friend of jsm174. I persuaded him to add rotor support for tvheadend. ;-) He is a very nice guy! I would like to help where possible with adding more support for satellite to tvheadend. I have diseqc switches and rotors to offer testing of software. I also frequent 2 satellite forums where I can find detailed expert information if needed. I have read many topics related to diseqc in the forums. I know forum users who are very knowledgable with linux down to device driver level and they are always helpful.

I have read in the past that there are some best practices when it comes to device connections. I believe these best practices are what is supported by most commercial DVB satellite receivers. For instance, diseqc switches should be physically connected between the rotor and the LNB's. Another best practice when driving 2 separate rotors off of the same DVB card or satellite receiver is to program rotor #1 for stored positions in the range of 30-99. And rotor #2 for LAT/LONG positioning. The diseqc rotor commands are received by both rotors but only the appropriate rotor responds. I have this configuration in place today.

Please let me know what questions you would like answered and I will do my best to research the correct information. Thanks.


adamsutton commented Jun 23, 2013

@jsm174 @andoma I'm just getting around to adding rotor support to the new DVB code and so thought I should review topics discussed here. I should point out that I have found a buf in the str2double code, it can actually produce wildly wrong numbers, so I'll fix that.

As for the issue of 1.4 this is a fundamental issue with floating point, they're imprecise and not garaunteed to be able to accurately represent all numbers. Try it:

double d = 1.4;
printf("d = %0.16lf\n", d);

That's not a bug in the dbl code. Some higher level languages/libs use non-standard techniques for storing floating point to overcome some of these limitations (though they have penalties associated). But in most cases this shouldn't be an issue as long as you round to a sensible precision before display.

adamsutton added a commit to adamsutton/tvheadend that referenced this pull request Jun 25, 2013

linuxdvb: added rotor GOTOX/USALS implementation
This is taken from PR #238. I still don't have the movement duration stuff
done. And now I really need to think more about the config.

jsm174 commented Jun 25, 2013

@adamsutton That's fantastic news!

In my rotor-support-2 branch I decided to continue using snprintf when going from JSON back to dbl. I use the locale to convert the system decimal point (comma, etc) to a decimal point and vice vera. I'm still not 100% satisfied with the approach but it has been working well:



adamsutton commented Jun 25, 2013

@jsm174 I've started to integrate here,, but I'm still trying to sort out configuration (i.e. UI) before its actually usable.

@adamsutton Thank you for beginning to integrate rotor support!

@jsm174 Hi Jason, I've installed your rotor-support-2 branch with my TM-2600 motor. I initially added 0.8W to sort the alignment of my dish/motor. I had USALS selected as my rotor type in satconfig.

The motor moved as expected and I managed to tune to a channel but whenever I try and add another satellite from the list the motor doesn't move when I try to tune to any of the multiplexes. If I change the satconfig to GOTOX then the motor seems to move back to 0 then to 0.8W no matter what satellite is added.

I can only imagine I'm doing some wrong with my intial config. If it wouldn't be too much hassle could you give me some help, tips, or a simple setup guide for adding multiple satellites?

Am I also right in thinking it isn't possible to add a single multiplex for a single satellite rather than having to "Add DVB Network by location" which adds all the listed multiplexes for a single satellite.

@ant-thomas I will try to help you. I am Jason's main tester.

You should be able to add single multiplexes for single SAT's.

Do you have and DISEQC switches in your setup? Or just a single motor connected to your DVB card?

I have a PROF 7500 tuner connected to an SG-2100 that I use for USALS. I also have a GBOX for moving a C-BAND dish that I use for GOTOX.

@signalquest Thanks for the reply.

I don't have any switches. DVB card is connected directly to the motor (Card: TBS 8920, Motor: Technomate TM-2600)

It looks like it supports USALS and GOTOX

I've tested the movement of the motor/dish with the xdipo program ( which moves the motor correctly.

@signalquest After re-reading the guide that @jsm174 posted further up I have figured things out. I wasn't setting up my satconf correctly. All sorted now.

@ant-thomas Great! I am glad it is working for you! I am happy more people are testing/using this. I look forward to it being in Master.

gurabli commented Jul 21, 2013

Hi! I'm new to Openelec and Tvheadend, so sorry for n00b questions: I would like to use Openelec with tvheadend to control my motor using a TBS6981 card. Is this supported or not? How hard is to configure this for me (without any Linux knowledge at all)?
Thank you!

@gurabli Without any Linux knowledge at all you might struggle. I've never used TVHeadend with an Openelec build but if you want motor support you need get hold of the rotor-support-2 branch of TVHeadend ( by @jsm174 and compile and install that version of TVHeadend. Once that's installed follow the instructions above (#238 (comment))

@gurabli I agree if you are not comfortable on a command line it might be daunting for you, but I think if you like to learn new technical things go for it! We can answer questions for you and this forum is a good resource too (


CSchlipp commented Jul 21, 2013

@gurabli Openelec does not allow you to compile tvheadend (or anything
else) while running. There is no apt-get, only a limited amount of plugins.
You would have to compile your own complete openelec image which
includes tvh, xbmc, etc. pp...
Or you can wait until this change is included in master and a new
version of openelec is released, which normally also includes the latest
tvh release.

@gurabli Another option would be to use XBMCbuntu and then install/compile TVHeadend yourself. Or go for a minimal install of ubuntu then install XBMC and TVHeadend yourself. With a lack of linux knowledge your best chance is probably to go down the XBMCbuntu route if you want motor support before it hits master.

gurabli commented Jul 22, 2013

Thank you all for your detailed answers! Few years ago I would have jumped onboard to this challenge, but now we have a baby coming in few months and that means much less time for computing. But I would be more then happy to join the testing. This time, I'm afraid, I have no time for this:(

I wonder what would you say, I know it is the kind of question that devs hate, but when do you expect to have proper rotor support implemented to the Master? Are we talking about weeks, months or next year maybe category? I really would like to use my HTPC with a DVB-S2 card and not to buy an STB, but I would very much like to have a stable system where the rotor is working the same as it would work with any STB. Will it be possible?

Keep up with the good work, and thanks for all your hard time devoted to this project!

On 25/06/13 17:26, Adam Sutton wrote:

@jsm174 I've started to integrate here,,
but I'm still trying to sort out configuration (i.e. UI) before its
actually usable.

I haven't been watching the repo, but if the new channel scanning order
thing is sorted I'll be happy to update and test... My rotor has 7 sats
programmed into it currently, and I was planning to put several more in
once this is bottomed out...



Adam Laurie Tel: +44 (0) 20 7993 2690
Suite 117 Fax: +44 (0) 20 7691 7776
61 Victoria Road

@AdamLaurie Jason and I talked about this sorting issue today. He plans to try to work on it this coming Friday. I think this would be a great thing to fix as well. Thanks.

@signalquest Awesome! I look forward to testing it... Unfortunately I'm off on vacation Monday, so I won't be in a position to do any actual testing until I get back in early August, but I'll take a look as soon as I get a chance. I will be checking email etc though, so if there's any discussion required I should be able to take part... Thanks guys, and talk soon!


adamsutton commented Jul 25, 2013


Bare in mind that if you really want to work on getting this into master, you're going to have to look at the new code. I have already included rotor support based on this patch, although its far from complete and certainly untested at this stage.

I've not yet dealt with the sorting issues, though I will try and look into that when I find time. Though I think it will be slightly easier in the new framework (I hope).


@adamsutton Thanks for your feedback. I will discuss with Jason about looking at your code. I can help you test your code if you would like. Master is the ultimate goal. Thanks again.

I just spoke with @jsm174 and he does not want to add more to his code since @adamsutton has pulled it into his new code.

@adamsutton can we start testing your code now? Maybe it can help you?


adamsutton commented Jul 26, 2013

@signalquest I would greatly appreciate anyone testing it. Though you must bare in mind I've still got quite a bit to do to make it user-friendly (the config/UI etc.. is still not ideal). But feel free to try it and shout if you get stuck.

Best to get me in the IRC channel.

having Amiko 3800 Usals/goto X motor...ill try to test it too adam.


adamsutton commented Nov 16, 2013

I'm closing this, the rotor support was migrated into rewrite which has now been merged to master. Much of the code was stolen from @jsm174 , with the boiler plate stuff added by me.

Any feedback welcome.

@adamsutton adamsutton closed this Nov 16, 2013

Hi All,

I finally got around to updating my box and installing this, but I can't figure out how to set up "goto" satellite entries with the new code - is it documented somewhere?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment