rOn Thu, 22 Sep 2022 23:53:26 -0700, Jeff Liebermann
<jeffl@cruzio.com> wrote:

>On Fri, 23 Sep 2022 12:39:05 +0700, John B. <slocombjb@gmail.com>
>wrote:
>
>>Well (:-) When making an open ocean trip, on a sail boat, one
>>calculates the speed by marking up the position for the "Noon Fix"
>>and measuring the distance from the last "Noon Fix" and dividing by 24
>>(:-)
>
>Nope. The navigator throws a floating "chip log" overboard, with a
>knotted rope attached. The rope knots are spaced 17 ft apart. The
>navigator counts how many knots go through his hands in 10 seconds. If
>5 knots pass through the navigators hands in 10 seconds, the vessel
>speed is 5 knots. If you want mph, a speed of 1 knot equals about
>1.15 mph. One could probably do this on a bicycle, but I don't think
>it would be very accurate (or easy).

Certainly, that is where the term "knot" referring to boat speed
originated but I would also say that in some 20 years of "boating"
including a couple of open ocean trips I have NEVER seen the system
actually used, (:-) But, I'm not too sure about your 10 second timing.
Remember that measuring spead with a "chip log" dates back to the
16th century and I'm not sure that one's pocket watch was calibrated
in seconds, way back then (:-) Somewhere I have the memory that a 30
second sand glass was the standard.

>Noon sights will work, but it's easier to just read the speed off the
>GPS display.
>
>About 20 years ago, I showed a group of high skool students how a
>sextant was used to calculate longitude. Most could not believe that
>sailors went through all the calculations and that navigators used
>sight reduction tables (HO 229), plotting tables, and "drafting"
>instruments. The consensus was that it was "too complicated to be
>useful". Sigh.

Well, "way back when" it was probably the mark of a qualified mariner,
but as you say there was a bit of figuring in it and it did need an
accurate time source. I started sailing before GPS existed and what I
did was get a time signal from the radio to set my watch (:-)

--
Cheers,

John B.

On Thursday, September 22, 2022 at 7:45:59 PM UTC-4, jeff.li...@gmail.com wrote:
> On Thu, 22 Sep 2022 12:05:31 -0700 (PDT), "funkma...@hotmail.com"
> <funkma...@hotmail.com> wrote:
>
> >On Thursday, September 22, 2022 at 10:43:10 AM UTC-4, jeff.li...@gmail.com wrote:
> >> On Thu, 22 Sep 2022 04:57:47 -0700 (PDT), "funkma...@hotmail.com"
> >> <funkma...@hotmail.com> wrote:
> >>
> >> >Because this conversation is about GPS, not doppler radar. You for some inexplicable reason brought up doppler radar in a conversation about GPS.. Your work (?) on doppler radar has absolutely nothing to do with a conversation on GPS. Why did _you_ bring up doppler radar in a discussion about CPS, you stupid jackass?
> >> Umm... that was my fault. I mentioned that GPS speed is measured by
> >> using Doppler shift, not by dividing distance between positions by
> >> time.
> >
> >Not to my understanding. Doppler shift is the compression/expansion of the frequency from a known source in reference to a known receiver. GPS is fundamentally a positioning tool - triangulation from timestamps versus arrival time on the receiver. This is shown by the NMEA string of the receiver output. That isn't doppler shift, in fact, doppler shift could corrupt the GPS data if it forces the carrier frequency to shift outside the limits of the receiver.. The speed calculated from GPS is a function of the distance traveled between established positions over time.
> >
> >> Doppler is more accurate because there are no errors produced
> >> by atmospheric diffraction.
> >
> >Not sure what that means. The receiver must lock onto the various satellites carrier frequencies to extract the timestamp data. Doppler shift may be compensated for in the receiver (knowing the Fr shift as a function of the direction traveled) but I'm pretty sure doppler isn't used as part of the positioning or speed calculations.
> "GPS Speedometer Principle of speed measurement using GPS"
> <https://www.onosokki.co.jp/English/hp_e/products/keisoku/automotive/lc8_principle.htm>
>
> "The Ionospheric Effect"
> <https://www.e-education.psu.edu/geog862/node/1715>
> "One of the largest errors in GPS positioning is attributable to the
> atmosphere."
>
> "Doppler GPS speed and heading"
> <https://forums.garmin.com/developer/connect-iq/f/discussion/7609/doppler-gps-speed-and-heading>
>
> "How does a GNSS receiver estimate velocity?"
> <https://insidegnss.com/how-does-a-gnss-receiver-estimate-velocity/>
> "Improved performance could be achieved by processing differences of
> consecutive carrier phase measurements (TDCP – time-differenced
> carrier phase), a strategy that enables velocity accuracies one order
> of magnitude better than the “raw” Doppler measurements output from
> the receiver’s tracking loops."
>
> I'm not sure about this one, but this GPS bicycle speedometer outputs
> only altitude, speed and time, which it uses to calculate distance.
> <https://www.amazon.com/MEILAN-Computer-Wireless-Speedometer-Waterproof/dp/B07SM5QLW3/>
> No position (lat-long) output. The chip might be capable of producing
> lat-long and using that and the clock to calculate speed, but it
> (probably) doesn't and instead just displays Doppler speed.
>

I stand corrected!
I could have sworn I read the position was a triangulation based on a time stamp on the signal. After reading your links I don't know where I could have gotten that idea. I have a modicum of satcom experience (data communication, not GPS). My first "real" job (as an intern, actually) was working for a company that had made a practical burst-mode microwave link analyzer, using a novel method of a swept frequency burst inserted into a TDMA time slot. Conventional MLAs require that the link be taken off-line for equalization - this method allowed for constant monitoring using any empty timeslot. This equalization compensated for frequency response and group delay but had to account for phase shift. I seem to remember some discussions regarding the effect of polarity shift as well ...this was back in the late 80's, I might be confusing that with something else. They went into production with the product, Intelsat and Eutelsat bought a few hundred of them.
Of course my experience is only tangential at best to this discussion - back the regularly scheduled programming.

Jeff Liebermann <jeffl@cruzio.com> wrote:
> On Fri, 23 Sep 2022 06:56:18 +0700, John B. <slocombjb@gmail.com>
> wrote:
>
>> On Thu, 22 Sep 2022 16:45:51 -0700, Jeff Liebermann <jeffl@cruzio.com>
>> wrote:
>>
>>> On Thu, 22 Sep 2022 12:05:31 -0700 (PDT), "funkma...@hotmail.com"
>>> <funkmasterxx@hotmail.com> wrote:
>>>
>>>> On Thursday, September 22, 2022 at 10:43:10 AM UTC-4, jeff.li...@gmail.com wrote:
>>>>> On Thu, 22 Sep 2022 04:57:47 -0700 (PDT), "funkma...@hotmail.com"
>>>>> <funkma...@hotmail.com> wrote:
>>>>>
Huge snips.
w >
> In other words, some GPS receivers (or firmware) are junk.

That certainly has been my experience each time I bought a new phone (use
sat nav app) or less frequently GPS computer seems to be more accurate, I
certainly remember older units getting very confused as to which road/trail
I was on thinking I was on a parallel road or so on.
>

Clearly some could be software ie locking on to the road/trail etc when
navigating though the GPS traces seem tighter.

> Also, if you search the document for "Doppler", you'll find that speed
> measurement is heavily tied to Doppler shift measurement.
>
Roger Merriman

On Friday, September 23, 2022 at 12:50:16 AM UTC-4, jeff.li...@gmail.com wrote:
>
>
> Also, if you search the document for "Doppler", you'll find that speed
> measurement is heavily tied to Doppler shift measurement.
> --

Doppler radar is precisely how every law enforcement radar speed "monitoring" system works. (now watch Jeff prove me wrong again).

