Date   

Re: experiences and lessons learned with a fresh Eumetcast install for WIndows and Linux

Ernst Lobsiger
 

Markus, George and potential GNU/Linuxers

Concerning the first post I can add my experience of installing TelliCast on Debian 10 amd64 (Buster).
My receivers are headless command line systems managed via ssh. Keyboard and monitor is only used
during the base install. I downloaded and burnt on CD the latest 343MB debian-10.3-amd64-netinst.iso.
All the following refers to a fully 64bit receiver system including TC client and latest EKU software.

The base install on an old Fujitsu/Siemens P7935 (Intel Core2 Duo 3.33GHz, 8GB RAM) takes 1/2 hour.

1) Device driver
   TBS-6903 device drivers are the reason I had to change back to Debian with systemd. The latest
   GIT media driver tree from TBS does not compile anymore on Devuan ASCII 2.0 or 2.1 which still
   has kernel 4.9. It's a pity Devuan does not seem to have the manpower to follow other distros.
   I'am still convinced that a systemd free GNU/Linux OS is more suited for a TC receiver only PC.
   But it's probably true: UNIX is dead and Linux goes the way of a modern desktop/mobile OS where
   you constantly plug in or connect to all kinds of things that have to be handled automatically.

2) EKU software
   I had no problem to get my eToken Pro v4.2.5.4 EKU working. I did *not* add any udev eToken rule.
   I faced the problems I reported before: I had to install gtk2.0.0 as the SavenetAuthenticationClient
   has been developped and linked to graphic stuff not found on my Debian 10 CLI only receiver system.
   I had to add the missing link: ln -s /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 /lib/libcrypto.so

3) Diseqc switching
   Something I do not use. But I use my own version of szap-s2 compiled from CrazyCat sources.

4) smcroute
   This is where systemd begins to interfere. The EUMETSAT distributed SysV init scripts originate
   from the old days of DVB-S and do not fit well in a systemd handled GNU/Linux. I also had to:

   systemctl disable smcroute
   systemctl disable smcroute-helper

   There is more: systemd comes with its own ntp client service. This is normally disabled when
   you install a full featured ntpd. But when you sync your clock with TelliCast (as EUMETSAT
   proposes) you better check that your RTC is not pushed back and forth beween TC and systemd.

   I use my own versions of dvb-eumetcast and tellicast-client scripts outside of /etc/init.d

   The EUMETSAT distributed script dvb-eumetcast still relies on old ifconfig which is not there
   unless you apt-get install net-tools. Even then it failed to configure my dummy0, dummy1, dummy2
   multicast interfaces. This is new to me: In older Linux kernels with module dummy loaded you
   could just type "ifconfig dummy0 192.168.1.1 multicast" and you had your new dummy0 configured.
   in Debian 10 with kernel 4.19.0-8-amd64 I had to create my 3 dummies first with utility ip:

   ip link add dummy0 type dummy  
   ip link add dummy1 type dummy
   ip link add dummy2 type dummy

   Then I could configure them with ifconfig. I will rewrite my dvb-eumetcast script to
   only use ip instead of ancient ifconfig and probably drop EUMETSAT a note about that.

   There is more problems with smcroute. This used to be one executable in /usr/sbin.
   The version 2.4.2-4 distributed with Debian 10 is now called with smcrouted and
   smcroutectl (sounds like systemctl :-) and smcroute is actually a "compatibility
   wrapper for users with old startup scripts" in /usr/sbin. It's obvious that this
   can go wrong with the EUMETSAT distributed dvb-eumetcast script. As a new feature
   the daemon flushes "unused dynamic" multicast routes after a default delay of 60s.
   This feature deserves more study. It drops routes for channels that have not been
   active recently. When TelliCast announces data in such a channel it usually fails
   with: "WRN: ... Failed to open data channel ... address ... No data received from
   sender". Starting the daemon smcrouted with "smcroute -d -c 0" did the trick !

5) SUCCESS
   It took me 5 hours too. Next install will be with CloneZilla in 10 minutes.

6) Tune as usual
   I have very little missed packets as usual. As posted several times before I
   recommend to disable C-States in BIOS and to pin busiest interrupts to cores.

Bottom line: Yes, installing a GNU/Linux TC receiver is not for the faint of heart.
But if you are willing to google, read posts and man pages it can easily be done.
A couple of people on this list have done it before in different ways and are willing
to help. Please keep in mind that EUMETSAT pushed routers from the very beginning
of DVB-S2 transmission and that they do not have the manpower to keep up with
all that's going on around PCIe DVB-S2 cards and the many GNU/Linux distros.


