New approach for GNU/Linux TC receivers using DVB-S2 PCIe cards


Ernst Lobsiger
 

Dear GNU/Linux users

As long as I can remember the static multicast router "smcroute" has been
the solution to prevent packet loss when the TC client joins and leaves
multicast groups. Smcroute seems not to be packed with some GNU/Linux distros
and comes in different versions. Lately there have been important updates that
made the EUMETSAT distributed SysV file "dvb-eumetcast" (first version 2008)
fail. I recently helped Graham Woolf to setup a system with Debian 10.7 and his
TBS-6909X. This endeavour ended in 287 e-Mails back and forth and a couple of
fixes of the latest EUMETSAT distributed "dvb-eumetcast" from my side. Graham's
receiver is now running (no news is good news) while my wife is still waiting
for the second portion (5 x 5ml Pots) of highly recommended "Hadrian's Balm".
http://www.hadriansbalm.co.uk/           ..  which is maybe another Brexit fallout.

I have collected and reported all encountered problems including former issues
with the new SaveNet 9.0 EKU software. This lead to an in depth reconsideration
of the situation and discovery of a novel approach using the properties of
more recent Linux kernels only. It is now EUMETSAT's declared aim to get rid
of "smcroute" as far as possible using kernel ethernet bridging and bonding
the DVB-interfaces (one per PID) to a common internal interface "dvbond0".
All TC clients then attach to this internal interface "dvbond0". I have one
of these novel TC receivers running here without packet loss (though somewhat
higher system load).  EUMETSAT is interested in as much feedback as possible
re this new solution. Hoping that some more users with GNU/Linux receivers
(or the sheer intention to setup such a beast) grab a surplus PC and a DVB
card (e.g. SkyStar2 eXpress HD, TBS-6925, TBS-6903, TBS-6903X, TBS-6909X) to
test this novel approach, I attach the latest relevant e-Mail from OPS below.
Please share your problems/findings under this thread but also report those
directly to EUMETSAT OPS under the subject "EUMHD-3310: InproveLinuxSetup".


Happy hacking,

Ernst


P.S.

This new solution should also apply to USB boxes like TBS-5925 and TBS-5927.
32Bit Linux is slowly fading away, please consider to setup a 64Bit version.




<CITE>

RE: EUMHD-3310 RE: ImproveLinuxSetup
Von     EUMETSAT User Helpdesk
Absender     Andreea Munteanu
An     Ernst Lobsiger
Datum     Mo 11:19

Dear Ernst,

Regarding dvb-eumetcast, after analysis of different options, and considering important
aspects of dependencies and maintenance effort of the package, here is the outcome.

A new test version of dvb-eumetcast package can be downloaded from this location:

ftp://ftp.eumetsat.int/pub/OPS/out/user/EUMETCast_Support/tellicast-client-pre-release/linux/new_versions/

After un-tarring the package you find the Readme file with further instructions and information.

In short words, we want to remove the dependency from smcroute. There are other options with a smaller
footprint supported by the OS. The default method to combine the dvb interfaces into one network interface
is a bonding interface supported since a while by the kernels.

This package still contains smcroute method as an option, but this is just to be able to compare
the performance of the different methods.

Please test this version and provide your feedback. Feel free to distribute to the community.
We would like to have as much feedback as possible if there are problems encountered.

Prerequisite is a DVB device working under the linuxtv DVB-S2 API implemented in the kernel.
We cannot discuss DVB device related issues as these are responsibility of the manufacturers.


Best regards,

Andreea Munteanu
EUMETSAT User Services

</CITE>


Graham Woolf
 

Hi Ernst

Second package should be with you soon - I hope

My system is running OK but I am getting lots of lots packets due to high winds here - I may have to get someone in to see to my dish

Would you recommend me upgrading  my system ? Is it complicated ?

Regards

Graham


Ernst Lobsiger
 

On Wed, Feb 24, 2021 at 03:17 AM, Graham Woolf wrote:
Would you recommend me upgrading  my system ? Is it complicated ?
Hi Graham,

it's up to you, whether you want to be a forerunner again. The change is not complicated.
You stop /etc/init.d/tellicast-client and /etc/init.d/dvb-eumetcast. Make a backup of
dvb-eumetcast and /etc/dvb-eumetcast.cfg. Then using mc you copy the content of file
dvb-eumetcast-1.2-0_905.x86_64.tar.gz to the respective places in the file system.

Starting again the new /etc/init.d/dvb-eumetcast should setup the novel dvbond0 interface.
If you want your 3 demodulator setup to begin with edit the new dvb-eumetcast.cfg first.
The configuration files also allow for the HB13 backup satellite and fix the problem
with PID 509 that has not been used for years but still exists in your current setup.