On Friday, September 23, 2022 at 11:41:11 AM UTC-4, Roger Merriman wrote:
> Jeff Liebermann <je...@cruzio.com> wrote:
> > On Fri, 23 Sep 2022 06:56:18 +0700, John B. <sloc...@gmail.com>
> > wrote:
> >
> >> On Thu, 22 Sep 2022 16:45:51 -0700, Jeff Liebermann <je...@cruzio.com>
> >> wrote:
> >>
> >>> On Thu, 22 Sep 2022 12:05:31 -0700 (PDT), "funkma...@hotmail.com"
> >>> <funkma...@hotmail.com> wrote:
> >>>
> >>>> On Thursday, September 22, 2022 at 10:43:10 AM UTC-4, jeff.li...@gmail.com wrote:
> >>>>> On Thu, 22 Sep 2022 04:57:47 -0700 (PDT), "funkma...@hotmail.com"
> >>>>> <funkma...@hotmail.com> wrote:
> >>>>>
> Huge snips.
> w
> >
> > In other words, some GPS receivers (or firmware) are junk.
> That certainly has been my experience each time I bought a new phone (use
> sat nav app) or less frequently GPS computer seems to be more accurate, I
> certainly remember older units getting very confused as to which road/trail
> I was on thinking I was on a parallel road or so on.
> >
>
> Clearly some could be software ie locking on to the road/trail etc when
> navigating though the GPS traces seem tighter.

There are a couple of single-track Strava segments in my local park that parallel decently maintained carriage roads. It seems like they should be far enough apart for Strava to tell the difference (never closer the ~20 feet except for the entry points), but the app keeps assigning users of the carriage roads to the single track so the KOMs are set by carriage road riders doing 30+ MPH on CX bikes. Looking at the strava ride data, it's pretty obvious when you're on the carriage road vs the single track, but try to tell the Strava algorithm that....

> > Also, if you search the document for "Doppler", you'll find that speed
> > measurement is heavily tied to Doppler shift measurement.
> >
> Roger Merriman

funkma...@hotmail.com <funkmasterxx@hotmail.com> wrote:
> On Friday, September 23, 2022 at 11:41:11 AM UTC-4, Roger Merriman wrote:
>> Jeff Liebermann <je...@cruzio.com> wrote:
>>> On Fri, 23 Sep 2022 06:56:18 +0700, John B. <sloc...@gmail.com>
>>> wrote:
>>>
>>>> On Thu, 22 Sep 2022 16:45:51 -0700, Jeff Liebermann <je...@cruzio.com>
>>>> wrote:
>>>>
>>>>> On Thu, 22 Sep 2022 12:05:31 -0700 (PDT), "funkma...@hotmail.com"
>>>>> <funkma...@hotmail.com> wrote:
>>>>>
>>>>>> On Thursday, September 22, 2022 at 10:43:10 AM UTC-4, jeff.li...@gmail.com wrote:
>>>>>>> On Thu, 22 Sep 2022 04:57:47 -0700 (PDT), "funkma...@hotmail.com"
>>>>>>> <funkma...@hotmail.com> wrote:
>>>>>>>
>> Huge snips.
>> w
>>>
>>> In other words, some GPS receivers (or firmware) are junk.
>> That certainly has been my experience each time I bought a new phone (use
>> sat nav app) or less frequently GPS computer seems to be more accurate, I
>> certainly remember older units getting very confused as to which road/trail
>> I was on thinking I was on a parallel road or so on.
>>>
>>
>> Clearly some could be software ie locking on to the road/trail etc when
>> navigating though the GPS traces seem tighter.
>
> There are a couple of single-track Strava segments in my local park that
> parallel decently maintained carriage roads. It seems like they should be
> far enough apart for Strava to tell the difference (never closer the ~20
> feet except for the entry points), but the app keeps assigning users of
> the carriage roads to the single track so the KOMs are set by carriage
> road riders doing 30+ MPH on CX bikes. Looking at the strava ride data,
> it's pretty obvious when you're on the carriage road vs the single track,
> but try to tell the Strava algorithm that....

One of the woods has two parallel tracks one is very rooty and Sandy and
git to clear quite frankly, the other much less so! So your times vary
hugely yet the Strava segment is mostly the same one.
>
>
>>> Also, if you search the document for "Doppler", you'll find that speed
>>> measurement is heavily tied to Doppler shift measurement.
>>>
>> Roger Merriman
>

Roger Merriman.

On Fri, 23 Sep 2022 11:18:14 -0700 (PDT), "funkma...@hotmail.com"
<funkmasterxx@hotmail.com> wrote:

>On Friday, September 23, 2022 at 12:50:16 AM UTC-4, jeff.li...@gmail.com wrote:
>> Also, if you search the document for "Doppler", you'll find that speed
>> measurement is heavily tied to Doppler shift measurement.

>Doppler radar is precisely how every law enforcement radar speed "monitoring" system works. (now watch Jeff prove me wrong again).

Yep. There are other systems (monopulse, phased array, CW, etc) that
will provide other useful information besides speed, such as which
freeway lane the speeding car is in. Mobile speed guns are mostly IR
laser:
<https://kustomsignals.com/handheld-lidar/prolaser-4>
while fixed installations (automatic speed traps) use RF.

Incidentally, I have two really ancient 24GHz Kustom Road Runner radar
guns. Plenty fun measuring the speed of passing cyclists and
calibrating my car speedometer.
<https://photos.app.goo.gl/92mdDZmTuCQUPEpK9>

--
Jeff Liebermann jeffl@cruzio.com
PO Box 272 http://www.LearnByDestroying.com
Ben Lomond CA 95005-0272
Skype: JeffLiebermann AE6KS 831-336-2558

On Friday, September 23, 2022 at 4:54:56 PM UTC-4, jeff.li...@gmail.com wrote:
> On Fri, 23 Sep 2022 11:18:14 -0700 (PDT), "funkma...@hotmail.com"
> <funkma...@hotmail.com> wrote:
>
> >On Friday, September 23, 2022 at 12:50:16 AM UTC-4, jeff.li...@gmail.com wrote:
> >> Also, if you search the document for "Doppler", you'll find that speed
> >> measurement is heavily tied to Doppler shift measurement.
> >Doppler radar is precisely how every law enforcement radar speed "monitoring" system works. (now watch Jeff prove me wrong again).
> Yep. There are other systems (monopulse, phased array, CW, etc) that
> will provide other useful information besides speed, such as which
> freeway lane the speeding car is in. Mobile speed guns are mostly IR
> laser:
> <https://kustomsignals.com/handheld-lidar/prolaser-4>
> while fixed installations (automatic speed traps) use RF.
>
> Incidentally, I have two really ancient 24GHz Kustom Road Runner radar
> guns. Plenty fun measuring the speed of passing cyclists and
> calibrating my car speedometer.
> <https://photos.app.goo.gl/92mdDZmTuCQUPEpK9>
> --

Right, I got a radar detector as a present a few years ago that has a Lidar detector as well. I really can't use it in my area becasue there are so many other sources that set off the radar section. When I did have it in the car I don't think the lidar warning ever went off, but I had to keep it turned off most of the time since my commute at the time took me through a long section of strip malls with automatic door openers to the stores. You'd think the FCC would have set aside a different band for that.

On Fri, 23 Sep 2022 02:11:01 -0700 (PDT), "funkma...@hotmail.com"
<funkmasterxx@hotmail.com> wrote:

>I stand corrected!
>I could have sworn I read the position was a triangulation based on a time stamp on the signal.

It was like that in the early days of GPS before 2000. The first
handheld GPS was in 1989 (Magellan Nav1000). From skimming GPS World
magazine archives,
<https://www.gpsworld.com/gnss-systemalgorithms-methodsinnovation-doppler-aided-positioning-11601/>
my guess is the first usable Doppler based speed displays were in
2000, when selective availability finally was turned off. That's
because the clock jitter intentionally introduced to make selective
availability work also reduced the accuracy of velocity measurements.
There was equipment prior to 2000 that used Doppler to display
velocity because even with selective availability, Doppler was better
than a distance divided by time method.

>After reading your links I don't know where I could have gotten
>that idea.

As I mentioned in a different reply in this thread, I had the same
wrong idea and was corrected in sci.geo.satellite-nav newsgroup.

>I have a modicum of satcom experience (data communication, not
>GPS). My first "real" job (as an intern, actually) was working
>for a company that had made a practical burst-mode microwave
>link analyzer, using a novel method of a swept frequency burst
>inserted into a TDMA time slot.

