GPS Control Software Update Shows Glitch
http://www.gpsworld.com/gnss-system/...h-9414?print=1
January 21, 2010

The GPS AEP Command and Control operational software update previously
reported enables new capabilities for the warfighter. The new
capabilities are not something we can discuss in this venue. They are
considerable, but require absolute compliance with the published GPS
Interface Control Document (ICD). Some of the new features that are
incorporated only work with authorized military receivers that have
successfully passed security tests. However the live introduction of the
new functions is causing problems wherein some of these receivers are
intermittently not tracking Y-code, and non-compliant civilian receivers
are also reporting continuing problems.

Corrective action could encompass either the Air Force rolling back the
update or revising its software, or the manufacturers modifying GPS
software within the receivers to be totally compliant with the ICD.

In November and December 2009, the new software uploaded operational GPS
IIA and IIR space vehicles with navigation data and completed normal
operational functions. The software is part of the GPS modernization
effort, with its principal features being telemetry, tracking, and
commanding for the new GPS IIF space vehicle — as yet unlaunched -- and
more robust security for the military M-code signal.

GPS Interface Control Document (ICD)
http://www.navcen.uscg.gov/pubs/gps/icd200/

On Jan 23, 12:00*pm, Sam Wormley wrote:
GPS Control Software Update Shows Glitchhttp://www.gpsworld.com/gnss-system/news/gps-control-software-update-...
January 21, 2010

The GPS AEP Command and Control operational software update previously
reported enables new capabilities for the warfighter. The new
capabilities are not something we can discuss in this venue. They are
considerable, but require absolute compliance with the published GPS
Interface Control Document (ICD). Some of the new features that are
incorporated only work with authorized military receivers that have
successfully passed security tests. However the live introduction of the
new functions is causing problems wherein some of these receivers are
intermittently not tracking Y-code, and non-compliant civilian receivers
are also reporting continuing problems.

Corrective action could encompass either the Air Force rolling back the
update or revising its software, or the manufacturers modifying GPS
software within the receivers to be totally compliant with the ICD.

In November and December 2009, the new software uploaded operational GPS
IIA and IIR space vehicles with navigation data and completed normal
operational functions. The software is part of the GPS modernization
effort, with its principal features being telemetry, tracking, and
commanding for the new GPS IIF space vehicle — as yet unlaunched -- and
more robust security for the military M-code signal.

IBM had this problem in spades with System/360. Some operation would
have an undocumented side-effect of setting some memory location to
zero. Programmers would notice it and then write code that depended
on this side effect. Of course, there was nothing in the IBM System/
360 Principles of Operation (i.e. the "ICD") that would guarantee it.
A new version of the operating system would be released and the code
for that operation would change and no longer exhibit the side effect
of setting that memory location to zero. Customer programs crash and
the screams could be heard all the way in Armonk. The amount of
testing that IBM would have to do on a new OS release was simply
enormous.

I am sure that some legacy GPS receivers were built to depend on some
side effect that the latest AEP software (Version 2?) no longer
exhibits. We should all welcome Boeing to the world of legacy
software maintenance. Boeing should figure out which field the legacy
receivers are counting on and change the uploads to set the
"undefined" field (or fields if they are really unlucky) to their
previously undefined values.

--Mike Jr.

Sam Wormley wrote:
[...]
However the live introduction of the
new functions is causing problems wherein some of these receivers are
intermittently not tracking Y-code, and non-compliant civilian receivers
are also reporting continuing problems.

Sounds like some manufacturers didn't pay proper attention to the spec and
relied on something they should not have. Perhaps parts of the spec that
were unused until now were not implemented, or perhaps as Mike drew by
analogy the receiver relied on a part of the signal that was omnipresent but
not part of the spec.


Corrective action could encompass either the Air Force rolling back the
update or revising its software, or the manufacturers modifying GPS
software within the receivers to be totally compliant with the ICD.