One side effect is that the eLuna user-bytes graphs will only work 50% as dummy0 has
now been replaced by dvbond0. It should be noted, that the new solution is on layer 2
(like bridges and switches) while the classic solution is on layer 3 (like routers).

You can revert again by copying back /etc/init.d/dvb-eumetcast and /etc/dvb-eumetcast.cfg
on a stopped system. I have adapted eLuna for a single MC interface either dummy0 or dvbond0.
This is a Q&D fix that does not touch existing RRDs. The smcroute graph has been replaced
given the fact that EUMETSAT said they will slowly go to 1 PID per TC service in the future.

My receiver Luna running now with the new dvbond0 is here: http://5.153.116.236:86

If you want to adapt your eLuna monitoring you can wget the respective files from Luna.
Don't forget that these files must belong to your apache2 user (chown www-data:www-data).


Good luck

Ernst


Graham Woolf
 

Hi Ernst

I always like to be a forerunner

Thanks for that  I will have a go tomorrow

Do I copy the new szap-2 and mc-grp-join files as well ?

I have tried wget for your latest eluna files but it cant seem to find anything - I used wget http://5.153.116.236:86/eluna.tgz and get file not found

I did hear back from Jonathan at Hadrians Balm and your parcels were sent separately for some reason so hopefully the second one should be with you soon

Regards

Graham


Ernst Lobsiger
 

On Wed, Feb 24, 2021 at 10:24 AM, Graham Woolf wrote:
Do I copy the new szap-2 and mc-grp-join files as well ?
Graham,

szap-s2 is probably the same you already have. mc-grp-join MUST be copied and will run in the background
with the new solution. There is no eluna.tgz this time. Just use the same paths you have starting from the
apache2 server root /var/www to directly get the respective update.sh or graph.pm files you need to change.
You can try with a graphical browser from Windows first if that helps. On the TC receiver use w3m or wget.

Regards,
Ernst


Graham Woolf
 

Hi Ernst

All changes done and all working perfectly

Regards

Graham


Ernst Lobsiger
 

Dear GNU/Linux users

The version of szap-s2 distributed in the evaluation kit with dvbond0
produces considerable additional UNIX system load with TBS-6903X/09X cards.
One reason is an added retreival of the demodulator chip temperature.

On the other hand this version can set MODCODs on the cards mentionned.
One possibility to get rid of the added system load is the -Q switch.
The -Q (Quiet) switch suppresses all unnecessary parameter retreival:

Look for these lines in dvb-eumetcast and add the -Q (+ final space):
...
                         A*)
                         # C-Band Africa...
                         SZAP_OPTION="-l $LOF_C  -Q  "
                         ;;

                         H*)
                         # C-Band Africa...
                         SZAP_OPTION="-l $LOF_KU  -Q  "
                         ;;

                         E*)
                         # C-Band Africa...
                         SZAP_OPTION="-l $LOF_KU  -Q  "
                         ;;

...

BTW comment # C-Band Africa...  under E* and H* is copy & paste error.
If you run my TBS-6909X 3 demodulator single cable solution you can set
the SID=1 (using P1) and set Bas MODCODs 8psk 3/5 only with W00001000.

For above settings make these changes in channels.conf:

Eutelsat 10A:11263:hS1O25:0:33000:::
AtlanticBird3:3732:h:0:11963::::
E1:11263:hS1P1:0:33000:::
E1B:11263:hS1P1W00001000:0:33000:::
E1H:11263:hS1P1:0:33000:::
E2:11388:hS1P1:0:33000:::
H1:11317:vS1:0:29950:::
H1B:11317:vS1:0:29950:::
H1H:11317:vS1:0:29950:::
H2:11355:vS1:0:29950:::
Htest:11393:vS1:0:27500:::
A1:3848:hS1:0:9892::::
#name:frequency:PolarisationDVBStdModcod:diseqSatNr:Symbolrate:::


Stop tellicast-client and dvb-eumetcast and restart to apply changes.


Cheers,
Ernst


Ernst Lobsiger
 

Dear GNU/Linux users

in the wake of ongoing improvement of the GNU/Linux setup of TC receivers there is a new milestone.
This weekend MODCOD setting with the latest TBS szap-s2 has been integrated in the drivers for
professional stv0900 and stv0910 based cards and USB-boxes. This means that it should now be
possible to set MODCODs with a HEX bitmap the same way as this is done in the SR1 setup. The
only setting that makes sense for PCIe cards is W00001000 to prevent HVS-1 side effects on Basic
service. Note that HVS-1 alone with W00040000 cannot run due to PCIe bridge DMA buffer lattency.