Methinks that's roughly how digital cable TV works. Fill the channel
with spread spectrum (noise) at a level just below the maximum channel
power handling capability. Then, tweak the channel tilt, shape and
group delay everything looks nice. The mux can be temporarily set to
provide a time slot where there's no interfering traffic.

>Conventional MLAs require that the link be taken off-line for
>equalization - this method allowed for constant monitoring
>using any empty timeslot. This equalization compensated for
>frequency response and group delay but had to account for
>phase shift.

Phase delay is a single frequency version of group delay.

>I seem to remember some discussions regarding the effect of
>polarity shift as well ...this was back in the late 80's, I
>might be confusing that with something else.

Polarity? Do you mean polarization shift as in Faraday rotation?
That's a function of the RF path and the earth's magnetic field.
However, if you really want to mangle an RF signal, try putting
obstructions in the Fresnel Zone's along the path.

>They went into production with the product, Intelsat and
>Eutelsat bought a few hundred of them.

If the link analyzer was capable of doing offline channel
equalization, it would have been revolutionary in the late 1980's.
Back then, the big thing was BITE (built in test equipment). The
obvious benefit was continuous quality monitoring and impairment
correction without a rack full of equipment and expensive downtime. I
think the pitch line was something like: "Now that you have it
working, how would you like to make it reliable?"

>Of course my experience is only tangential at best to this
>discussion - back the regularly scheduled programming.

What were we discussing? I forgot. Actually, I also forgot which
newsgroup I was writing.

--
Jeff Liebermann jeffl@cruzio.com
PO Box 272 http://www.LearnByDestroying.com
Ben Lomond CA 95005-0272
Skype: JeffLiebermann AE6KS 831-336-2558

On Fri, 23 Sep 2022 14:42:57 -0700, Jeff Liebermann <jeffl@cruzio.com>
wrote:

>On Fri, 23 Sep 2022 02:11:01 -0700 (PDT), "funkma...@hotmail.com"
><funkmasterxx@hotmail.com> wrote:
>
>>I stand corrected!
>>I could have sworn I read the position was a triangulation based on a time stamp on the signal.
>
>It was like that in the early days of GPS before 2000. The first
>handheld GPS was in 1989 (Magellan Nav1000). From skimming GPS World
>magazine archives,
><https://www.gpsworld.com/gnss-systemalgorithms-methodsinnovation-doppler-aided-positioning-11601/>
>my guess is the first usable Doppler based speed displays were in
>2000, when selective availability finally was turned off. That's
>because the clock jitter intentionally introduced to make selective
>availability work also reduced the accuracy of velocity measurements.
>There was equipment prior to 2000 that used Doppler to display
>velocity because even with selective availability, Doppler was better
>than a distance divided by time method.

(chomp)
Something to think about concerning the accuracy of using successive
GPS positions divided by time to calculate speed. The basic accuracy
of GPS positions is limited by a large number of parameters. Over
time the error can be over several meters. For a fixed location, it
looks like this:
<https://www.visualgps.net/VisualGPSView/images/ssScatter.png>
Now, visualize trying to connect the dots between two consecutive
position reports and calculate the distance. The distance can be
anything between any of the points on either mess. Since the pattern
is mostly incoherent noise, there's no correlation between two
consecutive points. It's possible to average each positions, but that
would take so long that the speed indication response time would be
horrible.

Worse, let's say we have a bicycle going at 9 meters/sec (20 mph). The
update rate for GPS is typically once every 2 seconds. So, in 2
seconds, the bicycle moves 18 meters. However, the rms error on my
phone GPS is about +/-3 meters. So, the 18 meter distance needed to
get the exact correct speed could be anywhere between 18 +/-6 meters
or 12 to 24 meters between position reports. (It's 6 meters because
there are two points, each with an error radius of 3 meters). Even
so, the number would easily switch between extremes (because they
random) making on reading 12 meters and the next reading 24 meters.
Such a GPS speedometer would have a display that looked like a Las
Vegas slot machine.

Translation: Even with todays improved constellations and
corrections, using distance divided by time will produce a really
awful speedometer.

--
Jeff Liebermann jeffl@cruzio.com
PO Box 272 http://www.LearnByDestroying.com
Ben Lomond CA 95005-0272
Skype: JeffLiebermann AE6KS 831-336-2558

On Friday, September 23, 2022 at 6:09:50 PM UTC-4, jeff.li...@gmail.com wrote:
> On Fri, 23 Sep 2022 14:42:57 -0700, Jeff Liebermann <je...@cruzio.com>
> wrote:
> >On Fri, 23 Sep 2022 02:11:01 -0700 (PDT), "funkma...@hotmail.com"
> ><funkma...@hotmail.com> wrote:
> >
> >>I stand corrected!
> >>I could have sworn I read the position was a triangulation based on a time stamp on the signal.
> >
> >It was like that in the early days of GPS before 2000. The first
> >handheld GPS was in 1989 (Magellan Nav1000). From skimming GPS World
> >magazine archives,
> ><https://www.gpsworld.com/gnss-systemalgorithms-methodsinnovation-doppler-aided-positioning-11601/>
> >my guess is the first usable Doppler based speed displays were in
> >2000, when selective availability finally was turned off. That's
> >because the clock jitter intentionally introduced to make selective
> >availability work also reduced the accuracy of velocity measurements.
> >There was equipment prior to 2000 that used Doppler to display
> >velocity because even with selective availability, Doppler was better
> >than a distance divided by time method.
> (chomp)
> Something to think about concerning the accuracy of using successive
> GPS positions divided by time to calculate speed. The basic accuracy
> of GPS positions is limited by a large number of parameters. Over
> time the error can be over several meters. For a fixed location, it
> looks like this:
> <https://www.visualgps.net/VisualGPSView/images/ssScatter.png>

Yup, I see a lot of this

https://www.strava.com/activities/4424213642

That was actually in my basement (the lower building) but it has me running around between my and my neighbors yards.

> Now, visualize trying to connect the dots between two consecutive
> position reports and calculate the distance. The distance can be
> anything between any of the points on either mess. Since the pattern
> is mostly incoherent noise, there's no correlation between two
> consecutive points. It's possible to average each positions, but that
> would take so long that the speed indication response time would be
> horrible.
>
> Worse, let's say we have a bicycle going at 9 meters/sec (20 mph). The
> update rate for GPS is typically once every 2 seconds. So, in 2
> seconds, the bicycle moves 18 meters. However, the rms error on my
> phone GPS is about +/-3 meters. So, the 18 meter distance needed to
> get the exact correct speed could be anywhere between 18 +/-6 meters
> or 12 to 24 meters between position reports. (It's 6 meters because
> there are two points, each with an error radius of 3 meters). Even
> so, the number would easily switch between extremes (because they
> random) making on reading 12 meters and the next reading 24 meters.
> Such a GPS speedometer would have a display that looked like a Las
> Vegas slot machine.
>
> Translation: Even with todays improved constellations and
> corrections, using distance divided by time will produce a really
> awful speedometer.
> --
> Jeff Liebermann je...@cruzio.com
> PO Box 272 http://www.LearnByDestroying.com
> Ben Lomond CA 95005-0272
> Skype: JeffLiebermann AE6KS 831-336-2558

On Friday, September 23, 2022 at 5:43:04 PM UTC-4, jeff.li...@gmail.com wrote:
> On Fri, 23 Sep 2022 02:11:01 -0700 (PDT), "funkma...@hotmail.com"
> <funkma...@hotmail.com> wrote:
>
> >I stand corrected!
> >I could have sworn I read the position was a triangulation based on a time stamp on the signal.
> It was like that in the early days of GPS before 2000. The first
> handheld GPS was in 1989 (Magellan Nav1000).

Ah, so I'm _not_ losing my mind....

> From skimming GPS World
> magazine archives,
> <https://www.gpsworld.com/gnss-systemalgorithms-methodsinnovation-doppler-aided-positioning-11601/>
> my guess is the first usable Doppler based speed displays were in
> 2000, when selective availability finally was turned off. That's
> because the clock jitter intentionally introduced to make selective
> availability work also reduced the accuracy of velocity measurements.
> There was equipment prior to 2000 that used Doppler to display
> velocity because even with selective availability, Doppler was better
> than a distance divided by time method.
> >After reading your links I don't know where I could have gotten
> >that idea.
> As I mentioned in a different reply in this thread, I had the same
> wrong idea and was corrected in sci.geo.satellite-nav newsgroup.
> >I have a modicum of satcom experience (data communication, not
> >GPS). My first "real" job (as an intern, actually) was working
> >for a company that had made a practical burst-mode microwave
> >link analyzer, using a novel method of a swept frequency burst
> >inserted into a TDMA time slot.

