Tvheadend

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

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

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

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.

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

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.

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.

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 .

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?

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.

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

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

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.

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

https://bitbucket.org/updatelee/updatedvb

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

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

The kernel panic is possibly related to videobuf2. This media tree is synced with linux media. Some of the drivers are starting to be moved to videobuf2. Any that have been are creating kernel panic. My Prof 7301 with cx-88 locks the whole machine up tight within minutes. I had to revert back to pre-videobuf2 cx-88.

The frontend has been modified to add in the ability to read the spectrum info from the device. You have to copy frontend.h and dmx.h over to /usr/include/linux/dvb/ then recompile your software before it can access frontend.

There is a support thread for the driver here....

http://rickcaylor.websitetoolbox.com/post/v4lupdatelee-6433163

updateDVB app here...

http://rickcaylor.websitetoolbox.com/post/updatedvb-thread-6428438

updatelee is the guy you want to talk to there.