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

Ron L

Can you get someone to go outside and watch the dish to see if it turns when you flip between usals and not usals? If the dish doesn't move between config changes and it works on Universal but not usals only thing I can think of is 22Khz. Might not be selecting the band on the lnbf.

Not sure how accurate the signal strength indicator is in TVH. I don't think may of the kernel drivers give accurate signal strength info.

Philip Reynolds

Hello Jaroslav,
my libm.so.6 is in /lib/x86_64-linux-gnu/ I'm getting the same error as Trevor.

Is it possible to change it somehow?

Thanks,

Phil.

Jaroslav Kysela

Philip Reynolds wrote:
> Hello Jaroslav,
> my libm.so.6 is in /lib/x86_64-linux-gnu/ I'm getting the same error as Trevor.

> Is it possible to change it somehow?

No idea, -lm should work when gcc and libc is configured properly.

http://www.linuxquestions.org/questions/programming-9/what-exactly-does-the-lm-option-of-gcc-787841/

EDIT: You may try to add the /lib/x86_64-linux-gnu path to library search patch: -L/lib/x86_64-linux-gnu


gcc -DROTOR_TEST -L/lib/x86_64-linux-gnu -lm -o rotor_test ./src/input/mpegts/linuxdvb/linuxdvb_rotor.c

Philip Reynolds

Hello again,
well, whatever I try it wont compile. Ubuntu is using libm-2.19.so if that makes a difference.
If you have time, could you test these values-

./rotor_test 60.64 24.87 115 -0.8 (if -0.8 is correct for west?)?

These are the exact values used in 2248 and 2263.

Thanks for your patience,
Phil.

Jaroslav Kysela

Philip Reynolds wrote:
> Hello again,
> well, whatever I try it wont compile. Ubuntu is using libm-2.19.so if that makes a difference.
> If you have time, could you test these values-

> ./rotor_test 60.64 24.87 115 -0.8 (if -0.8 is correct for west?)?

It gives wrong values, but I found the culprit so fix is in v3.9-2274-g932ade3 .

Philip Reynolds

You are the man:)

That was it, thank you very much.

Best regards,
Phil.

Trevor Tate

latest tvheadend git seems to be working for me now (using my extra bit of code i put in), not sure if proper usals is working though, and still cant get the test piece compiled
am running linuxmint 64bit here

wonder why my rotor just takes direct angles, going to test with lon and lat values in tommorow

(at first it did not work, but changed the rotor delay setting to 5 seconds instead of 120, knowing my dish was at position) for first rotor tune, it then worked on, went nicely to 13 hotbird and back to 28.2

Cheers

Trevor Tate

This did the trick, the -lm needs to be at the end (a few google searches sorted this!)
gcc -DROTOR_TEST -o rotor_test ./src/input/mpegts/linuxdvb/linuxdvb_rotor.c -lm

Trevor Tate

perhaps regarding the usals, I wonder if its to do with installation.

Motor at hardware zero postion
Install Satellite for strongest signal at satellite closest to Zero (South), which was -1'W Thor satellite, tune for highest signal strengh

What then I think i did is store zero position on dreambox, does this actually issue the command 0x6F re calculate satellite positions to motor? so the motor now takes direct angle of satellite, not calculated maths position with reference to south.