Best regards,
Ernst


Re: MSG Animator - no receive.

David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺
 

-----Original Message-----
From: Heinz Meschnark
Sent: Wednesday, February 12, 2020 8:51 PM
To: MSG-1@groups.io
Subject: [MSG-1] MSG Animator - no receive.

Hello!
I will using MSG Animator and I have installed MSG Data Manager and MSG Animator in the same folder.
the licence is valid.
I beginning with EumetCastBas, after "Start MSG Data Manager". When I enter Msg Animator, then I can see
the notice "Reminder and the request - name and licence code.
After entering the valid code .
There is no reaction after the code has been entered and no receive of pictures.
Please, can you help.
Thank you in advance,
73!
.

Attachments:


Screen Shot 02-11-20 at 10.39 PM.PNG
Screen Shot 02-02-20 at 03.32 PM.PNG
Screen Shot 02-02-20 at 03.41 PM.PNG
Screen Shot 02-02-20 at 03.50 PM.PNG
Screen Shot 02-11-20 at 10.07 PM.PNG
Screen Shot 02-11-20 at 10.09 PM.PNG
====================================================

Heinz,

Thanks for the screenshots. Sorry to hear of your problem. This topic is more suited to the SatSignal group:

https://groups.io/g/SatSignal

- From the MSG Data Manager screenshot it seems you have not yet installed the licence. Is the licence not staying set? Remember that when you do that you need to run the program with right-click, Run as Administrator.

- For an IR animation you need channel 09, 10.8 um.

- In the MSG Animator, right-click the icon which is in the Notification Area (what I call the system tray). Options, Set image data path, and ensure that it is at the top of the image tree, such as:

C:\MSG-1\Images (in your system, guessing from the screenshots).
D:\MSG\Images (in my system)

Cheers,
David
--
SatSignal Software - Quality software for you
Web: http://www.satsignal.eu
Email: david-taylor@...
Twitter: @gm8arv


MSG Animator - no receive.

Heinz Meschnark
 

Hello!
I will using MSG Animator and I have installed MSG Data Manager and MSG Animator in the same folder.
the licence is valid.
I beginning with EumetCastBas, after "Start MSG Data Manager". When I enter Msg Animator, then I can see
the notice "Reminder and the request - name and licence code.
After entering the valid code .
There is no reaction after the code has been entered and no receive of pictures.
Please, can you help.
Thank you in advance,
73!
.


Re: experiences and lessons learned with a fresh Eumetcast install for WIndows and Linux

Ernst Lobsiger
 

George,

Yes, dB is what I have used from the very beginning. Again from my first patch of the stv090x driver
up to now there has been much change. In Konstantins TBS drivers there was a module parameter
to select % or dB(m). Below is what I have used for 3 years now. As a result of this thread I wanted
to compile the latest OS drivers from TBS. No way with Devuan 2.0 or 2.1 because some modules
asked for a newer kernel. So I just installed Debian 10 amd64 and will double check my stuff again.

Meanwhile play with the bash files attached. They should still work for TBS-6983/08/03 ...

Cheers,
Ernst


Re: experiences and lessons learned with a fresh Eumetcast install for WIndows and Linux

George Sz
 

Ernst,

Thanks for posting the module option again, I did not know of this due to lack of documentation. Googling this option will direct you back to this forum.

Anyway, I removed the splitter and the input levels increased, SNR didn't change however. Btw, is there any way to force the 6903 drivers to return dB instead of percentage?

Regards,
George


Re: experiences and lessons learned with a fresh Eumetcast install for WIndows and Linux

Ernst Lobsiger
 

Markus,

That's a long story. TBS is basically a HW manufacturer. The USB box TBS-5925
has the same first generation ST demodulator chip as the TBS-6925 and the SR1.
No way to receive 2 ACM/VCM transponders at the same time as with a TBS-6903.