In November and December 2009, the new software uploaded operational GPS
IIA and IIR space vehicles with navigation data and completed normal
operational functions. The software is part of the GPS modernization
effort, with its principal features being telemetry, tracking, and
commanding for the new GPS IIF space vehicle ? as yet unlaunched -- and
more robust security for the military M-code signal.

GPS only gives you position. Kinda narrows what the satellites can do unless
they go multi-purpose. I wonder what kind of position accuracy was expected
with the uprades.

On 1/23/10 2:56 PM, eric gisse wrote:
Sam Wormley wrote:
[...]
However the live introduction of the
new functions is causing problems wherein some of these receivers are
intermittently not tracking Y-code, and non-compliant civilian receivers
are also reporting continuing problems.

Sounds like some manufacturers didn't pay proper attention to the spec and
relied on something they should not have. Perhaps parts of the spec that
were unused until now were not implemented, or perhaps as Mike drew by
analogy the receiver relied on a part of the signal that was omnipresent but
not part of the spec.


Corrective action could encompass either the Air Force rolling back the
update or revising its software, or the manufacturers modifying GPS
software within the receivers to be totally compliant with the ICD.

In November and December 2009, the new software uploaded operational GPS
IIA and IIR space vehicles with navigation data and completed normal
operational functions. The software is part of the GPS modernization
effort, with its principal features being telemetry, tracking, and
commanding for the new GPS IIF space vehicle ? as yet unlaunched -- and
more robust security for the military M-code signal.

GPS only gives you position. Kinda narrows what the satellites can do unless
they go multi-purpose. I wonder what kind of position accuracy was expected
with the uprades.



Actually one get PVT (Position, Velocity and Time) from the
receivers. Dual frequency P(Y) Code receivers, with out augmentation,
such as WAAS, or other DGPS have positional accuracies of about
one meter, velocities better than 0.1 m/s and time accuracies of
a few nanoseconds.

For nonmilitary single frequency receivers:

Keep in mind that most GPS receivers employ "smoothing filters" and so
instantaneous velocity reading during acceleration is not necessarily
accurate. However at constant velocity (and assuming no obstruction of
signals), the GPS receiver will likely measure velocity to an accuracy
of 0.2 m/s (0.7 kph or 0.4 mph) 2drms.

Ref: Misra & Enge "GPS: Signals, Measurements, and Performance" (2001)

Sec. 5.2.1 (pgs 196-197) Velocity Estimation

"The relative motion of a satellite and the user results in changes in
the observed frequency of the satellite signal. This Doppler shift is
measured routinely in the carrier tracking loop of a GPS receiver
[Section 9.6]. Given the satellite velocity, the Doppler shift can be
used to estimate the user velocity. The Doppler shift, or equivalently,
the range rate [Section 1.3.3], can be written as a projection of the
relative velocity vector on the satellite line-of-sight vector. The
measurement, however, is biased by the receiver clock bias rate (i.e.,
frequency offset), and what's actually measured is the pseudorange
rate.

"The delta pseudoranges obtained from carrier phase measurements are
proportional to the average pseudorange rates or the line-of-sight
velocity of the user relative to the satellite over the time interval.
The model for pseudorange rates can be obtained by differentiating
(5.1). It is left as an exercise to show that

[equation 5.28 is true]

where v_sup(k) [a vector quantity] is the satellite velocity vector,
known from the navigational message broadcast by the satellite; v is
the user velocity vector, to be estimated. Both v_sup(k) and v are
expressed in the ECEF coordinate frame. The user-to-satellite unit
vector 1_sup(k) is determined from an estimate of the user position;
b_dot is the bias of the receiver clock (m/s), and the
epsilon_sub_phi_sup(k) denotes the combined error doe to changes during
the measurement interval in the satellite clock, ionosphere and
troposphere. Note that the velocity of an object attached to the earth
is zero in the ECEF coordinate frame.

