Date   

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

Andreas Mueller
 

@Peter,

i was also initally facing the tc-cast-client segfaults - by digging more into the SafenetAuthenticationClient-core-9.0.43-0_amd64.deb Package i found a SACSrv daemon to be installed which then showed status 'error' when executing 'sudo service SACSrv status' -> Starting SACSrv daemon: SACSrv/usr/bin/SACSrv: error while loading shared libraries: libgtk-x11-2.0.so.0: cannot open shared object file: No such file or directory.
After installing the missing component with 'sudo apt-get install libgtk2.0.0' it started right away with no issues. I'm using EumetCast's initial file from their FTP server - so no further patching was done. My tc-cast-client never hung nor restarted after fixing that.

Andreas


Re: Removal of Sentinel-3 OLCI Level-1 Full Resolution NRT data from EUMETCast Satellite service

James Brown
 

On 17 Sep 2020, at 11:39, David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺 via groups.io <david-taylor=blueyonder.co.uk@groups.io> wrote:

EUMETSAT announcement:

Sentinel-3 OLCI Level-1 Full Resolution (FR) Near Real Time (NRT) data will be removed from EUMETCast Satellite in July 2021. The planned date for the removal of OLCI Level 1 FR NRT data from our EUMETCast Satellite service is 29 July 2021.

Alternative services to access these data are available:

See:

https://www.eumetsat.int/website/home/News/DAT_5184373.html

Cheers,
David
--
SatSignal Software - Quality software for you
Web: https://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk
Twitter: @gm8arv
I’m wondering which of the new services they are making space for?

Cheers.
James.


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

Ernst Lobsiger
 

Andreas

Link Margins (LM) are something like:

16APSK 2/3 : LM = SNR - 9.3
  8PSK 2/3 : LM = SNR - 5.9

EUMETSAT recommends LM > = 4dB for good EUMETCast reception.
With SNR = 9.1 dB you have a negative LM for HVS-1. Unless you
have a real MODCOD filter (that sets MODCODs on the demod chip)
you cannot receive HVS-1 nor BASIC as this is disturbed by HVS-1
packets as well. If your Windows setup allows for MODCOD selection
try to set 8PSK 2/3 only (you should see a remarkable improvement).

Under GNU/Linux (apart from routers) you have limited possibilities:

1) Have a dedicated 1.25m dish with very accurate pointing to 10° East.
   Depending on your antenna position you can expect SNR up to 15dB.
2) Use a TBS5925 USB box or TBS6925 PCIe card with my patched driver
   for BASIC only. Both HW solutions deprecated, not produced anymore,
   use a first generation VCM capable chip for one transponder only.
3) Use a Technisat SkyStar 2 eXpress HD if you are lucky to find one on
   e-Bay. I recently tested this card again and Christian was able to
   get one for 20Euros that works in his 55Euro Ancalagon for BASIC only.
   With TBS drivers this makes a perfect GNU/Linux BASIC only receiver.