Years back TBS worked with a driver programmer Konstantin Dimitrov and mostly
produced closed source blobs you had to link in. The driver of the TBS-6925 was an
Open Source exception basically programmed by Manu. Together with Konstantin I was
finally able to get it working for DVBS-2 EUMETCast on a TBS-6925. It seems they
later sacked Konstantin and wanted to go fully Open Source. There was a time TBS
still distributed Konstantins drivers without having the source (!). Some of the
EUMETSAT recommended drivers might still date back to those days and finally
stopped working with newer Linux kernels. The Open Source TBS-6903/08 driver
was loosing interrupts and also had the PCIe-Bridge buffer delay problem with
HVS-2. I was able to fix that with the help of CrazyCat. Ever since CrazyCat
seems to have maintained the Open Source tree of TBS device drivers. So my
recommandation is just to try the latest from the Open Source TBS repo.
But the TBS-5925 driver code has probably not been touched for years now.
If you have a driver problem with latest Linux kernels CrazyCat might fix that.

Here I added a MODCOD filter to this TBS-5925/6925 driver that worked well.
This is useful to stop HVS-1/BAS interaction in rainy weather conditions.
I tried the same with the TBS-6903/08 but have never got it working :-( ...

Cheers,
Ernst


Re: experiences and lessons learned with a fresh Eumetcast install for WIndows and Linux

Markus Kempf
 

Ernst,

do you have a link or a writeup of your judgement of the TBS drivers? Which one would be best for the 5925?

Markus


Re: experiences and lessons learned with a fresh Eumetcast install for WIndows and Linux

Ernst Lobsiger
 

George,

 Here is the module parameter I was talking about. This is copied in part from my message #27249:

<cite>


And here comes the next trick that makes the 6903 driver shine.
If you want a single cable system that takes T1 + T2 it's easy
again. Edit a file /etc/modprobe.d/stv6120.conf with content:

options stv6120 rfsource=1

The meaning that you might want to write into the file as comment:

#  Parameter rfsource is loaded when booting (cannot be changed in /sys/module/...)
#  0  = you can attach two cables LNB0->adaper0 and LNB1->adapter1 (DEFAULT)
#  1  = connect the cable to LNB0 where you can use adapter0 + adapter1
#  2  = connect the cable to LNB1 where you can use adapter0 + adapter1

Of course 1 and 2 is only possible if T1 and T2 is in the same band and polarisation.
But this is the case for EUMETCast transponders T1 and T2.

Cheers,
Ernst

</cite>


Re: experiences and lessons learned with a fresh Eumetcast install for WIndows and Linux

Markus Kempf
 

thanks for the feedback. I believe the core of the problems is the proprietary and closed source Tellicast client and the authentication requirements. That matches well with another monolithic and proprietary system like Windows but not with the fragmented Linux (Unix) world. But nethertheless the Linux install would be unproblematic with a concise and correct documentation or simply the correction of simple errors. Deb and rpm versions cover 90% of the market already.
1) make the TBS drivers consistent with the mainstream linux kernel or create a DKMS procedure to automatically recompile with every new kernel version
2) update the Safenet Authentication client to v10, maybe the erorr in the DEB file was corrected or build a new DEB for v9 or at least document the possible problems in the README or the general documentation
3) create a quick start guide linking the spread out info

In the long run I would hope for Eumetsat making up their mind and adopting an open access policy comparable to the Copernicus/Sentinel program with p2p access to the data (not Eumetcast Terrestrial with Tellicast/EKU and limited to research networks) .
In 2005 I had a 2Mbs connection to the Internet, now I have 1Gbs. The need for the satellite transmission is diminishing at least in the civilized parts of Europe and the british islands.

Markus


Re: experiences and lessons learned with a fresh Eumetcast install for WIndows and Linux

Ernst Lobsiger
 

George,

Why do you use a splitter? Inside the tuner chip there is a matrix switch. With a single module parameter you can connect your cable directly to one input and feed both adapter chains of the TBS-6903. That's the way I receive BAS/HVS-1 + HVS-2 with a single cable. This works with the TBS-6983/03/08 cards the same way. Or have you tried that before and found the system works better with the splitter in front of the card? Or is this again a case of missing documentation?

Regards,
Ernst


Re: experiences and lessons learned with a fresh Eumetcast install for WIndows and Linux

George Sz
 

Markus,

Considering how much time I wasted on Debian before, I'm not likely going back to that distro ever again. At one point I decided to switch to Ubuntu Server and in my experience, it's a lot easier to get work done on that distro. Getting Eumetcast to run, as far as I can recall, takes for me about an hour or two, and that includes OS installation. I also perform OS/kernel updates now and then and so far my system has survived all of these adventures. In my experience, the installation process has become a lot more simple over the years. I remember I had to spend days trying to get my dongle working with that old akstre garbage.

