Date   

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@...
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@...
Twitter: @gm8arv


Re: Data Tailor Q&A Drop-in Session coming soon

Hugo
 

Thanks for the heads up , David... very interesting project.

Kind regards,

Hugo


Data Tailor Q&A Drop-in Session coming soon

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

Data Tailor Q&A Drop-in Session coming soon

From the EUMETSAT Web site:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To support users as we release our new pilot data services, we are arranging a series of Q&A Drop-ins where users can get answers to questions relating to Data Tailor, Data Store and EUMETView.

The first Q&A Drop-in session will be on the topic of the Data Tailor standalone software on 24 September 2020, 11:00–12:00 UTC.

You may recall that we released our first version of the Data Tailor back in January 2020. Further information on the Data Tailor:

https://www.eumetsat.int/website/home/Data/DataDelivery/NewPilotDataServices/TheDataTailor/index.html

Our expert team will be online for the hour long session to respond to your questions and provide information on:

How to install the Data Tailor
How to generate data transformations
Upcoming planned evolutions to the Data Tailor software

The session will be provided through the online meeting tool WebEx. To register and receive meeting login in details, contact the User Service Helpdesk.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

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


Re: TelliCast Missed Packets False Alarms

Ernst Lobsiger
 

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


Am 14.09.2020 21:09, schrieb David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺 via groups.io:

David
As I said before this is not a driver problem which also means it's
not receiver dependant. I have two
receivers that use the stiid135 chip and only one receiver has had the
problem. Christian uses an old
stv0903 chip. The only coincidence is that Christian uses my scripts
and that both of us also use ntp.
The statistics page is dumped and then analized with textbrowser w3m
while under Windows IIRC
you use wget to dump this page (do you?).
If these scripts work correctly then 07:50 and 07:55 there must have
been some missed and not recovered
= lost packets while 07:59 "TelliCastStatsCollector" found again
missed/recovered = 0/0 on the same page.
Two rather unlikely explanations come to mind:
a) The client (auto) reseted the statistics page between 07:55 and
07:59 (Terra still has 0/0 now)
b) The eLuna update script 07:50 and 07:55 ended in error that somehow
filled lost packets in the rrd DB.
Regards
Ernst
====================================
Ernst,
Well it appears to be a driver or receiver problem as with the same
Windows-10/64 PC no missed packets with a networked Ayecka RX,
continuous missed/recovered with a TBS5927/BDADataEx. Different
receiver chip?
Under Windows I use my own software to retrieve the statistics page,
not wget. URL:
url := 'http://' + node + '/www/tsl/receiver/tsl_receiver_statistics.html';
where node includes the port number.
I can certainly see that there is a time window where a small number
of errors might be corrected between one reporting interval and the
next, but I imagine that to be within a few packets, so likely well
under a millisecond. Yes, we should check that out! But I don't
recall ever seeing the count being reset to zero. Missed and
recovered being equal and non-zero, yes. But never going backwards.
Perhaps the Linux variant of TelliCast behaves differently? Seems unlikely!
Cheers,
David
--
SatSignal Software - Quality software for you
Web: https://www.satsignal.eu
Email: david-taylor@...
Twitter: @gm8arv


Re: TelliCast Missed Packets False Alarms

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

David

As I said before this is not a driver problem which also means it's not receiver dependant. I have two
receivers that use the stiid135 chip and only one receiver has had the problem. Christian uses an old
stv0903 chip. The only coincidence is that Christian uses my scripts and that both of us also use ntp.
The statistics page is dumped and then analized with textbrowser w3m while under Windows IIRC
you use wget to dump this page (do you?).

If these scripts work correctly then 07:50 and 07:55 there must have been some missed and not recovered
= lost packets while 07:59 "TelliCastStatsCollector" found again missed/recovered = 0/0 on the same page.

Two rather unlikely explanations come to mind:
a) The client (auto) reseted the statistics page between 07:55 and 07:59 (Terra still has 0/0 now)
b) The eLuna update script 07:50 and 07:55 ended in error that somehow filled lost packets in the rrd DB.

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

Ernst,

Well it appears to be a driver or receiver problem as with the same Windows-10/64 PC no missed packets with a networked Ayecka RX, continuous missed/recovered with a TBS5927/BDADataEx. Different receiver chip?

Under Windows I use my own software to retrieve the statistics page, not wget. URL:

url := 'http://' + node + '/www/tsl/receiver/tsl_receiver_statistics.html';

