Date   

Re: TelliCast Missed Packets False Alarms

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

Dear All
[]
Looking at David's MRTG page I see a similar effect. Some stations
show this BASIC missed packets event, others don't. The TC clients
statistics page is updated every few seconds. Could this be a problem
of the script reading the page (maybe with error) while it is updated?

http://www.satsignal.eu/mrtg/performance_eumetcast-europe_losses.php

I remember to have seen the effect at least once before but didn't
pay much attention to it. How frequent is this effect? Any other ideas?
What is the script normally used under Windows to get these values?


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

Ernst,

I just checked my TelliCastStats program and it reads the whole "Statistics" Web page at once and then parses it for the required strings. However there could be some missed that were corrected until the next run of the program, so there is a chance for error there.

In the statistics I publish, though, there counters are reset to zero at the end of the day, and the values of missed and recovered are typically equal before the reset. I'm coming to the conclusion that it /might/ be the TBS driver or BDADataEx software, as the same PC (Penguin) fed from am Ayecka SR1 over an add-in network card produced zero missed and zero recovered. Same eToken & TelliCast version (2.14.6) etc. etc.

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


TelliCast Missed Packets False Alarms

Ernst Lobsiger
 

Dear All

A couple of us do make regular plots of missed or missed/recovered
Tellicast IP packets. Plots are mostly done with MRTG some are using
RRDTool. Under GNU/Linux I use a bash script that picks the values
from the TC clients WEB interface (statistics page). I assume this
is done in a similar way under Windows, though I did not find the
script used. Today I observed that my script seems to make rare
false alarms. I had a couple of BASIC missed packets on one receiver
while all 3 other receivers did not show this. More interesting the
WEB interface of the receiver with this false alarm still showed
0/0 missed/recovered packets. I checked Christian Peters receiver
Ancalagon that perfectly works with an older SkyStar 2 eXpress HD
and this receiver showed exactly the same pattern: Missed packets
at 07:50 but nothing missed in the packet statistics that is updated
every 30 minutes by our script "TelliCastStatsCollector" (thanks Arne).
I also checked the TC clients log file and found absolutely nothing.

Looking at David's MRTG page I see a similar effect. Some stations
show this BASIC missed packets event, others don't. The TC clients
statistics page is updated every few seconds. Could this be a problem
of the script reading the page (maybe with error) while it is updated?

http://www.satsignal.eu/mrtg/performance_eumetcast-europe_losses.php

I remember to have seen the effect at least once before but didn't
pay much attention to it. How frequent is this effect? Any other ideas?
What is the script normally used under Windows to get these values?


Best regards
Ernst


Re: Gaps in AVHRR images yesterday.

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

I meant to add:

- check your receiver for SNR [Es/No, Carrier-to-noise] unless it's at least 12 dB in clear conditions, I suggest disabling HVS-1 reception. Unfortunately that means no GOES or Himawari.

Instructions for disabling HVS-1 are on page 16 of the Novra guide:

http://www.eumetsat.int/website/wcm/idc/idcplg?IdcService=GET_FILE&dDocName=PDF_DMT_736617&RevisionSelectionMethod=LatestReleased&Rendition=Web

- check both TelliCast for [ideally] zero packet loss, missed and recovered. There are some systems where there is steady stream of missed and recovered packets, but with the same count for each. Temporarily disable HVS-1 and check again. BAS should have zero packet loss.

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


Re: Gaps in AVHRR images yesterday.

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

Thanks for the response David.
[]
** I can only judge from reception of MSG, RSS, GOES-16 and 17, Himawari and IODC. All coming through to the processing PC perfectly. The Ethernet graph in Task Manager/Performance on the receiver shows moderate traffic but at regular intervals has a burst for which the peaks go off the top of the scale.

** EUMETSAT_data_channel_1 has files that don’t appear to be moving: BUFR, NOAA-19 and BIN files. ‘Delete files from RX’ is ticked in AVHRR Manager
[]
Thanks for the help.

Robert
==========================================

Robert,

Thanks for the answers.

"Perfect reception": The programs handling the data you mention have the ability to fill in missing data (by the Persistent Images setting). So it's possible that any imperfections are being hidden. Use the Tools, Missing Segments Report... menu option to see whether the reception is as perfect as you expect.

