• gps sattelites

    From Hul Tytus@21:1/5 to All on Sat Jun 11 08:02:24 2022
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin Brown@21:1/5 to Hul Tytus on Sat Jun 11 09:19:38 2022
    On 11/06/2022 09:02, Hul Tytus wrote:
    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.

    http://heavens-above.com/

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Gerhard Hoffmann@21:1/5 to All on Sat Jun 11 11:23:57 2022
    Am 11.06.22 um 10:02 schrieb Hul Tytus:
    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.

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ricky@21:1/5 to Hul Tytus on Sat Jun 11 05:44:56 2022
    On Saturday, June 11, 2022 at 4:02:32 AM UTC-4, Hul Tytus wrote:
    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.

    Are you taking readings over a wide area? The constellation doesn't vary with location until you move significant distances... unless you are dealing with significant variations in horizons. I don't think horizon effects are going to be included in
    any databases.

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Miles, KE5FX@21:1/5 to Ricky on Sat Jun 11 13:59:03 2022
    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 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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Hul Tytus@21:1/5 to Martin Brown on Sat Jun 11 23:53:58 2022
    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

    Martin Brown <'''newspam'''@nonad.co.uk> wrote:
    On 11/06/2022 09:02, Hul Tytus wrote:
    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.

    http://heavens-above.com/

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Hul Tytus@21:1/5 to Gerhard Hoffmann on Sun Jun 12 00:01:43 2022
    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


    Gerhard Hoffmann <dk4xp@arcor.de> wrote:
    Am 11.06.22 um 10:02 schrieb Hul Tytus:
    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.

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Hul Tytus@21:1/5 to jmiles@gmail.com on Sun Jun 12 00:15:51 2022
    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

    John Miles, KE5FX <jmiles@gmail.com> wrote:
    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 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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From rbowman@21:1/5 to Hul Tytus on Sat Jun 11 23:01:06 2022
    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?

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin Brown@21:1/5 to Hul Tytus on Sun Jun 12 09:00:59 2022
    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
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Hul Tytus@21:1/5 to rbowman on Sun Jun 12 10:31:35 2022
    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

    rbowman <bowman@montana.com> wrote:
    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?

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin Brown@21:1/5 to Hul Tytus on Sun Jun 12 12:03:42 2022
    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.
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Hul Tytus@21:1/5 to Martin Brown on Sun Jun 12 10:46:21 2022
    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.

    Hul

    Martin Brown <'''newspam'''@nonad.co.uk> wrote:
    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
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Clifford Heath@21:1/5 to Martin Brown on Sun Jun 12 21:49:40 2022
    On 12/6/22 18:00, Martin Brown wrote:
    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
    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

    I don't think it handles satellite ephemera, but for anyone interested
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Chris Jones@21:1/5 to Hul Tytus on Sun Jun 12 23:32:23 2022
    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
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Chris Jones@21:1/5 to Hul Tytus on Sun Jun 12 23:40:45 2022
    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
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lasse Langwadt Christensen@21:1/5 to All on Sun Jun 12 07:56:55 2022
    søndag den 12. juni 2022 kl. 15.40.57 UTC+2 skrev Chris Jones:
    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
    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.

    https://www.rtl-sdr.com/rtl-sdr-tutorial-gps-decoding-plotting/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Hul Tytus@21:1/5 to Martin Brown on Sun Jun 12 17:33:56 2022
    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".

    Hul

    Martin Brown <'''newspam'''@nonad.co.uk> wrote:
    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. 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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Hul Tytus@21:1/5 to Martin Brown on Sun Jun 12 17:56:34 2022
    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.

    Hul



    Martin Brown <'''newspam'''@nonad.co.uk> wrote:
    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 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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From rbowman@21:1/5 to Lasse Langwadt Christensen on Sun Jun 12 12:59:13 2022
    On 06/12/2022 08:56 AM, Lasse Langwadt Christensen wrote:
    søndag den 12. juni 2022 kl. 15.40.57 UTC+2 skrev Chris Jones:
    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
    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.

    https://www.rtl-sdr.com/rtl-sdr-tutorial-gps-decoding-plotting/


    Another project to get around to someday. I'm currently using a rtl-sdr
    dongle to pick up ADS-B information.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ricky@21:1/5 to Hul Tytus on Sun Jun 12 14:33:14 2022
    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?

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Hul Tytus@21:1/5 to Chris Jones on Sun Jun 12 21:58:20 2022
    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

    Chris Jones <lugnut808@spam.yahoo.com> wrote:
    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
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Dave Platt@21:1/5 to gnuarm.deletethisbit@gmail.com on Sun Jun 12 14:57:00 2022
    In article <e4d1b33e-f630-4eaf-b3a7-0d5f127d3799n@googlegroups.com>,
    Ricky <gnuarm.deletethisbit@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).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Hul Tytus@21:1/5 to Lasse Langwadt Christensen on Sun Jun 12 22:01:00 2022
    Thanks Lasse. I'll take a look.

    Hul

    Lasse Langwadt Christensen <langwadt@fonz.dk> wrote:
    s??ndag den 12. juni 2022 kl. 15.40.57 UTC+2 skrev Chris Jones:
    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
    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.

    https://www.rtl-sdr.com/rtl-sdr-tutorial-gps-decoding-plotting/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ricky@21:1/5 to Dave Platt on Sun Jun 12 18:12:35 2022
    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.


    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.

    Variations due to atmospheric disruptions are minimized by WAAS and similar correction schemes. I find without WAAS the error was typically 30 feet with larger excursions, while with the WAAS correction turned on, normal accuracy is typically better
    than 10 feet. Apparently they are done by brute force, a stationary... station, measures it's location and periodically reports the error. This is broadcast by the sats as a correction based on your area.


    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.

    I assume you know this is done by correlating PRN codes which give a lot of gain in the signal. Each sat has a different PRN which looks like noise to all the other codes, so very little interference. I believe the code is 1024 bits long, so lots of
    gain.


    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.

    As long as they all see the same delay, it won't make a difference.


    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).

    We evaluated small, GPS circuit boards for use in a product once and came down to two candidates, so we lab tested them using an external antenna. One worked just fine with some seconds to 1st lock (20 sec maybe). The other brand never got a lock. The
    vendor didn't care enough to find out why their units weren't working.

    --

    Rick C.

    -- Get 1,000 miles of free Supercharging
    -- Tesla referral code - https://ts.la/richard11209

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Clifford Heath@21:1/5 to Hul Tytus on Mon Jun 13 11:24:28 2022
    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?

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ricky@21:1/5 to Hul Tytus on Sun Jun 12 18:26:25 2022
    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.

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin Brown@21:1/5 to Hul Tytus on Mon Jun 13 09:34:39 2022
    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
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin Brown@21:1/5 to Hul Tytus on Mon Jun 13 10:48:01 2022
    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?

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Clifford Heath@21:1/5 to Hul Tytus on Tue Jun 14 10:33:31 2022
    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: <<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?

    Contact the author of that package and ask if they're interested in
    helping implement that?

    CH

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Hul Tytus@21:1/5 to Martin Brown on Tue Jun 14 00:18:02 2022
    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?

    Hul

    Martin Brown <'''newspam'''@nonad.co.uk> wrote:
    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
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Hul Tytus@21:1/5 to Martin Brown on Tue Jun 14 00:42:43 2022
    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

    Hul

    Martin Brown <'''newspam'''@nonad.co.uk> wrote:
    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?

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin Brown@21:1/5 to Hul Tytus on Tue Jun 14 07:52:55 2022
    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.
    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

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Hul Tytus@21:1/5 to Martin Brown on Tue Jun 14 08:48:37 2022
    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.

    Hul

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

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Clifford Heath@21:1/5 to Martin Brown on Tue Jun 14 20:20:19 2022
    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 :)

    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

    You need to keep the sum of squares if you want variance.
    But yes, a good technique.

    CH

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Joe Gwinn@21:1/5 to '''newspam'''@nonad.co.uk on Tue Jun 14 11:25:00 2022
    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
    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.
    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

    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 more powerful approach is a Jackknife Estimator.

    .<https://en.wikipedia.org/wiki/Jackknife_resampling>


    Joe Gwinn



    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin Brown@21:1/5 to Joe Gwinn on Tue Jun 14 17:03:07 2022
    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.


    --
    Regards,
    Martin Brown

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Joe Gwinn@21:1/5 to '''newspam'''@nonad.co.uk on Tue Jun 14 18:31:49 2022
    On Tue, 14 Jun 2022 17:03:07 +0100, Martin Brown
    <'''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.


    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From whit3rd@21:1/5 to Ricky on Tue Jun 14 22:09:10 2022
    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,
    in May 1980; I took sightings off local peaks to locate a seismometer or two, but the big mountain
    was... unavailable at that time.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jasen Betts@21:1/5 to Hul Tytus on Wed Jun 15 12:04:56 2022
    On 2022-06-11, Hul Tytus <ht@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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)