Date   

Re: New release EUMETCastView v1.4.9

Hugo
 

Hello Ian,

Not sure what you mean with file extensions. It depends on the satellite which kind of image is transmitted.
For example Metop and Meteosat has a proprietary file structure, FY-3D is HDF5, GOES-16/17 is netCDF etc...
In EUMETCastView you don't have to bother with file extensions. The program will figure out the correct way to decode the images as
long as you set the program to the correct file directories.
Kind regards,
Hugo


Re: New release EUMETCastView v1.4.9

Douglas Deans
 

On 23/11/2020 16:41, Hugo wrote:
Hi,
In this release I solved some bugs for MERSI images and added a new Projection. Beside the Lambert, the Perspective and the Stereographic projections I added the Oblique Mercator Projection. This projection works only for Metop, VIIRS M and MERSI images. This projection eliminates the "bow-ties" in VIIRS M and MERSI images. When selecting a segment that lies over the south pole (only Metop) the projection will show the countries outside the selected region.  I don't have that problem
for regions over the north pole. This is something that I need to solve.
See https://www.flickr.com/photos/137270544@N02/50610090861/in/datetaken-public/ <https://www.flickr.com/photos/137270544@N02/50610090861/in/datetaken-public/> as an example of an Oblique Mercator projection.
As always you can download the latest release from https://github.com/hvanruys/EUMETCastView/releases <https://github.com/hvanruys/EUMETCastView/releases>
Kind regards,
Hugo
==================================================================================

Many thanks Hugo. All seems to be working well.
The Oblique Mercator Projection works well with VIIRS M and MERSI data and is very speedy and I like not needing the POI files for the projections.

Best Regards,
Douglas.


Re: New release EUMETCastView v1.4.9

ian
 

Hi hugo new to all this ,could you please tell me what the file extensions namesect are for images this software works with,connected to eumetcast ,and very impressed with the images you are producing thanks ian

 

Sent from Mail for Windows 10

 

From: Hugo
Sent: 23 November 2020 16:41
To: MSG-1@groups.io
Subject: [MSG-1] New release EUMETCastView v1.4.9

 

Hi,

In this release I solved some bugs for MERSI images and added a new Projection. Beside the Lambert, the Perspective and the Stereographic projections I added the Oblique Mercator Projection. This projection works only for Metop, VIIRS M and MERSI images. This projection eliminates the "bow-ties" in VIIRS M and MERSI images. When selecting a segment that lies over the south pole (only Metop) the projection will show the countries outside the selected region.  I don't have that problem
for regions over the north pole. This is something that I need to solve.

See  https://www.flickr.com/photos/137270544@N02/50610090861/in/datetaken-public/ as an example of an Oblique Mercator projection.

As always you can download the latest release from https://github.com/hvanruys/EUMETCastView/releases 

Kind regards,

Hugo

 

 


Virus-free. www.avast.com


New release EUMETCastView v1.4.9

Hugo
 

Hi,

In this release I solved some bugs for MERSI images and added a new Projection. Beside the Lambert, the Perspective and the Stereographic projections I added the Oblique Mercator Projection. This projection works only for Metop, VIIRS M and MERSI images. This projection eliminates the "bow-ties" in VIIRS M and MERSI images. When selecting a segment that lies over the south pole (only Metop) the projection will show the countries outside the selected region.  I don't have that problem
for regions over the north pole. This is something that I need to solve.

See  https://www.flickr.com/photos/137270544@N02/50610090861/in/datetaken-public/ as an example of an Oblique Mercator projection.

As always you can download the latest release from https://github.com/hvanruys/EUMETCastView/releases 

Kind regards,

Hugo

 


Re: xrit2pic 2020.4

R. Alblas
 

Hugo,

I'll check this. The executable on my webpage is not ment  just for one distro; it works here also on e.g. Fedora. (A matter of used kernel, not distro, I think.)

I just read now:

Support for i386 as a host architecture was dropped in 19.10.

So 18.04 should still work on i386.

Anyway, it is something to look at.

Regards,
Rob.



On 11/21/2020 09:43 AM, Hugo wrote:
Hi Rob,

Ubuntu dropped since 18.04 the i386 architecture. I don't think that many people are still using 16.04 ...
Kind regards,

Hugo


Re: Tellicast Monitoring - Localhost

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

On 21/11/2020 08:48, Tim Holdsworth via groups.io wrote:
All,
My reception and display of Eumetcast output is and was  working properly.
But my Tellicast monitoring (localhost:8100) was not.
When my browser is asked to display localhost:8100 it displayed the website of a well known radio station.
After searching the net for a possible solution without success I asked Ops for help.
They replied very quickly, "search for a file called 'index.html' and delete it".
This fixed the problem.
But I do not understand why when my browser is asked to go to localhost:8100 it displays something else.
An explanation would be much appreciated.
Thanks in anticipation
Tim Holdsworth
Tim,

