Date   

Re: AppImage EUMETCastView v1.5.2 for Linux

Ernst Lobsiger
 

Hugo,

here is a screen shot of EUMETCastView appimage in Debian 11 (RC1) with LXDE. I can only resize the window manually
(with the mouse) in width. It always remains too high and the two resize buttons top left of EUMETCastView do not work.

Regards,
Ernst

P.S. It's on a (0 Euro) 10 years old AXXIV workstation with XEON proc and AMD card. Full HD resolution is all I have  ...


Re: AppImage EUMETCastView v1.5.2 for Linux

Hugo
 

Hi Ernst,

Thanks for testing this out .... 
I do my development on a MSI portable with a second 4K screen and I always forget that I must keep the window layout within 1920x1080 pixels.
EUMETCastView is intended to run on a normal HD monitor, but it is of course nicer to see the images on a 4K monitor...
I will do the changes and post a new version of the appimage.
My eumetcast receiver is a pc with Devuan ASCII (2.1) and I tried the appimage on that system . Unfortunately the app complained about GLIBC v2.27 not found ....
Apparently every distro of Devuan never used GLIBC v21.27 .... so that didn't work . Adding the correct glibc to the AppImage resulted in a crash.
In the end I think that distributing apps for Linux via AppImages is the right way to go. Snap (Ubuntu) and flatpak (Red hat) are too closely linked with distributions.

Kind regards,

Hugo


Re: AppImage EUMETCastView v1.5.2 for Linux

Ernst Lobsiger
 

Hi Hugo

First of all I was wrong about the 14 paintGL calls of the 3D globe when using MobaXterm. This was only 4 paintGL calls. :-0 !
The Windows 10 PC was an I7 that used to run EUMETCastView as Windows App just fine. So no problem with OpenGL here.
The portable version of MobaXterm.exe went to the trash can and I manually cleaned the firewall application exception list.

Now I installed my spare XEON workstation with 16GB RAM. First try was with PopOS 20.10 (never heard of that before).
The AppImage worked fine except I wasn't able to fit the height of EUMETCastView to the height of my full HD monitor.
I got 60 paintGL calls which was possibly the limit of my cheap ASUS monitor. As a CLI user I want to be in control of the
system as much as possible. So PopOS 20.10 is not for me but it looks like a good choice for (still) Windows 10 users.

I then installed Debian 11 (RC1). I didn't take a desktop install as I don't want this kind of Office imitation. So I started
with a minimum CLI install. I added contrib and non-free to the repository list to apt-get install firmware-amd-graphics.
Then I installed lxde-core. The AppImage worked fine but I had the same problem of EUMETCastView being slightly
too high to fit in my window (It would possibly fit if there was no LXDE launch bar at the bottom of the screen). The
3D globe frame rate was again around 60 paintGL calls per second. So no difference compared with PopOS 20.10.

Is there a possibility to limit the maximum EUMETCastView Window size in pixels in some *.ini file? What monitor do
you propose to use for the latest EUMETCastView? Maybe after all these years I must have a closer look at LXDE.

Best regards,

Ernst



Re: AppImage EUMETCastView v1.5.2 for Linux

Ernst Lobsiger
 

Jeskynar and Hugo

It must be back with Win 3.11 that I did some X over a network. I started the portable version of MobaXterm and just installed fuse on
one of my Debian CLI systems and AppImage worked under Windows 10. Login with ssh and start AppImage. But NO 3D-GLOBE so far :-\.
GNU/Linux usage on CLI Debian Buster (XEON) went up to 25% ... If we get the 3D-Globe running I could start AppImage on my TC receiver
where I store all the raw data. So no network data transfer with SAMBA but but X (with frame rate in black 3D-Globe Window of only 14 :-(.

Next step is pop_OS 20.10 or Debian 11 (RC1)

Ernst


Re: AppImage EUMETCastView v1.5.2 for Linux

Jeskynar
 

If your desktop is Windows 10 then you can use MobaXterm to login to your linux system and have X Window programs display on your Windows 10 desktop. It even supports OpenGL apparently.


On Fri, 14 May 2021 at 15:57, Ernst Lobsiger via groups.io <ernst.lobsiger=belponline.ch@groups.io> wrote:
On Fri, May 14, 2021 at 07:39 AM, Hugo wrote:
I suppose you have other Linux distibutions other than Debian Buster CLI ....;)
I'm very interested in your findings...
Hugo,

TBH for the moment I have only CLI GNU/Linux systems. My receivers have ssh+WEB servers.
So I can manage and view everything from/with Windows 10. The latter OS is needed for anual
tax declarations and as a frontend for my aircraft noise calculation program under GNU/Linux
(and recently I used it for my Windows 10 version of the PyTROLL/Satpy Starter Kit 3.0 :-) ).

I have a spare XEON workstation under may desk that should be fine with OpenGL.
I'll install a graphic Debian Buster or maybe even Bullseye. I guess the coastlines
are contained in the AppImage as well. How do you handle an updated TLE-File?

Regards,
Ernst


Re: AppImage EUMETCastView v1.5.2 for Linux