It's all coming back to me now! The BMLA (Burst Mode Link analyzer) had three different RF busts in the time slot. The first burst was a fixed frequency at the center of the channel BW. The second burst swept from the center fr to the upper bw limit of the channel, then the third swept from the center fr to the lower bw limit of the channel. The sweep modulation was really fixed frequency shifts that were held for a time and all three bursts were QPSK modulated. I don't remember the number or duration of the fr steps, but the phase of each step was quadrature shifted once.

> Methinks that's roughly how digital cable TV works. Fill the channel
> with spread spectrum (noise) at a level just below the maximum channel
> power handling capability. Then, tweak the channel tilt, shape and
> group delay everything looks nice. The mux can be temporarily set to
> provide a time slot where there's no interfering traffic.

I'm not sure you can tweak group delay if you don't know the phase characteristics at the source, so it would seem to me a spread spectrum signal would have to be a lot more coherent than to qualify as noise. A COFDM "test" signal might work, and you also work in Bit Error Rate Testing (BERT is part of BITE!). I do remember a big problem compensating for gaussian noise during the development of the BMLA, but the details on that are sketchy to me now other than remembering the senior development team threw a party at work when they finally got the software filtering algorithm right. I wasn't involved on the project on that level.

> >Conventional MLAs require that the link be taken off-line for
> >equalization - this method allowed for constant monitoring
> >using any empty timeslot. This equalization compensated for
> >frequency response and group delay but had to account for
> >phase shift.
> Phase delay is a single frequency version of group delay.
> >I seem to remember some discussions regarding the effect of
> >polarity shift as well ...this was back in the late 80's, I
> >might be confusing that with something else.
> Polarity? Do you mean polarization shift as in Faraday rotation?
> That's a function of the RF path and the earth's magnetic field.
> However, if you really want to mangle an RF signal, try putting
> obstructions in the Fresnel Zone's along the path.

Thinking back on it they had to do an analysis of RHCP vs LHCP. I seem to remember it wasn't much of an issue, but there was someone in the organization that thought it might be. This system was actually just the IF, not the RF (the channel bw center fr was 140 MHz, but that was the IF band in the system), so that had a lot to do with it. I seem to remember the head of the analog hardware team getting frustrated and saying something like 'the polarity of the satellite frequency is transparent to the function of this product'....or something like that. Does that make sense to you? I could be misremembering something.

> >They went into production with the product, Intelsat and
> >Eutelsat bought a few hundred of them.
> If the link analyzer was capable of doing offline channel
> equalization, it would have been revolutionary in the late 1980's.

Yes, it was a pretty big deal. We got a boatload of funding from various public and private sources after the senior scientist published the concept in a white paper. I was hired directly from that first round of funding.

> Back then, the big thing was BITE (built in test equipment). The
> obvious benefit was continuous quality monitoring and impairment
> correction without a rack full of equipment and expensive downtime. I
> think the pitch line was something like: "Now that you have it
> working, how would you like to make it reliable?"

Exactly. The ability to keep the link functioning and monitor-tweak in real time means more revenue.

> >Of course my experience is only tangential at best to this
> >discussion - back the regularly scheduled programming.
> What were we discussing? I forgot. Actually, I also forgot which
> newsgroup I was writing.

It doesn't matter, it's just nice to have a conversation here where certain trolls aren't defecating.

> --
> Jeff Liebermann je...@cruzio.com
> PO Box 272 http://www.LearnByDestroying.com
> Ben Lomond CA 95005-0272
> Skype: JeffLiebermann AE6KS 831-336-2558

On Friday, September 23, 2022 at 8:41:11 AM UTC-7, Roger Merriman wrote:
> Jeff Liebermann <je...@cruzio.com> wrote:
> > On Fri, 23 Sep 2022 06:56:18 +0700, John B. <sloc...@gmail.com>
> > wrote:
> >
> >> On Thu, 22 Sep 2022 16:45:51 -0700, Jeff Liebermann <je...@cruzio.com>
> >> wrote:
> >>
> >>> On Thu, 22 Sep 2022 12:05:31 -0700 (PDT), "funkma...@hotmail.com"
> >>> <funkma...@hotmail.com> wrote:
> >>>
> >>>> On Thursday, September 22, 2022 at 10:43:10 AM UTC-4, jeff.li...@gmail.com wrote:
> >>>>> On Thu, 22 Sep 2022 04:57:47 -0700 (PDT), "funkma...@hotmail.com"
> >>>>> <funkma...@hotmail.com> wrote:
> >>>>>
> Huge snips.
> w
> >
> > In other words, some GPS receivers (or firmware) are junk.
> That certainly has been my experience each time I bought a new phone (use
> sat nav app) or less frequently GPS computer seems to be more accurate, I
> certainly remember older units getting very confused as to which road/trail
> I was on thinking I was on a parallel road or so on.
> >
>
> Clearly some could be software ie locking on to the road/trail etc when
> navigating though the GPS traces seem tighter.
> > Also, if you search the document for "Doppler", you'll find that speed
> > measurement is heavily tied to Doppler shift measurement.
> >
> Roger Merriman

I guess the question would be - did a Garmin 830 get confused?

On Sat, 24 Sep 2022 07:34:15 -0700 (PDT), "funkma...@hotmail.com"
<funkmasterxx@hotmail.com> wrote:

>On Friday, September 23, 2022 at 6:09:50 PM UTC-4, jeff.li...@gmail.com wrote:
>For a fixed location, it
>> looks like this:
>> <https://www.visualgps.net/VisualGPSView/images/ssScatter.png>

>Yup, I see a lot of this
>https://www.strava.com/activities/4424213642
>That was actually in my basement (the lower building) but it has me running around between my and my neighbors yards.

Terrible but fairly typical if you're dealing with reflections and low
signal levels. I see 10 position reports and approximately 13 meter
error radius. Switch to "satellite map" for a better view. If your
"connect the dots" map was over a 30 minute "ride" as Strava
indicates, you were only getting a valid position report an average of
once every 3 minutes. Such data is useless for measuring speed, but
does illustrate what is wrong with using distance between position
reports divided by time to calculate speed.

Incidentally, if you're going to make a habit of riding in your
basement, I can show you how to build a GPS signal amplifier. It's an
amplified patch antenna on the roof, RG-188u coax cable to the
basement, power injector, and a 2nd passive patch (transmit) antenna
in the basement. However, it's useless. All your position reports
will show that you're riding in place. You can ride in circles in
your basement and your GPS will show that you're not moving (much).
It's not too difficult to guess how I found that problem.

Trivia: Your Strava link above suggests that I login to Strava to see
more detail. When I do so, there is some more detail, but the "3m"
distance ruler in the lower left of the map disappears.

What GPS device do you use for recording your rides for Strava?

--
Jeff Liebermann jeffl@cruzio.com
PO Box 272 http://www.LearnByDestroying.com
Ben Lomond CA 95005-0272
Skype: JeffLiebermann AE6KS 831-336-2558