While I agree that compiling the TBS drivers is a pain, doing a few compiles will get you the necessary experience. Regarding DiSEqC, when it comes to professional use, it just adds one more point of failure so in the end I'm not surprised about its omission in the docs.

Perhaps my biggest issue so far was the proprietary client software, namely that nasty udev bug that was eventually addressed. I just wish its disk write issue did not require these RAM disk hacks. Sidenote: I still wonder why this is happening, maybe the client is doing a forced cache flush, then perform a hash check to make sure data has been written to disk properly? I mean, the Linux disk cache system could easily take care of fast write spikes.

As for the hardware I'm running, it's an off-lease 4th gen core i5 Lenovo SFF with 8GB of RAM, with a TBS 6903 inside. The dish I'm using is a 1.8m Prodelin with a Russian feedhorn, with a single cable setup, using a splitter to feed both inputs of the card.

Regards,
George


Re: experiences and lessons learned with a fresh Eumetcast install for WIndows and Linux

Ernst Lobsiger
 

Markus

The real problem of GNU/Linux is twofold:

- Linuxers want their "own" distro and their "very special" EUMETCast system
- There is no central EUMETCast knowledge base like Davids site for Windows

The hint for the link you made above is found in my README.amd64.gz in message #28250.

My receivers work rock solid on 11 years old hardware with Intel Duo processors taking
BAS + HVS-1 + HVS-2 with a single cable and doing quite a bit of image processing too.

Missed packets are often related to excessive wait states by slow HDDs. I have written
almost "scientfic papers" about that issue. I'm not sure a NAS is the way to go here.

Systemd poses another problem as the EUMETSAT scripts date from quite a while back
and even if I'm no "greybeard" I do not welcome systemd on my EUMETCast receivers.

Cheers
Ernst

P.S. Your next GNU/Linux receiver setup will be much faster :-) ...





Re: experiences and lessons learned with a fresh Eumetcast install for WIndows and Linux

Christian Peters
 

Markus,

thank you for that long article!
That's really interesting and it's good to know there are some other users trying to setup TC on Linux.
Yes, it was really a challenge I never would get the system up without the help of Ernst.
My system runs Debian Stretch and it only runs the TelliCast client software with some basic xrit2pic scripts.
My sytem uses two TBS 5925 to get the data from two transponders. Ernst wrote a special version of dvb-eumetcast and split the the three services on three dummy devices.
Yes, the USB problem, the eToken link and the compiling of the kernel driver for the TBS is really a problem so I didn't touch the system since it runs (now for 214 days without reboot....the last reboot was a power interruption caused by a thunderstorm).

I would love to see an updated script for installing a TC receiver system with a TBS USB device, a TBS PCIe card and a Novra S300N receiver and for one or two Linux distributions like Ubuntu and Debian/Devuan to animate some other people to try Linux as platform. If it runs it runs rock solid! Regarding the reception quality I can't compare but I even get some key errors.

But at my Win10 processor I have to look every day whether the system does a reboot after installing updates in the night...which stops all processing software I have to restart then... :-P
I'm not sure if I would be able to get a Win10 system to not reboot....except disconnecting from the internet... :-D
Maybe all will be much easier if the Linux receiver would use a NOVRA300 hardware....but as the MTG mission will start next year, a third transponder will be set up and I think three of them would be to expensive for me and it would maybe not be possible to use three TBS USB devices like the 5925 on a Win10 or Linux system...!?
I don't know how this challenge could be managed in a easy way....and as the Linux drivers/firmware available for the new TBS PCIe cards is not really working with EUMETCAST....maybe setting up a Linux receiver would be impossible except for really experts in this future!? :-(

But most user know that setting up something in Linux is a challenge and even fun to get it working, but it would be really great if you and Ernst could contact EUMETSAT and could help to update the setup instruction script to lower the bar regarding setting up a Linux TC receiver.

But nevertheless I'm happy with my Linux TC receiver as it runs...but setting it up again I think I would need an updated script and again much help form Ernst and you...! ;-)

Regards,

Christian



Am 10.02.20 um 18:51 schrieb Markus Kempf:

I have used Eumetcast since 2005 and did a few posts to this group a long time ago. My receiving system started on a Pentium system that was up to date in 2005 running Windows XP. I later migrated to Win7 on a new hardware (2014) and finally to Win10 about three years ago. The old Tellicast sw installation just worked and I never touched it. For other reasons, I had to make a completely new fresh installation of Win10. I decided to finally update my old setup and downloaded/replicated the Eumetsat directory at:

