Date   

Re: CTH picture not available past couple of weeks?

Kobus Botha
 

Hi David
Thanks so  much. I slipped up with the new update on this.
Highly appreciated!
Kobus.


Re: Solar Outage Revisited

Ernst Lobsiger
 

Dear All,

to end this thread I upload all the SNR plots we have from
Belp (Ernst), Carmel (Robert) and Naila (Thorsten) fall 2022.
I add historical data from 2017 when we made our first steps.

This is the outcome: All azimuth pointings fall 2022 are good.

The Gibertini dish of Thorsten Miglus has also very good
elevation pointing and therefore the highest SNR values.

My Gibertini points a little bit too high. But though it has a
threaded elevation rod my mount does not work as expected.
Even if I loose all the elevation screws the antenna stays
clamped by the mount and has to be pulled down or pressed up
until the force of the rod surmounts friction and elevation
jumps. To improve this is still one of my mechanical projects.
It's maybe a 0.3° elevation miss pointing and I let it for now.

Robert Moore's 1m dish probably points 0.5°-0.8° too low. No idea
whether this is easy to adjust. But we should also have more SNR
data and will try to confirm these findings in early spring 2023.

I added the 2017 data because I still had a smaller Triax TD80.
It seems I had good elevation pointing but azimuth too far West.
I tried to correct that during the outage period (no good idea!).
The last plot shows that I overshot and had now my azimuth too
far East. Who ever had a Triax will know its catastrophic mount.

Robert's Novra 300 has 25dB lower signal levels than Thorsten's
very similar equipment. A mystery to me is also the strong noise
in Robert's SNR measurement data. We checked the IF cable specs
to be fine. Can and should a next TV engineer check the IF cable
for bad connectors? E.g. make some sort or reflection or SWR
measurement with a 75 Ohm load on the other end of the cable?


Cheers,
Ernst

Two last results attached. All plots as a *.zip file on wetransfer (9MB):

https://we.tl/t-nu6aZrmOdj


Re: CTH picture not available past couple of weeks?

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

On 31/10/2022 13:28, Kobus Botha wrote:
I do not receive the CTH - MPE picture- picture anymore on Eutelsat- Africa.
Problems with Eumetsat- or with me?
Kobus Botha- South Africa
Kobus,

There is a beta version of the MSG Data Manager available to handle these EUMETSAT changes:

https://www.eumetsat.int/change-file-formats-meteosat-meteorological-products

See: https://www.satsignal.eu/software/beta.htm

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


Re: CTH picture not available past couple of weeks?

Kobus Botha
 

I do not receive the CTH - MPE picture- picture anymore on Eutelsat- Africa.
Problems with Eumetsat- or with me?
Kobus Botha- South Africa


Re: Solar Outage Revisited

geojohnt@...
 

Ernst,

Thanks for your further explanations and diagrams.

I 'hear what you are saying' but the maths leaves me cold - especially Dr. Kelso's in depth article.

I suspect we - or rather you and David, have now exhausted this topic.
It seems to me that if your dish is fairly accurately aligned on E 10-A then the satellites small daily changes and correction in azimuth and elevation (which amount to 0.0X of a degree) won't have any effect on your signal unless you are using a dish in excess of say 3 m.

It was interesting to see - well hear - the large Meteosat control dish at the ground station in Ursingen regularly clunking tracking the satellite.

Regards,
John



-----Original Message-----
From: Ernst Lobsiger via groups.io <ernst.lobsiger@...>
To: MSG-1@groups.io
Sent: Sun, 30 Oct 2022 18:39
Subject: Re: [MSG-1] Solar Outage Revisited

On Sun, Oct 30, 2022 at 06:02 AM, <geojohnt@...> wrote:
Oh, does WXtrack know about the equation of time since it appears to use computer time converted to UTC.
John,

the 'Equation of Time' (eqt) is simply the difference of (local) solar time
(where 12:00 is always REAL NOON with the sun exactly in the south)
and a super precise watch that you set once to 12:00 at local noon in a
moment where you are told that eqt=0 (2022/12/25 in the HELIOS table).
Now over the year every REAL NOON is seen at  12:00 = Watch-Time + eqt.

I made no bodge as David suspects and only used the eqt as a test to
understand whether the time shift we observe between the dip maxima is
*ONLY* due to the eqt or whether there are other aspects to consider.