In the long run you cannot go with USB boxes as you need one box
per transponder the way you need one SR1 per EUMETCast transponder.
With a good SNR you can use a TBS6903 for T1+T2 with a single cable.
You can use a TBS6908 (equals 2 x TBS6903) for up to 4 transponders.
You should soon be able to use a "cheap" TBS6909X V2? for 4 EUMETCast
transponders (don't buy this card yet, latest HW changes are under way!).


Best regards
Ernst


@David
Agreed, Windows must be far easier for setting up a TelliCast receiver.
K.-P. is doing his best to make GNU/Linux TC receivers still possible.
But as you said, different distributions make this "mission impossible".
On the other hand automatic updates from Microsoft must be a nightmare.

@Peter
I use Devuan that is still systemd free and have good results. Some
scripts distributed by EUMETSAT are buggy (including the SACSrv SysV
script!) that can make installation a little bit harder. Some may also
be dependant on binutils installed (not mentionned). But once you have
a running GNU/Linux TC receiver it will work for years without updates.
You can use old surplus HW and even make DVB-Routers with PCIe cards.
I use TBS PCIe cards and have my own adapted multi transponder scripts.
I could/should publish all my latest findings, but I am 68 and time flies.


On Thu, Sep 17, 2020 at 03:09 AM, Andreas Mueller wrote:
Now for my environment the only hope would be to get a patched 5927 driver similar to the 5925 version - unfortunately this goes beyond my skills ...
@ Andreas
I tried to patch the stv0910x driver (without HW documentation!) for MODCOD selection along the lines I did it for stv090x. Unfortunately no success ..


Removal of Sentinel-3 OLCI Level-1 Full Resolution NRT data from EUMETCast Satellite service

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

EUMETSAT announcement:

Sentinel-3 OLCI Level-1 Full Resolution (FR) Near Real Time (NRT) data will be removed from EUMETCast Satellite in July 2021. The planned date for the removal of OLCI Level 1 FR NRT data from our EUMETCast Satellite service is 29 July 2021.

Alternative services to access these data are available:

See:

https://www.eumetsat.int/website/home/News/DAT_5184373.html

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


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

Andreas Mueller
 

Markus,

thanks for replying on that - also read your comments and was hoping there's a solution other than using a 5925 (for which a modified driver is available as per Ernst's last comments). What surprised me: on Windows there's no such issue when not filtering for certain MODCODs whereas for Linux this seems to be the case.

Now for my environment the only hope would be to get a patched 5927 driver similar to the 5925 version - unfortunately this goes beyond my skills ...

Andreas


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

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

Hello,
[]
However, upon shutdown of such a hanged tc-cast-client, the logs reveal
that for a moment the launch initialises dongle, HTTP server, etc. and
then terminates. So this seems like some timing issue or so.

If anybody has advice on this, we would appreciate comments.

Best,
Peter.
==============================

Peter,

Perhaps prove the system and its components first on Windows - much, much easier!

My own experience with Linux is that everything is version dependent - sometime critically so. So if EUMETSAT recommend a particular distribution, and a certain version of that distribution, it's better to use what is recommended rather than deviate in any way.

Perhaps you could post the last few lines of the TelliCast log file?

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


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

Peter Novak
 

Hello,
continuation of this thread comes in quite timely for what we are doing.
We also are at the moment collecting "experiences" with a fresh install
of EUMETCast reception station with Ayecka SR1. Just yesterday we tried
to install Tellicast + Safenet Auth Client on Debian 10 Buster. Only
much later into the install we realised that Debian 10 is not yet well
supported, but we tried our luck. We have some mixed "feelings" about
that. Maybe this post could be useful to somebody and/or somebody will
be able to identify/explain the issues we had to work around.