ftp://ftp.eumetsat.int/pub/OPS/out/user/EUMETCast_Support/

After a short read of the documentation I downloaded the latest TBS Win10 drivers for my 5925 and Crazycats BDADataEx because I need Diseqc switching, something TVB's IP tool does not provide. I knew that already, but for a newbie it should be mentioned in the Eumetcast documentation.

https://www.tbsdtv.com/download/

After about 15min of downloading, installing and configuring, the system was up and running, receiving my usual data (actually much more because I did not edit the channels configuration :-). I believe that almost everybody could do this in a reasonable amount of time with the docs available and given the fact that the stuff simply works.

Then I got the idea that the Eumetcast reception could be done with my new NAS server system, replacing the old PC and saving some electrical energy and money because the NAS runs 24/7 anyway. I had the same idea a few years ago, but the old NAS server was ARM based and the proprietary Tellicast client is not available. The new system is Intel based, so it seemed perfectly fit for the purpose. I was quite confident that this would work in a short amount of time, given my 35 years of experience working as an engineer in the IT industry and beeing a Unix native... Unfortunately, that was a fallacy. The current state of the software and documentation provided by Eumetsat makes it very unlikely that a normal user will succeed. My biggest mistake was not to search in the archive of this group, because most problems have been addressed already by Christian Peters and Ernst Lobsiger.
My NAS server uses Debian 10, with a backport kernel 5.4. Unlike Ernst/Christian, I like to use systemd, so I'm not a real Unix greybeard...

1) DVB device driver
Even after so many years, the installation of the device drivers for a TBS5925 is still a mess, because they are not part of the slipstream process and have to be compiled by the user and for every new kernel version. That's a real pain for every system not totally dedicated to Eumetcast reception and nothing else. I have used the install scripts at:

https://github.com/tbsdtv/linux_media/wiki

The drivers work, the device gets recognized. Unfortunately the procedure taints the signed kernel and some debian provided modules will no longer work (eg.my USB soundcard).
In the Eumetsat documentation you could eiher use the 2014 or 2016 drivers or the above method depending on which document you read, no consistency at all.

2) EKU software
The crypto dongle, unfortunately still needed, that I use, is the original Aladin dongle ID 0529:0514 Aladdin Knowledge Systems eToken Pro v4.2.5.4. After following the advice in EUMETCast_Support/tellicast-client-pre-release/linux/README_Safenet_EKU_linux.txt, the dongle was not recognized by the system, the lsusb command showed nothing. The troubleshooting guide gives a hint, but has outdated info. On a modern Debian 10 system, the file /lib/udev/rules.d/90-hid-eToken.rules must be changed to include idProduct 514. This can also be found in the archives of this group.
SUBSYSTEM=="block" , ATTRS{idVendor}=="0529", ATTRS{idProduct}=="0514|0602|3002|3004|3005|3006|3007", MODE="0777"
SUBSYSTEM=="usb" , ATTRS{idVendor}=="0529", ATTRS{idProduct}=="0514|0602|3002|3004|3005|3006|3007", MODE="0777"
SUBSYSTEM=="usbmisc" , ATTRS{idVendor}=="0529", ATTRS{idProduct}=="0514|0602|3002|3004|3005|3006|3007", MODE="0777"
SUBSYSTEM=="hid" , ATTRS{idVendor}=="0529", ATTRS{idProduct}=="0514|0602|3002|3004|3005|3006|3007", MODE="0777"
SUBSYSTEM=="hidraw" , ATTRS{idVendor}=="0529", ATTRS{idProduct}=="0514|0602|3002|3004|3005|3006|3007", MODE="0777"
I'm really astonished, given the many old dongles, that they break the compatibility with the old devices and do not mention this in the documentation. A normal user will already fail at this point.
The dongle now showed up with "lsusb" but still did not work with tc-cast-client -k. After many hours of research, I found the problem. The library libcrypto must be present in /lib or /usr/lib. This is an error in the DEB control file of the Safenet Authentication client core library and should not happen. Again, a normal user would most likely fail again at this point. The archives of this group give another solution, but this simple symbolic link is good enough.
ln -s /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 /lib/libcrypto.so

3) Diseqc switching
I have a setup with two dishes and four LNBs, so there is the need to switch to the right LNB. Unfortunately, the documentation again does not really mention it. You can find a hint in the config file /etc/channels.conf in a comment #name:frequency:PolarisationDVBStdModcod:diseqSatNr:Symbolrate:::
szap-s2 can switch, but you have to change the entries to your used number. In my case: E1B:11263:hS1:3:33000:::
Again, this would stop normal users and could be clearly explained in a Linux setup guide.

