MythTV, Prof 7301, Galaxy 19 and a few questions..(long)

Status
Please reply by conversation.

myth_user

Member
Original poster
May 2, 2010
7
0
CA, USA
Hi all,
so I've taken the plunge into the world of FTA satellite and have come a long way as of a few weeks ago when I didn't know what FTA stood for. :) This is my first post here so bear with me. This weekend I got my setup tuned for the very first time and was ecstatic when I was able to receive a few channels. However being somewhat of a newbie I had a few questions around tuning/expanding my setup.

First few words on my current setup. I have a split frontend/backend MythTV (0.21) configuration for receiving OTA ATSC and basic NTSC cable. The BE server runs rather dated but stable CentOS 5.2 with the primary tuner being a Hauppauge HVR-1600 along with an older bt878 (bttv) based NTSC analog only card. The FE runs Minimyth and has enough grunt to play 1080i/720p with no VDPAU being used on the built in GeForce 8200. Ive had this setup working flawlessly for over a year. More details of my setup here.

About 3-4 weeks ago I started investigating about getting Satellite TV. In fact I started by thinking I was going to subscribe to Dish Networks and called their sales line. After holding for 5-10mins and a short conversation later with a not too friendly sales rep it became clear to me that this would be problematic for what I wanted. He gave the game away when he asked me what's FTA? Firstly I wanted the service to fully integrate with my existing MythTV setup,and the options available were RGB/S-video from the settop with irblaster with their closed system. And secondly their dish/lnb setup had limited ability to receive FTA channels.

So I decided to go down the FTA route and not get Dish. After much research I ordered a GEOSATpro 36" Dish, GEOSATpro SL1 Standard Linear LNBF and a Prof 7301 DVB-S2 card. I knew the Linux drivers may be problematic in CentOS 5.2 (2.6.18-92.1.22.el5.centos.plus) kernel, but decided to risk it. After messing around for a week or so, applying some patches I got the V4L to compile both the cx18 for the HVR-1600, and the cx88 drivers for the Prof 7301. For reference I have the kernel log of the driver here.

After much work of getting the dish mounted on my roof, orienting to point correctly to Galaxy 19 with a satellite signal meter I bought off Ebay, I managed to scan for channels and pick some up this weekend, hurray! I did "scan -a 1 -f 0 -d 0 -l 10750 /usr/share/dvb/dvb-s/Galaxy19-97w > /root/.szap/channels.conf" and picked up these channels. After messing around with LNB skew I can lock onto 15-20 channels plus bunch of radio stations. I had to import my channels.conf file manually to MythTV btw as 0.21 tuning in Myth is hit and miss.

So although I'm happy with my progress so far, majority of the video channels listed in the scan don't seem to lock correctly in Mythtv. I've only managed to lock to two English channels, Al Jazeeraa and Russia Today. Saudi TV2 which is English according to ftalist.com is picked up in the scan but doesn't lock. I do have a few light tree branches unfortunately that could be hindering the signal, but cutting them down would be problematic. Why am I able to receive some channels but not all as listed by the scan on a same satellite? Is this a signal strength issue or something else?:confused:

Secondly, I was thinking of upgrading to a motorized setup with a SG-2100, anyone have experience driving an SG-2100 with MythTv 0.21 and Prof 7301? I picked the 7301 specifically for DiSEqC 1.2 support. I'm in Bay Area, CA. Dishponter tells me I can get to Galaxy 17, 23 etc, what other birds are worth connecting to? I've scanned Lyngsat, but find the layout so confusing. Would getting a SG-2100 be worth where I am with this setup to pick up more English channels?:confused:

Lastly, do I need to install S2API separately to get DVB-S2 or is it included in the latest V4L? I read somewhere I may need to uncomment some header file to enable S2API, anyone got DVB-S2 working on the Prof 7310 with Linux here?:confused:

Many thanks for any tips/pointers,

Tony
 
I can't help you much on the Linux app side, because I took one look at it and decided it would never work for me. Instead I'm assembling custom software, which won't help you.

Putting that aside, you should be getting more in the neighborhood of 200 channels rather than 20 on 97W. If your transponder list is up-to-date and the scan isn't finding numbers like this, you may still need to tweek your dish alignment. Has your LNB skew been optimized? If tree branches are in the path, that will certainly cause problems.

A motor is definitely recommended. I have a 7301 that drives a plethora of DiSEqC gear, including motors without any issues. While 97W has a motherlode of channels, there are certainly plenty on other birds, many worth the trouble

Because the 7301 driver will try to lock any kind of signal, you likely can get away without S2API. However there are good reasons to keep your V4L version current, as earlier driver versions were not particularly mature with respect to the demod chip in the 7301. There is some chance this could be limiting your ability to lock certain transponders.
 