1. after the installation according to EUMETSAT instructions Tellicast
did not work out of the box. The EKU dongle was recognised as
"Aladdin Knowledge Systems Token JC", but Tellicast was constantly
crashing with logs like these:
[Sep15 13:09] tc-cast-client[1046]: segfault at 968 ip 00007f6f3a73f8bb sp 00007ffce06ee290 error 4 in libpthread-2.28.so[7f6f3a73f000+f000]
[ +0.000003] Code: 00 00 0f 05 89 82 d0 02 00 00 48 8d 82 10 03 00 00 64 48 89 04 25 10 05 00 00 64 c6 04 25 12 06 00 00 01 48 8b 2d 35 57 01 00 <48> 8b 85 68 09 00 00 64 48 89 04 25 20 06 00 00 48 8d ba e0 02 00
2. we found Ernst's write-up at https://groups.io/g/MSG-1/topic/experiences_and_lessons/71144718?p=Created,,,20,1,0,0&jump=1
This was very useful for understanding of how shaky the whole
installation process can be on various Linux distros. We applied most
of the relevant advice in that post, but did not get rid of those
segfaults.
3. we diagnosed that Tellicast cannot connect to the EKU as
`tc-cast-client -k` was unable to list the host_key_4 as "Aladdin
EToken PRO" correctly. This led to suspicion that maybe the dongle
drivers are the culprit.
4. we also quickly realised that the SAC software is some 3rd party
piece operating the dongle. Some googling around revealed that
actually EUMETSAT publishes an old version of the driver (9.0.43).
Since we are on a relatively new Linux distro, we figured that 9.0.43
might be incompatible with our system and simply fails silently.
5. at this point, we decided to just install another version of that
driver to see what happens. If we'd be lucky, Tellicast won't mind
and on the other hand, the new driver might be happy with Debian 10.
We found version 10.7.77 published by GlobalSign at
https://support.globalsign.com/ssl/ssl-certificates-installation/safenet-drivers#Linux%20Debian.
This is probably not safe and feels fishy, but we hoped to get a
debugging data point out of that. So we gave it a try.
6. long story short, the whole thing worked. Suddenly Tellicast stopped
crashing and started to decode Announcement Channel packets. After
some fiddling, we even managed to start receiving Basic Service.
7. this is not yet a full success, because we observe that most of the
time (say 5 out of 7) Tellicast hangs upon start as follows:
MSG:2020-09-15 12:12:45.353:Program started =============
MSG:2020-09-15 12:12:45.353:Watchdog starting... [3520]
MSG:2020-09-15 12:12:45.353:Watchdog started [3520].
MSG:2020-09-15 12:12:45.405:Starting new child...
MSG:2020-09-15 12:12:45.405:Started new child [3523].
VRB:2020-09-15 12:12:45.606:Child connecting to watchdog on port 46857 ...

However, upon shutdown of such a hanged tc-cast-client, the logs reveal
that for a moment the launch initialises dongle, HTTP server, etc. and
then terminates. So this seems like some timing issue or so.

If anybody has advice on this, we would appreciate comments.

Best,

Peter.

On Wed, Sep 16, 2020 at 01:24:25PM -0700, Andreas Mueller wrote:

Ernst,

thanks for taking care ...

yes i've picked both 64bit versions:
ftp.eumetsat.int/pub/OPS/out/user/EUMETCast_Support/EUMETCast_Licence_cd/Linux/EKU_software/SafenetAuthenticationClient-core-9.0.43-0_amd64.deb
ftp.eumetsat.int/pub/OPS/out/user/EUMETCast_Support/EUMETCast_Licence_cd/Linux/Tellicast/tellicast-client-2.14.6-1_amd64.deb

For the TBS driver build i followed https://github.com/tbsdtv/linux_media/wiki

Andreas




--
Meandair B.V. | aviation navigation solutions
Olof Palmestraat 14 | 2616 LR Delft | The Netherlands
Tel +31 (0)638 167 279 | http://www.meandair.com/
Participant in ESA BIC Noordwijk, The Netherlands


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

Peter Novak
 

Hello,
this thread comes in quite timely for what we are doing. We also are at
the moment collecting "experiences" with a fresh install of EUMETCast
reception station with Ayecka SR1. Just yesterday we tried to install
Tellicast + Safenet Auth Client on Debian 10 Buster. Only much later
into the install we realised that Debian 10 is not yet well supported,
but we tried our luck. We have some mixed "feelings" about that. Maybe
this post could be useful to somebody and/or somebody will be able to
identify/explain the issues we had to work around.