4) smcrouted
Now my DVB device worked, the EKU worked and I created the necessary network devices with EUMETCast_Support/EUMETCast_Licence_cd/Linux/DVB_devices/Common_Apps/dvb-eumetcast-setup.sh. Unfortunately I still could not receive data... A check with service tellicast-client status showed that smcrouted failed, because another one is already running. So at least on a Debian 10 system, the distribution provided smcrouted service must be disabled.
systemctl disable smcroute
systemctl disable smcroute-helper

5) SUCCESS
After many hours of work, the system finally works...

6) some quirks
the reception is worse compared to the Win10 setup. The count of missed packets is much higher.
I still have missing key errors sometimes in my log file
I need to adapt the metrics and stats scripts for my system

Hopefully this long article will help somebody to setup an Eumetcast system under Linux.

Markus





experiences and lessons learned with a fresh Eumetcast install for WIndows and Linux

Markus Kempf
 

I have used Eumetcast since 2005 and did a few posts to this group a long time ago. My receiving system started on a Pentium system that was up to date in 2005 running Windows XP. I later migrated to Win7 on a new hardware (2014) and finally to Win10 about three years ago. The old Tellicast sw installation just worked and I never touched it. For other reasons, I had to make a completely new fresh installation of Win10. I decided to finally update my old setup and downloaded/replicated the Eumetsat directory at:

ftp://ftp.eumetsat.int/pub/OPS/out/user/EUMETCast_Support/

After a short read of the documentation I downloaded the latest TBS Win10 drivers for my 5925 and Crazycats BDADataEx because I need Diseqc switching, something TVB's IP tool does not provide. I knew that already, but for a newbie it should be mentioned in the Eumetcast documentation.

https://www.tbsdtv.com/download/

After about 15min of downloading, installing and configuring, the system was up and running, receiving my usual data (actually much more because I did not edit the channels configuration :-). I believe that almost everybody could do this in a reasonable amount of time with the docs available and given the fact that the stuff simply works.

Then I got the idea that the Eumetcast reception could be done with my new NAS server system, replacing the old PC and saving some electrical energy and money because the NAS runs 24/7 anyway. I had the same idea a few years ago, but the old NAS server was ARM based and the proprietary Tellicast client is not available. The new system is Intel based, so it seemed perfectly fit for the purpose. I was quite confident that this would work in a short amount of time, given my 35 years of experience working as an engineer in the IT industry and beeing a Unix native... Unfortunately, that was a fallacy. The current state of the software and documentation provided by Eumetsat makes it very unlikely that a normal user will succeed. My biggest mistake was not to search in the archive of this group, because most problems have been addressed already by Christian Peters and Ernst Lobsiger.
My NAS server uses Debian 10, with a backport kernel 5.4. Unlike Ernst/Christian, I like to use systemd, so I'm not a real Unix greybeard...

1) DVB device driver
Even after so many years, the installation of the device drivers for a TBS5925 is still a mess, because they are not part of the slipstream process and have to be compiled by the user and for every new kernel version. That's a real pain for every system not totally dedicated to Eumetcast reception and nothing else. I have used the install scripts at:

https://github.com/tbsdtv/linux_media/wiki

The drivers work, the device gets recognized. Unfortunately the procedure taints the signed kernel and some debian provided modules will no longer work (eg.my USB soundcard).
In the Eumetsat documentation you could eiher use the 2014 or 2016 drivers or the above method depending on which document you read, no consistency at all.