Putting that aside, you should be getting more in the neighborhood of 200 channels rather than 20 on 97W. If your transponder list is up-to-date and the scan isn't finding numbers like this, you may still need to tweek your dish alignment. Has your LNB skew been optimized? If tree branches are in the path, that will certainly cause problems.

Thanks much, here's the tuning data file I'm using for the scan, does this look right or is it missing a bunch of stuff for Galaxy 19?

# Galaxy 19 @ 97W
# freq pol sr fec
S 11789000 V 28125000 AUTO
S 11836000 V 20770000 AUTO
S 11867000 V 22000000 AUTO
S 11874000 H 22000000 AUTO
S 11898000 V 22000000 AUTO
S 11936000 H 20000000 AUTO
S 11966000 H 22000000 AUTO
S 11991000 V 22000000 AUTO
S 11999000 H 20000000 AUTO
S 12053000 V 22000000 AUTO
S 12084000 V 22000000 AUTO
S 12090000 H 20000000 AUTO
S 12115000 V 22425000 AUTO
S 12146000 V 22000000 AUTO
S 12152000 H 20000000 AUTO
S 12177000 V 23000000 AUTO

I was trying to use LyngSat to update this but wasn't really getting very far.

A motor is definitely recommended. I have a 7301 that drives a plethora of DiSEqC gear, including motors without any issues. While 97W has a motherlode of channels, there are certainly plenty on other birds, many worth the trouble

Because the 7301 driver will try to lock any kind of signal, you likely can get away without S2API. However there are good reasons to keep your V4L version current, as earlier driver versions were not particularly mature with respect to the demod chip in the 7301. There is some chance this could be limiting your ability to lock certain transponders.

Sounds good, I think I will grab a SG-2100 once I get the current setup more operational. I was concerned about Linux/MythTv support for DiSEqC 1.2, but doesn't sound like it's a big issue.

I used the backport V4L tree rather than the s2-liplianin tree because of my older kernel, do you know if the two have merged yet or do I need the s2-liplianin for DVB-S2? I'm also guessing I have to upgrade to MythTv 0.22 to be able to play DVB-S2 as 0.21 BE will be not compatable with 0.22 FE. Perhaps this is a better question for the mythtv-users or linuxtv mailers.

I read elsewhere that you were testing Linux blind scanning on this card. Care to share which tree you're using and appropriate patches? I would be more than happy to test on my setup once it gets more operational.;)

Thanks
 
Thanks much, here's the tuning data file I'm using for the scan, does this look right or is it missing a bunch of stuff for Galaxy 19?

# Galaxy 19 @ 97W
# freq pol sr fec
S 11789000 V 28125000 AUTO
S 11836000 V 20770000 AUTO
S 11867000 V 22000000 AUTO
S 11874000 H 22000000 AUTO
S 11898000 V 22000000 AUTO
S 11936000 H 20000000 AUTO
S 11966000 H 22000000 AUTO
S 11991000 V 22000000 AUTO
S 11999000 H 20000000 AUTO
S 12053000 V 22000000 AUTO
S 12084000 V 22000000 AUTO
S 12090000 H 20000000 AUTO
S 12115000 V 22425000 AUTO
S 12146000 V 22000000 AUTO
S 12152000 H 20000000 AUTO
S 12177000 V 23000000 AUTO

I was trying to use LyngSat to update this but wasn't really getting very far.

This looks out of date, although you should still find more than 15-20 channels with it. Lyngsat is a better bet, although it is also often out-of-date.

I used the backport V4L tree rather than the s2-liplianin tree because of my older kernel, do you know if the two have merged yet or do I need the s2-liplianin for DVB-S2? I'm also guessing I have to upgrade to MythTv 0.22 to be able to play DVB-S2 as 0.21 BE will be not compatable with 0.22 FE. Perhaps this is a better question for the mythtv-users or linuxtv mailers.

I haven't tried any back ports so I can't say anything useful about them. Some simple diffs on the STV0903 driver files should answer the question. It may sound strange, but you should not need the S2API or DVB-S2 support in Myth for DVB-S2 to work with the 7301. The way the driver is written, it will lock to the appropriate format automatically no matter what the application requests.

I read elsewhere that you were testing Linux blind scanning on this card. Care to share which tree you're using and appropriate patches? I would be more than happy to test on my setup once it gets more operational.;)

My work has not been made public for the moment. I have blindscanning working on both the 7301 and 7500. However I am not happy with a number of coding choices made in the original driver and the overall Linux DVB design. These cause a number of operational headaches that I can workaround, but are in my mind not acceptable for the masses. I started fixing this back in January, but I'm always trying to juggle too many projects at the same time and had to focus on the higher priorities. Some of these are even more compelling to me than PC blindscanning.
 
