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


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


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


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





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


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


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.


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


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.






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.


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


geojohnt@...
 

Hello Ernst,

Thanks for your thoughts and pointing observations.

For the second time in a week I had no signal overnight last night due to strong winds from the English Channel moving my patio mount dish.
Last night the gusts were in excess of 80 km per hour over a prolonged period.
More concrete block on the stand but the wind is getting up again and the forecast tonight is for more severe weather.

Thank goodness my dishes are not 'up a pole!'

Regards,
John.




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

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


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

On 30/10/2022 18:52, Ernst Lobsiger via groups.io wrote:
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
I had to check back, Ernst.

WXtrack uses great circle calculations (normalised), although the "bearing" isn't needed, but the "range" provides the offset.

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


Ernst Lobsiger
 

On Wed, Nov 2, 2022 at 12:02 AM, David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺 wrote:
WXtrack uses great circle calculations (normalised), although the "bearing" isn't needed, but the "range" provides the offset.
David,

thanks for this clarification. Then I think our small differences are a result of figure 0 only.

If you have the satellite at Az, El and the Sun at Saz, Sel, then:

Great circle distance:
dist = acos(sin(El) * sin(Sel) +  cos(El) * cos(Sel) * cos(Az-Saz))

Using a scalar product:
x1 = cos(El) * cos(Az);
y1 = cos(El) * sin(Az)
z1 = sin(El)
x2 = cos(Sel) * cos(Saz)
y2 = cos(Sel) * sin(Saz)
z2 = sin(Sel)
dist = acos(x1*x2 + y1*y2 + z1*z2)

After my two rotations looking along the antenna beam:
Direction to the sat (1, 0, 0)
Direction to the sun (x3, y3, z3)
dist = acos(x3)

These methods are all equivalent and return identical results in Python.

Cheers,
Ernst

P.S.
I have not tested whether pyorbital (with reference to T.S. Kelso) and
your Pascal library from T.S. Kelso have 100% equivalent code though.


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

On 02/11/2022 12:53, Ernst Lobsiger via groups.io wrote:
P.S.
I have not tested whether pyorbital (with reference to T.S. Kelso) and
your Pascal library from T.S. Kelso have 100% equivalent code though.
Thanks, Ernst.

Unfortunately Dr. T.S.Kelso's more recent versions are in C/C++, and it would be far too much effort to incorporate the changes in my Pascal (actually Delphi) code.

I have seen minor discrepancies with geostationary satellites which I've never been able to resolve, but I think they are well under a degree for pointing accuracy. Out of date Kepler data causes much bigger errors!

For other planets I use Paul Schlyter's algorithm (used with permission, thanks Paul).

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