Hugo
 

> I guess the coastlines are contained in the AppImage as well. How do you handle an updated TLE-File?

Yes the coastline database is in the AppImage and also the images for the 3D globe.
When the AppImage first starts up I download 2 TLE's ( weather.txt and resource.txt) which are saved outside the container. ( which is read-only by design)
They can be updated any time.
When EUMETCastView runs from an AppImage , there is an environment variable APPDIR which holds the directory with the expanded files ( in the /tmp directory).
This way one knows when the application is run natively or from an AppImage .

grts,

Hugo


Re: AppImage EUMETCastView v1.5.2 for Linux

Ernst Lobsiger
 

On Fri, May 14, 2021 at 07:39 AM, Hugo wrote:
I suppose you have other Linux distibutions other than Debian Buster CLI ....;)
I'm very interested in your findings...
Hugo,

TBH for the moment I have only CLI GNU/Linux systems. My receivers have ssh+WEB servers.
So I can manage and view everything from/with Windows 10. The latter OS is needed for anual
tax declarations and as a frontend for my aircraft noise calculation program under GNU/Linux
(and recently I used it for my Windows 10 version of the PyTROLL/Satpy Starter Kit 3.0 :-) ).

I have a spare XEON workstation under may desk that should be fine with OpenGL.
I'll install a graphic Debian Buster or maybe even Bullseye. I guess the coastlines
are contained in the AppImage as well. How do you handle an updated TLE-File?

Regards,
Ernst


Re: AppImage EUMETCastView v1.5.2 for Linux

Hugo
 

Hi Ernst,

All the needed Qt stuff is in the AppImage, but you need of course a working OpenGL Linux distribution for EUMETCastView.
The AppImage is created in Ubuntu 18.04 and also tested on Pop!_OS and it worked without any problems.
I suppose you have other Linux distibutions other than Debian Buster CLI ....;)
I'm very interested in your findings...

grts,

Hugo


Re: AppImage EUMETCastView v1.5.2 for Linux

Ernst Lobsiger
 

Hi Hugo

That's an interesting approach. What minimum GNU/Linux stuff does this need?

I tried on a Debian Buster amd64 CLI system:

1) It asked for fusermount (which is in package fuse).
2) With fuse installed it cannot open the display so it certainly needs a graphic terminal.
3) Does it need QT and all the graphic 3D-libs and driver stuff as well?

Regards,
Ernst


AppImage EUMETCastView v1.5.2 for Linux

Hugo
 

Hello,

I created an AppImage of EUMETCastView 1.5.2 for Linux. AppImages are binaries that contains all the dependencies that the application needs.
( https://docs.appimage.org/introduction/index.html ).
Just download the binary, make it executable and run it !

You can download the AppImage at https://github.com/hvanruys/EUMETCastView/releases/tag/v1.5.2 

Grts,

Hugo


Re: GOMS3 support in the MSG Data Manager beta

Ernst Lobsiger
 

On Wed, May 12, 2021 at 08:37 AM, David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺 wrote:
Let me find the 0330 - looks like there's an offset - at a very quick glance.

David
David,

The offset of the visual channel is only a couple of times per day. The rest looks fine.
My worst offset so far was yesterday 20210511 03:30 (see image some posts back)

Cheers,
Ernst.


Re: GOMS3 support in the MSG Data Manager beta

Hugo
 

Ernst,

There was an overlay offset of channel VIS 0.9 at 3:30 and at 8:30 ....

grts,

Hugo


Re: GOMS3 support in the MSG Data Manager beta

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

On 12/05/2021 12:03, Ernst Lobsiger via groups.io wrote:
Dear All
I still struggle then and when with GOMS3. Satpy uses channels 0.9um and 10.7um
to produce an "overview" composite. Sometimes the 09um channel looks completely
offset from where it should be. To make sure that this is not a PyTROLL/Satpy issue:
Could users with MSG Data Manager, that still have the data of the images attached,
confirm that they see the same problem (if channels 0.9 and 10.7 are used)? Thanks!
Regards,
Ernst
Let me find the 0330 - looks like there's an offset - at a very quick glance.

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


Re: GOMS3 support in the MSG Data Manager beta

Hugo
 

Hi Ernst,

I can confirm that the VIS 0.9 channel of 8:30 is completely offset. The IR 3.8 is not offset but looks strange (always).
The VIS 0.9 image of 9:00 is again ok, so it's not a PyTroll problem.
I used of course EUMETCastView :)

grts,

Hugo


Re: GOMS3 support in the MSG Data Manager beta

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

On 12/05/2021 12:03, Ernst Lobsiger via groups.io wrote:
Dear All
I still struggle then and when with GOMS3. Satpy uses channels 0.9um and 10.7um
to produce an "overview" composite. Sometimes the 09um channel looks completely
offset from where it should be. To make sure that this is not a PyTROLL/Satpy issue:
Could users with MSG Data Manager, that still have the data of the images attached,
confirm that they see the same problem (if channels 0.9 and 10.7 are used)? Thanks!
Regards,
Ernst
Alignment looks OK here at a quick look - not tried overlaying those particular images yet. Quick test with GeoSatSignal, it's fine.

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