2) EKU software
The crypto dongle, unfortunately still needed, that I use, is the original Aladin dongle ID 0529:0514 Aladdin Knowledge Systems eToken Pro v4.2.5.4. After following the advice in EUMETCast_Support/tellicast-client-pre-release/linux/README_Safenet_EKU_linux.txt, the dongle was not recognized by the system, the lsusb command showed nothing. The troubleshooting guide gives a hint, but has outdated info. On a modern Debian 10 system, the file /lib/udev/rules.d/90-hid-eToken.rules must be changed to include idProduct 514. This can also be found in the archives of this group.
SUBSYSTEM=="block" , ATTRS{idVendor}=="0529", ATTRS{idProduct}=="0514|0602|3002|3004|3005|3006|3007", MODE="0777"
SUBSYSTEM=="usb" , ATTRS{idVendor}=="0529", ATTRS{idProduct}=="0514|0602|3002|3004|3005|3006|3007", MODE="0777"
SUBSYSTEM=="usbmisc" , ATTRS{idVendor}=="0529", ATTRS{idProduct}=="0514|0602|3002|3004|3005|3006|3007", MODE="0777"
SUBSYSTEM=="hid" , ATTRS{idVendor}=="0529", ATTRS{idProduct}=="0514|0602|3002|3004|3005|3006|3007", MODE="0777"
SUBSYSTEM=="hidraw" , ATTRS{idVendor}=="0529", ATTRS{idProduct}=="0514|0602|3002|3004|3005|3006|3007", MODE="0777"
I'm really astonished, given the many old dongles, that they break the compatibility with the old devices and do not mention this in the documentation. A normal user will already fail at this point.
The dongle now showed up with "lsusb" but still did not work with tc-cast-client -k. After many hours of research, I found the problem. The library libcrypto must be present in /lib or /usr/lib. This is an error in the DEB control file of the Safenet Authentication client core library and should not happen. Again, a normal user would most likely fail again at this point. The archives of this group give another solution, but this simple symbolic link is good enough.

ln -s /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 /lib/libcrypto.so

3) Diseqc switching
I have a setup with two dishes and four LNBs, so there is the need to switch to the right LNB. Unfortunately, the documentation again does not really mention it. You can find a hint in the config file /etc/channels.conf in a comment #name:frequency:PolarisationDVBStdModcod:diseqSatNr:Symbolrate:::
szap-s2 can switch, but you have to change the entries to your used number. In my case: E1B:11263:hS1:3:33000:::
Again, this would stop normal users and could be clearly explained in a Linux setup guide.

4) smcrouted
Now my DVB device worked, the EKU worked and I created the necessary network devices with EUMETCast_Support/EUMETCast_Licence_cd/Linux/DVB_devices/Common_Apps/dvb-eumetcast-setup.sh. Unfortunately I still could not receive data... A check with service tellicast-client status showed that smcrouted failed, because another one is already running. So at least on a Debian 10 system, the distribution provided smcrouted service must be disabled.
systemctl disable smcroute
systemctl disable smcroute-helper

5) SUCCESS
After many hours of work, the system finally works...

6) some quirks
the reception is worse compared to the Win10 setup. The count of missed packets is much higher.
I still have missing key errors sometimes in my log file
I need to adapt the metrics and stats scripts for my system

Hopefully this long article will help somebody to setup an Eumetcast system under Linux.

Markus


Re: Receiving Noaa 20 data

George Sz
 

I've had this problem before and had to sift through several channels for VIIRS data.

What you're likely looking for is here:

NOAA20 VIIRS: bas, NPP-2
NPP VIIRS hvs-1, E1H-RDS-1

Regards,
George


Re: Signal Level

David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺
 

Same here. I can confirm this!
Regards
Hartmut

David, Ian

I can confirm that after a short period of with an increase of the
signal level 0,5 dB up the level decreased later that evening to a level
below 14 dB.
At this moment the signal level is 14,1 dB which is 0,2/0,3 dB lower
that the average level i saw the last months with clear sky in the morning.

Greetings Herman
=======================================================

Folks,

Thanks, both, for the confirmation. I suggest reporting this to EUMETSAT so that they are at least aware of the issue, although the response may be simply that "our provider says it's within specification".

Cheers,
David
--
SatSignal Software - Quality software for you
Web: http://www.satsignal.eu
Email: david-taylor@...
Twitter: @gm8arv


Re: Signal Level

Hartmut Schulla
 

Same here. I can confirm this!
Regards
Hartmut

-----Ursprüngliche Nachricht-----
Von: MSG-1@groups.io [mailto:MSG-1@groups.io] Im Auftrag von Herman Vijlbrief
Gesendet: Donnerstag, 6. Februar 2020 09:26
An: MSG-1@groups.io
Betreff: Re: [MSG-1] Signal Level

David, Ian

I can confirm that after a short period of with an increase of the
signal level 0,5 dB up the level decreased later that evening to a level
below 14 dB.
At this moment the signal level is 14,1 dB which is 0,2/0,3 dB lower
that the average level i saw the last months with clear sky in the morning.

Greetings Herman


Thanks, Ian.  I've not heard anything from EUMETSAT, except their
standard response that the services are provided by a third party.