This looks out of date, although you should still find more than 15-20 channels with it. Lyngsat is a better bet, although it is also often out-of-date.

Thanks, this is what I thought. Reading through the newer V4L wiki, which is much more readable than the old, I guess I should be using w_scan first to generate this.

I haven't tried any back ports so I can't say anything useful about them. Some simple diffs on the STV0903 driver files should answer the question. It may sound strange, but you should not need the S2API or DVB-S2 support in Myth for DVB-S2 to work with the 7301. The way the driver is written, it will lock to the appropriate format automatically no matter what the application requests.

No problem, I'll give DVB-S2 a shot once I have DVB-S working reliably, I guess it must fall back to the older multiproto API.

My work has not been made public for the moment. I have blindscanning working on both the 7301 and 7500. However I am not happy with a number of coding choices made in the original driver and the overall Linux DVB design. These cause a number of operational headaches that I can workaround, but are in my mind not acceptable for the masses. I started fixing this back in January, but I'm always trying to juggle too many projects at the same time and had to focus on the higher priorities. Some of these are even more compelling to me than PC blindscanning.

Sounds good, how is this better than the w_scan tool other than perhaps leveraging the hardware more for improved performance? In other words if I run w_scan for long enough time, will I get similar results to your tool? I understand faster blind scanning performance will mean being able to detect transient feeds quicker.:D
 
No problem, I'll give DVB-S2 a shot once I have DVB-S working reliably, I guess it must fall back to the older multiproto API.

Actually not. This is just a function of the way the driver is written. The application simply sends a tuning request through the existing DVB-S API; neither the API nor the app is aware that DVB-S2 even exists. Although the API only contains the particulars to tune DVB-S signals, the STV0903 driver ignores just about everything other than frequency, although SR factors in if my memory serves. The driver centers the tuner and will attempt to lock any signal it can at that frequency or something closeby, whether it is DVB, DVB-S2 or even DSS (the latter I'm not sure about, it's been awhile), whatever the FEC, pilot and SR. There is no provision to pass what it finds back to the app, but the signal is available for use.

Sounds good, how is this better than the w_scan tool other than perhaps leveraging the hardware more for improved performance? In other words if I run w_scan for long enough time, will I get similar results to your tool? I understand faster blind scanning performance will mean being able to detect transient feeds quicker.:D

I don't use w_scan, so I can only speculate. I expect w_scan will sort of work with the 7301 and 7500, but it will likely take a very long time and is also likely to keep finding the same TP again and again, because of the way the driver will always look for the closest signal to the frequency supplied. With the existing API there is no way for the driver to send the found parameters back, meaning the results will be meaningless. Most DVB-S drivers will only lock a signal with essentially the supplied parameters, giving w_scan an idea of what is there. These are some of the issues I've already fixed, but there are a number of others. One may be able to get w_scan to crudely work with the 7301/7500, but I wouldn't be surprised if a more traditionally coded DVB driver worked better. The true hardware blindscan I've worked out is both fast and pretty accurate (I'll never be satisfied).
 
I don't use w_scan, so I can only speculate. I expect w_scan will sort of work with the 7301 and 7500, but it will likely take a very long time and is also likely to keep finding the same TP again and again, because of the way the driver will always look for the closest signal to the frequency supplied. With the existing API there is no way for the driver to send the found parameters back, meaning the results will be meaningless. Most DVB-S drivers will only lock a signal with essentially the supplied parameters, giving w_scan an idea of what is there. These are some of the issues I've already fixed, but there are a number of others. One may be able to get w_scan to crudely work with the 7301/7500, but I wouldn't be surprised if a more traditionally coded DVB driver worked better. The true hardware blindscan I've worked out is both fast and pretty accurate (I'll never be satisfied).

So I did manage to compile w_scan and give it a shot. Just had to replace the header files at /usr/include/linux/dvb with the latest from the V4L source to compile successfully. I ran it with the following options, "w_scan -cUS -fs -s S97W0 -l STANDARD -x" and it gave me a few more stations to lock onto. The full scan took about ~10mins to complete. Is that considered really slow?

I don't have a non PC based settop receiver to compare, so interested to find out what normal blind scans on Galaxy19 should take. I now have ~373 video/audio stations in my channel.conf but am still able to only lock into a small subset of these via MythTV, perhaps ~35, so guessing it may be a signal issue. I'll try playing around with the dish more over next weekend.
 
Defn try and get that dish peaked better.

Do you have any diseqc switches in the setup? If I rem right the w_scan app didn't handle committed switches correctly.
 
Status
Please reply by conversation.

Users Who Are Viewing This Thread (Total: 0, Members: 0, Guests: 0)

Who Read This Thread (Total Members: 1)

Top