where node includes the port number.

I can certainly see that there is a time window where a small number of errors might be corrected between one reporting interval and the next, but I imagine that to be within a few packets, so likely well under a millisecond. Yes, we should check that out! But I don't recall ever seeing the count being reset to zero. Missed and recovered being equal and non-zero, yes. But never going backwards.

Perhaps the Linux variant of TelliCast behaves differently? Seems unlikely!

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


Re: TelliCast Missed Packets False Alarms

Ernst Lobsiger
 

David

As I said before this is not a driver problem which also means it's not receiver dependant. I have two
receivers that use the stiid135 chip and only one receiver has had the problem. Christian uses an old
stv0903 chip. The only coincidence is that Christian uses my scripts and that both of us also use ntp.
The statistics page is dumped and then analized with textbrowser w3m while under Windows IIRC
you  use wget to dump this page (do you?).

If these scripts work correctly then 07:50 and 07:55 there must have been some missed and not recovered
= lost packets while 07:59 "TelliCastStatsCollector" found again missed/recovered = 0/0 on the same page.

Two rather unlikely explanations come to mind:
a) The client (auto) reseted the statistics page between 07:55 and 07:59                 (Terra still has 0/0 now)
b) The eLuna update script 07:50 and 07:55 ended in error that somehow filled lost packets in the rrd DB.

Regards
Ernst




Re: TelliCast Missed Packets False Alarms

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

David

Sorry my interpretation of the Alta plot was wrong. I was taking the losses you had yesterday early morning
for today morning. So your output of "TelliCastStatsCollector" for Alta is what should be expected. It clearly
shows the jump shortly befor 08:00 that can also be seen in the MRTG plot. And YES this is a hickup seen
all over Europe and you are right that stations might not see it because of their different channel selection.

But this does not resolve or explain my problem:

1) All my 4 receivers have identical channel selection but only Terra has seen the even in the eLuna graph.
2) None of the 4 receivers has seen the 07:50 event in the cumulative "TelliCastStatsCollector" output file.
3) Christian Peters has seen exactly the same strange bahaviour on Ancalagon that I see here on Terra.
[]

Best regards
Ernst
========================================

No problem with the interpretation of Alta. That PC is due for retirement and I may be abusing it in the period up to switch-off (hammering the HD etc. as I intend to make it a virtual machine).

If the uplink switch this morning did cause a brief outage, it's possible that the different receivers will have a different response to that uplink switch (including lock-up time), and hence some may see nothing, some missed and recovered, and some lost. Can you correlate the observations with receiver type?

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


Re: TelliCast Missed Packets False Alarms

Ernst Lobsiger
 

David

Sorry my interpretation of the Alta plot was wrong. I was taking the losses you had yesterday early morning
for today morning. So your output of "TelliCastStatsCollector" for Alta is what should be expected. It clearly
shows the jump shortly befor 08:00 that can also be seen in the MRTG plot. And YES this is a hickup seen
all over Europe and you are right that stations might not see it because of their different channel selection.

But this does not resolve or explain my problem:

1) All my 4 receivers have identical channel selection but only Terra has seen the even in the eLuna graph.
2) None of the 4 receivers has seen the 07:50 event in the cumulative "TelliCastStatsCollector" output file.
3) Christian Peters has seen exactly the same strange bahaviour on Ancalagon that I see here on Terra.

TelliCastStatsCollector outputs from today (plots have been attached at the first post of the thread):

--------------------------------------------------------------------------------
TelliCastStatsCollector_0   (A script for GNU/Linux)                 Version 1.1
(c) David Taylor, Arne van Belle, and Ernst Lobsiger                 License GPL