If I were checking that I would look to see what "localhost" points to on your PC, likely in windows\system32\drivers\etc\ "hosts." You can edit that file with notepad as you may already know. It might contain:

123.001.002.003 localhost

instead of:

127.0.0.1 localhost

although on the system here the 127.0.0.1 is commented out. "132.001.002.003" would be the IP address of the unwanted station.

Something in that area, anyway!

Where was the file "index.html"?

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


Tellicast Monitoring - Localhost

Tim Holdsworth
 

All, 
My reception and display of Eumetcast output is and was  working properly.
But my Tellicast monitoring (localhost:8100) was not.
When my browser is asked to display localhost:8100 it displayed the website of a well known radio station.
After searching the net for a possible solution without success I asked Ops for help.
They replied very quickly, "search for a file called 'index.html' and delete it".
This fixed the problem.
But I do not understand why when my browser is asked to go to localhost:8100 it displays something else.
An explanation would be much appreciated.
Thanks in anticipation
Tim Holdsworth


Re: xrit2pic 2020.4

Hugo
 

Hi Rob,

Ubuntu dropped since 18.04 the i386 architecture. I don't think that many people are still using 16.04 ...
Kind regards,

Hugo


Re: FY-3D.

Ernst Lobsiger
 

On Fri, Nov 20, 2020 at 02:15 PM, Graham Woolf wrote:
Hi Ernst

I have done that but my logging level was set to quiet

I have set up three instances so will see what happens tomorrow

Regards

Graham
Graham

You can temporarily change the log_level in the WEB interface. A permanent setting must be put in the client *.ini file (needs a client restart).
Make sure you have a "log_file=>>path to your log file" definition: ">>" writes to memory buffer first, then dumps to HDD  (similar to ram-disk).


Good Luck
Ernst


Re: FY-3D.

Graham Woolf
 

Hi Ernst

I have done that but my logging level was set to quiet

I have set up three instances so will see what happens tomorrow

Regards

Graham


Re: FY-3D.

Ernst Lobsiger
 

Graham

You have to setup one instance of TCLogSummary per service.
That's about how it should look like for yesterday (Io, HVS-1).

===============================================
TClogSummary                       Version 0.95

Devuan 3.0 GNU/Linux EUMETCast receiver      io
GNU/Linux TelliCast Client Ver. 2.14.7  (HVS-1)

TelliCast Client Event Summary from  2020-11-19
Head time 00:00:03.0 -UTC- Tail time 23:59:59.4

A BASH script by                 Ernst Lobsiger
With ideas from                  Arne van Belle
===============================================
Number of messages of category ERR: 0
===============================================
Number of messages of category WRN: 0
===============================================
Number of messages of category MSG: 26857
===============================================
Number of *Starting* (what) events: 0
===============================================
Number of *Missed* (file) messages: 0
===============================================
Number of *Connected*  achan/dchan: 0/5919
===============================================
Number of *Reconnect*  achan/dchan: 0/0
===============================================
Number of *Disconnect* finis/coord: 5918/0
===============================================
Transm. *ended[/int.]* Lists/Files: 0/0
===============================================
Transm.  *interrupted* Lists/Files: 1/35
===============================================
Received and delivered Lists/Files: 7493/27209
===============================================
Treated number of recv Files/Lines: 2/354625
===============================================

Cheers,
Ernst


Re: FY-3D.

Ernst Lobsiger
 

On Fri, Nov 20, 2020 at 08:54 AM, Graham Woolf wrote:
Hi Ernst

I have just set up TCLogSummary and will run it and see what I get tomorrow

Regards

Graham
Graham

You can already run it from the command line for yesterday and for today (UP to NOW).

Good Luck
Ernst


Re: FY-3D.

Graham Woolf
 

Hi Ernst

I have just set up TCLogSummary and will run it and see what I get tomorrow

Regards

Graham


Re: FY-3D.

Ernst Lobsiger
 

Graham

Your list from yesterday has 11 GEO1k files and 9 1000m files. NOT expected.
Your list from today has 10 GEO1k files and 11 1000m files. NOT expected.

1) You either look too early and the files are not in (as I just explained to Douglas).
2) You simply didn't receive all FY-3D files on HVS-1  (use TCLogSummary.cmd)

Regards
Ernst

P.S.
My two receivers with a TBS-6909X taking all 3 services with 3 demodulators
have not lost one single UDP packet (and so no files) for the last three weeks.


Re: FY-3D.

Ernst Lobsiger
 