1. after the installation according to EUMETSAT instructions Tellicast
did not work out of the box. The EKU dongle was recognised as
"Aladdin Knowledge Systems Token JC", but Tellicast was constantly
crashing with logs like these:
[Sep15 13:09] tc-cast-client[1046]: segfault at 968 ip 00007f6f3a73f8bb sp 00007ffce06ee290 error 4 in libpthread-2.28.so[7f6f3a73f000+f000]
[ +0.000003] Code: 00 00 0f 05 89 82 d0 02 00 00 48 8d 82 10 03 00 00 64 48 89 04 25 10 05 00 00 64 c6 04 25 12 06 00 00 01 48 8b 2d 35 57 01 00 <48> 8b 85 68 09 00 00 64 48 89 04 25 20 06 00 00 48 8d ba e0 02 00
2. we found Ernst's write-up at https://groups.io/g/MSG-1/topic/experiences_and_lessons/71144718?p=Created,,,20,1,0,0&jump=1
This was very useful for understanding of how shaky the whole
installation process can be on various Linux distros. We applied most
of the relevant advice in that post, but did not get rid of those
segfaults.
3. we diagnosed that Tellicast cannot connect to the EKU as
`tc-cast-client -k` was unable to list the host_key_4 as "Aladdin
EToken PRO" correctly. This led to suspicion that maybe the dongle
drivers are the culprit.
4. we also quickly realised that the SAC software is some 3rd party
piece operating the dongle. Some googling around revealed that
actually EUMETSAT publishes an old version of the driver (9.0.43).
Since we are on a relatively new Linux distro, we figured that 9.0.43
might be incompatible with our system and simply fails silently.
5. at this point, we decided to just install another version of that
driver to see what happens. If we'd be lucky, Tellicast won't mind
and on the other hand, the new driver might be happy with Debian 10.
We found version 10.7.77 published by GlobalSign at
https://support.globalsign.com/ssl/ssl-certificates-installation/safenet-drivers#Linux%20Debian.
This is probably not safe and feels fishy, but we hoped to get a
debugging data point out of that. So we gave it a try.
6. long story short, the whole thing worked. Suddenly Tellicast stopped
crashing and started to decode Announcement Channel packets. After
some fiddling, we even managed to start receiving Basic Service.
7. this is not yet a full success, because we observe that most of the
time (say 5 out of 7) Tellicast hangs upon start as follows:
MSG:2020-09-15 12:12:45.353:Program started =============
MSG:2020-09-15 12:12:45.353:Watchdog starting... [3520]
MSG:2020-09-15 12:12:45.353:Watchdog started [3520].
MSG:2020-09-15 12:12:45.405:Starting new child...
MSG:2020-09-15 12:12:45.405:Started new child [3523].
VRB:2020-09-15 12:12:45.606:Child connecting to watchdog on port 46857 ...

However, upon shutdown of such a hanged tc-cast-client, the logs reveal
that for a moment the launch initialises dongle, HTTP server, etc. and
then terminates. So this seems like some timing issue or so.

If anybody has advice on this, we would appreciate comments.

Best,

Peter.

On Wed, Sep 16, 2020 at 01:24:25PM -0700, Andreas Mueller wrote:

Ernst,

thanks for taking care ...

yes i've picked both 64bit versions:
ftp.eumetsat.int/pub/OPS/out/user/EUMETCast_Support/EUMETCast_Licence_cd/Linux/EKU_software/SafenetAuthenticationClient-core-9.0.43-0_amd64.deb
ftp.eumetsat.int/pub/OPS/out/user/EUMETCast_Support/EUMETCast_Licence_cd/Linux/Tellicast/tellicast-client-2.14.6-1_amd64.deb

For the TBS driver build i followed https://github.com/tbsdtv/linux_media/wiki

Andreas




--
Meandair B.V. | aviation navigation solutions
Olof Palmestraat 14 | 2616 LR Delft | The Netherlands
Tel +31 (0)638 167 279 | http://www.meandair.com/
Participant in ESA BIC Noordwijk, The Netherlands


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

Markus Kempf
 

Andreas,

I have a very similar setup (Debian 10, backport kernel 5.5, TBS 5925, 100cm dish (78cm before)). Fiddling with a lot of kernel, network and cpu state parameters did not solve the missing key/packets problem. In fact, I set most things to be energy efficient now, because this system runs 24/7 and electricity is very expensive. The system is also loaded with three RTL-SDR receivers for ADSB and radio sonde reception and another DVB receiver for Sat-TV plus TVheadend and works as a NAS for my home network. Despite all these tasks, the load is around 50% and I don't loose packets. Why? The simple reason was already given by Ernst. You need either a bigger dish or move 10E to the center of your dish or a Linux driver that can filter for the right MODCOD for BAS only (or another DVB receiver with different HW/FW). When I achieved SNRs above 10.5, the problem went away for BAS+HVS. For BAS only I had no problems with the patched driver provided by Ernst and SNRs above ~8.5.