If you see my data as being out of date please try a Ctrl_F5 (or what
even incantation is required for your browser this week!). I do see
similar effects on a number of other stations, and refresh sorts it. 
I'm not quite sure why it is, but something isn't telling the Web
server / browser client that the image needs to be downloaded again
as it's been updated.  Perhap someone more expert in HTML can suggest
something?

Cheers,
David
----------------------------------------------------------------------------


Thanks for your reply David. I have done many refresh attempts to no
avail.

I have just very recently updated to the new Microsoft Edge browser
which is now available for download and it appears that browser is
what is causing the problem but only on your lost/missed and recovered
graphs, with all other graphs being fine. Internet Explorer shows all
graphs up to date so I will you that browser when required.

Regards
Ian.




Re: Signal Level

Herman Vijlbrief
 

David, Ian

I can confirm that after a short period of with an increase of the signal level 0,5 dB up the level decreased later that evening to a level below 14 dB.
At this moment the signal level is 14,1 dB which is 0,2/0,3 dB lower that the average level i saw the last months with clear sky in the morning.

Greetings Herman


Thanks, Ian.  I've not heard anything from EUMETSAT, except their standard response that the services are provided by a third party.

If you see my data as being out of date please try a Ctrl_F5 (or what even incantation is required for your browser this week!). I do see similar effects on a number of other stations, and refresh sorts it.  I'm not quite sure why it is, but something isn't telling the Web server / browser client that the image needs to be downloaded again as it's been updated.  Perhap someone more expert in HTML can suggest something?

Cheers,
David
----------------------------------------------------------------------------


Thanks for your reply David. I have done many refresh attempts to no avail.

I have just very recently updated to the new Microsoft Edge browser which is now available for download and it appears that browser is what is causing the problem but only on your lost/missed and recovered graphs, with all other graphs being fine. Internet Explorer shows all graphs up to date so I will you that browser when required.

Regards
Ian.



Re: Signal Level

Ian Deans
 

On 05/02/2020 18:23, David J Taylor via Groups.Io wrote:
I have just seen a number of mails re an increase in signal level of
about 0.5dB and cannot believe what I am reading !!!
I was about to send a mail reporting that for the last 4 hours or so in
clear conditions my signal level is down by 0.5 SNR up here north of
Dundee and still is. What is going on !!!
When I checked your level David from your graph about 2 hours ago your
level looked a bit down as well.
By the way David I noticed that your lost and missed and recovered
graphs appear to be about 4/5 days old.
Regards
Ian.
Thanks, Ian.  I've not heard anything from EUMETSAT, except their standard response that the services are provided by a third party.
If you see my data as being out of date please try a Ctrl_F5 (or what even incantation is required for your browser this week!).  I do see similar effects on a number of other stations, and refresh sorts it. I'm not quite sure why it is, but something isn't telling the Web server / browser client that the image needs to be downloaded again as it's been updated.  Perhap someone more expert in HTML can suggest something?
Cheers,
David
----------------------------------------------------------------------------

Thanks for your reply David. I have done many refresh attempts to no avail.

I have just very recently updated to the new Microsoft Edge browser which is now available for download and it appears that browser is what is causing the problem but only on your lost/missed and recovered graphs, with all other graphs being fine. Internet Explorer shows all graphs up to date so I will you that browser when required.

Regards
Ian.


Re: Signal Level

David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺
 

I have just seen a number of mails re an increase in signal level of
about 0.5dB and cannot believe what I am reading !!!

I was about to send a mail reporting that for the last 4 hours or so in
clear conditions my signal level is down by 0.5 SNR up here north of
Dundee and still is. What is going on !!!

When I checked your level David from your graph about 2 hours ago your
level looked a bit down as well.

By the way David I noticed that your lost and missed and recovered
graphs appear to be about 4/5 days old.

Regards
Ian.
===============================

Thanks, Ian. I've not heard anything from EUMETSAT, except their standard response that the services are provided by a third party.

If you see my data as being out of date please try a Ctrl_F5 (or what even incantation is required for your browser this week!). I do see similar effects on a number of other stations, and refresh sorts it. I'm not quite sure why it is, but something isn't telling the Web server / browser client that the image needs to be downloaded again as it's been updated. Perhap someone more expert in HTML can suggest something?

Cheers,
David
--
SatSignal Software - Quality software for you
Web: http://www.satsignal.eu
Email: david-taylor@...
Twitter: @gm8arv