Tom Kunich <cyclintom@gmail.com> wrote:
> On Friday, September 23, 2022 at 8:41:11 AM UTC-7, Roger Merriman wrote:
>> Jeff Liebermann <je...@cruzio.com> wrote:
>>> On Fri, 23 Sep 2022 06:56:18 +0700, John B. <sloc...@gmail.com>
>>> wrote:
>>>
>>>> On Thu, 22 Sep 2022 16:45:51 -0700, Jeff Liebermann <je...@cruzio.com>
>>>> wrote:
>>>>
>>>>> On Thu, 22 Sep 2022 12:05:31 -0700 (PDT), "funkma...@hotmail.com"
>>>>> <funkma...@hotmail.com> wrote:
>>>>>
>>>>>> On Thursday, September 22, 2022 at 10:43:10 AM UTC-4, jeff.li...@gmail.com wrote:
>>>>>>> On Thu, 22 Sep 2022 04:57:47 -0700 (PDT), "funkma...@hotmail.com"
>>>>>>> <funkma...@hotmail.com> wrote:
>>>>>>>
>> Huge snips.
>> w
>>>
>>> In other words, some GPS receivers (or firmware) are junk.
>> That certainly has been my experience each time I bought a new phone (use
>> sat nav app) or less frequently GPS computer seems to be more accurate, I
>> certainly remember older units getting very confused as to which road/trail
>> I was on thinking I was on a parallel road or so on.
>>>
>>
>> Clearly some could be software ie locking on to the road/trail etc when
>> navigating though the GPS traces seem tighter.
>>> Also, if you search the document for "Doppler", you'll find that speed
>>> measurement is heavily tied to Doppler shift measurement.
>>>
>> Roger Merriman
>
> I guess the question would be - did a Garmin 830 get confused?
>
Certainly in my experience it gets far less confused be that improbable
speeds or where it is exactly, perfect no but certainly quite a step up
form the last one I had.

Roger Merriman

Jeff Liebermann <jeffl@cruzio.com> wrote:
> On Sat, 24 Sep 2022 07:34:15 -0700 (PDT), "funkma...@hotmail.com"
> <funkmasterxx@hotmail.com> wrote:
>
>> On Friday, September 23, 2022 at 6:09:50 PM UTC-4, jeff.li...@gmail.com wrote:
>> For a fixed location, it
>>> looks like this:
>>> <https://www.visualgps.net/VisualGPSView/images/ssScatter.png>
>
>> Yup, I see a lot of this
>> https://www.strava.com/activities/4424213642
>> That was actually in my basement (the lower building) but it has me
>> running around between my and my neighbors yards.
>
> Terrible but fairly typical if you're dealing with reflections and low
> signal levels. I see 10 position reports and approximately 13 meter
> error radius. Switch to "satellite map" for a better view. If your
> "connect the dots" map was over a 30 minute "ride" as Strava
> indicates, you were only getting a valid position report an average of
> once every 3 minutes. Such data is useless for measuring speed, but
> does illustrate what is wrong with using distance between position
> reports divided by time to calculate speed.
>
> Incidentally, if you're going to make a habit of riding in your
> basement, I can show you how to build a GPS signal amplifier. It's an
> amplified patch antenna on the roof, RG-188u coax cable to the
> basement, power injector, and a 2nd passive patch (transmit) antenna
> in the basement. However, it's useless. All your position reports
> will show that you're riding in place. You can ride in circles in
> your basement and your GPS will show that you're not moving (much).
> It's not too difficult to guess how I found that problem.
>
> Trivia: Your Strava link above suggests that I login to Strava to see
> more detail. When I do so, there is some more detail, but the "3m"
> distance ruler in the lower left of the map disappears.
>
> What GPS device do you use for recording your rides for Strava?
>
>
>
>
It should if a bike computer and reasonably advanced be able to connect to
trainer and have ability to turn off the GPS, not stuff I do as well I like
getting out of the house! The exercise is generally a by product of that!

Roger Merriman.

On Saturday, September 24, 2022 at 1:52:58 PM UTC-7, Roger Merriman wrote:
> Tom Kunich <cycl...@gmail.com> wrote:
> > On Friday, September 23, 2022 at 8:41:11 AM UTC-7, Roger Merriman wrote:
> >> Jeff Liebermann <je...@cruzio.com> wrote:
> >>> On Fri, 23 Sep 2022 06:56:18 +0700, John B. <sloc...@gmail.com>
> >>> wrote:
> >>>
> >>>> On Thu, 22 Sep 2022 16:45:51 -0700, Jeff Liebermann <je...@cruzio.com>
> >>>> wrote:
> >>>>
> >>>>> On Thu, 22 Sep 2022 12:05:31 -0700 (PDT), "funkma...@hotmail.com"
> >>>>> <funkma...@hotmail.com> wrote:
> >>>>>
> >>>>>> On Thursday, September 22, 2022 at 10:43:10 AM UTC-4, jeff.li...@gmail.com wrote:
> >>>>>>> On Thu, 22 Sep 2022 04:57:47 -0700 (PDT), "funkma...@hotmail.com"
> >>>>>>> <funkma...@hotmail.com> wrote:
> >>>>>>>
> >> Huge snips.
> >> w
> >>>
> >>> In other words, some GPS receivers (or firmware) are junk.
> >> That certainly has been my experience each time I bought a new phone (use
> >> sat nav app) or less frequently GPS computer seems to be more accurate, I
> >> certainly remember older units getting very confused as to which road/trail
> >> I was on thinking I was on a parallel road or so on.
> >>>
> >>
> >> Clearly some could be software ie locking on to the road/trail etc when
> >> navigating though the GPS traces seem tighter.
> >>> Also, if you search the document for "Doppler", you'll find that speed
> >>> measurement is heavily tied to Doppler shift measurement.
> >>>
> >> Roger Merriman
> >
> > I guess the question would be - did a Garmin 830 get confused?
> >
> Certainly in my experience it gets far less confused be that improbable
> speeds or where it is exactly, perfect no but certainly quite a step up
> form the last one I had.

Garmin have been building these units for many years now. While individual samples of position can vary a little we are NOT sampling every hour like some people seem to think. When you have a thousand samples a second and average the position, they are as I said + or - 13 feet. And without sensors, the tracking of the satellite across the sky is visible as speed, not position change. Plus they have streets, trails and off-road trails mapped so that they can track you on a street or trail and correct for the minor GPS errors. Heavens only knows where Liebermann is pretending he got the idea that GPS is doppler corrected. Perhaps he doesn't know what phase correction is.

We can pretend that Garmin doesn't know what they're doing or we can agree that they have a great deal more technology behind them than Liebermann.

On Sat, 24 Sep 2022 14:08:02 -0700 (PDT), Tom Kunich
<cyclintom@gmail.com> wrote:

>On Saturday, September 24, 2022 at 1:52:58 PM UTC-7, Roger Merriman wrote:
>> Tom Kunich <cycl...@gmail.com> wrote:
>> > On Friday, September 23, 2022 at 8:41:11 AM UTC-7, Roger Merriman wrote:
>> >> Jeff Liebermann <je...@cruzio.com> wrote:
>> >>> On Fri, 23 Sep 2022 06:56:18 +0700, John B. <sloc...@gmail.com>
>> >>> wrote:
>> >>>
>> >>>> On Thu, 22 Sep 2022 16:45:51 -0700, Jeff Liebermann <je...@cruzio.com>
>> >>>> wrote:
>> >>>>
>> >>>>> On Thu, 22 Sep 2022 12:05:31 -0700 (PDT), "funkma...@hotmail.com"
>> >>>>> <funkma...@hotmail.com> wrote:
>> >>>>>
>> >>>>>> On Thursday, September 22, 2022 at 10:43:10 AM UTC-4, jeff.li...@gmail.com wrote:
>> >>>>>>> On Thu, 22 Sep 2022 04:57:47 -0700 (PDT), "funkma...@hotmail.com"
>> >>>>>>> <funkma...@hotmail.com> wrote:
>> >>>>>>>
>> >> Huge snips.
>> >> w
>> >>>
>> >>> In other words, some GPS receivers (or firmware) are junk.
>> >> That certainly has been my experience each time I bought a new phone (use
>> >> sat nav app) or less frequently GPS computer seems to be more accurate, I
>> >> certainly remember older units getting very confused as to which road/trail
>> >> I was on thinking I was on a parallel road or so on.
>> >>>
>> >>
>> >> Clearly some could be software ie locking on to the road/trail etc when
>> >> navigating though the GPS traces seem tighter.
>> >>> Also, if you search the document for "Doppler", you'll find that speed
>> >>> measurement is heavily tied to Doppler shift measurement.
>> >>>
>> >> Roger Merriman
>> >
>> > I guess the question would be - did a Garmin 830 get confused?
>> >
>> Certainly in my experience it gets far less confused be that improbable
>> speeds or where it is exactly, perfect no but certainly quite a step up
>> form the last one I had.
>
>Garmin have been building these units for many years now. While individual samples of position can vary a little we are NOT sampling every hour like some people seem to think. When you have a thousand samples a second and average the position, they are as I said + or - 13 feet. And without sensors, the tracking of the satellite across the sky is visible as speed, not position change. Plus they have streets, trails and off-road trails mapped so that they can track you on a street or trail and correct for the minor GPS errors. Heavens only knows where Liebermann is pretending he got the idea that GPS is doppler corrected. Perhaps he doesn't know what phase correction is.
>
>We can pretend that Garmin doesn't know what they're doing or we can agree that they have a great deal more technology behind them than Liebermann.