Markus

Am 16/09/2020 um 23:19 schrieb Andreas Mueller:

Ernst,

you just asked the 2nd Question while i hit reply ... so:

yes in general everything works fine - i'm receiving data, the Web Interface works, the EKU works including the test with 'tc-cast-client -k' - its just the many missing keys / packets which seems not to be ok.

Andreas


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

Andreas Mueller
 

Ernst,

you just asked the 2nd Question while i hit reply ... so:

yes in general everything works fine - i'm receiving data, the Web Interface works, the EKU works including the test with 'tc-cast-client -k' - its just the many missing keys / packets which seems not to be ok.

Andreas


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

Andreas Mueller
 

Ernst.

my SNR is not the best - around 9.1 db (as i'm currently using a Multifeed Dish / 110cm Triax Unique with an Inverto BLACK Ultra Quattro HGLN) - so no link margin left for HVS and therefore just using the BAS Service. In Windows MODCOD was set to All (using BDADataEx) and as mentioned much much less missing keys / missed packets with this setting - so was a bit surprised with the Linux results.

Regarding C-States i'm pretty sure i disabled these - but will cross check again.

Other than that: do you see any chance to get this improved from SW perspective?

Andreas


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

Ernst Lobsiger
 

On Wed, Sep 16, 2020 at 01:24 PM, Andreas Mueller wrote:
ftp.eumetsat.int/pub/OPS/out/user/EUMETCast_Support/EUMETCast_Licence_cd/Linux/Tellicast/tellicast-client-2.14.6-1_amd64.deb
 
Andreas

One more thing to check: Does your EKU software work at all?
On the command line try as root:

tc-cast-client -k

This should issue a couple of lines and last line something like:
...
host_key_4: = ****-****-****-**** (Aladdin EToken PRO)

Regards
Ernst



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

Ernst Lobsiger
 

Andreas

First of all: What is your SNR in dB for transponder T1 (BASIC + HVS-1)?   Then: EKU in USB-2 plug?

If you compare with Windows: Do you choose MODCOD 8PSK 3/5 (BASIC) under Windows only?
The problem with the Linux driver for the stv0910 chip: There is no possibility for MODCOD selection.
If your SNR is too low (no link margin for HVS-1) then your BASIC reception will be disturbed as well.

It might be worth trying to switch off C-States (processor energy saving functionality) in the BIOS.

Regards
Ernst


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

Andreas Mueller
 

Ernst,
 
thanks for taking care ...
 
yes i've picked both 64bit versions:
ftp.eumetsat.int/pub/OPS/out/user/EUMETCast_Support/EUMETCast_Licence_cd/Linux/EKU_software/SafenetAuthenticationClient-core-9.0.43-0_amd64.deb
ftp.eumetsat.int/pub/OPS/out/user/EUMETCast_Support/EUMETCast_Licence_cd/Linux/Tellicast/tellicast-client-2.14.6-1_amd64.deb

For the TBS driver build i followed https://github.com/tbsdtv/linux_media/wiki

Andreas


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

Ernst Lobsiger
 

On Wed, Sep 16, 2020 at 12:19 PM, Andreas Mueller wrote:
Now i read here in this group about special TBS drivers: is this something worth to investigate? If so: what would be the best approach to start with?
 
Andreas
Andreas

If you are talking about my patched driver 2 posts back this is not for you.
The TBS5925 uses the stv0900 chip while your TBS5927 uses the stv0910.

Are you using the amd64 client and the 64Bit SACSrv EKU software?
This is distributed daily two times via EUMETCast in Info-Channel-1.

Regards
Ernst


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

Andreas Mueller
 

First of all - i'm new to this Group and EumetCast - so this is my first message ...
 
I recently setup my Receiving Station using Debian 9 with a Backport Kernel (4.19.0-0.bpo.10-amd64), a TBS 5927 (compiled the latest drivers provided on https://www.tbsdtv.com/download) and an Aladdin Token (guess its the latest one since i registered just recently at Eumetcast). Currently i'm using the EumetCast BAS service.
 
So far everything is working - however i'm receiving a lot of 'missing keys' as well as many 'Missed Packets before FEC'. Compared to a parallel Win10 Setup this is much worse. Now i read here in this group about special TBS drivers: is this something worth to investigate? If so: what would be the best approach to start with?
 
Andreas


Re: Coaxial cable

LaurentD
 

Sorry to be long in replying. I really appreciate your explanations. Really clear and helpful.

LNB makes the difference for sure!

Cheers,
Laurent 


Re: TelliCast Missed Packets False Alarms

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

David

TBH I have no idea concerning EUMETCast USB devices. AFAIK the whole TS is sent to the PC over the USB cable.
Several users seem to have acceptable even good results with the TBS5925 (same ST chip stv0900 AAC as in SR1).
What I do know is PCIe cards with ECP3 bridges. I have fixed the OS ECP3 code for missed interrupts and added a
buffer size that can be selected for up to 8 transponders with CrazyCat. All modern PCIe cards use the ECP3 bridge.

EUMETSAT has added a minimum traffic to T2 to resolve the PCIe buffer delay problem from the dissemination side.
AFAIK there is no such thing on T1 for HVS-1. That means you still cannot receive HVS-1 alone using a MODCOD
filter. You always need BASIC to keep the PCIe buffers busy. So at least for PCIe cards "time to correct" is no issue.

Cheers,
Ernst
=====================================

Thanks for those details, Ernst.

USB is strange in that it's a polling system (1 kHz rate for USB 2, IIRC), but clearly good enough to keep "CD quality" audio running without breaks. With 55 Mbps TS rate - who knows!

I do receive HVS-1 alone on an Ayecka SR1 with MODCOD selection, but of course that's with a UDP link and network devices, not PCIe. On my PC Lund (TBS6903/BDADataEx) it does take HVS-1 only, using MODCOD "All", but no TelliCast running for the BAS PIDs. Works with zero packet loss when the signal level is sufficiently high and stable.

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


Re: TelliCast Missed Packets False Alarms

Ernst Lobsiger
 

David

TBH I have no idea concerning EUMETCast USB devices. AFAIK the whole TS is sent to the PC over the USB cable.
Several users seem to have acceptable even good results with the TBS5925 (same ST chip stv0900 AAC as in SR1).
What I do know is PCIe cards with ECP3 bridges. I have fixed the OS ECP3 code for missed interrupts and added a
buffer size that can be selected for up to 8 transponders with CrazyCat. All modern PCIe cards use the ECP3 bridge.

EUMETSAT has added a minimum traffic to T2 to resolve the PCIe buffer delay problem from the dissemination side.
AFAIK there is no such thing on T1 for HVS-1. That means you still cannot receive HVS-1 alone using a MODCOD
filter. You always need BASIC to keep the PCIe buffers busy. So at least for PCIe cards "time to correct" is no issue.

Cheers,
Ernst


Re: TelliCast Missed Packets False Alarms

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

David

Your problem with the TBS5927 most probably is a driver problem. But
here it's not.

What I remember to have seen is that we get missed packets that are
shown recovered
with the next update of the TelliCast client statistics page
(approximately 3s later).

What I cannot know or even simulate is: What happens if my script unsing
the w3m browser
accesses the statistics page exactly when it's updating? Even java
script is involved!

Regards
Ernst
================================

Ernst,

Well, I'm using the latest TBS driver for the TBS5927, so what to make of that! I suspect others are simply not monitoring to the same level, and/or simply accepting the issue.

I don't think there's much you can do about the "time to correct" issue - it's fundamental to the way the error correction works, isn't it? The correction may not be possible until the next buffer of information is received, so that brings in USB polling, network buffer and PCIe buffer size, depending on the receiver architecture.

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

1581 - 1600 of 31500