HOST: terra
RECV: Quad Inverto Black Ultra, TBS-6903X V2 + 22uF, TelliCast client(s)  2.14.7
DESC: Receives BAS + HVS-1 + HVS-2 using a single LNB cable    (BAS stats shown)
--------------------------------------------------------------------------------
YearMonDay   -UTC-    Missed    Recov.      Lost      Received          Received
YYYY-MM-DD   hh:mm   Packets   Packets   Packets       Packets             Bytes
2020-09-14   00:29         0         0         0     1'043'779     1'218'611'135
2020-09-14   00:59         0         0         0     1'865'374     2'177'387'679
2020-09-14   01:29         0         0         0     2'817'145     3'288'413'332
2020-09-14   01:59         0         0         0     3'708'243     4'328'800'372
2020-09-14   02:29         0         0         0     4'826'564     5'634'922'354
2020-09-14   02:59         0         0         0     5'709'300     6'665'412'798
2020-09-14   03:29         0         0         0     6'579'318     7'680'698'882
2020-09-14   03:59         0         0         0     7'498'968     8'754'342'013
2020-09-14   04:29         0         0         0     8'363'918     9'763'886'580
2020-09-14   04:59         0         0         0     9'608'286    11'217'646'769
2020-09-14   05:29         0         0         0    10'357'582    12'091'441'267
2020-09-14   05:59         0         0         0    11'481'347    13'404'065'405
2020-09-14   06:29         0         0         0    12'693'048    14'819'622'799
2020-09-14   06:59         0         0         0    13'494'975    15'755'570'696
2020-09-14   07:29         0         0         0    14'793'577    17'272'532'428
2020-09-14   07:59         0         0         0    15'884'019    18'546'015'532
2020-09-14   08:29         0         0         0    16'853'594    19'677'643'258
2020-09-14   08:59         0         0         0    18'080'869    21'111'452'146
2020-09-14   09:29         0         0         0    19'202'724    22'421'229'930
2020-09-14   09:59         0         0         0    20'501'049    23'938'551'072
2020-09-14   10:29         0         0         0    21'409'451    24'998'841'248
2020-09-14   10:59         0         0         0    22'870'628    26'707'208'545
2020-09-14   11:29         0         0         0    24'321'310    28'402'840'570
2020-09-14   11:59         0         0         0    25'160'730    29'382'749'087
2020-09-14   12:29         0         0         0    26'499'225    30'946'232'612
2020-09-14   12:59         0         0         0    28'094'135    32'811'753'487
2020-09-14   13:29         0         0         0    29'150'829    34'045'559'296
And that's what Christian Peters got in Germany:

--------------------------------------------------------------------------------
TelliCastStatsCollector.sh  (A script for GNU/Linux)                 Version 1.0
(c) David Taylor, Arne van Belle, and Ernst Lobsiger                 License GPL

HOST: ancalagon
RECV: Inverto Black Ultra LNB, SKYSTAR 2 HD, TelliCast client(s) 2.14.7 ALPHA 1
DESC: Receives BS+ does image processing ...      (BS stats shown)
--------------------------------------------------------------------------------
YearMonDay   -UTC-    Missed    Recov.      Lost      Received          Received
YYYY-MM-DD   hh:mm   Packets   Packets   Packets       Packets             Bytes
2020-09-14   00:29         0         0         0     1'051'090     1'227'334'142
2020-09-14   00:59         0         0         0     1'901'876     2'220'304'879
2020-09-14   01:29         0         0         0     2'899'539     3'385'237'180
2020-09-14   01:59         0         0         0     3'787'944     4'422'607'635
2020-09-14   02:29         0         0         0     4'942'235     5'770'941'848
2020-09-14   02:59         0         0         0     5'872'905     6'857'666'586
2020-09-14   03:29         0         0         0     6'740'958     7'870'765'150
2020-09-14   03:59         0         0         0     7'667'971     8'953'200'506
2020-09-14   04:29         0         0         0     8'567'436    10'003'136'114
2020-09-14   04:59         0         0         0     9'835'906    11'485'217'661
2020-09-14   05:29         0         0         0    10'579'834    12'352'937'849
2020-09-14   05:59         0         0         0    11'741'757    13'710'328'069
2020-09-14   06:29         0         0         0    12'987'806    15'166'136'364
2020-09-14   06:59         0         0         0    13'784'921    16'096'641'451
2020-09-14   07:29         0         0         0    15'108'845    17'643'465'989
2020-09-14   07:59         0         0         0    16'246'422    18'972'118'399
2020-09-14   08:29         0         0         0    17'241'766    20'134'010'740
2020-09-14   08:59         0         0         0    18'461'761    21'559'584'884
2020-09-14   09:29         0         0         0    19'637'085    22'932'084'121
2020-09-14   09:59         0         0         0    20'975'525    24'496'528'383
2020-09-14   10:29         0         0         0    21'884'262    25'557'428'732
2020-09-14   10:59         0         0         0    23'389'786    27'317'971'286
2020-09-14   11:29         0         0         0    24'870'986    29'049'427'085
2020-09-14   11:59         0         0         0    25'737'011    30'060'698'446
2020-09-14   12:29         0         0         0    27'086'614    31'637'401'209
2020-09-14   12:59         0         0         0    28'734'347    33'564'763'511
2020-09-14   13:29         0         0         0    29'820'024    34'832'775'251


