
This folder contains a local data set that was used during
the development of NavSat Tracker.

It was designed so that while I am fine-tuning the user interface and
doing debugging, there was no need to abuse the data provider by 
hitting its webserver API hundreds of times a day.

Since the response basically polled all satellites in orbit the data is
good if you want to test views from different coordinates to check if 
the correct satellites are within view. If the bird is in orbit, you
should be able to get it somewhere.

You can change the content of this file to anything as long as it fits
the format of the JSON response.

The file name needs to stay the same "sresp.txt"

Some additional files are included related to Vallado's "Revisiting 
Spacetrack Report #3, AIAA 2006-6753" namely some test files to
exercise the SGP4.

This folder also has test file used to exercise SPG4V.incl (SGP4-VER.TLE),
straight from Vallado Apendix D. Next the expected output (tcppver.out)
from Vallado Apendix E.

A note on our test:

All satellites pass with accuracy < 0.85 m to < 0.55 m avg.
If you use a Sextant to look at these objects, the error deviation is
less than 0.02 degrees. Visually, you can't tell the difference.

Several satellites were designed by Vallado to be problematic and were intentional. 

Vallado's `tcppver.out` was generated with `opsmode='a'` (AFSPC/legacy). 
The FB port runs `opsmode='i'` (improved) for all `U`-classified satellites — 
which is the **correct default** for operational use. The errors here are not bugs; 
they are the expected difference between the two modes and are the very thing these 
test cases were designed to illustrate.

For a strict bit-for-bit match against `tcppver.out`, temporarily set 
gSatV.opsMode = _sgp4_opsAFSPC` for these specific test cases — but don't do  
it for operational NavSat use.

Some satellites are explicitly labelled *"check error code 4"* in VER.TLE. 
They have extreme eccentricities (0.995, 0.9950000) designed to trigger the 
edge cases error. The FB engine correctly raises errorCode=4 at t=25 min 
(23333) and t=20 min (33333), after which propagation stops. 
(Vallado's reference engine handles this differently in the "verify" driver).

R.W, 6/11/26