Bug #2298: USALS rotor does not work - Tvheadend

Bug #2298

USALS rotor does not work

Added by o o about 10 years ago. Updated about 10 years ago.

Status:

Fixed

Priority:

Normal

Assignee:

Category:

DVB

Target version:

Start date:

2014-09-13

Due date:

% Done:

Estimated time:

Found in version:

3.9.1462

Affected Versions:

Description

I have used a slightly rewritten version of JSMs excellent rotor patch for the 'old' version of tvheadend without any issues for a long time. Now it is time to get the rotor working with the 'new' tvheadend.

I defined two satellite positions, Thor 0.8W and Sirius 4.8E. The initial scan for services went fine. No duplicated services, and the dish moved to the correct positions. However, when I tried to switch to the different channels, nothing happens. The stream is stuck in "testing" state and the dish does not move to the correct position.

Pseudo code for a simple algorithm for tuning to a service would be:

if (new_satellite_position != old_satellite_position) {
old_satellite_position = new_satellite_position;
move the dish to the new_satellite_position;
wait (abs(new_position - old_position)*time_it_takes_to_move_one_degree);
}
tune to service

But when I read the code, there are some timeouts and other stuff that I really don't understand (I haven't code commercially for some years )

I have enabled debugging, but I didn't find anything of interest in the debug log.

If you want me to enable some special debug flags and try again, I'm happy to do that.

History

Updated by Gurabli Gurabli about 10 years ago

Sorry to hear this. I was hoping that USALS is fully working by now. Can you please confirm that it is working fine in any of the TVH versions? Which version should I try? Any guide or help that could show me how to set this up?

Updated by Digi Hoe about 10 years ago

But when I read the code, there are some timeouts and other stuff that I really don't understand (I haven't code commercially for some years )

What time have you set for your USALS motor?

Updated by o o about 10 years ago

I have a STAB HH90 rotor (Rotation Speed 2.4°/s (18 V); 1.5°/s (13 V)). The timeout is set to 500ms per degree.
Perhaps I have missunderstood the meaning of the timeout? The GUI says millis/degree and I use 500ms to be on the safe side.

In the /src/input/mpegts/linuxdvb/linuxdvb_rotor.c at line 274, the voltage is forced to 18V for quicker movement.
I can try to increase the timeout to see what happens in case the voltage is not correctly set to 18V.

Thanks for your help.

Updated by o o about 10 years ago

The calculation of the timeout is probably the cause of the problem (shall try when I come home).
I have defined two positions 4.8 and -0.8 and a timeout of 500ms per degree (at 18V the rotor moves 2.4 degrees per second). The rotor type is configured as USALS.

/src/input/mpegts/linuxdvb/linuxdvb_rotor.c:

static int
linuxdvb_rotor_grace
( linuxdvb_diseqc_t *ld, dvb_mux_t *lm ) {
linuxdvb_rotor_t lr = (linuxdvb_rotor_t)ld;
if (!ld->ld_satconf->lse_parent->ls_orbital_dir || lr->lr_rate == 0)
return 120;
int curpos = ld->ld_satconf->lse_parent->ls_orbital_pos;
if (ld->ld_satconf->lse_parent->ls_orbital_dir == 'W')
curpos = -(curpos);

return (lr->lr_rate*(deltaU32(curpos, lr->lr_position))+999)/1000;

}

linuxdvb_rotor_grace() is called from linuxdvb_rotor_usals_tune().

I my case the delta will be (500*(0 + 4)+999)/1000 = 2.999 seconds which will be casted to 2 seconds as int is returned. But, my rotor needs 5.6/2.4 = 2.33 seconds to move 5.6 degrees. The timout value must be rounded up to 3 seconds.

When using USALS shouldn't the variable double lr_sat_lon be used for calculating the "rotor" timeout instead?
Is the linuxdvb_rotor_grace function written for GOTOX configurations only?

As I'm a bit rusty so it might be that I have completely missunderstood the code :-)