"The principal source of error in (5.28) throughout the 1990s was the
satellite clock frequency dithering due to SA. Now with SA gone, the
remaining errors arise from changes in the ionospheric and tropospheric
delays and in multipath, and are generally small. Problems, however,
can arise if the user dynamics are excessive. The delta ranges give
only average velocity over a time interval. High accelerations and
jerks would clearly be problematic. The PPS performance specifications
for velocity estimation (0.1 m/s rms in any direction; 0.2 m/s 2drms)
are based on a constant-velocity scenario [JPO(1991)].

"Equation (5.28) is linear in user velocity components, and can be
rewritten...

the combined set of measurements from K satellites can be written as a
set of equations compactly in matrix notation as

[equation 5.29]

where matrix G characterizes the user-satellite geometry, as defined
previously (5.10). It is interesting that the problem of estimation of
user velocity based on pseudorange rates is identical in structure to
that of estimation of user position from pseudoranges (5.9). A
least-squares solution and the DOP parameters can be defined, as
before, and related to the rms error in these estimates".

Mike Jr wrote:
On Jan 23, 12:00 pm, Sam Wormley wrote:
GPS Control Software Update Shows Glitchhttp://www.gpsworld.com/gnss-system/news/gps-control-software-update-...
January 21, 2010

The GPS AEP Command and Control operational software update previously
reported enables new capabilities for the warfighter. The new
capabilities are not something we can discuss in this venue. They are
considerable, but require absolute compliance with the published GPS
Interface Control Document (ICD). Some of the new features that are
incorporated only work with authorized military receivers that have
successfully passed security tests. However the live introduction of the
new functions is causing problems wherein some of these receivers are
intermittently not tracking Y-code, and non-compliant civilian receivers
are also reporting continuing problems.

Corrective action could encompass either the Air Force rolling back the
update or revising its software, or the manufacturers modifying GPS
software within the receivers to be totally compliant with the ICD.

In November and December 2009, the new software uploaded operational GPS
IIA and IIR space vehicles with navigation data and completed normal
operational functions. The software is part of the GPS modernization
effort, with its principal features being telemetry, tracking, and
commanding for the new GPS IIF space vehicle — as yet unlaunched -- and
more robust security for the military M-code signal.

IBM had this problem in spades with System/360. Some operation would
have an undocumented side-effect of setting some memory location to
zero. Programmers would notice it and then write code that depended
on this side effect. Of course, there was nothing in the IBM System/
360 Principles of Operation (i.e. the "ICD") that would guarantee it.
A new version of the operating system would be released and the code
for that operation would change and no longer exhibit the side effect
of setting that memory location to zero. Customer programs crash and
the screams could be heard all the way in Armonk. The amount of
testing that IBM would have to do on a new OS release was simply
enormous.

I am sure that some legacy GPS receivers were built to depend on some
side effect that the latest AEP software (Version 2?) no longer
exhibits. We should all welcome Boeing to the world of legacy
software maintenance. Boeing should figure out which field the legacy
receivers are counting on and change the uploads to set the
"undefined" field (or fields if they are really unlucky) to their
previously undefined values.


this was common. We got around a lot of it by defining a range
of values reserved for customers in all aspects of computing.
We (DEC) promised to never use those values and also promised to
use the values that were reserved for DEC. Seemed to work well.

Side effects, as you describe above, is another story. We picked
field test sites who had previously demonstrated that they
exercised the code and aspects as much as possible.

/BAH

On Sat, 23 Jan 2010 09:38:14 -0800 (PST), Mike Jr
wrote:

IBM had this problem in spades with System/360. Some operation would
have an undocumented side-effect of setting some memory location to
zero. Programmers would notice it and then write code that depended
on this side effect. Of course, there was nothing in the IBM System/
360 Principles of Operation (i.e. the "ICD") that would guarantee it.
A new version of the operating system would be released and the code
for that operation would change and no longer exhibit the side effect
of setting that memory location to zero.

Early S/360 Fortran compilers (nothing to do with Principles Of
Operation, a hardware manual, or the OS) would create code that would
do this under certain circumstances. If a complicated formula
generated code that required the use of more than the available 4
floating-point hardware registers, the machine code would store the
4th register, use it for temporary results, then zero it in
preparation to reload the previous temp result, but "forget" to reload
the saved value in the register before continuing the operation.