But then again i think i often installed new images on my dreambox and used usals with just longitude and lattitude, it found the signal (I wonder if i did a goto 0 command in dreambox and store satellite zero (recalulate) thus adjusting back to direct angles.

need to do some further testing i think and get my dreambox out

Ron L

I don't remember ever seeing altitude in any of the old receivers I had.

On the old code if initial rotor grace time was 120 seconds it would never tune. Even if the dish was parked on the correct sat. I think the maximum I could set it at was around 15 or 20 seconds. Since then some time out options have been added to streams so playing with them might allow a longer initial rotor delay time. Regardless 120 seconds is probably way longer than you want or need for a default setting. The risk of setting it too short is that it may lock something as it passes by other satellites and add some services to a MUX that don't belong there. That happens to me fairly often as I spin my dish with a stand alone positioner. Other than making a bit of a mess of the services list it doesn't break any channels. My DVB card blindscans so it'll lock anything on the same frequency +/- 10Khz and same polarity. If you need to specify SR or SYSTEM to get a lock your chances of locking things on the move is considerably lower.

Trevor Tate

me neither, never seen altitude on receiver, on the rotot test code it makes no difference to me, maybe if you are at a very high altitude it makes a difference, im am 12 metres above sea level, dish is about 4 metres above that, 16 metres is same angle as 0

Jaroslav Kysela

Note that enigma2 uses always zero altitude. But it seems that it affects little the results for altitudes above 1000m - so I added another configuration option.

Ron L

I'm finding there is a bit of lag from the time the command is sent until the dish starts to move. Makes the grace time for short hops a bit too short. If you try to compensate by increasing mills/deg then long hops get too long a grace time. I added 2 seconds to the rounding issue line and I'm now able to dial in the grace time pretty much perfectly. If it tries to tune before the dish lands on it's spot you end up having to wait for it to time out and restart. If you guys notice long channel changes on 2 degree moves maybe check that out.

Jaroslav Kysela

Ron L wrote:

> I'm finding there is a bit of lag from the time the command is sent until the dish starts to move. Makes the grace time for short hops a bit too short. If you try to compensate by increasing mills/deg then long hops get too long a grace time. I added 2 seconds to the rounding issue line and I'm now able to dial in the grace time pretty much perfectly. If it tries to tune before the dish lands on it's spot you end up having to wait for it to time out and restart. If you guys notice long channel changes on 2 degree moves maybe check that out.

OK, I added "Min Rotor Time (seconds)" parameter for this correction. It's in v3.9-2278-g7a16e29 .

Levente Cseh

I just set up a new server, and used the 3.9.2275~g066b273 version. It now works perfectly for me. Channel zaps are very fast between channels on different satellites. I'm using 5 orbital positions, (13E, 16E, 19.2E, 28.2E, 28.5E) on a Cine S2, 2 DVB-T tuners, and 2 types of IPTV streams, both multicast and HTTP.

The only problem I have is, that when a scan is ongoing, the server response is very slow. Although I have an i3-2120 @3.3GHz with 4Gb of RAM. What would be the reason for this?

Ron L

Jaroslav Kysela wrote:
> Ron L wrote:
> > I'm finding there is a bit of lag from the time the command is sent until the dish starts to move. Makes the grace time for short hops a bit too short. If you try to compensate by increasing mills/deg then long hops get too long a grace time. I added 2 seconds to the rounding issue line and I'm now able to dial in the grace time pretty much perfectly. If it tries to tune before the dish lands on it's spot you end up having to wait for it to time out and restart. If you guys notice long channel changes on 2 degree moves maybe check that out.
>

> OK, I added "Min Rotor Time (seconds)" parameter for this correction. It's in v3.9-2278-g7a16e29 .

Awesome. I can dial in the grace time perfectly with that.

Adam Laurie

I wanted to be able to set up my rotor positions without having to revert to unplugging and re-plugging a standard sat receiver, and just do everything from the command line, so I resurrected an old

project of mine:

http://www.alcrypto.co.uk/satmap/

This has a python command line utility called 'diseqctool.py' which allows you to not only steer your dish, but also to search for specific feeds and center the dish on the strongest signal. I use this

in conjunction with the GOTOX steering mode. Source code lives here:

https://github.com/AdamLaurie/satmap

Running the command with no arguments gives you the help:


$ ./diseqctool.py 

Usage: ./diseqctool.py <COMMAND> [ARG(s)] ... [<COMMAND> [ARG(s)] ... ]

  Commands:

     ADAPTER <#>                                      Set DVB adapter no (Default is 0)
     DEMUX <DEVICE>                                   Set DVB Demux device (default is '/dev/dvb/adapter0/demux0')
     EAST <'STEP'|'TIME'> <#>                         Drive EAST for # steps or seconds (TIME 0 drives to end stop)
     FE <DEVICE>                                      Set DVB Front End device (default is '/dev/dvb/adapter0/frontend0')
     FIND <FREQ> <'H'|'V'> <RATE> <'EAST'|'WEST'>     Find and centre on active signal
     FREQ <FREQ>                                      Set Frequency in Hz (default is 10700000)
     GOTO <#>                                         Goto stored satellite position #
     INFO                                             Show Front End device info
     LIMIT <'EAST'|'WEST'>                            Set EAST or WEST motor drive end stops
     POLARITY <'H'|'V'>                               Set Horizonal or Vertical polarity (default is 'H')
     POWER <#>                                        Power up positioner motor for # seconds
     SCAN <TYPE> <'EAST'|'WEST'> <STEPS> <LOGFILE>    Perform frequency scan and log results
     SIGNAL                                           Show current status of receiver
     STATUS                                           Show current status of positioner motor
     STEER <DEGREES> <'EAST'|'WEST'>                  Steer to angle - e.g. 13.0 EAST for HotBird
     STOP                                             Stop positioner motor
     STORE <#>                                        Store current position as satellite #
     SYMBOL <RATE>                                    Set Symbol Rate (default is 22000000)
     TUNE                                             Tune DVB Receiver (default is 10700000 Hz, Horizontal, Symbolrate 22000000)
     WEST <'STEP'|'TIME'> <#>                         Drive WEST for # steps or seconds (TIME 0 drives to end stop)

  Commands will be executed sequentially and must be combined as appropriate.

  Note that not all cards provide power all the time, so you may need to bracket
  steering commands with POWER to enable motor - e.g.

    ./diseqctool.py power 5 west step 50 power 30

  Timings will vary with equipment, but as there is no way for Diseqc 1.x compliant
  hardware to tell when a positioning command has finished, you must ensure that
  power is made available for the maximum possible duration of any movement. EAST/WEST
  STEP command are self powering (# + 1 seconds).

and here is an example of setting up a satellite (Hotbird at 13.0 East):

First, go to your tvheadend control panel and disable your sat receiver card so that the python script can control it.

Now we can check that we can talk to the card (I have 4 TV tuners and a sat receiver, so my sat card is adapter number 4):

$ ./diseqctool.py adapter 4 info Setting adapter to 4 (/dev/dvb/adapter4) OK Device: /dev/dvb/adapter4/frontend0 Name: STV090x Multistandard Type: QPSK (DVB-S) Min Freq: 950.000 MHz (10700000) Max Freq: 2150.000 MHz (12750000) Freq Step: 0.0 MHz Freq Tolerance: 0.0 MHz Min Symbol Rate: 1 MSym/s (1000000) Max Symbol Rate: 45 MSym/s (45000000) Symbol Rate Tolerance: 0 ppm Notifier Delay: 0 ms Capabilities: Auto inversion Auto FEC QPSK 2G modulation

The first thing I'll do is steer to a known position - this could either be a satellite that's already configured, or as in this case, the specific location the satellite should be - 13.0 degrees east:

$ ./diseqctool.py adapter 4 power 5 steer 13.0 east power 30 Setting adapter to 4 (/dev/dvb/adapter4) OK Powering motor for 5 seconds - OK Steering to 13.00 EAST - OK Powering motor for 30 seconds - OK

Note that I apply power before and after the STEER command to ensure the rotor is active throughout.

Now I can start looking for the new satellite... First I find it on SatBeams:

http://www.satbeams.com/channels

and pick a frequency that is likely to be transmitting. It doesn't need to be FTA as we only want to lock onto the signal, not decrypt it.

In this case, there is a transponder on 11727000 with vertical polarity and a symbol rate of 27500000...

I know that my satellite dish is not correctly zeroed, and that I'm pointing about 28 steps East, so I will search Westward for my new bird:


$ ./diseqctool.py adapter 4 find 11727000 v 27500000 west

  Setting adapter to 4 (/dev/dvb/adapter4) OK

  Finding transponder with frequency 11727000 WESTwards
    Found after 23 steps
    signal strength: 33422
    signal strength: 33422
    signal strength: 33422
    signal strength: 34078
    signal strength: 34078
    signal strength: 34078
    signal strength: 34078
    signal strength: 34078
    signal strength: 34078
    signal strength: 34078
    signal strength: 34078
    signal strength: 34078
    signal strength: 34078
    signal strength: 33422
    signal strength: 33422
    signal strength: 33422
      strongest signal was 34078
      seeking back to that level...
          stepping another 5 steps to centre

I also know from previous tests that I have about 6 steps per degree, so if the number of steps is getting too high for the satellite's actual position, I can abort and try again on a different frequency.

Now we seem to have found the satellite, we can verify it by looking at some data:

$ ./diseqctool.py adapter 4 freq 11727000 polarity v symbol 27500000 tune signal Setting adapter to 4 (/dev/dvb/adapter4) OK Setting Frequency to 11727000 - OK Setting Polarity to Vertical - OK Setting Symbol Rate to 27500000 - OK Tuning receiver to 11727000 Hz, Vertical, Symbolrate 27500000 - OK Status: Signal detected Carrier detected FEC is stable (VITERBI) Found sync bytes Signal locked BER: 0 SNR: 20359 STRENGTH: 33422 Frequency: 1127000 Spectral Inversion: Auto Inversion Symbol Rate: 27500000 FEC: FEC Auto $ dvbsnoop -adapter 4 0x0010|grep -i orbital Orbital_position: 304 (= 13.0)

and we can see that we have a good signal, and in the dvbsnoop data our orbital position is indeed 13.0, so we're definitely looking at the right satellite!

Finally, I store the new sat in position 13:

$ ./diseqctool.py adapter 4 store 13 Setting adapter to 4 (/dev/dvb/adapter4) OK Storing position as satellite no. 13 - OK

and I can go back to my tvheadend config, set up a new network for Hotbird 13 and a GOTOX sat feed for it and we're done!

I hope this is useful, and please feel free to send me any feedback via the github page.

cheers,
Adam

Ron L

Having an stv090x device you may be interested in this....

https://bitbucket.org/updatelee/updatedvb

This is what I used to program my V-Box GOTOX positions. You don't need to know any frequency on the satellite, just start scanning in a loop and click the buttons to move the dish until you see the spectrum of the satellite appear in the graph. Click on frequency in the spectrum graph and it will tune then display a PID analysis of the stream, bitrates and other signal info including dBm. You can bump the dish one click at a time to peak dBm then save the GOTOX position to the V-Box. Also supports USALS. From the tuning window you can play, demux to dvr, stream to the network etc.

There are screen shots in it's wiki.

We use this a lot for finding back hauls of sporting events, concerts etc. Things that only pop up temporarily. There is no way to know in advance what satellite they will be on or what frequency. With this you can find these things fairly easily.

Adam Laurie

> Having an stv090x device you may be interested in this....
>

> https://bitbucket.org/updatelee/updatedvb

Nice. Thanks, i'll give it a try...

Adam Laurie

>
> Having an stv090x device you may be interested in this....
>
> https://bitbucket.org/updatelee/updatedvb >

> Nice. Thanks, i'll give it a try...

Unfortunately this didn't work for me. The drivers included cause a kernel panic as soon as anything tries to use the frontend. However, it's still a very interesting project. Do you know where the blind and spectrum scanning features are documented for the stv090x? I can't find anything on the TBS website...

« Previous Page Next Page »