Or that Tommy, with his 87 mph doesn't know what he is talking about?
--
Cheers,

John B.

On Sat, 24 Sep 2022 14:08:02 -0700 (PDT), Tom Kunich
<cyclintom@gmail.com> wrote:

Ok. I'll waste some more time on Tom.

>Garmin have been building these units for many years now.

Which demonstrates what? Does a GPS become more accurate as the
company becomes older and more experienced?

>While individual samples of position can vary a little

By YOUR number, it can vary +/-13ft. Each position can be anywhere in
your 13ft radius circle because the errors are random and do not
follow a predictable pattern. Calculating speed as distance traveled
over time results inaccurate because of this uncertainty.

My explanation from a previous posting on exactly the same topic which
you didn't bother reading:

Worse, let's say we have a bicycle going at 9 meters/sec (20 mph). The
update rate for GPS is typically once every 2 seconds. So, in 2
seconds, the bicycle moves 18 meters. However, the rms error on my
phone GPS is about +/-3 meters. So, the 18 meter distance needed to
get the exact correct speed could be anywhere between 18 +/-6 meters
or 12 to 24 meters between position reports. (It's 6 meters because
there are two points, each with an error radius of 3 meters). Even
so, the number would easily switch between extremes (because they
random) making on reading 12 meters and the next reading 24 meters.
Such a GPS speedometer would have a display that looked like a Las
Vegas slot machine.

Notice I said "the update rates for GPS is typically once every 2
seconds". That's the rate of NMEA 183 $GPRMC speed reports.
Internally, the sampling (not update) rate can be much higher.

Also, distance over time doesn't work too well unless you happen to be
riding in a straight line. On a curve, it fails badly while Doppler
works just fine. How would the GPS know where to measure? Inside of
the curve, outside, or middle of the road?

>we are NOT sampling every hour like some people seem to think.

We are also not sampling every day like Tom will surely claim. Please
stop inventing numbers for the occasion.

>When you have a thousand samples a second and average the position,
>they are as I said + or - 13 feet.

Where did you get "a thousand samples per second"? For position, the
best you can do is 1Hz or 1 samples per second. For smoother curves,
sometimes 50Hz is used. I think it's the same for speed calculations,
but I have to do some reading to be certain.
<https://www.furuno.com/en/gnss/technical/tec_rate>

>And without sensors, the tracking of the satellite across the sky
>is visible as speed, not position change.

Explain. That makes no sense. The speed is the Doppler shift which
is a measurement of the frequency of the received signals. Doppler
shift will work using only ONE satellite because the angle between the
direction of travel and the line between the GPS and ONE satellite is
known.

>Plus they have streets, trails and off-road trails mapped so that

My marine GPS's do not have road maps. Yet, they measure speed. I
also have some older GPS receivers that have no maps but can also
display speed. There are GPS speedometers that display speed and
don't display position.
<https://www.amazon.com/MEILAN-Computer-Wireless-Speedometer-Waterproof/dp/B07SM5QLW3/>
GPS does not need maps to display speed.

>they can track you on a street or trail and correct for the minor
>GPS errors.

Nice to know that GPS can display position, but we're discussing
speed.

>Heavens only knows where Liebermann is pretending he got the
>idea that GPS is doppler corrected. Perhaps he doesn't know what
>phase correction is.

More gibberish. GPS is not "Doppler corrected" or "phase corrected".
Show me a reference that agrees with your technobabble.

>We can pretend that Garmin doesn't know what they're doing or we
>can agree that they have a great deal more technology behind them
>than Liebermann.

Am I reading this correctly? Garmin is the company that allegedly
sold you three Garmin Edge 850 receivers that were "defective" because
they produce strange indications or you couldn't update the firmware.
Later, you blamed it on your sensor version. The Garmin 850 is also
the product that couldn't produce a stable reading for some number of
miles after you started riding. Garmin is also the company that made
it so difficult to sync your ride data to their servers that you are
still unable to post Strava ride reports. Garmin is also the company
that created a complex user interface that was beyond your ability to
program:
<https://www.youtube.com/watch?v=WVjqylnWtNo>
Yet, here you are defending Garmin. Did they bribe you? If I
complain endlessly about how bad Garmin is, can I also get a bribe
from them?

--
Jeff Liebermann jeffl@cruzio.com
PO Box 272 http://www.LearnByDestroying.com
Ben Lomond CA 95005-0272
Skype: JeffLiebermann AE6KS 831-336-2558

On Sat, 24 Sep 2022 18:24:53 -0700, Jeff Liebermann <jeffl@cruzio.com>
wrote:

>Where did you get "a thousand samples per second"? For position, the
>best you can do is 1Hz or 1 samples per second. For smoother curves,
>sometimes 50Hz is used. I think it's the same for speed calculations,
>but I have to do some reading to be certain.
><https://www.furuno.com/en/gnss/technical/tec_rate>

Oops. That should be "sometimes 10Hz is used". 50Hz is the data rate
for the NAV messages containing clock corrections, satellite health,
ephemeris, almanac, UTC time, telemetry, etc.
--
Jeff Liebermann jeffl@cruzio.com
PO Box 272 http://www.LearnByDestroying.com
Ben Lomond CA 95005-0272
Skype: JeffLiebermann AE6KS 831-336-2558

On Fri, 23 Sep 2022 15:41:07 -0000 (UTC), Roger Merriman
<roger@sarlet.com> wrote:

>Jeff Liebermann <jeffl@cruzio.com> wrote:
>> In other words, some GPS receivers (or firmware) are junk.

>That certainly has been my experience each time I bought a new phone (use
>sat nav app) or less frequently GPS computer seems to be more accurate, I
>certainly remember older units getting very confused as to which road/trail
>I was on thinking I was on a parallel road or so on.

Non-smartphones, dumb phones or feature phones handle GPS very
differently than Smartphones. In a smartphone, the GPS chipset
produces the location, speed, altitude, etc directly to the CPU, which
then displays it on a map or a screen full of numbers. In a dumb
phone, the satellite delays are sent to an internet service provider,
which calculates the location, speed, altitude, etc and sends the
results back to the dumb phone. That saves battery power and
eliminates the cost of a processor, but only works if you want a fixed
location, not a track displayed on a map.

Meanwhile, there were big improvements in GPS receiver design, which
improved sensitivity, accuracy, battery life, cold start, etc. The
big improvement was high-sensitivity GPS in about 2009.
<https://www.furuno.com/en/gnss/technical/tec_high>
Prior to this, most GPS receivers had problems in highly reflective
environments (urban canyons) and in weak signal areas (forests). With
high-sensitivity GPS, it was possible to obtain usable signals in
areas where GPS was previously useless.

There are a bunch of other improvements, such as additional
constellations (GLONASS, Galileo, DBS, etc), better augmentation (WAAS
via Inmarsat), additional signals (L5, L1C) and better post processing
in the phones. I can explain these and others but not right now.

>Clearly some could be software ie locking on to the road/trail etc when
>navigating though the GPS traces seem tighter.

That was a feature, not a bug. The problem was that the FCC demanded
that for E911 emergency service, the accuracy of a GPS location had to
be far better than what was available at the time. Basically, they
wanted to know which land of the street the caller was located. If in
a building, they wanted to know the floor number. Most cellular
service providers failed miserably and had to resort to marginal
tricks. One of these was to deliver a position to the PSAP (public
safety answering point) that was rounded off to the location of the
nearest road. The logic was that since about 80% of the 911 emergency
calls were from vehicles, which presumably were on a road, assuming
that the call was coming from a location on a road was tolerable.
Never mind people calling from wilderness location and areas away from
roads.