Best regards
Ernst


Re: TelliCast Missed Packets False Alarms

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

David

Your receivers Alta and Harstad clearly show the "Missed Packets Event" from 07:50 UTC (while Penguin does not).
"TelliCastStatsCollector" typically updates/adds one line every half hour. What do you see in the respective statistics
files of Alta and Harstad? If there is no increase of missed, recovered and lost packets between 07:29 and 07:59
this would mean that you see exactly the same thing as I see here on Terra and on Christian's Ancalagon. Yes
there is a chance that Missed and Recovered are not updated at the same page update. But what I see here is
that Missed and Recovered are still 0 and yours probabaly did not change from what you have had since 02:59?

Cheers
Ernst

P.S. I doubt that this has anything to do with drivers as I use a recent TBS and Christian has and older Technisat.
======================================

Ernst,

When I see events like that I look for other stations and for the 07:50 it's clearly spread across many receivers in Europe, so I believe it so be quite genuine, and not some artefact of timing. There's another event around 09:10, and pairs of events like this are typically associated with uplink stations swaps. The 07:50 shows a signal level drop at several stations - particularly Thorsten and Hartmut. For some time I have suspected that the AGC response of the TBS receivers is faster than the Ayecka, so a quick drop in signal could cause more losses in the Ayecka.

Penguin is TBS (faster response vs. steady losses) and Alta and Harstad are a single Ayecka with a 5-port 1Gbps hub. I chose the TBS5927 as the most recent TBS I had to hand. I should swap it with the 5925 which didn't give the missed/recovered when used on a less powerful PC (now a file store).

Statistics below show a genuine loss.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
TelliCast statistics for Alta using Ayecka SR 1 #1 on Basic Service
YYYY-MM-DD hh:mm Recov. Missed Bytes Packets
UTC Packets Packets Received Received
2020-09-14 00:29 0 0 1694911450 1456883
2020-09-14 00:59 0 0 3266029928 2807497
2020-09-14 01:29 0 0 5142555963 4418903
2020-09-14 01:59 0 0 6652508331 5715263
2020-09-14 02:29 0 0 8468076371 7276117
2020-09-14 02:59 0 0 9974067753 8569162
2020-09-14 03:29 0 0 11381370119 9779593
2020-09-14 03:59 0 0 12953323892 11131402
2020-09-14 04:29 0 0 14431665034 12402065
2020-09-14 04:59 0 0 16303606439 14008333
2020-09-14 05:29 0 0 17632880915 15152058
2020-09-14 05:59 0 0 19477360185 16736827
2020-09-14 06:29 0 0 21413373662 18398791
2020-09-14 06:59 0 0 22794798271 19585498
2020-09-14 07:29 0 0 24904048183 21397799
2020-09-14 07:59 5 78 26698937421 22937739
2020-09-14 08:29 5 78 28312265715 24323993
2020-09-14 08:59 5 78 30417799884 26132284
2020-09-14 09:29 24 176 32506523503 27926928
2020-09-14 09:59 24 176 35082944291 30135178
2020-09-14 10:29 24 176 36716034405 31538215
2020-09-14 10:59 24 176 39103714366 33584918
2020-09-14 11:29 24 176 41379720319 35538339
2020-09-14 11:59 24 176 42880593701 36826902
2020-09-14 12:29 24 176 44956290445 38608543
2020-09-14 12:59 24 176 47429640438 40729854
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I might also account for differences between stations by the different selection of data channels they chose to receive. Fewer or different UDP connections happening!

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


Re: TelliCast Missed Packets False Alarms

Ernst Lobsiger
 

David

Your receivers Alta and Harstad clearly show the "Missed Packets Event" from 07:50 UTC (while Penguin does not).
"TelliCastStatsCollector" typically updates/adds one line every half hour. What do you see in the respective statistics
files of Alta and Harstad? If there is no increase of missed, recovered and lost packets between 07:29 and 07:59
this would mean that you see exactly the same thing as I see here on Terra and on Christian's Ancalagon. Yes
there is a chance that Missed and Recovered are not updated at the same page update. But what I see here is
that Missed and Recovered are still 0 and yours probabaly did not change from what you have had since 02:59?

Cheers
Ernst

P.S. I doubt that this has anything to do with drivers as I use a recent TBS and Christian has and older Technisat.