Experienced users with TBS-6925, TBS-6983, TBS-6903/08 cards or TBS-5925, TBS-5927 USB
boxes can now experiment the same way as users with TBS-6903X and TBS-6909X PCIe cards.

Many thanks go to TBS, CrazyCat and Christian Peters that made this long awaited step possible.
CrazyCat did the programming (see below) Christian and I provided ssh accessible test receivers.

https://github.com/tbsdtv/linux_media/commits/latest

Best regards,
Ernst


Markus Kempf
 

Dear Ernst,

congrats for this achievement, one patch step less to do. But please, the biggest nuisance with the TBS drivers is the simple fact that they are not upstream kernel drivers. So with every kernel update of my Debian system (backport kernels) I have to recompile/link the driver. So please TBS, Ernst, CrazyCat get them upstream (solve the likely quality issues raised by the kernel developers).

Markus

Am 15.03.2021 um 11:44 schrieb Ernst Lobsiger via groups.io:

Dear GNU/Linux users

in the wake of ongoing improvement of the GNU/Linux setup of TC receivers there is a new milestone.
This weekend MODCOD setting with the latest TBS szap-s2 has been integrated in the drivers for
professional stv0900 and stv0910 based cards and USB-boxes. This means that it should now be
possible to set MODCODs with a HEX bitmap the same way as this is done in the SR1 setup. The
only setting that makes sense for PCIe cards is W00001000 to prevent HVS-1 side effects on Basic
service. Note that HVS-1 alone with W00040000 cannot run due to PCIe bridge DMA buffer lattency.

Experienced users with TBS-6925, TBS-6983, TBS-6903/08 cards or TBS-5925, TBS-5927 USB
boxes can now experiment the same way as users with TBS-6903X and TBS-6909X PCIe cards.

Many thanks go to TBS, CrazyCat and Christian Peters that made this long awaited step possible.
CrazyCat did the programming (see below) Christian and I provided ssh accessible test receivers.

https://github.com/tbsdtv/linux_media/commits/latest

Best regards,
Ernst


Ernst Lobsiger
 

On Mon, Mar 15, 2021 at 06:16 AM, Markus Kempf wrote:
the biggest nuisance with the TBS drivers is the simple fact that they are not upstream kernel drivers
Markus,

to make a Linux device driver upstream is close to mission impossible.
Even if it's OS somebody capable has to be payed for a fulltime job
like that. And the money has to be earned first by companies like TBS.

TelliCast receivers run with the same kernel and no updates for years.
People that ask for the *latest and greatest* must pay a little price.
Compiling the TBS media module tree takes about 5 ridiculous minutes.

Regards,
Ernst


Markus Kempf
 

Ernst,

just an example, since kernel 5.7 the tuner chip Montage TS2022 rev4 (M88DS3103) is supported and earlier revisions have been supported since years (https://github.com/b-rad-NDi/media_tree). I bought an used Terratec S2 USB box for a few bucks when I got aware of this (for regular DVB TV reception). I believe the original work was done by Hauppauge, but current maintenance is done by volunteers. No witchcraft or big money necessary. Second best option would be a well working slipstream solution automating the update, unfortuantely the present solution falls short of that. I had always great difficulty to compile it for kernels >5.4. Btw TBS sells the "professional" DVB cards at a premium price, they should invest in the product. That they are not doing that is yet another sign that the market segment satellite data broadcast is declining.

No updates is not an option for a connected system! Never updated IoT devices are a big threat for your network security. Take care.

Regards,

Markus

PS: I moved the stuff last year into a VM and stopped updating :-)

Am 15.03.2021 um 14:48 schrieb Ernst Lobsiger via groups.io:

On Mon, Mar 15, 2021 at 06:16 AM, Markus Kempf wrote:
the biggest nuisance with the TBS drivers is the simple fact that they are not upstream kernel drivers
Markus,

to make a Linux device driver upstream is close to mission impossible.
Even if it's OS somebody capable has to be payed for a fulltime job
like that. And the money has to be earned first by companies like TBS.

TelliCast receivers run with the same kernel and no updates for years.
People that ask for the *latest and greatest* must pay a little price.
Compiling the TBS media module tree takes about 5 ridiculous minutes.

Regards,
Ernst


Ernst Lobsiger
 

Markus,

instead of keeping complaining:

“Ask not what your country can do for you – ask what you can do for your country.”   (JFK)
To begin with all technical documentation of ST chips is under NDA. That's where you start.

Ernst