Prof 7301, 7500 and 8000 Tuners
- Thread starter pendragon
- Start date
- Latest activity Latest activity:
- Replies 228
- Views 76K
- Status
I see so now with the http://www.st.com/stonline/products/literature/bd/14947.pdf (STV0903) and http://www.st.com/stonline/products/literature/bd/11107.pdf (STB0899) so the ultimate convination will be STB6100 with STB0899 right?
I'm waiting for the Prof Revolution prof8000 since it is PCIe but uses STB6100 + STV0903 so I'm waiting to see if is worth it.
So the new STV0903 is better and has all what STB0899 has?
DO you think the best solution right now is STMicro chips?
DO you think the best solution right now is STMicro chips?
Had a few minutes to play with the Prof 7301 on Linux. This is on a custom, but fairly benign 2.6.28 kernel. Following zamar23's tips, I pulled Igor's latest patch and applied it to a recent snapshot of his. I then applied Andreas Regel's patches for the stv0903. All the hardware seemed to get recognized as tester239 posted, but my kernel panics as soon as I try to tune something.
Next I tried zamar23's ready to install tarball. That shows some differences in the logs when the drivers attach to the 7301, and I had no kernel panics when tuning. In fact I was able to record the full 3840 V 27690 transponder on 58W and all the streams show up fine in TSReader. The tuning status, signal level, CNR and BER are all hosed, however. I had little success in doing a simple transponder scan and when I tried to send DiSEqC commands, there was no positive indication they went out and nothing locked. However I didn't scope the data and didn't split my spectrum analyzer off the line.
I need to compare the two builds I did because Regel's changes look as though they need to be wedged in somehow. There may well be a long road to success as the drivers appear very immature at the moment.
Next I tried zamar23's ready to install tarball. That shows some differences in the logs when the drivers attach to the 7301, and I had no kernel panics when tuning. In fact I was able to record the full 3840 V 27690 transponder on 58W and all the streams show up fine in TSReader. The tuning status, signal level, CNR and BER are all hosed, however. I had little success in doing a simple transponder scan and when I tried to send DiSEqC commands, there was no positive indication they went out and nothing locked. However I didn't scope the data and didn't split my spectrum analyzer off the line.
I need to compare the two builds I did because Regel's changes look as though they need to be wedged in somehow. There may well be a long road to success as the drivers appear very immature at the moment.
Igor posts new patches to it almost daily. He is getting Prof 7301 card in a couple of weeks, and the driver is going to be officially released shortly after. Its just another driver in a long Linux drivers collection he released over the years. He would finish support for the USB card version as well long ago, if he had the USB card at hand. There may be something you're missing in terms of proper installation. Several testers posted good results with both versions, but they're not finished yet. Pls post your findings with kernel printouts in this thread, if you want to help finalize the driver. Or, you're welcome to offer your own version. 
I moved over to Windows for more Prof tuner testing.
To address a common question coming up on forums, I am able to get Prof tuners of different types to run simultaneously on the same Windows machine, but not two of the same. I only tried DVB Dream, but this has always worked well for me with multiple tuners as long as I run separate instances. Thus one 7301 (PCI) and one 7500 (USB) work fine and completely independently, but two 7500s or two 7301s don't. In fact if I have two like tuners connected, Windows shows both devices in the Device Manager, but DVB Dream only lists one available BDA device.
Next I tried to address another question regarding the sensitivity of the Prof tuners relative to other units. I've taken a 'gentle criticism' that I may not be terribly useful in determining this because I normally have plenty of link margin. So I took my smallest Ku dish (a T90 toroid) with a crummy LNB and moved it slightly off 83 W as necessary to generate poor CNRs. The target was RTV and I came up with the following abilities for locking from best to worst:
Prof 7301/Prof 7500 (pretty much a tie)
DVB World 2104
TechnoTrend S2-3200
Pansat 9200HD
Even when all the other tuners had lost lock and were capturing nothing viewable, the Profs were still capturing perfect transport streams. While this is only one test, I was impressed. For those who like to read arbitrary SQ numbers, most of the time my Profs are running with SQs of 99-100%. By the time I got tired of dropping the CNR, I still had a perfect picture at an SQ of 20%. I have no calibration as to what this scale measures or means, and didn't spend much time dwelling on it.
To address a common question coming up on forums, I am able to get Prof tuners of different types to run simultaneously on the same Windows machine, but not two of the same. I only tried DVB Dream, but this has always worked well for me with multiple tuners as long as I run separate instances. Thus one 7301 (PCI) and one 7500 (USB) work fine and completely independently, but two 7500s or two 7301s don't. In fact if I have two like tuners connected, Windows shows both devices in the Device Manager, but DVB Dream only lists one available BDA device.
Next I tried to address another question regarding the sensitivity of the Prof tuners relative to other units. I've taken a 'gentle criticism' that I may not be terribly useful in determining this because I normally have plenty of link margin. So I took my smallest Ku dish (a T90 toroid) with a crummy LNB and moved it slightly off 83 W as necessary to generate poor CNRs. The target was RTV and I came up with the following abilities for locking from best to worst:
Prof 7301/Prof 7500 (pretty much a tie)
DVB World 2104
TechnoTrend S2-3200
Pansat 9200HD
Even when all the other tuners had lost lock and were capturing nothing viewable, the Profs were still capturing perfect transport streams. While this is only one test, I was impressed. For those who like to read arbitrary SQ numbers, most of the time my Profs are running with SQs of 99-100%. By the time I got tired of dropping the CNR, I still had a perfect picture at an SQ of 20%. I have no calibration as to what this scale measures or means, and didn't spend much time dwelling on it.
Igor posts new patches to it almost daily. He is getting Prof 7301 card in a couple of weeks, and the driver is going to be officially released shortly after. Its just another driver in a long Linux drivers collection he released over the years. He would finish support for the USB card version as well long ago, if he had the USB card at hand. There may be something you're missing in terms of proper installation. Several testers posted good results with both versions, but they're not finished yet. Pls post your findings with kernel printouts in this thread, if you want to help finalize the driver. Or, you're welcome to offer your own version.
I am able to tune and receive streams on this card on Linux, so I doubt there is an installation issue. The driver is simply at an alpha stage and there is nothing wrong with that, and certainly no criticism on my part of Igor's efforts and contributions. To clarify a little more:
Your link is where I picked up Igor's latest patch from a couple of days ago. My first test wasn't completely fair as I tried to incorporate a number of fixes to the stv0903 driver that Igor does not have in his baseline. Some of these appear important for proper blind scan operation, but I did not review each one. My presumption is there is a collision between Igor's baseline, which is more focused on the 7301 and Andreas' which is directed at the TT-1600. Both tuners use the stv0903, and Andreas appears to be much farther along in exploiting this chip's capabilities. It will take more time than I have this weekend to untangle that mess, but I believe a synthesis of the two is the right path to pursue.
When I switched to Igor's pure baseline, I had no system stability issues and had some ability to tune and receive transport streams on my default dish (all DiSEqC positions at 1). But DiSEqC commands didn't seem to work and I couldn't run scan. I didn't start this project to participate in driver development, although if I find anything I'll be happy to send it to Igor. I'm going to put a little more time into this, but if it looks like a more robust driver is down the road, I may wait for that to happen. I've already earned my stripes in driver coding over the past 35+ years.
I'll post their your published findings and the suggestion to integrate Andreas' Blind Scan efforts. This part will probably take time, since it looks like a pioneering effort in sat cards. Sure, this groundbreaking work to add hardware blindscan to a new sat card series would be much easier to accomplish with your help, and would increase Linux popularity among FTA sat card fans, which are in large numbers around the Globe.
Last edited:
I dug up an old tool that makes drilling down differences in a file tree somewhat easier. This pointed out the most obvious difference between the version that works for me and the one that doesn't is they are using different drivers for the stv0903 chip.
The baseline that works for me is an unmodified build of zamar23's "ready to install" tarball that apparently dates from July 2009. My previous post may have misidentified the source as I now have no idea where it came from. This version uses a specific stv0903.* driver. Tuning sort of works and it doesn't crash, but that's about all. The debug messages are a little different from the following version.
The baseline that didn't work for me was based on Igor's latest with his most recent 7301 patch and a merge of the Andreas changes. This baseline uses the stv0900.* driver while Andreas patched a third driver called stv090x.*, meaning many of the changes I applied are likely not having any effect. I see the same debug messages as tester239 at initialization, and whenever I try to tune, the kernel panics. tester239 also mentions 'tuning issues', but did not provide any specific detail.
It would appear that sometime after July 2009, the stv0903 and stv0900 drivers were merged. The stv090x driver seems to be targeted at the TT-1600, where a fair amount of work has been done on blindscanning. At this point I'm a little unclear where to apply time with these separate efforts proceeding. I may try a more virgin pull from Igor to see if that works any better.
The baseline that works for me is an unmodified build of zamar23's "ready to install" tarball that apparently dates from July 2009. My previous post may have misidentified the source as I now have no idea where it came from. This version uses a specific stv0903.* driver. Tuning sort of works and it doesn't crash, but that's about all. The debug messages are a little different from the following version.
The baseline that didn't work for me was based on Igor's latest with his most recent 7301 patch and a merge of the Andreas changes. This baseline uses the stv0900.* driver while Andreas patched a third driver called stv090x.*, meaning many of the changes I applied are likely not having any effect. I see the same debug messages as tester239 at initialization, and whenever I try to tune, the kernel panics. tester239 also mentions 'tuning issues', but did not provide any specific detail.
It would appear that sometime after July 2009, the stv0903 and stv0900 drivers were merged. The stv090x driver seems to be targeted at the TT-1600, where a fair amount of work has been done on blindscanning. At this point I'm a little unclear where to apply time with these separate efforts proceeding. I may try a more virgin pull from Igor to see if that works any better.
Last edited:
It seems to be quite typical to use others' modules in open source development, tossing them back-en-force and around. At the end nobody actually knows, where this thing came from, but amazingly enough it "just works". It might be that Igor added Andreas code to his own making it more universal. Basically, he seems to already have done the same thing before you did it again.
Perhaps Igor incorporated the essence of Andreas' changes into the stv0900 driver. I have not done a comparison. What concerns me is Andreas posted the changes on 14 Oct and I have not seen any consequent action from Igor. He may have already done the work beforehand, but in the world of Linux I have seen so much duplication of effort and wasting of time that I always tend to take the cynical route in the absence of any real information.
I started from Igor's latest baseline and applied the two patches: snr-str-1.patch from 17 Oct and prof_7301.patch from 27 Oct. Things are a little unclear about the first patch from Igor's 7301 thread, but I looked at the code and it wasn't there before. Builds fine, loads the drivers fine and crashes the system when I try to tune.
So I pulled an earlier baseline from Igor from around 27 Sept and applied the patches. This actually allows me to tune to a certain degree. It's not terribly reliable but I was able to scan 58W some of the time. The most obvious problem when it works is it doesn't seem able to select H. Everything is always V. I rebooted the machine to Windows immediately and H & V selection worked fine there. Went back to Linux and had the same problem.
I did try again to send DiSEqC commands to my switches as that would help a lot in troubleshooting. But there never was an indication that it worked, perhaps because the tuning can be so erratic.
There is some progress, but I'd be generous to call this alpha quality. I know the song and dance about Linux, but here I am spending hours just to compile a driver that works. From what I can tell there is marginal baseline control as I can never apply the patches cleanly, regardless of the version I choose. Not all the files are in sync. Don't count on blindscanning anytime soon at this rate.
So I pulled an earlier baseline from Igor from around 27 Sept and applied the patches. This actually allows me to tune to a certain degree. It's not terribly reliable but I was able to scan 58W some of the time. The most obvious problem when it works is it doesn't seem able to select H. Everything is always V. I rebooted the machine to Windows immediately and H & V selection worked fine there. Went back to Linux and had the same problem.
I did try again to send DiSEqC commands to my switches as that would help a lot in troubleshooting. But there never was an indication that it worked, perhaps because the tuning can be so erratic.
There is some progress, but I'd be generous to call this alpha quality. I know the song and dance about Linux, but here I am spending hours just to compile a driver that works. From what I can tell there is marginal baseline control as I can never apply the patches cleanly, regardless of the version I choose. Not all the files are in sync. Don't count on blindscanning anytime soon at this rate.
I assume you installed S2 API, and used Igor's szap-s2 scanner or s2scan with parameter n specified to scan TPs and tune to channels?
Try also this Igor's depository, and apply the attached below patch to it.
"L@@K! Assembled with this. Everything works.
:"
Typical config: Kubuntu 9.04+VDR 1.7.9+S2API+VDPAU(GeForce 9500)+xine-0.9.3 DVB-S2 Prof-7301
It looks like he's working on several drivers for sat cards of different make at the same time. It's business as usual given the popularity of sat cards, higher demand for Linux drivers on low end PC hardware, and much higher demand for sat cards in general in Europe. May be the solution will have to wait until Prof adds blindscan support for its Windows drivers based on STMicro docs Igor doesn't have access to.
Here's also the thread on Linux driver development progress for TT S2-1600 for those interested to take part.
Try also this Igor's depository, and apply the attached below patch to it.
"L@@K! Assembled with this. Everything works.
:"Typical config: Kubuntu 9.04+VDR 1.7.9+S2API+VDPAU(GeForce 9500)+xine-0.9.3 DVB-S2 Prof-7301
It looks like he's working on several drivers for sat cards of different make at the same time. It's business as usual given the popularity of sat cards, higher demand for Linux drivers on low end PC hardware, and much higher demand for sat cards in general in Europe. May be the solution will have to wait until Prof adds blindscan support for its Windows drivers based on STMicro docs Igor doesn't have access to.
Here's also the thread on Linux driver development progress for TT S2-1600 for those interested to take part.
Last edited:
Maybe I'm stupid, but I thought Igor had incorporated S2API into the repository at:
s2-liplianin: Summary
If I use that through the latest update (changeset 13255) and add the patch for the 7301 (mine is a little newer than the one you list and has a few more changes in it), the kernel panics on tuning. If instead I start with an earlier version from 27 Sep (changeset 13249) and apply the 7301 patch, the system doesn't crash and I have some tuning capability. But it is rather flakey. There may very well be differences in the code Igor and his merry band are running, but I think I've made a decent effort to get close. It may be that we also have different standards for software maturity.
In my reading it appears the S2API is still a work in progress and only a subset of apps have incorporated it. The developers are very proud they have not documented it, yet. I suppose the most practical approach with Linux is to read the kernel and module code, but frankly when I'm writing an app I'd rather not shoot at a moving target. My understanding was the S2API added capabilities through a different interface mechanism, and that it did not incorporate all the previous API functionality. Thus if one had an app that worked with the old API, it would of necessity continue to function. Anecdotally it seems people continue to have more success using the old API than the new, which is perfectly fine while the S2API details get ironed out. As I have no desperate need for S2API, I tried apps that only employ the old API. This could be the root of the problem, but then the problem would not be mine if I understand the S2API concept.
I can try Igor's commit repository, but I'm already convinced this part of the Linux tree is rather chaotic and whatever works today probably won't work tomorrow. It will be all worked out in time, but I don't have a lot of desire to join the fray and become another headless chicken running around like I have for the past few days. If I had wanted to do V4L driver development, I would already be there. What I want to do is enhance my blindscanning capabilities and am willing to work and contribute to the Linux cause. So far I have done nothing in that direction, and the prospects for near-term success appear gloomier than when I first looked.
Igor does what he wants and for the most part the world benefits. But the Linux world is fraught with personalities, politics, power plays, egos and the like and the subculture of V4L is no different. I would not be surprised if good work, like stv0903 blindscanning, is being ignored and wheels reinvented for reasons other than technical. If one reads through the stv090x driver, it is clear that a lot of work has gone into the blindscanning code and I'm inclined to believe a fair amount of it works on the TT S2-1600. Whether they had access to STMicro documentation or if someone figured it out doesn't really matter. There is a good understanding of the stv0903 in the wild. I don't have the same comfort factor with Igor's stv0900 driver. I'm not actually criticizing Igor, but the process, because I believe this could have been brought to 'market' faster with better cooperation. One recurring problem I've had with Linux over the past decade is that hardware is often obsolete by the time the software that supports it is becoming mature. As a consumer this does not breed confidence.
s2-liplianin: Summary
If I use that through the latest update (changeset 13255) and add the patch for the 7301 (mine is a little newer than the one you list and has a few more changes in it), the kernel panics on tuning. If instead I start with an earlier version from 27 Sep (changeset 13249) and apply the 7301 patch, the system doesn't crash and I have some tuning capability. But it is rather flakey. There may very well be differences in the code Igor and his merry band are running, but I think I've made a decent effort to get close. It may be that we also have different standards for software maturity.
In my reading it appears the S2API is still a work in progress and only a subset of apps have incorporated it. The developers are very proud they have not documented it, yet. I suppose the most practical approach with Linux is to read the kernel and module code, but frankly when I'm writing an app I'd rather not shoot at a moving target. My understanding was the S2API added capabilities through a different interface mechanism, and that it did not incorporate all the previous API functionality. Thus if one had an app that worked with the old API, it would of necessity continue to function. Anecdotally it seems people continue to have more success using the old API than the new, which is perfectly fine while the S2API details get ironed out. As I have no desperate need for S2API, I tried apps that only employ the old API. This could be the root of the problem, but then the problem would not be mine if I understand the S2API concept.
I can try Igor's commit repository, but I'm already convinced this part of the Linux tree is rather chaotic and whatever works today probably won't work tomorrow. It will be all worked out in time, but I don't have a lot of desire to join the fray and become another headless chicken running around like I have for the past few days. If I had wanted to do V4L driver development, I would already be there. What I want to do is enhance my blindscanning capabilities and am willing to work and contribute to the Linux cause. So far I have done nothing in that direction, and the prospects for near-term success appear gloomier than when I first looked.
Igor does what he wants and for the most part the world benefits. But the Linux world is fraught with personalities, politics, power plays, egos and the like and the subculture of V4L is no different. I would not be surprised if good work, like stv0903 blindscanning, is being ignored and wheels reinvented for reasons other than technical. If one reads through the stv090x driver, it is clear that a lot of work has gone into the blindscanning code and I'm inclined to believe a fair amount of it works on the TT S2-1600. Whether they had access to STMicro documentation or if someone figured it out doesn't really matter. There is a good understanding of the stv0903 in the wild. I don't have the same comfort factor with Igor's stv0900 driver. I'm not actually criticizing Igor, but the process, because I believe this could have been brought to 'market' faster with better cooperation. One recurring problem I've had with Linux over the past decade is that hardware is often obsolete by the time the software that supports it is becoming mature. As a consumer this does not breed confidence.
I can't agree with you more. Another problem is that in the region Igor targets his drivers for and where they're mostly early tested, blindscan is not the first priority if popular at all. Try contact Prof tech support about it. They answered me 4 months ago that blindscan for these cards is of interest to very few people if any, and they can't commit resources on something like that in this turbulent time. Period...
Btw, blindscan is the exciting feature, but what is the objective demand for it in sat cards in NA? How many people here are FTA thinking inclined - anyone did market research on this?
What I see from AZBox success, FTA community is hungry for something challenging and exciting to play with, but Linux HTPC remains a remote undertaking, and AZBox fits the transfer bill as intermediary btw familiar and unknown. However, for the silent majority a convenient "easy button" box would probably do better, if only it can show more fan at the moment.
Returning to Linux drivers, despite your critique his drivers are wildly popular with available in that region sat cards choice, which is much broader than in NA, and recommended for all practical purposes on every local forum. Here's an example from German C'T Magazine. To organize work better, you're welcome to communicate with him and Andreus. I merely suggested available sources at the moment, nothing more..
Btw, blindscan is the exciting feature, but what is the objective demand for it in sat cards in NA? How many people here are FTA thinking inclined - anyone did market research on this?
What I see from AZBox success, FTA community is hungry for something challenging and exciting to play with, but Linux HTPC remains a remote undertaking, and AZBox fits the transfer bill as intermediary btw familiar and unknown. However, for the silent majority a convenient "easy button" box would probably do better, if only it can show more fan at the moment.
Returning to Linux drivers, despite your critique his drivers are wildly popular with available in that region sat cards choice, which is much broader than in NA, and recommended for all practical purposes on every local forum. Here's an example from German C'T Magazine. To organize work better, you're welcome to communicate with him and Andreus. I merely suggested available sources at the moment, nothing more.
.
Last edited:
I've been pretty busy with school/tv/work and that probably isn't going to change much. I've gotten my new PLL Ku lnb installed, and the 7301 drivers compiled and attaching.. but tuning does not work at all. I may just end up waiting for a stable base driver and then see about blind scanning and such after that. I still don't quite get the drivers.. Kernel stuff can be a bit over my head at times. Attempting to tune/lock with the 7301 gives me a bugus return value of 0xe7f7 or something crazy like that. Like I said, I haven't had much time to dive into this.
One good thing though: Even if the DVB API v5 doesn't support scanning and changing acquisition methods (which SUCKS, honestly) one can still write an easy blind-scan utility if the driver automagically will find the symbol rate given a broad number and a known frequency. This would just be a simple loop through frequencies, jumping the size of the bandwidth every time a transponder is found and locked on to. Assuming once the demod locks it will return the _proper_ symbol rate, not the one you fudged, this should work just fine. In fact, I've already written a program to do that.. *cough* automated lyngsat clone *cough*
Hope to hear more good news about this card..
One good thing though: Even if the DVB API v5 doesn't support scanning and changing acquisition methods (which SUCKS, honestly) one can still write an easy blind-scan utility if the driver automagically will find the symbol rate given a broad number and a known frequency. This would just be a simple loop through frequencies, jumping the size of the bandwidth every time a transponder is found and locked on to. Assuming once the demod locks it will return the _proper_ symbol rate, not the one you fudged, this should work just fine. In fact, I've already written a program to do that.. *cough* automated lyngsat clone *cough*
Hope to hear more good news about this card..
I guess you didn't expect for the modules code not being finalized. Interesting read: Linux Device Drivers.
I'm not quite sure I follow you. Yes, I'm quite aware that the code available is very preliminary and didn't really expect anything to work out of the box. If time hasn't been so short lately, I might have played around with it more, and (at the very least) figured how I got an invalid return value and what it means.. beyond that, I don't know much about the hardware so I'm kinda in the dark as to what is expected and the proper way of interfacing with the demodulator. I never got any emails back from vendors or driver authors so
On another note, I'd use the latest kernel available from the repo, but my satellite system is a production system and I need to keep it somewhat stable. If I had a secondary test system, I'd be all for getting the super-latest kernel and patching that.. might have had better luck.
Haven't even had much time to _watch_ anything from the dish let alone futz around with kernel drivers. Hell, I still need to get that damn Unity 4000 box playing nice. Sigh, this hobby is best left for someone with more time (or better time management
)- Status