On Fri, Nov 20, 2020 at 06:20 AM, Douglas Deans wrote:
Ernst I probably need to look at this more closely, but when I do have a failure it usually checks out as ok on EUMETCastView in colour.
Having said that today's image has produced fine.

Regards,
Douglas.
Douglas

Be sure to give enough time slack for the data to arrive. If you already had todays picture before your last post then the timing may be tight on some days. My scripts
do not know when the files arrive. They do not predict passes but they look at the available file names with segment times and reverse calculate the orbit positions.
For todays almost overhead pass the last file was 13:17 UTC but yesterday (as the nearest pass was more west of IsleOfMan) it was 13:36 UTC and this can even be later.
You have to add an additional worst case slack of 50 minutes (half an typical sun synchronous sat revolution time) to the time of maximum elevation of a central pass.
Then you have EARS timelyness which IIRC is up to another 30 minutes. If you make a picture while data is comming in you could end up with a list of unpaired
1000m and GEO1k files. Then simply try 30 minutes later again (remember FY-3D has LTAN 14:00 which is also 30 minutes after NOAA-20 and Suomi-NPP).

Regards
Ernst


Re: FY-3D.

Graham Woolf
 

Hi Ernst

Here is my list and its only 20 files compared to your 22

I:/EUMETCast/HVS/MERSI\FY3D_20201119_132600_132700_15621_MERSI_1000M_L1B.HDF
I:/EUMETCast/HVS/MERSI\FY3D_20201119_132600_132700_15621_MERSI_GEO1K_L1B.HDF
I:/EUMETCast/HVS/MERSI\FY3D_20201119_132700_132800_15621_MERSI_1000M_L1B.HDF
I:/EUMETCast/HVS/MERSI\FY3D_20201119_132700_132800_15621_MERSI_GEO1K_L1B.HDF
I:/EUMETCast/HVS/MERSI\FY3D_20201119_132800_132900_15621_MERSI_1000M_L1B.HDF
I:/EUMETCast/HVS/MERSI\FY3D_20201119_132800_132900_15621_MERSI_GEO1K_L1B.HDF
I:/EUMETCast/HVS/MERSI\FY3D_20201119_132900_133000_15621_MERSI_1000M_L1B.HDF
I:/EUMETCast/HVS/MERSI\FY3D_20201119_132900_133000_15621_MERSI_GEO1K_L1B.HDF
I:/EUMETCast/HVS/MERSI\FY3D_20201119_133000_133100_15621_MERSI_GEO1K_L1B.HDF
I:/EUMETCast/HVS/MERSI\FY3D_20201119_133100_133200_15620_MERSI_1000M_L1B.HDF
I:/EUMETCast/HVS/MERSI\FY3D_20201119_133100_133200_15620_MERSI_GEO1K_L1B.HDF
I:/EUMETCast/HVS/MERSI\FY3D_20201119_133200_133300_15620_MERSI_1000M_L1B.HDF
I:/EUMETCast/HVS/MERSI\FY3D_20201119_133200_133300_15620_MERSI_GEO1K_L1B.HDF
I:/EUMETCast/HVS/MERSI\FY3D_20201119_133300_133400_15620_MERSI_1000M_L1B.HDF
I:/EUMETCast/HVS/MERSI\FY3D_20201119_133300_133400_15620_MERSI_GEO1K_L1B.HDF
I:/EUMETCast/HVS/MERSI\FY3D_20201119_133400_133500_15620_MERSI_GEO1K_L1B.HDF
I:/EUMETCast/HVS/MERSI\FY3D_20201119_133500_133600_15620_MERSI_1000M_L1B.HDF
I:/EUMETCast/HVS/MERSI\FY3D_20201119_133500_133600_15620_MERSI_GEO1K_L1B.HDF
I:/EUMETCast/HVS/MERSI\FY3D_20201119_133600_133700_15620_MERSI_1000M_L1B.HDF
I:/EUMETCast/HVS/MERSI\FY3D_20201119_133600_133700_15620_MERSI_GEO1K_L1B.HDF

And for today I only have 21