Whoever coded the compiler left the reload instruction out of the
resulting code, and it took such a long, complicated formula written
all in a single statement to cause the error that it rarely happened.

I was doing actuarial calcs for a life insurance company at the time,
and tracked down the problem - it took me a couple of days because I
was not an assembler programmer at the time and I was working from a
listing of the generated machine code. The formula that caused it was
such that a multiply-by-zero-or-by-one was used to include or exclude
a fairly complex term from the result, which helped to identify the
code error. A multiply by the erroneous zero was the giveaway.

I informed IBM about this obscure bug in their compiler around 1967/8,
but I don't know if they ever took it seriously coming from an
actuarial student at the time.

Happy Trails wrote:
On Sat, 23 Jan 2010 09:38:14 -0800 (PST), Mike Jr
wrote:

IBM had this problem in spades with System/360. Some operation would
have an undocumented side-effect of setting some memory location to
zero. Programmers would notice it and then write code that depended
on this side effect. Of course, there was nothing in the IBM System/
360 Principles of Operation (i.e. the "ICD") that would guarantee it.
A new version of the operating system would be released and the code
for that operation would change and no longer exhibit the side effect
of setting that memory location to zero.

Early S/360 Fortran compilers (nothing to do with Principles Of
Operation, a hardware manual, or the OS) would create code that would
do this under certain circumstances. If a complicated formula
generated code that required the use of more than the available 4
floating-point hardware registers, the machine code would store the
4th register, use it for temporary results, then zero it in
preparation to reload the previous temp result, but "forget" to reload
the saved value in the register before continuing the operation.

Whoever coded the compiler left the reload instruction out of the
resulting code, and it took such a long, complicated formula written
all in a single statement to cause the error that it rarely happened.

I was doing actuarial calcs for a life insurance company at the time,
and tracked down the problem - it took me a couple of days

Only a couple of days!? [awed emoticon here]

because I
was not an assembler programmer at the time and I was working from a
listing of the generated machine code. The formula that caused it was
such that a multiply-by-zero-or-by-one was used to include or exclude
a fairly complex term from the result, which helped to identify the
code error. A multiply by the erroneous zero was the giveaway.

I informed IBM about this obscure bug in their compiler around 1967/8,
but I don't know if they ever took it seriously coming from an
actuarial student at the time.

There have been a few bugs of this flavor on many systems in the
past. I vaguely recall one where the work around was to
split up the calculation statement. I don't remember the platform
nor the language nor the decade when it happened.


/BAH

On Mon, 25 Jan 2010 08:43:54 -0500, jmfbahciv jmfbahciv@aol wrote:

Only a couple of days!? [awed emoticon here]

Yes - I did mention that I knew what I was looking for based on the
actuary's statement, did I not?

There have been a few bugs of this flavor on many systems in the
past. I vaguely recall one where the work around was to
split up the calculation statement. I don't remember the platform
nor the language nor the decade when it happened.

That worked on this one. Splitting it up meant that a temporary result
in a register got stored as permanent before the "requires more than 4
FP registers" limit was hit.

I remember the extra-slick IBM salesman at the time pointing out the
place in the programmer's manual where it stated you were to avoid
using mixed-mode arithmetic (mixing FP and integer operands in the
same expression), so I rewrote it using all FP terms, and it still
screwed up, as I knew it would, hahaha. I don't know why that warning
was there - it handled the conversion between integer, single
precision FP and double precision FP perfectly okay, both coming and
going.

On 10-01-25 8:43 , jmfbahciv wrote:

There have been a few bugs of this flavor on many systems in the
past. I vaguely recall one where the work around was to
split up the calculation statement. I don't remember the platform
nor the language nor the decade when it happened.

That's pretty common debugging in any day and age.

I'd do the same assuming I'd made a mistake in a statement. Once
working correctly, I'd leave well enough alone and move on.
Deadlines.

The other joy was moving FORTRAN from one platform to another and then
validating the code on the new platform ... tedious at best.