Date
1 - 15 of 15
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 +103sSorry 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 |
|
|
|
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@aol.com
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° --------------------------------------------------- |
|
|
|
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.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@aol.com
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
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@aol.com
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@aol.com
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 |
|
|
|
On 30/10/2022 18:52, Ernst Lobsiger via groups.io wrote:
David,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. |
|
|
|
On 02/11/2022 12:53, Ernst Lobsiger via groups.io wrote:
P.S.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 |
|
|