After a few screwups, the PSAP's quietly asked the cellular vendors
involved (mostly AT&T) to disarm this feature. The other vendors were
more into improving the accuracy of the GPS system and ran into a
different problem. The road maps were horribly inaccurate. They were
good enough for driving from point A to point B, but not good enough
for GPS location. Besides the ongoing confusion between different
datums, different agencies used different mapping methods, resulting
in different map errors. For example, 911 service used the telephone
company property maps, which were not very well maintained. I was
marginally involved in trying to reconcile map errors in Santa Cruz
county. I could overlay various maps on top of each other and find
wide variations between maps. Of course, none of the map "owners"
wanted to fix their maps and insisted that their maps were perfect.

At this time, most of the major errors have been fixed, but the
millions of minor discrepancies remain. LIDAR mapping and satellite
imaging has done wonders for fixing the maps. However, it will
probably be a few more years before you're able to look through the
viewfinder of a phone, eyeglasses, binoculars or computer and obtain
an accurate map overlay using augmented reality.
<https://www.google.com/search?q=augmented+reality&tbm=isch>

Programs, such as Strava, improve things so that they appear better on
a map. Instead of a series of jagged "connect the dots" lines, these
programs smooth the track so that it looks like a very accurate and
smooth line. I don't believe that they snap the track to the nearest
road because there are so many runners, hikers, swimmers and cyclists
that do not follow the roads. Unless you were using a smartphone GPS
for generating your riding track, you shouldn't have seen it snap to
the nearest road.

Accurate elevation is a different horror story. In general, the sports
GPS computers use the map elevation (via Garmin Connect) or calibrated
barometric pressure. GPS elevation data is horribly inaccurate.
"How Are Elevation Readings Calculated for My Activity in Garmin
Connect?"
<https://support.garmin.com/en-US/?faq=dRY70Lc6yv2oY3eam1ZWxA>
"Barometric Altimeter Accuracy of Outdoor Products"
<https://support.garmin.com/en-US/?faq=WlvNrOungC28xGtwB7hLY5>
However, Garmin will record GPS elevation data if the GPS receiver
provides it.

--
Jeff Liebermann jeffl@cruzio.com
PO Box 272 http://www.LearnByDestroying.com
Ben Lomond CA 95005-0272
Skype: JeffLiebermann AE6KS 831-336-2558

On Fri, 23 Sep 2022 14:16:58 -0700 (PDT), "funkma...@hotmail.com"
<funkmasterxx@hotmail.com> wrote:

>On Friday, September 23, 2022 at 4:54:56 PM UTC-4, jeff.li...@gmail.com wrote:
>> On Fri, 23 Sep 2022 11:18:14 -0700 (PDT), "funkma...@hotmail.com"
>> <funkma...@hotmail.com> wrote:
>>
>> >On Friday, September 23, 2022 at 12:50:16 AM UTC-4, jeff.li...@gmail.com wrote:
>> >> Also, if you search the document for "Doppler", you'll find that speed
>> >> measurement is heavily tied to Doppler shift measurement.
>> >Doppler radar is precisely how every law enforcement radar speed "monitoring" system works. (now watch Jeff prove me wrong again).
>> Yep. There are other systems (monopulse, phased array, CW, etc) that
>> will provide other useful information besides speed, such as which
>> freeway lane the speeding car is in. Mobile speed guns are mostly IR
>> laser:
>> <https://kustomsignals.com/handheld-lidar/prolaser-4>
>> while fixed installations (automatic speed traps) use RF.
>>
>> Incidentally, I have two really ancient 24GHz Kustom Road Runner radar
>> guns. Plenty fun measuring the speed of passing cyclists and
>> calibrating my car speedometer.
>> <https://photos.app.goo.gl/92mdDZmTuCQUPEpK9>

>Right, I got a radar detector as a present a few years ago that has a Lidar detector as well. I really can't use it in my area becasue there are so many other sources that set off the radar section. When I did have it in the car I don't think the lidar warning ever went off, but I had to keep it turned off most of the time since my commute at the time took me through a long section of strip malls with automatic door openers to the stores. You'd think the FCC would have set aside a different band for that.

Umm... LIDAR is radar using light instead of RF (radio frequencies).
There's nothing in a strip mall that will trigger LIDAR. However, the
10.525GHz and 24GHz supermarket Doppler motion detectors will trigger
radar detectors.

A LIDAR speed gun can produce a reading in 0.3 seconds. See data
sheet at:
<https://kustomsignals.com/handheld-lidar/prolaser-4>
In the time your radar detector needs to detect the LIDAR light, the
speed trap already has your speed and photo, and you don't have any
time to slow down.

As for a dedicated frequency for different services, there's not
enough spectrum available to do that. The FCC no longer makes
decisions based on technical merit or need. The ongoing debacle about
LightSquared/Ligado interfering with GPS is a good example of
frequency allocation based on politics instead of technology.
<https://spacenews.com/report-ligados-wireless-network-will-interfere-with-iridium-and-some-gps-services/>
I can provide about 5 other past examples of politics over-riding
technology if you want.

--
Jeff Liebermann jeffl@cruzio.com
PO Box 272 http://www.LearnByDestroying.com
Ben Lomond CA 95005-0272
Skype: JeffLiebermann AE6KS 831-336-2558

On Sat, 24 Sep 2022 07:36:17 -0700 (PDT), "funkma...@hotmail.com"
<funkmasterxx@hotmail.com> wrote:

>On Friday, September 23, 2022 at 5:43:04 PM UTC-4, jeff.li...@gmail.com wrote:

>Ah, so I'm _not_ losing my mind....

A plea of insanity should not be so easily discounted.

>It's all coming back to me now! The BMLA (Burst Mode Link analyzer) had three different RF busts in the time slot. The first burst was a fixed frequency at the center of the channel BW. The second burst swept from the center fr to the upper bw limit of the channel, then the third swept from the center fr to the lower bw limit of the channel. The sweep modulation was really fixed frequency shifts that were held for a time and all three bursts were QPSK modulated. I don't remember the number or duration of the fr steps, but the phase of each step was quadrature shifted once.

What that seems to be doing is simulating a spread spectrum signal
using PN (pseudo noise) FM modulation. The advantage is that the FM
modulation sweeps have a flat frequency response within the channel
bandwidth, while DSSS (direct sequence spread spectrum) produced a
lumpy sin(x)/x style amplitude spectrum. One can't do equalization
with such a lumpy spectra.

>> Methinks that's roughly how digital cable TV works. Fill the channel
>> with spread spectrum (noise) at a level just below the maximum channel
>> power handling capability. Then, tweak the channel tilt, shape and
>> group delay everything looks nice. The mux can be temporarily set to
>> provide a time slot where there's no interfering traffic.
>
>I'm not sure you can tweak group delay if you don't know
>the phase characteristics at the source, so it would seem
>to me a spread spectrum signal would have to be a lot more
>coherent than to qualify as noise.

It can be done with an all pass filter. Gain is 1 at all frequencies,
but the phase shift (group delay) is adjustable.

>A COFDM "test" signal might work,

Dunno. I have no experience with COFDM. It's a good way to do
digital television, but I don't know how it's used in telecom.

>and you also work in Bit Error
>Rate Testing (BERT is part of BITE!).

After the modulation schemes started providing more bits per baud, BER
(bit error rate) began to be replaced by PER (packet error rate). That
was about the time I started questioning my sanity.

>I do remember a big problem compensating for gaussian noise
>during the development of the BMLA, but the details on that
>are sketchy to me now other than remembering the senior development
>team threw a party at work when they finally got the software
>filtering algorithm right. I wasn't involved on the project
>on that level.

The problem with equalizing filters, phase shifters, and analog
circuitry in general is that they often introduce additional noise at
every step in the process. My guess(tm) is that was what they were
fighting. Add an adjustment which would add some more noise.

>Thinking back on it they had to do an analysis of RHCP vs
>LHCP. I seem to remember it wasn't much of an issue, but there
>was someone in the organization that thought it might be.
>This system was actually just the IF, not the RF (the channel
>bw center fr was 140 MHz, but that was the IF band in the
>system), so that had a lot to do with it. I seem to remember
>the head of the analog hardware team getting frustrated
>and saying something like 'the polarity of the satellite
>frequency is transparent to the function of this product'
>....or something like that. Does that make sense to you?
>I could be misremembering something.

