Topics

Gaps in AVHRR images yesterday.


geojohnt@...
 

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.



 


Hugo
 

Hello John,

Same here ... I didn't receive them either ...

grts,

Hugo


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.

 

 

 

 


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.

 

 

 

 


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.
 
 
 
 


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


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
=======================







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


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.
=================================





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.
=================================


 


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


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


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


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


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


Robert Moore
 

I have my weekend job, checking packet loss etc. Meanwhile a different problem has emerged: a very nice NOAA-19 image this morning 0620_NOAA19_59849, no missing segments. The latitude of my home station is correctly entered in HRPT Reader, the countries.dat file is present and Keplers are up to date (today). But HRPT Reader says I am at 2.75 degrees south, when I'm 53.26 degrees north. So I turned on country outlines; outline of southern England just visible off the top of the image. Denmark is just below the outline for the southern coast of West Africa - obviously the outline is serious displaced northwards. So turned on lat. and long. markers - to my surprise the longitude line converged southwards, the with North pole somewhere in South Africa (not visible in this image) and I'm now at 3.3 South, Denmark on the Equator.
So; outlines displaced drastically northwards, right way up, and lat/long upside down. The image itself excellent!
Might it be a good idea to uninstall and reinstall AVHRR Manager just to eliminate any corruption of something somewhere?


Robert





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


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

I have my weekend job, checking packet loss etc. Meanwhile a different problem has emerged: a very nice NOAA-19 image this morning 0620_NOAA19_59849, no missing segments. The latitude of my home station is correctly entered in HRPT Reader, the countries.dat file is present and Keplers are up to date (today). But HRPT Reader says I am at 2.75 degrees south, when I'm 53.26 degrees north. So I turned on country outlines; outline of southern England just visible off the top of the image. Denmark is just below the outline for the southern coast of West Africa - obviously the outline is serious displaced northwards. So turned on lat. and long. markers - to my surprise the longitude line converged southwards, the with North pole somewhere in South Africa (not visible in this image) and I'm now at 3.3 South, Denmark on the Equator.
So; outlines displaced drastically northwards, right way up, and lat/long upside down. The image itself excellent!
Might it be a good idea to uninstall and reinstall AVHRR Manager just to eliminate any corruption of something somewhere?

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

Robert,

Overlays being way off very strongly suggests that your Kepler data is way out of date. Look at the View, Diagnostics menu, and search for lines like:

Decoded pass quarter hour is 2019-May-15 10:00 UTC
Update orbit data for METOP-A read from C:\Tools\SatSignal\HRPTreader\Keps\Updates\METOP-A.txt
Orbit data is only 0.1 days stale - OK

Perhaps the HRPT Reader isn't looking where you expected? Remember that the HRPT Reader can accept either current data (like weather.txt with multiple satellite) or historic data such as METOP-A.txt with many entries for a single satellite. My KeplerUpdater will keep the historic data current. If yours has lapsed, there's a daily update here:

http://www.satsignal.eu/software/KeplerUpdates.zip

See:

http://www.satsignal.eu/software/KeplerManager.htm

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


Robert Moore
 

That solved the problem empirically but not (for me) theoretically. I ran Kepler updater and now have lat/long and outlines correct in AVHRR Manager. I normally download Keplers by hand and did so this morning. When I came to compare the two lines for satellites in the manually download file with the updater files, they were identical. But perhaps one overwrote the other thus making them identical. I'll run the updater overnight in future.
Ah, well ......
BTW Is the Kepler Manager program superseded by Updater (not that I've used the former for a long while)?
Robert

-----Original Message-----
From: MSG-1@groups.io <MSG-1@groups.io> On Behalf Of David J Taylor GM8ARV ?????????????? ???? via groups.io
Sent: 18 September 2020 13:55
To: MSG-1@groups.io
Subject: Re: [MSG-1] Gaps in AVHRR images yesterday.

I have my weekend job, checking packet loss etc. Meanwhile a different problem has emerged: a very nice NOAA-19 image this morning 0620_NOAA19_59849, no missing segments. The latitude of my home station is correctly entered in HRPT Reader, the countries.dat file is present and Keplers are up to date (today). But HRPT Reader says I am at 2.75 degrees south, when I'm 53.26 degrees north. So I turned on country outlines; outline of southern England just visible off the top of the image. Denmark is just below the outline for the southern coast of West Africa - obviously the outline is serious displaced northwards. So turned on lat. and long.
markers - to my surprise the longitude line converged southwards, the with North pole somewhere in South Africa (not visible in this image) and I'm now at 3.3 South, Denmark on the Equator.
So; outlines displaced drastically northwards, right way up, and lat/long upside down. The image itself excellent!
Might it be a good idea to uninstall and reinstall AVHRR Manager just to eliminate any corruption of something somewhere?

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

Robert,

Overlays being way off very strongly suggests that your Kepler data is way out of date. Look at the View, Diagnostics menu, and search for lines like:

Decoded pass quarter hour is 2019-May-15 10:00 UTC Update orbit data for METOP-A read from C:\Tools\SatSignal\HRPTreader\Keps\Updates\METOP-A.txt
Orbit data is only 0.1 days stale - OK

Perhaps the HRPT Reader isn't looking where you expected? Remember that the HRPT Reader can accept either current data (like weather.txt with multiple
satellite) or historic data such as METOP-A.txt with many entries for a single satellite. My KeplerUpdater will keep the historic data current. If yours has lapsed, there's a daily update here:

http://www.satsignal.eu/software/KeplerUpdates.zip

See:

http://www.satsignal.eu/software/KeplerManager.htm

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


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

That solved the problem empirically but not (for me) theoretically. I ran Kepler updater and now have lat/long and outlines correct in AVHRR Manager. I normally download Keplers by hand and did so this morning. When I came to compare the two lines for satellites in the manually download file with the updater files, they were identical. But perhaps one overwrote the other thus making them identical. I'll run the updater overnight in future.
Ah, well ......
BTW Is the Kepler Manager program superseded by Updater (not that I've used the former for a long while)?
Robert
===========================

Always good to hear of progress, Robert..

Yes, the Kepler Manager was replaced in July 2019, as [I hope] notified in the SatSignal group. The SSL libraries now required were incompatible with the older program. In addition, I wrote the updater to be more efficient, and to use the EUMETSAT Kepler data for the polar orbiting satellites they operate (as discovered by Thorsten Miglus).

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


geojohnt@...
 

David,

Sorry for the delay in responding - just seen this 'way down the pile.'

My SNR is always around 13.00 dB in clear sky conditions, so I guess that is not the problem and disabling HVS-1 won't make much difference?

>- 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.

This is a bit 'worrying' as I don't remember ever having zero MP's even before HVS-1.
And the old version of Tellicast.

Remember, I have an SR1 that regularly indicates minus (into the 1,000's) value of traffic for up to 5 seconds.
And, as Ernst and I think, we get missed packets when we 'switch on' (use) another quad LNB port on another receiver on the EUMETCast LNB.

At the moment my statistics from 2020-09-10 14:31 (13 days) are:

BS MPb4 FEC 2284.     FEC RP 181.

HVS-1 MPb4 FEC 1763     FEC RP 14.

SR1 statistics for same period Bad Frame Count 139.   Bad Packet Count 281.

I would not add too much weight to these figures, although through a clear sky period, as I've been moving around in front of the dish doing patio work and we had a period of heavy rain last night.

Regards,
John.

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


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

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