TBS DVB-S2 tuner users may now be able to use open source drivers

I had briefly mentioned this previously in the article, Hints on receiving 16APSK signals using TVHeadEnd or similar PVR backend software, but in case you didn’t happen to read it there I thought it was worth calling attention to. If you consider yourself a Linux expert, you may want to give the open source drivers mentioned in this thread on the TBS forum a try. Note that not every TBS card is supported, so make sure yours is before you try these, but that said, I believe that more cards are supported than just those specifically listed.

This is probably going to be a bit of a daunting task for those not well-versed in the ways of Linux, although if you read the entire thread first it might help because there are little gems of information buried in there that can help you succeed. For example, there is this post by user liljim:

I was able to get the TBS6909 installed on a fresh installation of Ubuntu 16.04, but ONLY after having followed this from CrazyCat’s bitbucket README:

NOTE: this document assumes that all prerequisite packages like kerner headers
and build tools are already installed in your Linux system.
For Ubuntu:
sudo apt-get install git build-essential linux-headers-generic \
ncurses-dev libproc-processtable-perl fakeroot\


This information is not in the github documentation. Maybe that’s an obvious bit of advice for most users, I don’t know – I overlooked it to start with. I feel as if it should be included in the github README regardless.

So what is the advantage of using the open source drivers? Well, some would claim that they provide better performance, or fix bugs in the original TBS closed-source drivers. TBS doesn’t seem to discourage the use of these drivers (the thread on this is in their forum, after all).

My only real concern is that there is no clear path for the person who already has the original TBS drivers installed, but wants to give the open source drivers a test drive, but with the ability to go back to the original drivers if something doesn’t work or if it turns out they have an unsupported card. A Linux expert would probably know what to do in that situation, but a regular user would likely panic because they’d have no idea how to get everything back to a working state, short of a total reinstall of the operating system. Also, the installation process requires the use of git, which may not be installed on all systems. If you’ve found the installation of the original TBS drivers a challenge (even when using the bash script posted late last year), you’ll probably not be happy with all the steps necessary to install the open source drivers.

I think for these to be generally accepted they are going to need to simplify the installation process. It would be great if they could provide an installation shell script that would do all the heavy lifting, but I am not holding my breath on that one. And don’t forget that you will likely need to reinstall these drivers every time you apply a Linux kernel update, so if you attempt an install of these drivers and you don’t have a photographic memory, you might want to keep notes on what you had to do to make them work so you can do it again at some time in future.


Hints on receiving 16APSK signals using TVHeadEnd or similar PVR backend software

Every now and then you may see a report of a satellite transponder using 16APSK modulation, rather than more common and easier to receive formats such as QPSK or 8PSK, and you might wonder if you can receive it. If you use TVHeadEnd or similar backend software, you may have attempted to scan in a 16APSK transponder, with no success. So what is the secret to receiving such feeds? Here are some things you need to keep in mind.

First, not all satellite tuner cards can receive 16APSK signals, even if they were originally advertised with that capability. At least one manufacturer, TBS Technologies, offers both “consumer” grade and “professional” grade cards. The “professional” grade cards can cost nearly twice as much as the “consumer” grade ones, but if you really want to receive 16APSK signals, it appears that only the “professional” cards will do (disclaimer: Obviously I have not tested every “consumer” grade card out there; there may have been one or more made that really do receive 16APSK signals). I do not know the technical details of why certain cards will work and others will not, but if you have a “consumer” grade one, you might want to check the currently advertised specifications for it, and see if the manufacturer still claims it will support 16APSK.

Second, even if you have a tuner card capable of receiving 16APSK signals, some versions of TVHeadEnd may not be able to scan the transponder. In at least one case it was discovered that temporarily changing both the tuner’s “Skip Initial Bytes:” and “Input Buffer (Bytes):” settings to zero (0) allowed a successful scan of a transponder (don’t forget to change those values back to their original values after the scan is complete, otherwise you may have problems with live viewing and/or recordings). If a newer version of TVHeadEnd is available, you may want to consider upgrading, but backup your existing system first in case the upgrade causes new issues – that is a whole other subject.

Third, but only if you are a true Linux geek, you MIGHT want to consider trying the open source drivers mentioned in this thread on the TBS forum. This is not a requirement; the standard TBS drivers will work to receive 16APSK, and right now installing the open source drivers requires some Linux expertise.

Fourth, if you have multiple C-band dishes (lucky you), try a different one. 16APSK signals are difficult to receive – see my previous article, Two reasons a dish may pull in some available free-to-air signals but not others: The modulation and the FEC (Forward Error Correction) code rate. If you find that you can receive the 16APSK signals but have frequent video and/or audio glitches, you may need to tweak your dish settings. Setting up a C-band dish is something of an art in that not only does the dish need to be pointed directly at the satellite, but the LNB skew must be correct, the focal depth of the LNB must be set correctly, and the scaler ring and LNB must be the correct distance from the center of the dish and pointed exactly at the dish center. Oh, and the dish should be perfectly round and not bent out of shape. If any of these are off, you may lose a couple dB of signal strength or more, which might not be enough to impede your ability to receive QPSK or 8PSK signals, but could destroy your chances of receiving 16APSK signals reliably.

Another thing to keep in mind is that you stand almost zero chance of receiving 16APK signals reliably on anything smaller than a 10 foot dish. If you can find one, a 12 foot dish will probably work better than a 10 foot one, provided all the other adjustments are correct (it is pointed precisely at the satellite, the skew is set correctly, and so on). But if you have two or more 10 foot C-band dishes, it’s worth trying each of them to see which offers better reception. The advantage to having a larger dish is that it gives you more “wiggle room” in case some of your dish adjustments aren’t perfect.

Fifth, this may be one of those situations where a phase-locked loop (PLL) LNB really is a good idea – see Are phase-locked loop (PLL) LNB’s a good idea?. PLL LNB’s seem to work best on weaker signals, and these definitely qualify.

If all this seems like a lot of effort, keep in mind that there are very few 16APSK transponders in North America, and the ones that are up there tend to be transient – you never know when they will go away. Also, one reason that 16APSK is frequently used is to cram more channels onto a single transponder. It saves the uplinker money, but can mean that the available channels are low quality, with lots of compression artifacts. Nevertheless, I understand that some may wish to try to receive everything available, so hopefully the above will be helpful. If you have any other hints for receiving 16APSK signals, please feel free to leave a comment.