Re: GOMS3 support in the MSG Data Manager beta

Ernst Lobsiger
 

Hi Graham

Yes your Satpy works the same my Satpy does. The question was whether we see the same thing with David's MSG Data Manager.

a) If MSG Data Manager (using channels 0.9 and 10.8) sees the same, then Roshydromet has a data problem.
b) If MSG Data Manager (using channels 0.9 and 10.7) sees no channel offset, then David might explain how the
    channel data is geographically located on the globe. There could be a difference compared to PyTROLL/Satpy.

Regards,
Ernst


Re: GOMS3 support in the MSG Data Manager beta

Graham Woolf
 

Hi Ernst

Here are my images - they appear to be the same as yours

However if you look at my 0700 image today that appears to be OK

Regards

Graham


Re: GOMS3 support in the MSG Data Manager beta

Ernst Lobsiger
 

Dear All

I still struggle then and when with GOMS3. Satpy uses channels 0.9um and 10.7um
to produce an "overview" composite. Sometimes the 09um channel looks completely
offset from where it should be. To make sure that this is not a PyTROLL/Satpy issue:
Could users with MSG Data Manager, that still have the data of the images attached,
confirm that they see the same problem (if channels 0.9 and 10.7 are used)? Thanks!

Regards,
Ernst


Re: TP 1 SNR reduction.

geojohnt@...
 

Ian and All,

I see from David's graphs that many users saw a step increase in SNR/LM at 12:00 UTC to day.

I continued my check on the Hotbird EUMETCast dissemination today moving the dish a bit further away from the fir tree than yesterday but I couldn't get an increase in my SNR.

The Hotbird transponder was turned off - well, the data stopped at 17:20:49 UTC according to the TC logs - and my SR1 was showing no lock when I had a look at 19:00 BST after watching the news.
So it was time to physically shift the dish back to its original position, realign it and reconfigure the SR1.
And I was pleased to see the Eutelsat 10 A EUMETCast signal had increased whilst I was on the other satellite.

Regards,
John.

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

My guess is that this signal issue is related to the Hotbird 13 degree

test which is due to complete about 14.00 UTC. In fact I have just
checked and the signal level appears to be increasing again, although I
will need better weather to completely confirm.

Regards
Ian.


-----Original Message-----
From: Ian Deans via groups.io <iandeans142@...>
To: MSG-1@groups.io
Sent: Fri, 7 May 2021 14:11
Subject: Re: [MSG-1] TP 1 SNR reduction.



On 07/05/2021 14:01, Douglas Deans via groups.io wrote:
> On 07/05/2021 13:44, David J Taylor GM8ARV 🏴 🇪🇺 via groups.io wrote:
>> On 06/05/2021 15:25, geojohnt via groups.io wrote:
>>> Hello All,
>>>
>>> I see from my own readings and David's across Europe signal graphs
>>> that most of us have seen a step drop in SNR/LM at 13:00 UTC today.
>>> My SNR is down from 13.5 this morning to around 12.5 dB with some
>>> cloud now.
>>>
>>> Regards,
>>> John Tellick.
>>
>> Folks,
>>
>> I headlined this in my daily report to EUMETSAT.  Previous responses
>> have suggested that as long as the signal is above the minimum agreed
>> level there's no need for action (by EUMETSAT).  They are in the hands
>> of their service provider, of course, they don't run the uplink
>> themselves.
>>
>> Cheers,
>> David
> ============================================================================
>
>
> Thanks David and I do agree. Nevertheless up here where the signal is
> more marginal it is annoying that there is an additional 1dB (which I
> lost yesterday) available. We know the back-up station can provide good
> improvements for example.
>
> Regards,
> Douglas.

===========================================================================







Re: TP 1 SNR reduction.

Ian Deans
 

On 07/05/2021 14:01, Douglas Deans via groups.io wrote:
On 07/05/2021 13:44, David J Taylor GM8ARV 🏴 🇪🇺 via groups.io wrote:
On 06/05/2021 15:25, geojohnt via groups.io wrote:
Hello All,

I see from my own readings and David's across Europe signal graphs that most of us have seen a step drop in SNR/LM at 13:00 UTC today.
My SNR is down from 13.5 this morning to around 12.5 dB with some cloud now.

Regards,
John Tellick.
Folks,

I headlined this in my daily report to EUMETSAT.  Previous responses have suggested that as long as the signal is above the minimum agreed level there's no need for action (by EUMETSAT).  They are in the hands of their service provider, of course, they don't run the uplink themselves.

Cheers,
David
============================================================================ Thanks David and I do agree. Nevertheless up here where the signal is more marginal it is annoying that there is an additional 1dB (which I lost yesterday) available. We know the back-up station can provide good improvements for example.
Regards,
Douglas.
===========================================================================

My guess is that this signal issue is related to the Hotbird 13 degree test which is due to complete about 14.00 UTC. In fact I have just checked and the signal level appears to be increasing again, although I will need better weather to completely confirm.

Regards
Ian.

261 - 280 of 31629