Yes and I'm familiar with the problem. At the time, the current
fashion in satellite distribution of programming material was C-band
using vertical or horizontal linear polarization. Switching between
satellites across the ecliptic caused some problems maintaining
polarization. If the unwanted polarization was even a few degrees
off, there would be interference.

That was "solved" by switching to circular polarization as in RH
(right hand) and LH (left hand) circular polarization. Instead of
having to have the polarization be perfectly orthogonal to maintain
isolation, RHCP and LHCP were inherently isolated my many more dB than
was possible with linear polarization. In addition, the interleaved
the channel frequencies between RHCP and LHCP, thus giving some
additional isolation.

The head of the analog team was correct. Once the signal were
separated between LH and RH channels at the dish feed, there should be
no further interaction. Reality is quite different. There were
plenty of dumb things a system designer could do that would recombine
the LR and RH signals, resulting in mutual interference. RF
multiplexing the channels at the IF frequency was a good way to create
IMD (intermodulation) products. That required that the system had to
be linear and free of distortion all the way to the video detectors.
IMD distortion testing and mitigation was a big part of the design. Of
course, test equipment had to be better than the equipment it was
suppose to test, so the test equipment designers really had a
difficult time.

>Exactly. The ability to keep the link functioning and monitor-tweak
>in real time means more revenue.

Slight diversion in link reliability:
<http://www.learnbydestroying.com/jeffl/antennas/dish-move-project/index.html>
<http://www.learnbydestroying.com/jeffl/antennas/dish-move-03/index.html>
<http://www.learnbydestroying.com/jeffl/antennas/dish-new-install-project/index.html>
The backup dish:
<http://www.learnbydestroying.com/jeffl/antennas/Dish-wood/index.html>

>It doesn't matter, it's just nice to have a conversation here
>where certain trolls aren't defecating.

Agreed. It's a pleasant change. However, I suspect we're putting the
cyclists to sleep. Hmmm... midnight. Time to put myself to sleep.

--
Jeff Liebermann jeffl@cruzio.com
PO Box 272 http://www.LearnByDestroying.com
Ben Lomond CA 95005-0272
Skype: JeffLiebermann AE6KS 831-336-2558

Jeff Liebermann <jeffl@cruzio.com> wrote:
> On Fri, 23 Sep 2022 15:41:07 -0000 (UTC), Roger Merriman
> <roger@sarlet.com> wrote:
>
>> Jeff Liebermann <jeffl@cruzio.com> wrote:
>>> In other words, some GPS receivers (or firmware) are junk.
>
>> That certainly has been my experience each time I bought a new phone (use
>> sat nav app) or less frequently GPS computer seems to be more accurate, I
>> certainly remember older units getting very confused as to which road/trail
>> I was on thinking I was on a parallel road or so on.
>
> Non-smartphones, dumb phones or feature phones handle GPS very
> differently than Smartphones. In a smartphone, the GPS chipset
> produces the location, speed, altitude, etc directly to the CPU, which
> then displays it on a map or a screen full of numbers. In a dumb
> phone, the satellite delays are sent to an internet service provider,
> which calculates the location, speed, altitude, etc and sends the
> results back to the dumb phone. That saves battery power and
> eliminates the cost of a processor, but only works if you want a fixed
> location, not a track displayed on a map.
>
> Meanwhile, there were big improvements in GPS receiver design, which
> improved sensitivity, accuracy, battery life, cold start, etc. The
> big improvement was high-sensitivity GPS in about 2009.
> <https://www.furuno.com/en/gnss/technical/tec_high>
> Prior to this, most GPS receivers had problems in highly reflective
> environments (urban canyons) and in weak signal areas (forests). With
> high-sensitivity GPS, it was possible to obtain usable signals in
> areas where GPS was previously useless.
>
> There are a bunch of other improvements, such as additional
> constellations (GLONASS, Galileo, DBS, etc), better augmentation (WAAS
> via Inmarsat), additional signals (L5, L1C) and better post processing
> in the phones. I can explain these and others but not right now.
>
>> Clearly some could be software ie locking on to the road/trail etc when
>> navigating though the GPS traces seem tighter.
>
> That was a feature, not a bug. The problem was that the FCC demanded
> that for E911 emergency service, the accuracy of a GPS location had to
> be far better than what was available at the time. Basically, they
> wanted to know which land of the street the caller was located. If in
> a building, they wanted to know the floor number. Most cellular
> service providers failed miserably and had to resort to marginal
> tricks. One of these was to deliver a position to the PSAP (public
> safety answering point) that was rounded off to the location of the
> nearest road. The logic was that since about 80% of the 911 emergency
> calls were from vehicles, which presumably were on a road, assuming
> that the call was coming from a location on a road was tolerable.
> Never mind people calling from wilderness location and areas away from
> roads.

My Garmin and Tom’s you can toggle under navigation has various profiles
one can set up I unsurprisingly have Gravel and MTB profiles and there is a
toggle for lock to road though that is more a navigating function than gps
accuracy as such.
>
> After a few screwups, the PSAP's quietly asked the cellular vendors
> involved (mostly AT&T) to disarm this feature. The other vendors were
> more into improving the accuracy of the GPS system and ran into a
> different problem. The road maps were horribly inaccurate. They were
> good enough for driving from point A to point B, but not good enough
> for GPS location. Besides the ongoing confusion between different
> datums, different agencies used different mapping methods, resulting
> in different map errors. For example, 911 service used the telephone
> company property maps, which were not very well maintained. I was
> marginally involved in trying to reconcile map errors in Santa Cruz
> county. I could overlay various maps on top of each other and find
> wide variations between maps. Of course, none of the map "owners"
> wanted to fix their maps and insisted that their maps were perfect.
>
> At this time, most of the major errors have been fixed, but the
> millions of minor discrepancies remain. LIDAR mapping and satellite
> imaging has done wonders for fixing the maps. However, it will
> probably be a few more years before you're able to look through the
> viewfinder of a phone, eyeglasses, binoculars or computer and obtain
> an accurate map overlay using augmented reality.
> <https://www.google.com/search?q=augmented+reality&tbm=isch>
>
> Programs, such as Strava, improve things so that they appear better on
> a map. Instead of a series of jagged "connect the dots" lines, these
> programs smooth the track so that it looks like a very accurate and
> smooth line. I don't believe that they snap the track to the nearest
> road because there are so many runners, hikers, swimmers and cyclists
> that do not follow the roads. Unless you were using a smartphone GPS
> for generating your riding track, you shouldn't have seen it snap to
> the nearest road.
>
> Accurate elevation is a different horror story. In general, the sports
> GPS computers use the map elevation (via Garmin Connect) or calibrated
> barometric pressure. GPS elevation data is horribly inaccurate.
> "How Are Elevation Readings Calculated for My Activity in Garmin
> Connect?"
> <https://support.garmin.com/en-US/?faq=dRY70Lc6yv2oY3eam1ZWxA>
> "Barometric Altimeter Accuracy of Outdoor Products"
> <https://support.garmin.com/en-US/?faq=WlvNrOungC28xGtwB7hLY5>
> However, Garmin will record GPS elevation data if the GPS receiver
> provides it.
>
>
I have to say the elevation is one of those for my uses close enough, in
that it’s broadly in line with known heights of hills do remember vaguely
some ride with some storm fronts where it dropped massively and
unbelievably!

But generally it’s close enough for my purposes.
>
>
Roger Merriman

On 9/27/2022 7:05 AM, Roger Merriman wrote:
>
>>
> I have to say the elevation is one of those for my uses close enough, in
> that it’s broadly in line with known heights of hills do remember vaguely
> some ride with some storm fronts where it dropped massively and
> unbelievably!
>
> But generally it’s close enough for my purposes.

I must say, I'm curious about "purposes."

I admit to being generally interested in data. For example, I was rather
obsessive about keeping cars' gas mileage data. But I seldom did
anything with the data, other than confirming (in the old, old days)
that a car needed a tuneup.

I was once given a nice sports watch with an altimeter. I glanced at it
from time to time, especially when traveling over mountains. But I
certainly never made any use of the numbers.

What do you do with your altitude data?

--
- Frank Krygowski