I:/EUMETCast/HVS/MERSI\FY3D_20201120_130700_130800_15635_MERSI_1000M_L1B.HDF
I:/EUMETCast/HVS/MERSI\FY3D_20201120_130700_130800_15635_MERSI_GEO1K_L1B.HDF
I:/EUMETCast/HVS/MERSI\FY3D_20201120_130800_130900_15635_MERSI_1000M_L1B.HDF
I:/EUMETCast/HVS/MERSI\FY3D_20201120_130800_130900_15635_MERSI_GEO1K_L1B.HDF
I:/EUMETCast/HVS/MERSI\FY3D_20201120_130900_131000_15635_MERSI_1000M_L1B.HDF
I:/EUMETCast/HVS/MERSI\FY3D_20201120_130900_131000_15635_MERSI_GEO1K_L1B.HDF
I:/EUMETCast/HVS/MERSI\FY3D_20201120_131000_131100_15634_MERSI_1000M_L1B.HDF
I:/EUMETCast/HVS/MERSI\FY3D_20201120_131100_131200_15635_MERSI_1000M_L1B.HDF
I:/EUMETCast/HVS/MERSI\FY3D_20201120_131100_131200_15635_MERSI_GEO1K_L1B.HDF
I:/EUMETCast/HVS/MERSI\FY3D_20201120_131200_131300_15635_MERSI_1000M_L1B.HDF
I:/EUMETCast/HVS/MERSI\FY3D_20201120_131200_131300_15635_MERSI_GEO1K_L1B.HDF
I:/EUMETCast/HVS/MERSI\FY3D_20201120_131300_131400_15634_MERSI_1000M_L1B.HDF
I:/EUMETCast/HVS/MERSI\FY3D_20201120_131300_131400_15634_MERSI_GEO1K_L1B.HDF
I:/EUMETCast/HVS/MERSI\FY3D_20201120_131400_131500_15634_MERSI_1000M_L1B.HDF
I:/EUMETCast/HVS/MERSI\FY3D_20201120_131400_131500_15634_MERSI_GEO1K_L1B.HDF
I:/EUMETCast/HVS/MERSI\FY3D_20201120_131500_131600_15634_MERSI_1000M_L1B.HDF
I:/EUMETCast/HVS/MERSI\FY3D_20201120_131500_131600_15634_MERSI_GEO1K_L1B.HDF
I:/EUMETCast/HVS/MERSI\FY3D_20201120_131600_131700_15634_MERSI_1000M_L1B.HDF
I:/EUMETCast/HVS/MERSI\FY3D_20201120_131600_131700_15634_MERSI_GEO1K_L1B.HDF
I:/EUMETCast/HVS/MERSI\FY3D_20201120_131700_131800_15634_MERSI_1000M_L1B.HDF
I:/EUMETCast/HVS/MERSI\FY3D_20201120_131700_131800_15634_MERSI_GEO1K_L1B.HDF

Regards

Graham


Re: FY-3D.

Douglas Deans
 

On 20/11/2020 12:48, Ernst Lobsiger via groups.io wrote:
On Fri, Nov 20, 2020 at 04:21 AM, Graham Woolf wrote:
Do you have any lat/long values that appear to work more
successfully or is it pot luck on each pass
Regards
Graham
Graham and Douglas
This looks as if you do not have some data that are needed for "true-color". Maybe some VIS data is not transmitted far north in the dark?
1) Can you give me a date and POI location and range you use that shows this problem (I have data 4 days back here) ?
2) Can you try a FY-3D IR (DAY!) composite with these input data that does not produce a VIS (DAY) "true_color" image ?
3) Can you have a look at the list [bestfiles] or use good old TCLogSummary.cmd to make sure you have no missing files?
Regards
Ernst
===================================================================================

Ernst I probably need to look at this more closely, but when I do have a failure it usually checks out as ok on EUMETCastView in colour.
Having said that today's image has produced fine.

Regards,
Douglas.


Re: FY-3D.

Ernst Lobsiger
 

On Fri, Nov 20, 2020 at 05:28 AM, Graham Woolf wrote:
Hi Ernst

Those errors were from yesterdays pass and I was using Isle of Man
# Isle of Man
lat = 54.228
lon = -4.532
ran = 20.0

Regards

Graham
Graham,

no problem here under GNU/Linux. The FY-3D files come in pairs 1000m and GEO location.
Not sure what happens if you are missing one file in a pair. Try to print [bestfiles] in the script.

Cheers
Ernst


Re: FY-3D.

Graham Woolf
 

Hi Ernst

Those errors were from yesterdays pass and I was using Isle of Man
# Isle of Man
lat = 54.228
lon = -4.532
ran = 20.0

Regards

Graham


Re: FY-3D.

Ernst Lobsiger
 

On Fri, Nov 20, 2020 at 04:06 AM, Douglas Deans wrote:
Yes I get that quite often with FY-3D as well Graham. I have noticed that changing the lat and/or lon can sometimes resolve it so perhaps it has something to do with the tolerance of the pass seeking code.

Regards,
Douglas.
Douglas

I doubt there is a problem in my simple pass seeking code. If you change the POI this may result in another orbit number.
If you only increase search range (ran) the pass will be "longer" and maybe reach far north in the (November) winter dark.

Cheers
Ernst