Tvheadend

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.

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.

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/boards/5/topics/12194?r=13343#message-13343

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

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

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.

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!

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

Have a good weekend,
Phil.

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!

Hi Gurabli,
sorry for the late reply.

Maybe you've tried already, but timeshifting does work- I've used it on a few occasions. It's something I rarely use though, so maybe you should give it a good test.

Best regards,
Phil.

So I installed XBMCBuntu and after that TVHeadend 3.4.28 with that commands

curl http://apt.tvheadend.org/repo.gpg.key | sudo apt-key add -
sudo apt-add-repository http://apt.tvheadend.org/stable
sudo apt-get update
sudo apt-get install tvheadend

My TeVii S660 is recognized as

Montage Technology DS3000

The problem now is to get the rotor working. The pictures here in this thread are no where to be found in my configuration windows. So I'm a bit off here. In the Satellite.config windows I have put two lines in it. One with switchport 2 (for Astra 19.2) and the other with switchport 3 (for Astra 28.2). But from there on I do not know if this is correct or if there are other configuration windows hidden in which I can tell the server to send a command for turning to 2 or to 3.

Hans Gruber vielleicht wrote:

So I installed XBMCBuntu and after that TVHeadend 3.4.28 with that commands

curl http://apt.tvheadend.org/repo.gpg.key | sudo apt-key add -
sudo apt-add-repository http://apt.tvheadend.org/stable
sudo apt-get update
sudo apt-get install tvheadend

My TeVii S660 is recognized as

Montage Technology DS3000

The problem now is to get the rotor working. The pictures here in this thread are no where to be found in my configuration windows. So I'm a bit off here. In the Satellite.config windows I have put two lines in it. One with switchport 2 (for Astra 19.2) and the other with switchport 3 (for Astra 28.2). But from there on I do not know if this is correct or if there are other configuration windows hidden in which I can tell the server to send a command for turning to 2 or to 3.

The 2 and 3 are the settings in the rotor to get to the position I saved in the rotor because everything else don't work here (GPS coordinates and such things, just the numbers I saved in the rotor work!)

I seem to have trouble with my rotor in tvheadend, I use the latest github version so uses all the latest patches for rotor.

I noticed that I can manually turn the motor with the dvbutils program gotox

to turn the dish correctly i have too close tvheadend, run gotox form dvbutils and then reload tvheadend, having the configuration set to universla lnb instead of gotox or usals .

looking at the code for dvbutils gotox program it uses the function dvbsec_diseqc_goto_rotator_bearing from libdvbsec - command byte 6E, , this may be why some people have problems with tvheadend, its the initial installation zero setting that is stored in the motor, ie for me it was 0.8 degrees West thor satellites that is the reference, the command 6E goes to satellite positions based on that reference position stored at installation. There is the calulations for the 2 bytes the 6E command needs on dvbsec_diseqc_goto_rotator_bearing code

Trevor Tate wrote:

looking at the code for dvbutils gotox program it uses the function dvbsec_diseqc_goto_rotator_bearing from libdvbsec - command byte 6E, , this may be why some people have problems with tvheadend, its the initial installation zero setting that is stored in the motor, ie for me it was 0.8 degrees West thor satellites that is the reference, the command 6E goes to satellite positions based on that reference position stored at installation. There is the calulations for the 2 bytes the 6E command needs on dvbsec_diseqc_goto_rotator_bearing code

Have you tried to fill correctly all values ? Also, you may enable trace for "diseqc" subsystem and check the "rotor USALS goto" lines.

I also added the "Zero Sat Longitude" settings to USALS now (v3.9-2190-g1b193a3).

still having problems with diseqc rotor control with tv headend

I have been doing a few tests and noticed that the tvheadend the E0 31 6E nn nn
28.2 Astra 2 = e0 b0
13 Hotbird = e0 5b

where the dbvutils gotox/dvbsec_diseqc_goto_rotator_bearing the E0 31 6E nn nn
28.2 Astra 2 = e1 c3
13 Hotbird = e0 d0

Trevor Tate wrote:

still having problems with diseqc rotor control with tv headend

The tvh function to calculate the position values is here:

https://github.com/perexg/tvheadend/blob/master/src/input/mpegts/linuxdvb/linuxdvb_rotor.c#L210-L280

It takes in account the position of dish. Maybe your rotor already does this calculation and expects only the satellite position number?
The dvbsec_diseqc_goto_rotator_bearing() function only converts the angle value to two-byte format.

https://github.com/tufei/dvb-apps/blob/master/lib/libdvbsec/dvbsec_api.c#L519-L551

quite possibly so, I have a dreambox 800 running enigma and i originally set the dish up with strongest satellite closest to 0' which was thor at -0.8 West

http://www.eutelsat.com/files/contributed/satellites/pdf/Diseqc/associated%20docs/positioner_appli_notice.pdf
chapter 3.9