Both WXtrack and my Python script use the same theory and even source
(TS) to find the exact position of the sun in some useful reference frame.
You can think of the eqt being taken care of in an implicit way already.

http://celestrak.com/columns/v02n03/

WXtrack also computes the position of E10A while I assume Lon=10° and Lat=0°.
I want to aim my antenna to this mean position EUTELSAT tries hard to keep.
Looking at figure 0 we see that E10A makes small movements in lon (due to
eccentricity e not exactly 0) and in lat (due to inclination i not exactly 0).
If we look at figure 0 a few days we also see that the whole pattern is slowly
drifting East (geopotential dip of the Earth) and EUTELSAT has to push E10A
back with rocket motors (you'll note a jump!) from time to time. So the difference
is that WXtrack has to use recent TLEs to be sure to be on the current figure 0
while I can also treat my data SNR from years back because EUTELSAT always kept
E10A in a box of +/-0.1° in both lon and lat. That's probably why dishpointer.com
also indicates its (Az, El) values with 1 decimal only. No chance to adjust our
consumer grade antennas with that precision without some kind of vernier!

Once you have two unit vectors U an V pointing to the sun and the sat it's
simple high school math to find the angle Alpha between the two vectors with
a dot product Alpha = acos(u1*v1 + u2*v2 + u3*v3). The only problem of this
approach is that you cannot see the relative position of sun and sat (whether
the sun is now top left or bottom right of E10A in whatever view to the sky).

That's what I tried to show with two rotations that move the usual (Az, El) system
to the actual view along the beam of an optimally pointed antenna (E10A in the
middle of polar coordinates, even if I use a square grid again for easy plotting).


Regarding your 2.5° when you see the first sign of SNR decrease I can attach
two plots that show two regions: A first slow decrease that I agree is basically
in the side lobe area and the begin of a steep decrease that I usually see when
the sun center is at about 1 half power beam width (HPBW) away from the satellite.
This must be the angular distance when the sun disk enters the antenna main lobe.
REMEMBER: HPBW is basically the diameter (not radius) of the blue filled circle.

Cheers,
Ernst

P.S.
Of course WXtrack should work with old SNR data if you have the corresponding TLEs.


Re: Solar Outage Revisited

geojohnt@...
 

David,

The equation of time a 'bodge?!'
Well?

Thanks for your useful comments on WXtrack..

Interesting comments on 'computer time.'
Made me look back into the days of setting up a PC from new.
I see that my computer is in the Time zone of (UTC+00:00) Dublin, Edinburgh, Lisbon and London.
And (of course) it knows when to change to BST and back.

All basic stuff - but I am getting past it.

Regards,
John




John,


WXtrack calculates from first principles, and doesn't use any bodges like the
"Equation of time".  The program directly compares the position of the sun and
the satellite (azimuth and elevation) and computes the difference between them.

The View, Solar noon effectively displays the "Equation of Time" - perhaps it's
an option you requested?  Just subtract the station offset from zero degrees.

The program does no time conversion from the "computer time".  Both Linux and
Windows use UTC internally, so the only conversion is the presentation level to
whatever time zone you wish to see in your displays.

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: Sun, 30 Oct 2022 16:00
Subject: Re: [MSG-1] Solar Outage Revisited

On 30/10/2022 13:02, geojohnt via groups.io wrote:
> I get my satellite outage - and solar crossing - timings from David's WXtrack
> and you made me wonder. Oh, does WXtrack know about the equation of time since
> it appears to use computer time converted to UTC.
> Well, since 'everything happens as predicted,' lowest point in SNR and the
> 'string across the dish' - Arne's solar crossing indicator, WXtrack does take
> account of the equation of time.






Re: Solar Outage Revisited

Ernst Lobsiger
 

On Sun, Oct 30, 2022 at 09:00 AM, David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺 wrote:
The program directly compares the position of the sun and the satellite (azimuth and elevation) and computes the difference between them.
David,

Above explanation can be misinterpreted. I take it for granted that WXtrack does not do Pythagoras sqrt(delta_az*delta_az + delta_el*delta_el).

Ernst


Re: Solar Outage Revisited

Ernst Lobsiger
 

On Sun, Oct 30, 2022 at 06:02 AM, <geojohnt@...> wrote:
Oh, does WXtrack know about the equation of time since it appears to use computer time converted to UTC.
John,

the 'Equation of Time' (eqt) is simply the difference of (local) solar time
(where 12:00 is always REAL NOON with the sun exactly in the south)
and a super precise watch that you set once to 12:00 at local noon in a
moment where you are told that eqt=0 (2022/12/25 in the HELIOS table).
Now over the year every REAL NOON is seen at  12:00 = Watch-Time + eqt.

I made no bodge as David suspects and only used the eqt as a test to
understand whether the time shift we observe between the dip maxima is
*ONLY* due to the eqt or whether there are other aspects to consider.

Both WXtrack and my Python script use the same theory and even source
(TS) to find the exact position of the sun in some useful reference frame.
You can think of the eqt being taken care of in an implicit way already.

http://celestrak.com/columns/v02n03/

WXtrack also computes the position of E10A while I assume Lon=10° and Lat=0°.
I want to aim my antenna to this mean position EUTELSAT tries hard to keep.
Looking at figure 0 we see that E10A makes small movements in lon (due to
eccentricity e not exactly 0) and in lat (due to inclination i not exactly 0).
If we look at figure 0 a few days we also see that the whole pattern is slowly
drifting East (geopotential dip of the Earth) and EUTELSAT has to push E10A
back with rocket motors (you'll note a jump!) from time to time. So the difference
is that WXtrack has to use recent TLEs to be sure to be on the current figure 0
while I can also treat my data SNR from years back because EUTELSAT always kept
E10A in a box of +/-0.1° in both lon and lat. That's probably why dishpointer.com
also indicates its (Az, El) values with 1 decimal only. No chance to adjust our
consumer grade antennas with that precision without some kind of vernier!

Once you have two unit vectors U an V pointing to the sun and the sat it's
simple high school math to find the angle Alpha between the two vectors with
a dot product Alpha = acos(u1*v1 + u2*v2 + u3*v3). The only problem of this
approach is that you cannot see the relative position of sun and sat (whether
the sun is now top left or bottom right of E10A in whatever view to the sky).

That's what I tried to show with two rotations that move the usual (Az, El) system
to the actual view along the beam of an optimally pointed antenna (E10A in the
middle of polar coordinates, even if I use a square grid again for easy plotting).


Regarding your 2.5° when you see the first sign of SNR decrease I can attach
two plots that show two regions: A first slow decrease that I agree is basically
in the side lobe area and the begin of a steep decrease that I usually see when
the sun center is at about 1 half power beam width (HPBW) away from the satellite.
This must be the angular distance when the sun disk enters the antenna main lobe.
REMEMBER: HPBW is basically the diameter (not radius) of the blue filled circle.

Cheers,
Ernst

P.S.
Of course WXtrack should work with old SNR data if you have the corresponding TLEs.


Re: Solar Outage Revisited

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

On 30/10/2022 13:02, geojohnt via groups.io wrote:
I get my satellite outage - and solar crossing - timings from David's WXtrack and you made me wonder. Oh, does WXtrack know about the equation of time since it appears to use computer time converted to UTC.
Well, since 'everything happens as predicted,' lowest point in SNR and the 'string across the dish' - Arne's solar crossing indicator, WXtrack does take account of the equation of time.
John,

WXtrack calculates from first principles, and doesn't use any bodges like the "Equation of time". The program directly compares the position of the sun and the satellite (azimuth and elevation) and computes the difference between them.

The View, Solar noon effectively displays the "Equation of Time" - perhaps it's an option you requested? Just subtract the station offset from zero degrees.

The program does no time conversion from the "computer time". Both Linux and Windows use UTC internally, so the only conversion is the presentation level to whatever time zone you wish to see in your displays.

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


Re: Solar Outage Revisited

geojohnt@...
 

Hello Ernst, 

Thanks for this report and the various plots - several things to think about.

I know of course about equation of time but my Windows computer time doesn't take this into account.
Why should it from a 'life on Earth - human toil' point of view.
However, satellite wise it is vital.

I get my satellite outage - and solar crossing - timings from David's WXtrack and you made me wonder. Oh, does WXtrack know about the equation of time since it appears to use computer time converted to UTC.
Well, since 'everything happens as predicted,' lowest point in SNR and the 'string across the dish' - Arne's solar crossing indicator, WXtrack does take account of the equation of time.

Mmmm. having said that, I've just looked up the equation of time and at my location which is 0.31 degrees west of Greenwich and 'noon is noon' at Greenwich - and the Sun where it should be (mind you this is the same across the globe), only on April 15th, June 14th, September 1st ad December 25th.

On October 12th - my maximum outage day, the Sun was 13 minutes, 32 seconds early.

Thanks for the useful link regards E 10-A's 'wandering.'
Actually it amazes me that a satellite can - with a little help from the ground - travel that speed and maintain (and maintain it) and its 'position' whist we ourselves are also spinning around below.

During the outage seasons I update my WXtrack Keps every day - I'm not sure how often a day they might be updated though.

Regarding your Gibertini 1.25 m dish, I would suggest that these are at the top end of the market for precision.
I use a bog standard domestic market 1 m dish - though it is pretty 'solid' and with a decent Az/El rear mount - unlike some manufacturers we could mention.
I see a start in reduction of SNR when 'the Sun is around 2.5 degrees east of the satellite.'
I suspect side lobes are at play here - the Gibertini dish may well be better in this respect?

Just to say also that with my dish, as far as I can tell, accurately aligned on E 10-A, I get a very good signal level (SNR) from E 9-B for EbS daily bulletins.
And AFN bars and tone is useful on 11.804 GHz V at S 91% and Q 91%.

Best wishes,
John




-----Original Message-----
From: Ernst Lobsiger via groups.io <ernst.lobsiger@...>
To: MSG-1@groups.io
Sent: Fri, 28 Oct 2022 14:27
Subject: [MSG-1] Solar Outage Revisited

Dear All,

while trying to get more insight about Robert Moore's antenna pointing
using the sun I have learnt some new aspects concerning solar outages.
I was wrong assuming the closest approach is always when sat azimuth
is crossed. There are two times to consider: Time of azimuth crossing
and time of closest approach. The fact that these times fall together
in the maximum of outage and that they do not differ much with small
Skews (Station Latitude close to Satellite Latitude e.g. Belp and E10A)
made me overlook this subtle difference. With Robert's TC station far
West of E10A and his antenna pointing probably too low the additional
time offset gave me a headache. I even suspected Windows time keeping!
While azimuth crossing is still the time for geometrical adjustment
of an antenna we must compare all SNR measurements with calculated
times of closest approach. Another point I was completely wrong in the
past (or is that my age?) is assuming the 0.25°/min the sun walks in
the sky translate to 0.25°/min in azimuth. This is FAR more complicated
and lead me to some hours of calculus. The formula I found shows in its
most special case of equinox and solar noon at the station an azimuth
change per minute of 0.25/sin(Latitude). Good to live in the North!

I have now (I think) improved my software and attach six images
showing the situation for the WXtrack output David has sent me.

My calculations show small differences with WXtrack. This might be
explained with the fact that I simply assume a fixed satellite position
while David uses TLEs and we all know that there is this "figure 0":

https://www.satellite-calculations.com/Satellite/satellitemotion.php?26/171/0/34710

I find the same time shift as David's software though. Comparing this to
the difference in the 'Equation of Time' (eqt) using a NOAA approximation
showed very good agreement in autumn 2022 but not so good in spring 2022.
I suspected the NOAA eqt approximation to be the culprit and downloaded
a more reliable eqt table from HELIOS sundial manufacturers in Germany.

Result of our calculated time shift explained with 'Equation of Time'
(Numbers are calculated as end of minus begin of solar outage period):

Spring 2022:  David -103s / Ernst -103s / NOAA-eqt +102s / HELIOS-eqt +103s
Autumn 2022:  David -80s  / Ernst -80s  / NOOA-eqt +70s  / HELIOS-eqt +79s

The sign difference is due to the definition of eqt: ZG = WOZ-MOZ (German)

I probably have to extract the 'Equation of Time' code from my sun
dial C-program and see whether this compares better to HELIOS values.

One thing my own SNR measurements during the outage autumn 2022 seem
to show is that my Gibertini OP 125L dish has a symmetric antenna beam
width (HPBW = 1.32° specified by the manufacturer at 10.95GHz). This
result should at least make us find "severe" elevation wrong pointing.


Cheers,
Ernst



Below is part of a an explanation David's procedure in WXtrack:

Ernst,

I didn't use any equation-of-time formulae, simply compared the
sun and satellite position using the orbital calculations. I see
a difference between the maximum effect between the start and end
of the event.  I get 103s in the Autumn, and 80s in the spring.

 Satellite solar outage list produced by WXtrack
 Location: Edinburgh-GS at Lat: 55.91°N  Lon: 3.20°W
 Satellite: EUTELSAT 10A,  separation <= 1.51°

The list shows dates and times when the sun is in the
beamwidth of the antenna, and may cause an outage
because of solar noise entering the receiver.

---------------------------------------------------
                  Early period group
     Date     Begin    Peak     End        Closest
---------------------------------------------------
 2022 Feb 25  11:25  11:28:32  11:31 UTC    1.30°
 2022 Feb 26  11:23  11:28:23  11:33 UTC    0.92°
 2022 Feb 27  11:22  11:28:11  11:34 UTC    0.55°
 2022 Feb 28  11:21  11:28:01  11:34 UTC    0.17°
 2022 Mar 01  11:21  11:27:47  11:33 UTC    0.21°
 2022 Mar 02  11:21  11:27:38  11:33 UTC    0.59°
 2022 Mar 03  11:22  11:27:25  11:32 UTC    0.97°
 2022 Mar 04  11:24  11:27:12  11:29 UTC    1.36°
---------------------------------------------------


---------------------------------------------------
                  Late period group
     Date     Begin    Peak     End        Closest
---------------------------------------------------
 2022 Oct 09  10:59  11:02:48  11:05 UTC    1.35°
 2022 Oct 10  10:57  11:02:32  11:07 UTC    0.97°
 2022 Oct 11  10:56  11:02:14  11:07 UTC    0.59°
 2022 Oct 12  10:55  11:02:00  11:08 UTC    0.22°
 2022 Oct 13  10:55  11:01:45  11:07 UTC    0.16°
 2022 Oct 14  10:55  11:01:31  11:07 UTC    0.53°
 2022 Oct 15  10:56  11:01:18  11:06 UTC    0.90°
 2022 Oct 16  10:57  11:01:05  11:04 UTC    1.27°
---------------------------------------------------


Re: Solar Outage Revisited

Ernst Lobsiger
 

On Fri, Oct 28, 2022 at 06:27 AM, Ernst Lobsiger wrote:
Skews (Station Latitude close to Satellite Latitude e.g. Belp and E10A)
Sorry,

... another silly mistake of mine. Sigh, in the age of Internet reading and writing has become a dying art. This should rather read:

Skews (Station Longitude close to Satellite Longitude e.g. Belp and E10A)

I'm still working on mine and Robert's SNR measurements to combine those in one plot with my astronomical calculations above.
If anybody else has a full set of SNR measurements from recent outage fall 2022 and agrees to have those treated and published
this way, please contact me in a PM. Thanks!

Ernst





Re: Solar Outage Revisited

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

On 28/10/2022 14:27, Ernst Lobsiger via groups.io wrote:
Below is part of a an explanation David's procedure in WXtrack:
Thanks very much, Ernst, for you detailed calculations.

Yes, it's not good enough to simply compare azimuth alone although that's a good approximation.

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


Re: Solar Outage Revisited

Ernst Lobsiger
 

On Fri, Oct 28, 2022 at 06:27 AM, Ernst Lobsiger wrote:
Spring 2022:  David -103s / Ernst -103s / NOAA-eqt +102s / HELIOS-eqt +103s
Autumn 2022:  David -80s  / Ernst -80s  / NOOA-eqt +70s  / HELIOS-eqt +79s
Sorry folks,

as usual I make silly typos. Before David corrects me, this should rather read:

Autumn 2022:  David -103s / Ernst -103s / NOAA-eqt +102s / HELIOS-eqt +103s
Spring 2022:  David -80s  / Ernst -80s  / NOOA-eqt +70s  / HELIOS-eqt +79s

Ernst


Solar Outage Revisited

Ernst Lobsiger
 

Dear All,

while trying to get more insight about Robert Moore's antenna pointing
using the sun I have learnt some new aspects concerning solar outages.
I was wrong assuming the closest approach is always when sat azimuth
is crossed. There are two times to consider: Time of azimuth crossing
and time of closest approach. The fact that these times fall together
in the maximum of outage and that they do not differ much with small
Skews (Station Latitude close to Satellite Latitude e.g. Belp and E10A)
made me overlook this subtle difference. With Robert's TC station far
West of E10A and his antenna pointing probably too low the additional
time offset gave me a headache. I even suspected Windows time keeping!
While azimuth crossing is still the time for geometrical adjustment
of an antenna we must compare all SNR measurements with calculated
times of closest approach. Another point I was completely wrong in the
past (or is that my age?) is assuming the 0.25°/min the sun walks in
the sky translate to 0.25°/min in azimuth. This is FAR more complicated
and lead me to some hours of calculus. The formula I found shows in its
most special case of equinox and solar noon at the station an azimuth
change per minute of 0.25/sin(Latitude). Good to live in the North!

I have now (I think) improved my software and attach six images
showing the situation for the WXtrack output David has sent me.

My calculations show small differences with WXtrack. This might be
explained with the fact that I simply assume a fixed satellite position
while David uses TLEs and we all know that there is this "figure 0":

https://www.satellite-calculations.com/Satellite/satellitemotion.php?26/171/0/34710

I find the same time shift as David's software though. Comparing this to
the difference in the 'Equation of Time' (eqt) using a NOAA approximation
showed very good agreement in autumn 2022 but not so good in spring 2022.
I suspected the NOAA eqt approximation to be the culprit and downloaded
a more reliable eqt table from HELIOS sundial manufacturers in Germany.

Result of our calculated time shift explained with 'Equation of Time'
(Numbers are calculated as end of minus begin of solar outage period):

Spring 2022:  David -103s / Ernst -103s / NOAA-eqt +102s / HELIOS-eqt +103s
Autumn 2022:  David -80s  / Ernst -80s  / NOOA-eqt +70s  / HELIOS-eqt +79s

The sign difference is due to the definition of eqt: ZG = WOZ-MOZ (German)

I probably have to extract the 'Equation of Time' code from my sun
dial C-program and see whether this compares better to HELIOS values.

One thing my own SNR measurements during the outage autumn 2022 seem
to show is that my Gibertini OP 125L dish has a symmetric antenna beam
width (HPBW = 1.32° specified by the manufacturer at 10.95GHz). This
result should at least make us find "severe" elevation wrong pointing.


Cheers,
Ernst



Below is part of a an explanation David's procedure in WXtrack:

Ernst,

I didn't use any equation-of-time formulae, simply compared the
sun and satellite position using the orbital calculations. I see
a difference between the maximum effect between the start and end
of the event.  I get 103s in the Autumn, and 80s in the spring.

 Satellite solar outage list produced by WXtrack
 Location: Edinburgh-GS at Lat: 55.91°N  Lon: 3.20°W
 Satellite: EUTELSAT 10A,  separation <= 1.51°

The list shows dates and times when the sun is in the
beamwidth of the antenna, and may cause an outage
because of solar noise entering the receiver.

---------------------------------------------------
                  Early period group
     Date     Begin    Peak     End        Closest
---------------------------------------------------
 2022 Feb 25  11:25  11:28:32  11:31 UTC    1.30°
 2022 Feb 26  11:23  11:28:23  11:33 UTC    0.92°
 2022 Feb 27  11:22  11:28:11  11:34 UTC    0.55°
 2022 Feb 28  11:21  11:28:01  11:34 UTC    0.17°
 2022 Mar 01  11:21  11:27:47  11:33 UTC    0.21°
 2022 Mar 02  11:21  11:27:38  11:33 UTC    0.59°
 2022 Mar 03  11:22  11:27:25  11:32 UTC    0.97°
 2022 Mar 04  11:24  11:27:12  11:29 UTC    1.36°
---------------------------------------------------


---------------------------------------------------
                  Late period group
     Date     Begin    Peak     End        Closest
---------------------------------------------------
 2022 Oct 09  10:59  11:02:48  11:05 UTC    1.35°
 2022 Oct 10  10:57  11:02:32  11:07 UTC    0.97°
 2022 Oct 11  10:56  11:02:14  11:07 UTC    0.59°
 2022 Oct 12  10:55  11:02:00  11:08 UTC    0.22°
 2022 Oct 13  10:55  11:01:45  11:07 UTC    0.16°
 2022 Oct 14  10:55  11:01:31  11:07 UTC    0.53°
 2022 Oct 15  10:56  11:01:18  11:06 UTC    0.90°
 2022 Oct 16  10:57  11:01:05  11:04 UTC    1.27°
---------------------------------------------------


Re: PyTROLL/pycoast 1.6.0 is out

Ernst Lobsiger
 

Graham,

Have you done the pycoast update while being in environment (pytroll)?

Maybe you should also update satpy (note your current version first)?

It works here on Luna and Kallisto without problems.

(pytroll) eumetcast@luna:~$ conda list satpy
# Name                 Version                   Build  Channel
satpy                     0.37.1             pyhd8ed1ab_1    conda-forge

(pytroll) eumetcast@luna:~$ conda list pycoast
# packages in environment at /home/eumetcast/miniconda3/envs/pytroll:
#
# Name                   Version                   Build  Channel
pycoast                   1.6.0              pyhd8ed1ab_0    conda-forge



Cheers,
Ernst


Re: PyTROLL/pycoast 1.6.0 is out

g-woolf@sky.com
 

Hi Ernst

I have done the update and I am now getting the following error and my scripts dont complete

   self._draw_major_lines(
  File "c:\Users\graha\miniconda3\envs\pytroll\lib\site-packages\pycoast\cw_base.py", line 1660, in _draw_major_lines
    index_array,
UnboundLocalError: local variable 'index_array' referenced before assignment

Any ideas

Thanks

Graham



On Thursday, 27 October 2022 at 07:14:20 UTC, Ernst Lobsiger via groups.io <ernst.lobsiger@...> wrote:


Dear SatPy users,

if you haven't noticed yet, pycoast 1.6.0 is out. This is a major update that among other things:
- fixes the 'Ireland has no coast' bug
- fixes the 'horizontal and vertical scratches' bug when areas cross the dateline
- adds a couple of new symbols like triangle, pentagon, hexagon, star5, star6, star7 ...
- allows for user defined shape files
- brings back cities from city files
- improves overlay caching
- has refactored code
- etc, etc.

Update with conda while you are in the (pytroll) environment (check version first):
conda list pycoast
conda update pycoast

Cheers,
Ernst



Re: PyTROLL/pycoast 1.6.0 is out

Douglas Deans
 

On 27/10/2022 08:14, Ernst Lobsiger via groups.io wrote:
Dear SatPy users,
if you haven't noticed yet, pycoast 1.6.0 is out. This is a major update that among other things:
- fixes the 'Ireland has no coast' bug
- fixes the 'horizontal and vertical scratches' bug when areas cross the dateline
- adds a couple of new symbols like triangle, pentagon, hexagon, star5, star6, star7 ...
- allows for user defined shape files
- brings back cities from city files
- improves overlay caching
- has refactored code
- etc, etc.
Update with conda while you are in the (pytroll) environment (check version first):
conda list pycoast
conda update pycoast
Cheers,
Ernst
==========================================================================

Many thanks for the information Ernst.
I had not checked that so will get the update done.

Best regards,
Douglas.


Re: PyTROLL/pycoast 1.6.0 is out

fvalk@...
 

Excellent Ernst, very welcome. Thanks for your work on this.

 

Ferdinand

 

From: MSG-1@groups.io On Behalf Of Ernst Lobsiger via groups.io
Sent: Thursday, 27 October, 2022 07:14
To: MSG-1@groups.io
Subject: [MSG-1] PyTROLL/pycoast 1.6.0 is out

 

Dear SatPy users,

if you haven't noticed yet, pycoast 1.6.0 is out. This is a major update that among other things:
- fixes the 'Ireland has no coast' bug
- fixes the 'horizontal and vertical scratches' bug when areas cross the dateline
- adds a couple of new symbols like triangle, pentagon, hexagon, star5, star6, star7 ...
- allows for user defined shape files
- brings back cities from city files
- improves overlay caching
- has refactored code
- etc, etc.

Update with conda while you are in the (pytroll) environment (check version first):
conda list pycoast
conda update pycoast

Cheers,
Ernst


PyTROLL/pycoast 1.6.0 is out

Ernst Lobsiger
 

Dear SatPy users,

if you haven't noticed yet, pycoast 1.6.0 is out. This is a major update that among other things:
- fixes the 'Ireland has no coast' bug
- fixes the 'horizontal and vertical scratches' bug when areas cross the dateline
- adds a couple of new symbols like triangle, pentagon, hexagon, star5, star6, star7 ...
- allows for user defined shape files
- brings back cities from city files
- improves overlay caching
- has refactored code
- etc, etc.

Update with conda while you are in the (pytroll) environment (check version first):
conda list pycoast
conda update pycoast

Cheers,
Ernst



Groups.io will be down for maintenance

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

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Note: groups.io will be down for maintenance on Saturday, October 22nd,
starting at 9AM Pacific Time (4PM Saturday October 22, 2022 UTC), for
approximately one hour."
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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