"Unused files": The EARS AVHRR Manager should be handling the NOAA-19 data. Is there an image on the NOAA_19 tab, and if so, what is the date of that image in the lower left corner. On the Ground Stations tab, is NOAA-19 checked (I don't think that makes a difference) and it the Kepler status showing a sensible age? The program version here is a beta 4.1.1.241 2019-Mar-11, although 4.1.2 is the release version.

"BUFR and BIN data": Is the "Process AVHRR polar winds" box checked in the relevant Metop Managers?

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


Re: Gaps in AVHRR images yesterday.

Ernst Lobsiger
 

On Sun, Sep 13, 2020 at 04:42 AM, Robert Moore wrote:
[channel]
name=EUMETSAT Data Channel 1
receive_buffer_size=8000000
target_directory=\EUMETCast\received\EUMETSAT_Data_Channel_1

** Well, I used to send these data to a folder called ….\received\EARS. But I have now altered this to data_Channel_1 and pointed the Manager at it. I don’t have the ‘receive_buffer_size=8000000’ line. Should I add it?
Robert

You should add the "receive_buffer_size=8000000" line to every single [channel] entry. In the very latest tellicast clients this is also possible once for all in the cast-client.ini file.
In the channels file(s) you can make changes without restarting the client(s). If you don't set that, it defaults to a lower value and maybe the client even complains in the log file.

Regards
Ernst


Re: Gaps in AVHRR images yesterday.

Robert Moore
 

Thanks for the response David.

Hard disk full? Has any disk on your system run out of space?
** I have rather excessive disk space, 1TB for each of BAS and HSV-1. 90% of BAS free and 99% of HVS-1!
The EUMETCAST disk on the processing PC is 90% free.

- are you maxing out on CPU?
**CPU on receiver is running at around 7% and on processing PC (which is also busy with other things) fluctuates between approx. 23% and 45% but mainly at the lower end of this range.

- I know that in the past you have had problems with the network link between receiver PC and processing PC. Perhaps you are still running a two-receiver system (as I do here)? If there are still network link issues those need to be resolved first.
** I can only judge from reception of MSG, RSS, GOES-16 and 17, Himawari and IODC. All coming through to the processing PC perfectly. The Ethernet graph in Task Manager/Performance on the receiver shows moderate traffic but at regular intervals has a burst for which the peaks go off the top of the scale.

My suit of programs /must/ be able to delete files in the receive directory tree, so check whether there is unprocessed data being left behind in EUMETSAT_data_channel_1.
** EUMETSAT_data_channel_1 has files that don’t appear to be moving: BUFR, NOAA-19 and BIN files. ‘Delete files from RX’ is ticked in AVHRR Manager

- I assume your TelliCast software is at least version 2.14.5. The current version is 2.14.6 but there's no specific need to upgrade [yet] if 2.14.5 is working correctly.

- You should have a separate receive directory for EUMETSAT Data Channel 1, and be pointing the EARS AVHRR Manager to that directory. The channel entry should be something like:
[channel]
name=EUMETSAT Data Channel 1
receive_buffer_size=8000000
target_directory=\EUMETCast\received\EUMETSAT_Data_Channel_1

** Well, I used to send these data to a folder called ….\received\EARS. But I have now altered this to data_Channel_1 and pointed the Manager at it. I don’t have the ‘receive_buffer_size=8000000’ line. Should I add it?

- what you describe (high segment loss) is symptomatic of having TWO EARS AVHRR Managers running. Is that possible? Is there a third-party program which might be accessing the received directory?

** I’ve been through task Manager and can find nothing that should not be there. Other than all the Windows stuff the only programs running on this PC are BAS, HVS-1 and the Tellicast software.

Thanks for the help.

Robert


Re: Gaps in AVHRR images yesterday.

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

Many thanks John,

Here is your list annotated to show my record:

Metop - B 2020-09-11 - 00:04. Chunk missing
NOAA 19 2020-09-11 - 00:57. Short section north of Norway
Metop - C 2020-09-11 - 06:16. NOAA19 Arctic circle to central west Africa
Metop - B 2020-09-11 - 14:46. Not received, gap in reception
Metop - C 2020-09-11 - 17:52. Nothing received between 17:19 and 18:01
Last image received 2029 Metop C
Metop - A 2020-09-11 - 20:40.
NOAA 19 2020-09-11 - 21:05.
Metop - A 2020-09-11 - 22:21.
NOAA 19 2020-09-11 - 22:49.
Metop - B 2020-09-11 - 23:38.

I have never had satisfactory performance from AVHRR Manager - always very gappy. In fact I only have it running occasionally because it is so frustrating. Just lucky it was running yesterday (more in hope than expectation).

You might indeed say that I have problems!

Robert
==========================================

Robert,

There is nothing particularly special about the EARS AVHRR data which would make the segment loss any greater that that of the SEVIRI data. Thoughts:

- Hard disk full? Has any disk on your system run out of space?

- are you maxing out on CPU?

- I know that in the past you have had problems with the network link between receiver PC and processing PC. Perhaps you are still running a two-receiver system (as I do here)? If there are still network link issues those need to be resolved first. My suit of programs /must/ be able to delete files in the receive directory tree, so check whether there is unprocessed data being left behind in EUMETSAT_data_channel_1.

- I assume your TelliCast software is at least version 2.14.5. The current version is 2.14.6 but there's no specific need to upgrade [yet] if 2.14.5 is working correctly.

- You should have a separate receive directory for EUMETSAT Data Channel 1, and be pointing the EARS AVHRR Manager to that directory. The channel entry should be something like:

[channel]
name=EUMETSAT Data Channel 1
receive_buffer_size=8000000
target_directory=\EUMETCast\received\EUMETSAT_Data_Channel_1

- what you describe (high segment loss) is symptomatic of having TWO EARS AVHRR Managers running. Is that possible? Is there a third-party program which might be accessing the received directory?

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


Re: Gaps in AVHRR images yesterday.

Robert Moore
 

Many thanks John,

Here is your list annotated to show my record:

Metop - B 2020-09-11 - 00:04. Chunk missing

NOAA 19 2020-09-11 - 00:57. Short section north of Norway

Metop - C 2020-09-11 - 06:16. NOAA19 Arctic circle to central west Africa

Metop - B 2020-09-11 - 14:46. Not received, gap in reception

Metop - C 2020-09-11 - 17:52. Nothing received between 17:19 and 18:01

Last image received 2029 Metop C

Metop - A 2020-09-11 - 20:40.

NOAA 19 2020-09-11 - 21:05.

Metop - A 2020-09-11 - 22:21.

NOAA 19 2020-09-11 - 22:49.

Metop - B 2020-09-11 - 23:38.

 

I have never had satisfactory performance from AVHRR Manager  - always very gappy. In fact I only have it running occasionally because it is so frustrating. Just lucky it was running yesterday (more in hope than expectation).

 

You might indeed say that I have problems!

 

Robert

 

 

 

From: MSG-1@groups.io <MSG-1@groups.io> On Behalf Of geojohnt via groups.io
Sent: 12 September 2020 16:19
To: MSG-1@groups.io
Subject: Re: [MSG-1] Gaps in AVHRR images yesterday.

 

David,

 

Thanks for the UNS link.

 

For Robert to compare(?) here are the EARS Service AVHRR Manager passes I received yesterday with gaps during 'assembling.'

Some passes were not the 'full possible length of pass' with one or other 'end missing,' but with no data gaps - if you see what I mean? 

 

My passes with gaps:

 

Metop - B 2020-09-11 - 00:04.

NOAA 19 2020-09-11 - 00:57.

Metop - C 2020-09-11 - 06:16.

Metop - B 2020-09-11 - 14:46.

Metop - C 2020-09-11 - 17:52.

Metop - A 2020-09-11 - 20:40.

NOAA 19 2020-09-11 - 21:05.

Metop - A 2020-09-11 - 22:21.

NOAA 19 2020-09-11 - 22:49.

Metop - B 2020-09-11 - 23:38.

 

Regards,

John.

 

++++++++++++++++++++++

 

 

John,


Glad you found the document interesting.  I remember discussing all this 
with EUMETSAT in the very early days!

If there's a broken link perhaps you would inform EUMETSAT?

There's a daily report issued for most of the services, so likely there's 
one covering the missed 1-minute segments as well.  Have fun comparing the 
predictions with your reception!

  https://www.eumetsat.int/website/home/Data/ServiceStatus/UserNotificationService/index.html



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

 

-----Original Message-----
From: David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺 via groups.io <david-taylor@...>
To: MSG-1@groups.io
Sent: Fri, 11 Sep 2020 19:40
Subject: Re: [MSG-1] Gaps in AVHRR images yesterday.

David,

Thanks for the EARS PDF link - I don't think I was aware of this document.

Interesting document, but the EARS VIIRS software link didn't work.

Active link:

https://www.eumetsat.int/website/wcm/idc/idcplg?IdcService=GET_FILE&dDocName=ZIP_CVIIRS_2_WIN64&RevisionSelectionMethod=LatestReleased&Rendition=Web

Yes, you are right, sometimes the antenna from one of the pass path
receiving stations might be busy on another mission or out of action.

But it seems from Roberts comments that he might be experiencing more gaps
'than are happening?'

Regards,
John.
=================================


 


Re: tc-cast-client connection failure

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

Had to reinstall the client after some issues from windows DEV update (Groan)

The client is now stuck on "Connecting". Signal good etc.
Any ideas anyone?
Regards
John Say
===================================

IP addresses? Route command? Firewall? The last two DEV updates here have re-enabled an on-board Wi-Fi adapter in a laptop resulting in its getting a wrong IP address from the router. I have reported this.

For those who may not know "DEV" is a beta version of Windows-10, and the most beta and unstable version released by Microsoft.

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


Re: Coaxial cable

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

Hi David,

Many thanks for those technical information and advice regarding the cable feature.

I've always considered until now that an amplifier was absolutely to ban as it has the effect to amplify any noise.

Adding an amplifier at mid-cable should be a good compromise.

Best regards,
Laurent
===================================

Laurent,

The satellite TV system is a little different to a conventional RF system in that the LNB has a lot of gain, meaning that it is the prime component in determining the signal to noise ratio. Yes, and amplifier will amplify the noise as well as the signal, but the output of the LNB is always quite large, so that you will have much more signal, and much more noise from the LNB that cable loss of perhaps 20 dB will ensure that the signal and noise are sufficiently high at the [PC end] receiver input that the noise from the LNB is greatly in excess of the receiver.

I'd love to quote some actual figures but I don't have them in my head, so I wouldn't want to guess. Perhaps someone can point to a suitable Web page?

In a conventional VHF or UHF TV system, there is no LNB so the signal from the antenna is much less, and minimising cable loss can be important, as the unamplified signal from the antenna may be much less than that from the LNB which includes amplification. In that case having an amplifier right at the antenna would be a sensible move if the signal was weak.

I hope that helps!

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


Re: Gaps in AVHRR images yesterday.

geojohnt@...
 

David,

Thanks for the UNS link.

For Robert to compare(?) here are the EARS Service AVHRR Manager passes I received yesterday with gaps during 'assembling.'
Some passes were not the 'full possible length of pass' with one or other 'end missing,' but with no data gaps - if you see what I mean? 

My passes with gaps:

Metop - B 2020-09-11 - 00:04.
NOAA 19 2020-09-11 - 00:57.
Metop - C 2020-09-11 - 06:16.
Metop - B 2020-09-11 - 14:46.
Metop - C 2020-09-11 - 17:52.
Metop - A 2020-09-11 - 20:40.
NOAA 19 2020-09-11 - 21:05.
Metop - A 2020-09-11 - 22:21.
NOAA 19 2020-09-11 - 22:49.
Metop - B 2020-09-11 - 23:38.

Regards,
John.

++++++++++++++++++++++


John,

Glad you found the document interesting.  I remember discussing all this 
with EUMETSAT in the very early days!

If there's a broken link perhaps you would inform EUMETSAT?

There's a daily report issued for most of the services, so likely there's 
one covering the missed 1-minute segments as well.  Have fun comparing the 
predictions with your reception!

  https://www.eumetsat.int/website/home/Data/ServiceStatus/UserNotificationService/index.html


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


-----Original Message-----
From: David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺 via groups.io <david-taylor@...>
To: MSG-1@groups.io
Sent: Fri, 11 Sep 2020 19:40
Subject: Re: [MSG-1] Gaps in AVHRR images yesterday.

David,

Thanks for the EARS PDF link - I don't think I was aware of this document.

Interesting document, but the EARS VIIRS software link didn't work.

Active link:

https://www.eumetsat.int/website/wcm/idc/idcplg?IdcService=GET_FILE&dDocName=ZIP_CVIIRS_2_WIN64&RevisionSelectionMethod=LatestReleased&Rendition=Web

Yes, you are right, sometimes the antenna from one of the pass path
receiving stations might be busy on another mission or out of action.

But it seems from Roberts comments that he might be experiencing more gaps
'than are happening?'

Regards,
John.
=================================





tc-cast-client connection failure

seggins2000
 

Had to reinstall the client after some issues from windows DEV update (Groan)

The client is now stuck on "Connecting". Signal good etc.
Any ideas anyone?
Regards
John Say


Re: Coaxial cable

LaurentD
 

Hi Prem,

Yes, very strange! It's also a good way to discover your website! Thanks for that. I can use now the Excel spreadsheet.

Best regards,
Laurent 


Re: Coaxial cable

LaurentD
 

Hi David,

Many thanks for those technical information and advice regarding the cable feature.  

I've always considered until now that an amplifier was absolutely to ban as it has the effect to amplify any noise.  

Adding an amplifier at mid-cable should be a good compromise.

Best regards,
Laurent


Re: Gaps in AVHRR images yesterday.

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

David,

Thanks for the EARS PDF link - I don't think I was aware of this document.

Interesting document, but the EARS VIIRS software link didn't work.

Active link:

https://www.eumetsat.int/website/wcm/idc/idcplg?IdcService=GET_FILE&dDocName=ZIP_CVIIRS_2_WIN64&RevisionSelectionMethod=LatestReleased&Rendition=Web

Yes, you are right, sometimes the antenna from one of the pass path receiving stations might be busy on another mission or out of action.

But it seems from Roberts comments that he might be experiencing more gaps 'than are happening?'

Regards,
John.
=================================

John,

Glad you found the document interesting. I remember discussing all this with EUMETSAT in the very early days!

If there's a broken link perhaps you would inform EUMETSAT?

There's a daily report issued for most of the services, so likely there's one covering the missed 1-minute segments as well. Have fun comparing the predictions with your reception!

https://www.eumetsat.int/website/home/Data/ServiceStatus/UserNotificationService/index.html

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


Re: Gaps in AVHRR images yesterday.

geojohnt@...
 

David,

Thanks for the EARS PDF link - I don't think I was aware of this document.

Interesting document, but the EARS VIIRS software link didn't work.

Active link:

https://www.eumetsat.int/website/wcm/idc/idcplg?IdcService=GET_FILE&dDocName=ZIP_CVIIRS_2_WIN64&RevisionSelectionMethod=LatestReleased&Rendition=Web

Yes, you are right, sometimes the antenna from one of the pass path receiving stations might be busy on another mission or out of action.

But it seems from Roberts comments that he might be experiencing more gaps 'than are happening?'

Regards,
John.

++++++++++++++++++++++


Folks,


EARS doesn't work like that - not a single download.  There are multiple 
receiving stations, each trying to get as much data in real-time as it can. 
This data is then segmented into one-minute chunks, and the central facility 
at EUMETSAT tries to get the best result it can by selecting one-minute 
chunks from all those available.  The gaps you see are where data [of good 
enough quality] is not available.

There will be some passes where a full data set is available, and some where 
there are gaps - perhaps one receiving station is out of action, or a 
scheduling conflict mean that the antenna was in use for more important data 
(prime satellite v.s. other).

You can see the location of some of the receiving stations on John's 
screen-shots.  There's a description in TD 14:

  https://www.eumetsat.int/website/wcm/idc/idcplg?IdcService=GET_FILE&dDocName=PDF_DMT_112370&RevisionSelectionMethod=LatestReleased&Rendition=Web

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

++++++++++++++++++++


-----Original Message-----
From: David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺 via groups.io <david-taylor@...>
To: msg-1@groups.io
Sent: Fri, 11 Sep 2020 17:02
Subject: Re: [MSG-1] Gaps in AVHRR images yesterday.

Hi all
I too have had gaps like this since the start of the service. I assumed that
they were failures in the downlink from the satellite to the ground station
at Svalbard
Alan
=======================







Re: Gaps in AVHRR images yesterday.

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

Hi all
I too have had gaps like this since the start of the service. I assumed that they were failures in the downlink from the satellite to the ground station at Svalbard
Alan
=======================

Folks,

EARS doesn't work like that - not a single download. There are multiple receiving stations, each trying to get as much data in real-time as it can. This data is then segmented into one-minute chunks, and the central facility at EUMETSAT tries to get the best result it can by selecting one-minute chunks from all those available. The gaps you see are where data [of good enough quality] is not available.

There will be some passes where a full data set is available, and some where there are gaps - perhaps one receiving station is out of action, or a scheduling conflict mean that the antenna was in use for more important data (prime satellite v.s. other).

You can see the location of some of the receiving stations on John's screen-shots. There's a description in TD 14:

https://www.eumetsat.int/website/wcm/idc/idcplg?IdcService=GET_FILE&dDocName=PDF_DMT_112370&RevisionSelectionMethod=LatestReleased&Rendition=Web

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


Re: Gaps in AVHRR images yesterday.

geojohnt@...
 

Hello Hugo, Robert and Alan,

Thanks for your comments.

Well, I do see gaps - a gap - every now and again in a Metop or NOAA pass processed and displayed in David's AVHRR Manager but not that many.
And I've put it down to the 'local' direct readout receiving station having a brief 'problem.'

Most passes I would suggest use a combination of three overlapping receiving stations for a full 'regional' pass.

Robert, dare I say, that if you are experiencing image gaps regularly - daily - then you have a problem.
Likewise Alan if your gaps are frequent. 

I'll make a point of reviewing my 24 hour AVHRR thumbnail images as I don't spend all day in front of the computer.

Although I run many/most of David's processing programmes 24/7 my computer is quite well specked and appears not be be stressed.
I'm 'alarmed' to hear every now and again some users report experiencing few - or no - TC missed packets and or see most missed packets FEC recovered.

I don't get 'that many' - how many over a 24 hour period are 'many' - and Ernst and I have experienced a few TC missed packets when switching on/using, another quad LNB output as reported a couple of weeks ago.

Regards,
John.

++++++++++++++++


  -----Original Message-----
From: Alan Sewards <alan@...>
To: msg-1@groups.io
Sent: Fri, 11 Sep 2020 15:10
Subject: Re: [MSG-1] Gaps in AVHRR images yesterday.

Hi all
I too have had gaps like this since the start of the service. I assumed that they were failures in the downlink from the satellite to the ground station at Svalbard
Alan

On 11 Sep 2020, at 15:05, Robert Moore <rsmoore@...> wrote:
Interesting John, I have ­always­ had gaps like this since the very beginning and have regarded it as normal. So should I have been getting gap-free images for all these years?
 
Robert
 
 
From: MSG-1@groups.io <MSG-1@groups.io> On Behalf Of geojohnt via groups.io
Sent: 11 September 2020 12:27
To: msg-1@groups.io
Subject: [MSG-1] Gaps in AVHRR images yesterday.
 
Hello All,
 
Further to my recent postings and responses to 'missed packets' on TC, yesterday I had (at least, these were the ones I saw) three gaps in AVHRR Manager displayed images.
See attached thumbnails.
 
During these processing/display times, BS TC statistics did not indicate any missed packets - nor HVS-1 TC statistics, though I don't think that is relevant.
 
Did anyone else experience these 'data gaps?'
 
If not, any idea what might have caused them?
 
Regards,
John Tellick.
 
 
 
 


Re: Gaps in AVHRR images yesterday.

Alan Sewards
 

Hi all
I too have had gaps like this since the start of the service. I assumed that they were failures in the downlink from the satellite to the ground station at Svalbard
Alan

On 11 Sep 2020, at 15:05, Robert Moore <rsmoore@...> wrote:

Interesting John, I have ­always­ had gaps like this since the very beginning and have regarded it as normal. So should I have been getting gap-free images for all these years?

 

Robert

 

 

From: MSG-1@groups.io <MSG-1@groups.io> On Behalf Of geojohnt via groups.io
Sent: 11 September 2020 12:27
To: msg-1@groups.io
Subject: [MSG-1] Gaps in AVHRR images yesterday.

 

Hello All,

 

Further to my recent postings and responses to 'missed packets' on TC, yesterday I had (at least, these were the ones I saw) three gaps in AVHRR Manager displayed images.

See attached thumbnails.

 

During these processing/display times, BS TC statistics did not indicate any missed packets - nor HVS-1 TC statistics, though I don't think that is relevant.

 

Did anyone else experience these 'data gaps?'

 

If not, any idea what might have caused them?

 

Regards,

John Tellick.

 

 

 

 


Re: Gaps in AVHRR images yesterday.

Robert Moore
 

Interesting John, I have ­always­ had gaps like this since the very beginning and have regarded it as normal. So should I have been getting gap-free images for all these years?

 

Robert

 

 

From: MSG-1@groups.io <MSG-1@groups.io> On Behalf Of geojohnt via groups.io
Sent: 11 September 2020 12:27
To: msg-1@groups.io
Subject: [MSG-1] Gaps in AVHRR images yesterday.

 

Hello All,

 

Further to my recent postings and responses to 'missed packets' on TC, yesterday I had (at least, these were the ones I saw) three gaps in AVHRR Manager displayed images.

See attached thumbnails.

 

During these processing/display times, BS TC statistics did not indicate any missed packets - nor HVS-1 TC statistics, though I don't think that is relevant.

 

Did anyone else experience these 'data gaps?'

 

If not, any idea what might have caused them?

 

Regards,

John Tellick.