by the way, is the gotox function in tvheadend working as i have stores positions in my motor, ie pos 1 = 28.2 and pos 2 = 13 hotbird, i put these and select gotox instead of usals and it does not seem to work either?

the only way i can turn the dish to the correct position is to use the gotox command

my motor is a technomate tm2600 http://www.technomate.com/products/TM%252d2600.html
looks pretty standard?

Trevor Tate wrote:

quite possibly so, I have a dreambox 800 running enigma and i originally set the dish up with strongest satellite closest to 0' which was thor at -0.8 West

http://www.eutelsat.com/files/contributed/satellites/pdf/Diseqc/associated%20docs/positioner_appli_notice.pdf
chapter 3.9

by the way, is the gotox function in tvheadend working as i have stores positions in my motor, ie pos 1 = 28.2 and pos 2 = 13 hotbird, i put these and select gotox instead of usals and it does not seem to work either?

the only way i can turn the dish to the correct position is to use the gotox command

The GOTOX command should work, again with --trace diseqc you may track which diseqc commands are sent to your rotor. Also, don't omit to fill the Satellite Longitude in for 19.2E = 19.2, 0.8W = -0.8 to correctly calculate rotation delay time in tvheadend.

finally got tvheadend to rotate my dish correctly, using USALS I have used the ideas in the dvbsec_diseqc_goto_rotator_bearing function from dvbsec into linuxdvb_rotor.c

Maybe you could add option for this in tvheadend for just satellite position number instead of the calculations you have, I would be interested to know how you did your satellite motor installation.

got another issues now is that the epggrab is swapping between satellites, my motor must be doing overtime rotating,

Also another feature that would be great is a nudge factor for n steps east or n steps west after moving to satellite for signal optimisation. When I use my dreambox i have saved positions which when first set up using USALS and using the SAT FIND utility couple of steps east or west until the peak signal was achieved, really helps with some weak transponders that intermitantly lock. Everytime I had strong winds i know i would have to nudge the usals positions the dish got to.

Changed from Mythtv to Tvheadend a couple of weeks ago and was happy to see how well the rotor support was working. But today I did an update and it stopped working to build: 3.9.2212~gb87eb89~trusty. Noticed that they changed something in usals. A line "zero sat longitude" has been added since. To be honest don't know what to add here.
!!
Somehow it remind me when I was using mythtv. After a while got the same problem
[[https://code.mythtv.org/trac/ticket/10845]]
Maybe I simply have to put the right parameters in new line zero sat longitude?!

Trevor Tate wrote:

finally got tvheadend to rotate my dish correctly, using USALS I have used the ideas in the dvbsec_diseqc_goto_rotator_bearing function from dvbsec into linuxdvb_rotor.c

Enter new issue to our tracker with your code to check.

Maybe you could add option for this in tvheadend for just satellite position number instead of the calculations you have, I would be interested to know how you did your satellite motor installation.

I don't have a motor - I'm tvh developer.

got another issues now is that the epggrab is swapping between satellites, my motor must be doing overtime rotating,

Create another issue. I agree that it would be good to sort muxes according positions for epggrab.

Also another feature that would be great is a nudge factor for n steps east or n steps west after moving to satellite for signal optimisation. When I use my dreambox i have saved positions which when first set up using USALS and using the SAT FIND utility couple of steps east or west until the peak signal was achieved, really helps with some weak transponders that intermitantly lock. Everytime I had strong winds i know i would have to nudge the usals positions the dish got to.

You mean a global nudge settings for all positions ?

Richard Bolster wrote:

Changed from Mythtv to Tvheadend a couple of weeks ago and was happy to see how well the rotor support was working. But today I did an update and it stopped working to build: 3.9.2212~gb87eb89~trusty. Noticed that they changed something in usals. A line "zero sat longitude" has been added since. To be honest don't know what to add here.
!!
Somehow it remind me when I was using mythtv. After a while got the same problem
[[https://code.mythtv.org/trac/ticket/10845]]
Maybe I simply have to put the right parameters in new line zero sat longitude?!

There are no changes if you keep the zero sat longitude as zero:

-  double pos = TO_RAD(lr->lr_sat_lon);
+  double pos = TO_RAD(lr->lr_sat_lon - lr->lr_zero_lon);

As you can see, if lr_zero_lon is 0, then the diseqc command computation is same as before. I guess, that you hit another problem.

You mean a global nudge settings for all positions ? maybe per satellite, not all satellites would need it i think

Before trying to find which other problem hit me I would like to try a build from two weeks ago, but how to obtain a previous unstable version?

Build it from source using git checkout <hash> - that allows you to move to a specific version before you compile. Clone it as per the instructions, then checkout that specific version immediately before running configure or Autobuild.sh.