Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
gps sattelites
133 views
Skip to first unread message
Hul Tytus
Jun 11, 2022, 4:02:32 AM6/11/22
to
Anyone know where a schedule of the times of orbit of the GPS sattelites
might be found? Given such data, forecasting a good time for taking readings
at a specific location should be possible. Eliminating multiple readings over
several days would be the enjoyable result.
Hul
might be found? Given such data, forecasting a good time for taking readings
at a specific location should be possible. Eliminating multiple readings over
several days would be the enjoyable result.
Hul
Martin Brown
Jun 11, 2022, 4:19:51 AM6/11/22
to
Will predict positions of most satellites bright enough to see with the
naked eye (or which flare bright enough to see sometimes).
Feeding in the orbital elements of the GPS satellites or knowing their
names should get you predictions of visibility for lat, long & time.
One I have never used seems to have their orbital elements in its database:
https://in-the-sky.org/spacecraft_elements.php?id=41328
Quite a lot of work to do it manually so you are probably going to need
to write a program taking as input their latest orbital elements and
then looking for the times when N or more GPS satellites are visible to you.
--
Regards,
Martin Brown
Gerhard Hoffmann
Jun 11, 2022, 5:24:05 AM6/11/22
to
Am 11.06.22 um 10:02 schrieb Hul Tytus:
The GPS system sends the data of all sats. The receivers need to know
that. Probably you can ask your receiver.
Try Lady Heather'S Disciplined Oscillator control program
< http://www.ke5fx.com/heather/readme.htm >
Gerhard
that. Probably you can ask your receiver.
Try Lady Heather'S Disciplined Oscillator control program
< http://www.ke5fx.com/heather/readme.htm >
Gerhard
Ricky
Jun 11, 2022, 8:45:00 AM6/11/22
to
You will get your best readings from sats spread around the sky. So including sats near the horizon would be important to minimize the calculation errors.
--
Rick C.
- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209
John Miles, KE5FX
Jun 11, 2022, 4:59:07 PM6/11/22
to
On Saturday, June 11, 2022 at 5:45:00 AM UTC-7, Ricky wrote:
> You will get your best readings from sats spread around the sky. So
>including sats near the horizon would be important to minimize the
>calculation errors.
Only to some extent. While you want a good spread, you actually want to
> You will get your best readings from sats spread around the sky. So
>including sats near the horizon would be important to minimize the
>calculation errors.
exclude SVs that are very close to the horizon because they're the ones
most vulnerable to multipath and propagation disturbances. Many receivers,
including all timing-grade receivers, use an elevation mask to avoid that.
For the same reason, the better antennas tend to use choke rings or other
ground topologies to discourage low-angle reception.
-- john, KE5FX
Hul Tytus
Jun 11, 2022, 7:54:05 PM6/11/22
to
Martin - thanks for the info, especially the "spacecraft elements" at in-the-sky.org. From
what's there, I need to learn the meaning of the terms shown and the procedure
for predicting positions at a given time. Any suggestions?
Hul
what's there, I need to learn the meaning of the terms shown and the procedure
for predicting positions at a given time. Any suggestions?
Hul
Hul Tytus
Jun 11, 2022, 8:01:50 PM6/11/22
to
Gerhard I looked at "heather" and I'll keep a record of same. Currently
I'm too much of a rube in sattelite language and information to be able
to pick needed data from the mass available there.
Hul
I'm too much of a rube in sattelite language and information to be able
to pick needed data from the mass available there.
Hul
Hul Tytus
Jun 11, 2022, 8:15:57 PM6/11/22
to
John I am looking at positions generated each second by one of Ublox's
9 series of GPS receivers. Some readings at a single location show (monday at
10, tues at 5..) good repeatability and some are noticebly off. The idea
is to see the satellite positions at the time of known readings, gain a feel
for good/bad satellite positions and use that to shedule further readings.
Hul
9 series of GPS receivers. Some readings at a single location show (monday at
10, tues at 5..) good repeatability and some are noticebly off. The idea
is to see the satellite positions at the time of known readings, gain a feel
for good/bad satellite positions and use that to shedule further readings.
Hul
rbowman
Jun 12, 2022, 1:01:14 AM6/12/22
to
On 06/11/2022 06:15 PM, Hul Tytus wrote:
> John I am looking at positions generated each second by one of Ublox's
> 9 series of GPS receivers. Some readings at a single location show (monday at
> 10, tues at 5..) good repeatability and some are noticebly off. The idea
> is to see the satellite positions at the time of known readings, gain a feel
> for good/bad satellite positions and use that to shedule further readings.
Are you getting NMEA sentences from the receiver?
> John I am looking at positions generated each second by one of Ublox's
> 9 series of GPS receivers. Some readings at a single location show (monday at
> 10, tues at 5..) good repeatability and some are noticebly off. The idea
> is to see the satellite positions at the time of known readings, gain a feel
> for good/bad satellite positions and use that to shedule further readings.
http://www.satsleuth.com/GPS_NMEA_sentences.aspx
I discard everything other the GPRMC since I'm tracking mobile units but
GPGSV gives the information on the satellites in view. Not useful for
prediction but it might be of interest.
If you're on Linux:
https://www.qsl.net/kd2bd/predict.html
Martin Brown
Jun 12, 2022, 4:01:11 AM6/12/22
to
On 12/06/2022 00:53, Hul Tytus wrote:
> Martin - thanks for the info, especially the "spacecraft elements" at in-the-sky.org. From
> what's there, I need to learn the meaning of the terms shown and the procedure
> for predicting positions at a given time. Any suggestions?
The bible for that sort of thing is Jean Meeus's book Astronomical
> Martin - thanks for the info, especially the "spacecraft elements" at in-the-sky.org. From
> what's there, I need to learn the meaning of the terms shown and the procedure
> for predicting positions at a given time. Any suggestions?
Algorithms but it is nearly out of print and copies in the USA sell for
insane prices. These guys still have reasonably priced stock.
https://www.firstlightoptics.com/books/astronomical-algorithms.html
(chapters 29 through 33 - assumes moderately advanced maths)
Bad news is it doesn't deal with terrestrial satellites only solar
system objects but the principles are the same it is just that there are
drag and oblateness corrections for orbiting the Earth in addition.
And also a much more significant correction for the observer being sat
on the surface of the Earth rather than at its centre. Objects in near
Earth orbit are subject to a lot of parallax from the ground.
Offhand I don't know of any code that does it very accurately (like the
GPS code does) but then you may not need great accuracy provided the
satellite positions are indicative of how many you have in the sky at
any one time. Never used any of these but worth a look:
https://listoffreeware.com/satellite-tracking-software-windows/
https://www.satsignal.eu/software/wxtrack.htm
Hope this is some help.
Regards,
Martin Brown
Hul Tytus
Jun 12, 2022, 6:31:43 AM6/12/22
to
I'm using the NMEA sentences from the reciever. That allows shifting
from, in my case, Ublox to Skytrack receivers, with minimal effort.
The "terminal" I've setup collects satelitte names & info which ...
hmmm... that includes the position of the satellites which should be
useful, could even generate the ability to predict positions from a heap
of past data. Should be something simpler though.
I'll take a look qsl.net.
Hul
from, in my case, Ublox to Skytrack receivers, with minimal effort.
The "terminal" I've setup collects satelitte names & info which ...
hmmm... that includes the position of the satellites which should be
useful, could even generate the ability to predict positions from a heap
of past data. Should be something simpler though.
I'll take a look qsl.net.
Hul
Hul Tytus
Jun 12, 2022, 6:46:28 AM6/12/22
to
Martin - thanks for the suggestion. I'll give Meeus' book a try. Accuracy of
the orbital need not be great for this application, as you mention.
I looked at Meeus' book once when seeking a procedure for calculating the
sun's position and was supprised at the lack of accurracy. Someone's keeping
their methods close to the vest.
the orbital need not be great for this application, as you mention.
I looked at Meeus' book once when seeking a procedure for calculating the
sun's position and was supprised at the lack of accurracy. Someone's keeping
their methods close to the vest.
Martin Brown
Jun 12, 2022, 7:03:50 AM6/12/22
to
On 12/06/2022 11:46, Hul Tytus wrote:
> Martin - thanks for the suggestion. I'll give Meeus' book a try. Accuracy of
> the orbital need not be great for this application, as you mention.
> I looked at Meeus' book once when seeking a procedure for calculating the
> sun's position and was supprised at the lack of accurracy. Someone's keeping
> their methods close to the vest.
The full methods for the solar system are published as VSOP82 onwards.
> Martin - thanks for the suggestion. I'll give Meeus' book a try. Accuracy of
> the orbital need not be great for this application, as you mention.
> I looked at Meeus' book once when seeking a procedure for calculating the
> sun's position and was supprised at the lack of accurracy. Someone's keeping
> their methods close to the vest.
Current one is VSOP2013. It is a semianalytic fit to numerical
integration and incredibly accurate.
Observations of a pulsar that got really close to Jupiter found a
problem with the FORTRAN continuation cards (>10) generated by the
symbolic algebra program. For a moment it looked like relativity was not
predicting the right time delay for light passing close to Jupiter. But
it turned out that Jupiter wasn't where the theory said it was.
Fixed from VSOP87 onwards. That is good enough for most purposes...
Almost all planetarium programs use this VSOP method now.
https://en.wikipedia.org/wiki/VSOP_model
--
Regards,
Martin Brown
Martin Brown
Jun 12, 2022, 7:03:53 AM6/12/22
to
On 12/06/2022 01:15, Hul Tytus wrote:
> John I am looking at positions generated each second by one of Ublox's
> 9 series of GPS receivers. Some readings at a single location show (monday at
> 10, tues at 5..) good repeatability and some are noticebly off. The idea
> is to see the satellite positions at the time of known readings, gain a feel
> for good/bad satellite positions and use that to shedule further readings.
If you don't mind getting a biassed estimate then the minimum variance
> John I am looking at positions generated each second by one of Ublox's
> 9 series of GPS receivers. Some readings at a single location show (monday at
> 10, tues at 5..) good repeatability and some are noticebly off. The idea
> is to see the satellite positions at the time of known readings, gain a feel
> for good/bad satellite positions and use that to shedule further readings.
estimate will weight down any sporadic glitches automatically.
Likewise for minimum 1-norm estimates (ie median rather than mean).
Unweighted least squares pays too much attention to the outliers.
(and the thing that is certain is that will have the odd one)
--
Regards,
Martin Brown
Clifford Heath
Jun 12, 2022, 7:50:30 AM6/12/22
to
in Astronomy this package might prove useful:
<https://github.com/cosinekitty/astronomy>
A few lines of code can give you telescope pointing directions (alt/az)
from any point on earth to any object given its celestial coordinates,
for example.
I'm sure the author would be appreciative of extension code to handle
satellites.
Clifford Heath.
Chris Jones
Jun 12, 2022, 9:32:37 AM6/12/22
to
On 12/06/2022 20:46, Hul Tytus wrote:
> Martin - thanks for the suggestion. I'll give Meeus' book a try. Accuracy of
> the orbital need not be great for this application, as you mention.
> I looked at Meeus' book once when seeking a procedure for calculating the
> sun's position and was supprised at the lack of accurracy.
Huh? NIST has a program you can download here, and it is pretty
> Martin - thanks for the suggestion. I'll give Meeus' book a try. Accuracy of
> the orbital need not be great for this application, as you mention.
> I looked at Meeus' book once when seeking a procedure for calculating the
> sun's position and was supprised at the lack of accurracy.
accurate. I have used it a lot:
https://midcdmz.nrel.gov/spa/
There is a report about it here:
http://www.nrel.gov/docs/fy08osti/34302.pdf
It says in the abstract that it uses Meeus's algorithm.
Chris Jones
Jun 12, 2022, 9:40:57 AM6/12/22
to
On 12/06/2022 10:15, Hul Tytus wrote:
> John I am looking at positions generated each second by one of Ublox's
> 9 series of GPS receivers. Some readings at a single location show (monday at
> 10, tues at 5..) good repeatability and some are noticebly off. The idea
> is to see the satellite positions at the time of known readings, gain a feel
> for good/bad satellite positions and use that to shedule further readings.
Unless you implement your own receiver, that isn't going to work
> John I am looking at positions generated each second by one of Ublox's
> 9 series of GPS receivers. Some readings at a single location show (monday at
> 10, tues at 5..) good repeatability and some are noticebly off. The idea
> is to see the satellite positions at the time of known readings, gain a feel
> for good/bad satellite positions and use that to shedule further readings.
reliably. The receiver can pick and choose which satellites it includes
or excludes in its calculations and there is no guarantee that it will
pick the same ones at two different times, even if the same ones happen
to be visible. For the same reason, you can't use two ordinary consumer
GPS receivers to do differential GPS by just subtracting the known error
in the position solution of one station from the other station's
position solution - that won't work at all if they are using different
satellites.
About 15 years ago I recall finding a software GPS receiver somewhere on
the internet, and I'm sure there have been more or better ones developed
since then. Perhaps that would suit your needs, as you could tweak its
behaviour, get it to print out the satellite positions, etc.
Lasse Langwadt Christensen
Jun 12, 2022, 10:56:59 AM6/12/22
to
Hul Tytus
Jun 12, 2022, 1:34:04 PM6/12/22
to
Martin the VSOP methods sound like what I was after, thanks for mentioning
it. The Predict program at qsl.net appears useful but the source is barred
by an indemnity clause in their "terms of service".
it. The Predict program at qsl.net appears useful but the source is barred
by an indemnity clause in their "terms of service".
Hul Tytus
Jun 12, 2022, 1:56:41 PM6/12/22
to
Martin the readings I've recently taken are formed by waiting about 2 minutes
after the reciever has "captured" a useable number of sattelites and then averaging
all readings for 8 minutes. This has shown uniquely accurate (repeatible) readings
one day and some distinctly at variance on another. The objective now is to identify
the good days and also the bad days in order to avoid the latter. Averaging more
than the most basic method mentioned above would be counter to current intent, at
least at this point.
after the reciever has "captured" a useable number of sattelites and then averaging
all readings for 8 minutes. This has shown uniquely accurate (repeatible) readings
one day and some distinctly at variance on another. The objective now is to identify
the good days and also the bad days in order to avoid the latter. Averaging more
than the most basic method mentioned above would be counter to current intent, at
least at this point.
rbowman
Jun 12, 2022, 2:59:22 PM6/12/22
to
dongle to pick up ADS-B information.
Ricky
Jun 12, 2022, 5:33:18 PM6/12/22
to
On Sunday, June 12, 2022 at 1:56:41 PM UTC-4, Hul Tytus wrote:
> Martin the readings I've recently taken are formed by waiting about 2 minutes
> after the reciever has "captured" a useable number of sattelites and then averaging
> all readings for 8 minutes. This has shown uniquely accurate (repeatible) readings
> one day and some distinctly at variance on another. The objective now is to identify
> the good days and also the bad days in order to avoid the latter. Averaging more
> than the most basic method mentioned above would be counter to current intent, at
> least at this point.
I wasn't doing averaging, but the GPS was. I connected it to a PC program that showed the readings on a map. It was mostly in a small area, but once in a while, it would take a trip, up to some 100 feet away from the location. That entire excursion would be a significant part of 8 minutes and would cause noticeable error in data collection with a short term average. There was no reason to suspect satellite positioning as the excursion was too short. Sats take hours to move across the sky. I think their orbit is 1/2 day, no?
> Martin the readings I've recently taken are formed by waiting about 2 minutes
> after the reciever has "captured" a useable number of sattelites and then averaging
> all readings for 8 minutes. This has shown uniquely accurate (repeatible) readings
> one day and some distinctly at variance on another. The objective now is to identify
> the good days and also the bad days in order to avoid the latter. Averaging more
> than the most basic method mentioned above would be counter to current intent, at
> least at this point.
I also found a location that simply would not register a solid reading. It wandered around by 100's of feet it seemed. This was on a ridge, potentially with line of sight, although at some 10 mile distance, to Camp David. Word is they use GPS spoofing in the area at times. I guess that can't be confirmed very easily.
GPS modules can be bought for $25 the last time I looked. One could be connected to an inexpensive data logger and left for a day or more. Plot the data on a map and you will see a drunkards walk. The excursions will be minimal from my observations.
--
Rick C.
+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209
Dave Platt
Jun 12, 2022, 5:57:16 PM6/12/22
to
In article <e4d1b33e-f630-4eaf...@googlegroups.com>,
Position "wander" (GPS drift) can be caused by a whole bunch of
phenomena. The signal path from any given satellite to the receiver
is going to be affected by multipath - e.g. signal reflections from
buildings, trees, airplanes, the ground, and so forth. As the
satellite moves, the multipath behavior will change. This creates an
effect similar to audible "picket fencing" in a VHF-FM signal.
If I recall correctly, ionospheric disturbances can also perturb the
signal. The ionosphere is far from static, and if there's significant
solar activity the signal propagation can change on a minute-to-minute
basis.
I find it quite amazing that the GPS receiver's front end and signal
processing logic can pick out a whole bunch of extremely weak signals
all transmitting on the same frequency, and measure their arrival times
(phases) to such a high resolution.
It would be interesting to use a single high-quality GPS antenna, with
an active signal booster/splitter, and feed the split signal to a
group of GPS receivers of different make/model/design, and then
compare and contrast the position reports and the "which satellites
were in view and which ones were used for this position report" data.
For best accuracy all of the receivers would need to be programmed
correctly with the length (i.e. propagation delay) between cable and
receiver.
That sort of comparison might help separate site-specific issues
(e.g. patterns of multipath) from device-specific ones (e.g.
differences in the algorithms used by different receivers' firmware).
Ricky <gnuarm.del...@gmail.com> wrote:
>I wasn't doing averaging, but the GPS was. I connected it to a PC program that showed the
>readings on a map. It was mostly in a small area, but once in a while, it would take a trip, up
>to some 100 feet away from the location. That entire excursion would be a significant part of 8
>minutes and would cause noticeable error in data collection with a short term average. There was
>no reason to suspect satellite positioning as the excursion was too short. Sats take hours to
>move across the sky. I think their orbit is 1/2 day, no?
Roughly that, yes. It's not a geostationary or geosynchronous orbit.
>I wasn't doing averaging, but the GPS was. I connected it to a PC program that showed the
>readings on a map. It was mostly in a small area, but once in a while, it would take a trip, up
>to some 100 feet away from the location. That entire excursion would be a significant part of 8
>minutes and would cause noticeable error in data collection with a short term average. There was
>no reason to suspect satellite positioning as the excursion was too short. Sats take hours to
>move across the sky. I think their orbit is 1/2 day, no?
Position "wander" (GPS drift) can be caused by a whole bunch of
phenomena. The signal path from any given satellite to the receiver
is going to be affected by multipath - e.g. signal reflections from
buildings, trees, airplanes, the ground, and so forth. As the
satellite moves, the multipath behavior will change. This creates an
effect similar to audible "picket fencing" in a VHF-FM signal.
If I recall correctly, ionospheric disturbances can also perturb the
signal. The ionosphere is far from static, and if there's significant
solar activity the signal propagation can change on a minute-to-minute
basis.
I find it quite amazing that the GPS receiver's front end and signal
processing logic can pick out a whole bunch of extremely weak signals
all transmitting on the same frequency, and measure their arrival times
(phases) to such a high resolution.
It would be interesting to use a single high-quality GPS antenna, with
an active signal booster/splitter, and feed the split signal to a
group of GPS receivers of different make/model/design, and then
compare and contrast the position reports and the "which satellites
were in view and which ones were used for this position report" data.
For best accuracy all of the receivers would need to be programmed
correctly with the length (i.e. propagation delay) between cable and
receiver.
That sort of comparison might help separate site-specific issues
(e.g. patterns of multipath) from device-specific ones (e.g.
differences in the algorithms used by different receivers' firmware).
Hul Tytus
Jun 12, 2022, 5:58:27 PM6/12/22
to
Chris "working reliably" has numerous definitions. The objective here is
to reduce the number of readings required, ie the number of days required.
At this point, I'm guessing that a lack of overhead sattelites is causing
large altitude errors. Might work. One way to find out.
Hul
to reduce the number of readings required, ie the number of days required.
At this point, I'm guessing that a lack of overhead sattelites is causing
large altitude errors. Might work. One way to find out.
Hul
Hul Tytus
Jun 12, 2022, 6:01:07 PM6/12/22
to
Ricky
Jun 12, 2022, 9:12:39 PM6/12/22
to
On Sunday, June 12, 2022 at 5:57:16 PM UTC-4, Dave Platt wrote:
> In article <e4d1b33e-f630-4eaf...@googlegroups.com>,
> Ricky <gnuarm.del...@gmail.com> wrote:
>
> >I wasn't doing averaging, but the GPS was. I connected it to a PC program that showed the
> >readings on a map. It was mostly in a small area, but once in a while, it would take a trip, up
> >to some 100 feet away from the location. That entire excursion would be a significant part of 8
> >minutes and would cause noticeable error in data collection with a short term average. There was
> >no reason to suspect satellite positioning as the excursion was too short. Sats take hours to
> >move across the sky. I think their orbit is 1/2 day, no?
> Roughly that, yes. It's not a geostationary or geosynchronous orbit.
>
> Position "wander" (GPS drift) can be caused by a whole bunch of
> phenomena. The signal path from any given satellite to the receiver
> is going to be affected by multipath - e.g. signal reflections from
> buildings, trees, airplanes, the ground, and so forth. As the
> satellite moves, the multipath behavior will change. This creates an
> effect similar to audible "picket fencing" in a VHF-FM signal.
A GPS receiver needs four sats to get a 3D lock. A few more improve the accuracy. But it also provides redundancy. If one sat is arriving by multi-path, the calculations using that sat will result in significant deviations. I don't know if they do, but such a sat can be removed from the calculations, improving the accuracy.
> In article <e4d1b33e-f630-4eaf...@googlegroups.com>,
> Ricky <gnuarm.del...@gmail.com> wrote:
>
> >I wasn't doing averaging, but the GPS was. I connected it to a PC program that showed the
> >readings on a map. It was mostly in a small area, but once in a while, it would take a trip, up
> >to some 100 feet away from the location. That entire excursion would be a significant part of 8
> >minutes and would cause noticeable error in data collection with a short term average. There was
> >no reason to suspect satellite positioning as the excursion was too short. Sats take hours to
> >move across the sky. I think their orbit is 1/2 day, no?
> Roughly that, yes. It's not a geostationary or geosynchronous orbit.
>
> Position "wander" (GPS drift) can be caused by a whole bunch of
> phenomena. The signal path from any given satellite to the receiver
> is going to be affected by multipath - e.g. signal reflections from
> buildings, trees, airplanes, the ground, and so forth. As the
> satellite moves, the multipath behavior will change. This creates an
> effect similar to audible "picket fencing" in a VHF-FM signal.
> If I recall correctly, ionospheric disturbances can also perturb the
> signal. The ionosphere is far from static, and if there's significant
> solar activity the signal propagation can change on a minute-to-minute
> basis.
> I find it quite amazing that the GPS receiver's front end and signal
> processing logic can pick out a whole bunch of extremely weak signals
> all transmitting on the same frequency, and measure their arrival times
> (phases) to such a high resolution.
> It would be interesting to use a single high-quality GPS antenna, with
> an active signal booster/splitter, and feed the split signal to a
> group of GPS receivers of different make/model/design, and then
> compare and contrast the position reports and the "which satellites
> were in view and which ones were used for this position report" data.
> For best accuracy all of the receivers would need to be programmed
> correctly with the length (i.e. propagation delay) between cable and
> receiver.
> That sort of comparison might help separate site-specific issues
> (e.g. patterns of multipath) from device-specific ones (e.g.
> differences in the algorithms used by different receivers' firmware).
--
Rick C.
-- Get 1,000 miles of free Supercharging
-- Tesla referral code - https://ts.la/richard11209
Clifford Heath
Jun 12, 2022, 9:24:41 PM6/12/22
to
On 13/6/22 03:56, Hul Tytus wrote:
> Martin the readings I've recently taken are formed by waiting about 2 minutes
> after the reciever has "captured" a useable number of sattelites and then averaging
> all readings for 8 minutes. This has shown uniquely accurate (repeatible) readings
> one day and some distinctly at variance on another. The objective now is to identify
> the good days and also the bad days in order to avoid the latter.
Did you also record the HDOP and VDOP figures from the GPS?
> Martin the readings I've recently taken are formed by waiting about 2 minutes
> after the reciever has "captured" a useable number of sattelites and then averaging
> all readings for 8 minutes. This has shown uniquely accurate (repeatible) readings
> one day and some distinctly at variance on another. The objective now is to identify
> the good days and also the bad days in order to avoid the latter.
It calculates how the trigonometry propagates the signal timing errors
into positioning errors, depending on the specific locations of the
satellites it's relying on. If you aren't using DOP, you should be.
Ricky
Jun 12, 2022, 9:26:29 PM6/12/22
to
On Sunday, June 12, 2022 at 5:58:27 PM UTC-4, Hul Tytus wrote:
> Chris "working reliably" has numerous definitions. The objective here is
> to reduce the number of readings required, ie the number of days required.
> At this point, I'm guessing that a lack of overhead sattelites is causing
> large altitude errors. Might work. One way to find out.
It's usually the other way around, several overhead sats and not so many closer to the horizon. Low elevation sats are often blocked by structures or terrain. Elevation accuracy is inherently poorer than the map coordinates. Having low elevation sats helps that issue, not only the sats overhead.
> Chris "working reliably" has numerous definitions. The objective here is
> to reduce the number of readings required, ie the number of days required.
> At this point, I'm guessing that a lack of overhead sattelites is causing
> large altitude errors. Might work. One way to find out.
GPS measures timing reported by the sats in a relative manner only. This creates a 3D hyperbola for each pair. The intersections show the location. The best accuracy comes from sats spread around so the axis of the hyperbolae are not so close to one another. Only once you calculate your position, can the actual time be determined from the reported times and the now known path delays.
--
Rick C.
-+ Get 1,000 miles of free Supercharging
-+ Tesla referral code - https://ts.la/richard11209
Martin Brown
Jun 13, 2022, 4:34:48 AM6/13/22
to
On 12/06/2022 18:33, Hul Tytus wrote:
> Martin the VSOP methods sound like what I was after, thanks for mentioning
> it. The Predict program at qsl.net appears useful but the source is barred
> by an indemnity clause in their "terms of service".
VSOP is really for very accurate solar system object positions. The
> Martin the VSOP methods sound like what I was after, thanks for mentioning
> it. The Predict program at qsl.net appears useful but the source is barred
> by an indemnity clause in their "terms of service".
trouble with multibody gravitational effects is that they cause the
orbital elements of each component to evolve with time.
Historically when computer controlled scopes first became available the
planets were easy enough but the moon was well beyond what they could
fit in the firmware - too many perturbations and the scope would almost
never point at the largest object in the night sky!
You should be able to get away with something much cruder for taking
satellite orbital elements to actual positions. The tedious bit will be
obtaining the relevant orbital elements every couple of weeks.
You are after all only interested in the the number of birds within a
given zenith angle at your location.
I have a spreadsheet that can take classical orbital elements for solar
system objects and turn them into x,y,z and thence to RA & Dec. It is
more intended for amateur astronomers doing comet hunting though.
--
Regards,
Martin Brown
Martin Brown
Jun 13, 2022, 5:48:10 AM6/13/22
to
On 12/06/2022 18:56, Hul Tytus wrote:
> Martin the readings I've recently taken are formed by waiting about 2 minutes
> after the reciever has "captured" a useable number of sattelites and then averaging
> all readings for 8 minutes. This has shown uniquely accurate (repeatible) readings
> one day and some distinctly at variance on another. The objective now is to identify
> the good days and also the bad days in order to avoid the latter. Averaging more
> than the most basic method mentioned above would be counter to current intent, at
> least at this point.
Do you have two examples of the raw data good and bad as CSV files?
> Martin the readings I've recently taken are formed by waiting about 2 minutes
> after the reciever has "captured" a useable number of sattelites and then averaging
> all readings for 8 minutes. This has shown uniquely accurate (repeatible) readings
> one day and some distinctly at variance on another. The objective now is to identify
> the good days and also the bad days in order to avoid the latter. Averaging more
> than the most basic method mentioned above would be counter to current intent, at
> least at this point.
I'd be interested to take a quick look (although it will be July before
I have any slack time for interesting look see type things).
My instinct is that switching from mean to median would go a long way to
solving your immediate problem by weighting down the sporadic outliers.
Averaging is only helpful against Gaussian distributed noise and my
instinct is that your noise is decidedly not that friendly.
--
Regards,
Martin Brown
Hul Tytus
Jun 13, 2022, 8:18:09 PM6/13/22
to
Martin while seeking "Astronomical Algorithms" I bumped into "Sun Position" by
someone named Craig. A British fellow apparantly. Claim was code for accuratly
finding the sun's position, in 6 languages! I had hopes Craig was using the
current VSOP procedure which you mentioned.
The intrest in the sun's position came from a different project and is not
a part of the GPS efforts I've described.
What's needed now is a description of the procedure for deriving a satellite's
position at a given time or an example of such code such as "Predict" on qsl.net.
Any suggestions?
someone named Craig. A British fellow apparantly. Claim was code for accuratly
finding the sun's position, in 6 languages! I had hopes Craig was using the
current VSOP procedure which you mentioned.
The intrest in the sun's position came from a different project and is not
a part of the GPS efforts I've described.
What's needed now is a description of the procedure for deriving a satellite's
position at a given time or an example of such code such as "Predict" on qsl.net.
Any suggestions?
Clifford Heath
Jun 13, 2022, 8:34:03 PM6/13/22
to
On 14/6/22 10:18, Hul Tytus wrote:
> Martin while seeking "Astronomical Algorithms" I bumped into "Sun Position" by
> someone named Craig. A British fellow apparantly. Claim was code for accuratly
> finding the sun's position, in 6 languages! I had hopes Craig was using the
> current VSOP procedure which you mentioned.
I already responded with a pointer to this:
> Martin while seeking "Astronomical Algorithms" I bumped into "Sun Position" by
> someone named Craig. A British fellow apparantly. Claim was code for accuratly
> finding the sun's position, in 6 languages! I had hopes Craig was using the
> current VSOP procedure which you mentioned.
<<https://github.com/cosinekitty/astronomy>
> What's needed now is a description of the procedure for deriving a satellite's
> position at a given time or an example of such code such as "Predict" on qsl.net.
> Any suggestions?
helping implement that?
CH
Hul Tytus
Jun 13, 2022, 8:42:49 PM6/13/22
to
Martin by "raw data" you're refering to data recieved each second of
the 8 minute sampling period each is not recorded but included in the average. CSV
is a term unknown to me, but that's probably due to memory and/or lack off access
to the source code or attending documentation. However, the position of the satellites
& some other data is recorded upto, I think, 64 entries. Therafter the oldest is replaced
by the newest. That is held in RAM and is consequently lost when power goes. The results,
ie the positions, are recorded by hand.
Along the lines you've mentioned regarding methods of averaging, especially those
avoiding the "outliers" here is a possible scheme:
record 1000 positions
on each new position
calculate the average
remove the most distant entry and place the new in it's place
the 8 minute sampling period each is not recorded but included in the average. CSV
is a term unknown to me, but that's probably due to memory and/or lack off access
to the source code or attending documentation. However, the position of the satellites
& some other data is recorded upto, I think, 64 entries. Therafter the oldest is replaced
by the newest. That is held in RAM and is consequently lost when power goes. The results,
ie the positions, are recorded by hand.
Along the lines you've mentioned regarding methods of averaging, especially those
avoiding the "outliers" here is a possible scheme:
record 1000 positions
on each new position
calculate the average
remove the most distant entry and place the new in it's place
Martin Brown
Jun 14, 2022, 2:53:04 AM6/14/22
to
On 14/06/2022 01:42, Hul Tytus wrote:
> Martin by "raw data" you're refering to data recieved each second of
> the 8 minute sampling period each is not recorded but included in the average. CSV
> is a term unknown to me, but that's probably due to memory and/or lack off access
> to the source code or attending documentation. However, the position of the satellites
> & some other data is recorded upto, I think, 64 entries. Therafter the oldest is replaced
> by the newest. That is held in RAM and is consequently lost when power goes. The results,
> ie the positions, are recorded by hand.
CSV = comma separated variables.
> Martin by "raw data" you're refering to data recieved each second of
> the 8 minute sampling period each is not recorded but included in the average. CSV
> is a term unknown to me, but that's probably due to memory and/or lack off access
> to the source code or attending documentation. However, the position of the satellites
> & some other data is recorded upto, I think, 64 entries. Therafter the oldest is replaced
> by the newest. That is held in RAM and is consequently lost when power goes. The results,
> ie the positions, are recorded by hand.
I was hoping that maybe the device could output an ASCII raw data dump.
time, x, y, z (or lat, long, height)
One thing to bear in mind is that the unit is mostly concerned with
obtaining a latitude & longitude for the observer so in marginal signal
or constellation situations it will tend to put the observer onto the
default oblate spheroid of the Earths surface (or some other perhaps
more detailed internal topographic map).
> Along the lines you've mentioned regarding methods of averaging, especially those
> avoiding the "outliers" here is a possible scheme:
> record 1000 positions
> on each new position
> calculate the average
> remove the most distant entry and place the new in it's place
have and then ignoring any values more than 3 sigma away from the mean
is one sort of quick and dirty heuristic I have seen used in realtime
crude and not very powerful data acquisition with (very) noisy data.
Basically it computes mean and variance of the original buffer and then
mean and variance of the modified dataset. Keeping track of number of
samples actually used. Rinse and repeat.
If you have the entire dataset at once then after the raw data are all
acquired you can do it better in post processing.
--
Regards,
Martin Brown
Hul Tytus
Jun 14, 2022, 4:48:44 AM6/14/22
to
Martin, on common terms, the "terminal" used here doesn't store the data
but just adds it to the average.
I found a source for Meeus' Astronomical Algorithms. Thanks for mentioning
it.
but just adds it to the average.
I found a source for Meeus' Astronomical Algorithms. Thanks for mentioning
it.
Clifford Heath
Jun 14, 2022, 6:20:53 AM6/14/22
to
On 14/6/22 16:52, Martin Brown wrote:
> On 14/06/2022 01:42, Hul Tytus wrote:
>> Martin by "raw data" you're refering to data recieved each second of
>> the 8 minute sampling period each is not recorded but included in the
>> average. CSV
>> is a term unknown to me, but that's probably due to memory and/or lack
>> off access
>> to the source code or attending documentation. However, the position
>> of the satellites
>> & some other data is recorded upto, I think, 64 entries. Therafter the
>> oldest is replaced
>> by the newest. That is held in RAM and is consequently lost when power
>> goes. The results,
>> ie the positions, are recorded by hand.
>
> CSV = comma separated variables
Values. Comma separated values. Variables would leave you guessing :)
> On 14/06/2022 01:42, Hul Tytus wrote:
>> Martin by "raw data" you're refering to data recieved each second of
>> the 8 minute sampling period each is not recorded but included in the
>> average. CSV
>> is a term unknown to me, but that's probably due to memory and/or lack
>> off access
>> to the source code or attending documentation. However, the position
>> of the satellites
>> & some other data is recorded upto, I think, 64 entries. Therafter the
>> oldest is replaced
>> by the newest. That is held in RAM and is consequently lost when power
>> goes. The results,
>> ie the positions, are recorded by hand.
>
> CSV = comma separated variables
> Keeping a running mean and average for the length of buffer that you
> have and then ignoring any values more than 3 sigma away from the mean
> is one sort of quick and dirty heuristic I have seen used in realtime
> crude and not very powerful data acquisition with (very) noisy data.
>
> Basically it computes mean and variance
But yes, a good technique.
CH
Joe Gwinn
Jun 14, 2022, 11:25:12 AM6/14/22
to
The more powerful approach is a Jackknife Estimator.
.<https://en.wikipedia.org/wiki/Jackknife_resampling>
Joe Gwinn
Martin Brown
Jun 14, 2022, 12:03:19 PM6/14/22
to
On 14/06/2022 16:25, Joe Gwinn wrote:
> On Tue, 14 Jun 2022 07:52:55 +0100, Martin Brown
> <'''newspam'''@nonad.co.uk> wrote:
>
>> On 14/06/2022 01:42, Hul Tytus wrote:
>>> Martin by "raw data" you're refering to data recieved each second of
> On Tue, 14 Jun 2022 07:52:55 +0100, Martin Brown
> <'''newspam'''@nonad.co.uk> wrote:
>
>> On 14/06/2022 01:42, Hul Tytus wrote:
>>> Martin by "raw data" you're refering to data recieved each second of
>>> Along the lines you've mentioned regarding methods of averaging, especially those
>>> avoiding the "outliers" here is a possible scheme:
>>> record 1000 positions
>>> on each new position
>>> calculate the average
>>> remove the most distant entry and place the new in it's place
>>
>> Keeping a running mean and average for the length of buffer that you
>> have and then ignoring any values more than 3 sigma away from the mean
>> is one sort of quick and dirty heuristic I have seen used in realtime
>> crude and not very powerful data acquisition with (very) noisy data.
>
> The simple version of this is the trimmed mean.
In rough and ready engineering terms it was frequently referred to as
>>> avoiding the "outliers" here is a possible scheme:
>>> record 1000 positions
>>> on each new position
>>> calculate the average
>>> remove the most distant entry and place the new in it's place
>>
>> Keeping a running mean and average for the length of buffer that you
>> have and then ignoring any values more than 3 sigma away from the mean
>> is one sort of quick and dirty heuristic I have seen used in realtime
>> crude and not very powerful data acquisition with (very) noisy data.
>
> The simple version of this is the trimmed mean.
the mean whose parents were unmarried at my place of work.
> The more powerful approach is a Jackknife Estimator.
>
> .<https://en.wikipedia.org/wiki/Jackknife_resampling>
resources though. Summing a few extra terms is more easily done.
--
Regards,
Martin Brown
Joe Gwinn
Jun 14, 2022, 6:32:02 PM6/14/22
to
On Tue, 14 Jun 2022 17:03:07 +0100, Martin Brown
>> The more powerful approach is a Jackknife Estimator.
>>
>> .<https://en.wikipedia.org/wiki/Jackknife_resampling>
>
>Doesn't really lend itself to real time computation with limited
>resources though. Summing a few extra terms is more easily done.
Well, it is often used in realtime, for radar, but the computer is
generally pretty capable.
For a jackknife mean, it usually means subtracting ni/N from the mean
of all N samples, for each sample ni, dropping the sample with the
largest effect. This is pretty fast. Keep doing this until the
successive means are reasonably close to one another, where
"reasonably" is domain dependent.
Joe Gwinn
<'''newspam'''@nonad.co.uk> wrote:
>On 14/06/2022 16:25, Joe Gwinn wrote:
>> On Tue, 14 Jun 2022 07:52:55 +0100, Martin Brown
>> <'''newspam'''@nonad.co.uk> wrote:
>>
>>> On 14/06/2022 01:42, Hul Tytus wrote:
>>>> Martin by "raw data" you're refering to data recieved each second of
>
>>>> Along the lines you've mentioned regarding methods of averaging, especially those
>>>> avoiding the "outliers" here is a possible scheme:
>>>> record 1000 positions
>>>> on each new position
>>>> calculate the average
>>>> remove the most distant entry and place the new in it's place
>>>
>>> Keeping a running mean and average for the length of buffer that you
>>> have and then ignoring any values more than 3 sigma away from the mean
>>> is one sort of quick and dirty heuristic I have seen used in realtime
>>> crude and not very powerful data acquisition with (very) noisy data.
>>
>> The simple version of this is the trimmed mean.
>
>In rough and ready engineering terms it was frequently referred to as
>the mean whose parents were unmarried at my place of work.
Heh.
>On 14/06/2022 16:25, Joe Gwinn wrote:
>> On Tue, 14 Jun 2022 07:52:55 +0100, Martin Brown
>> <'''newspam'''@nonad.co.uk> wrote:
>>
>>> On 14/06/2022 01:42, Hul Tytus wrote:
>>>> Martin by "raw data" you're refering to data recieved each second of
>
>>>> Along the lines you've mentioned regarding methods of averaging, especially those
>>>> avoiding the "outliers" here is a possible scheme:
>>>> record 1000 positions
>>>> on each new position
>>>> calculate the average
>>>> remove the most distant entry and place the new in it's place
>>>
>>> Keeping a running mean and average for the length of buffer that you
>>> have and then ignoring any values more than 3 sigma away from the mean
>>> is one sort of quick and dirty heuristic I have seen used in realtime
>>> crude and not very powerful data acquisition with (very) noisy data.
>>
>> The simple version of this is the trimmed mean.
>
>In rough and ready engineering terms it was frequently referred to as
>the mean whose parents were unmarried at my place of work.
>> The more powerful approach is a Jackknife Estimator.
>>
>> .<https://en.wikipedia.org/wiki/Jackknife_resampling>
>
>Doesn't really lend itself to real time computation with limited
>resources though. Summing a few extra terms is more easily done.
generally pretty capable.
For a jackknife mean, it usually means subtracting ni/N from the mean
of all N samples, for each sample ni, dropping the sample with the
largest effect. This is pretty fast. Keep doing this until the
successive means are reasonably close to one another, where
"reasonably" is domain dependent.
Joe Gwinn
whit3rd
Jun 15, 2022, 1:09:14 AM6/15/22
to
On Sunday, June 12, 2022 at 2:33:18 PM UTC-7, Ricky wrote:
> I also found a location that simply would not register a solid reading. It wandered around by 100's of feet it seemed. This was on a ridge, potentially with line of sight, although at some 10 mile distance, to Camp David. Word is they use GPS spoofing in the area at times. I guess that can't be confirmed very easily.
There's failures of most schemes; the old map-and-compass days got interesting around Mt.St. Helens,
> I also found a location that simply would not register a solid reading. It wandered around by 100's of feet it seemed. This was on a ridge, potentially with line of sight, although at some 10 mile distance, to Camp David. Word is they use GPS spoofing in the area at times. I guess that can't be confirmed very easily.
in May 1980; I took sightings off local peaks to locate a seismometer or two, but the big mountain
was... unavailable at that time.
Jasen Betts
Jun 15, 2022, 8:30:57 AM6/15/22
to
On 2022-06-11, Hul Tytus <h...@panix.com> wrote:
> Martin - thanks for the info, especially the "spacecraft elements" at in-the-sky.org. From
> what's there, I need to learn the meaning of the terms shown and the procedure
> for predicting positions at a given time. Any suggestions?
>
search for "satellite prediction software."
http://gpredict.oz9aec.net/ looks promising.
--
Jasen.
> Martin - thanks for the info, especially the "spacecraft elements" at in-the-sky.org. From
> what's there, I need to learn the meaning of the terms shown and the procedure
> for predicting positions at a given time. Any suggestions?
>
search for "satellite prediction software."
http://gpredict.oz9aec.net/ looks promising.
--
Jasen.
0 new messages