Results not matching with AGI STK

[akraj31]

Maybe there is some understanding issue because of which I am not able to generate correct results. Please help me regarding this.

I have compared the results with AGI STK Desktop application. AGI STK Help Page says

By default, STK utilizes the CSSI SGP4 routine, Version 2008-11-03.

Following is the full description of my usage:

TLE Data:

1 20959U 90103A   14044.72615235  .00000027  00000-0  00000+0 0  2724 
2 20959  54.3261 214.0472 0115346 348.3774  11.3322  2.00583365170051

ECI Data generated from AGI STK software:

Time (UTCG)                    x (km)            y (km)       z (km) 
28 Jul 2017 02:55:06.000    -6749.036399    -14064.485321    21282.805742
28 Jul 2017 02:55:07.000    -6745.397433    -14065.853241    21283.102965
28 Jul 2017 02:55:08.000    -6741.758320    -14067.220855    21283.399727
28 Jul 2017 02:55:09.000    -6738.119061    -14068.588164    21283.696028
28 Jul 2017 02:55:10.000    -6734.479656    -14069.955168    21283.991866
28 Jul 2017 02:55:11.000    -6730.840105    -14071.321867    21284.287243
28 Jul 2017 02:55:12.000    -6727.200408    -14072.688260    21284.582158
28 Jul 2017 02:55:13.000    -6723.560565    -14074.054349    21284.876612
28 Jul 2017 02:55:14.000    -6719.920576    -14075.420132    21285.170603
28 Jul 2017 02:55:15.000    -6716.280441    -14076.785610    21285.464134

My Code( using sgp4.js):

updateEntityToCurrentSimTime: function (time) {
        var date = new Date( "07/28/2017 08:25:05");
        var tleLines = ["1 20959U 90103A   14044.72615235  .00000027  00000-0  00000+0 0  2724",
                        "2 20959  54.3261 214.0472 0115346 348.3774  11.3322  2.00583365170051"];
                         
        var satrec = satellite.twoline2rv(tleLines[0], tleLines[1], SGP4.wgs84());         

        //update current date
        date.setSeconds(date.getSeconds() + time);            
                        
        var posAndVelECI = SGP4.propogate(satrec, 
                date.getUTCFullYear(),
                date.getUTCMonth() + 1,
                date.getUTCDate(),
                date.getUTCHours(),
                date.getUTCMinutes(),
                date.getUTCSeconds());
}

ECI data from my code(using node-SGP4):

28 Jul 2017 02:55:06 GMT 0    -6729.5866812930935    -14090.192704493445    21271.96936623743
28 Jul 2017 02:55:07 GMT 0    -6725.942904316203    -14091.546319840401    21272.272757457344
28 Jul 2017 02:55:08 GMT 0    -6722.298834777502    -14092.899684035756    21272.57569941536
28 Jul 2017 02:55:09 GMT 0    -6718.654766124882    -14094.252688097997    21272.87816771835
28 Jul 2017 02:55:10 GMT 0    -6715.010551711341    -14095.605386498912    21273.180174569126
28 Jul 2017 02:55:11 GMT 0    -6711.366191662035    -14096.9577791936    21273.481719959367
28 Jul 2017 02:55:12 GMT 0    -6707.721686056604    -14098.309866154083    21273.782803884547
28 Jul 2017 02:55:13 GMT 0    -6704.077034974807    -14099.661647352345    21274.083426340152
28 Jul 2017 02:55:14 GMT 0    -6700.432238496194    -14101.013122760449    21274.38358732169
28 Jul 2017 02:55:15 GMT 0    -6696.787150063399    -14102.36434670113    21274.683298872133

[joshuaferrara]

I'll try and take a look into this over the weekend. The results are quite close, meaning it's probably either a rounding error or some other small, hard to find issue. Will need to compare the results of node-sgp4 step by step to that of the original library and see where it goes haywire. Thanks for bringing this up!

[joshuaferrara]

I've ran some tests against another sgp4 Javascript library and have found the results to be similar within 11 decimal places. Both of these libraries are based off of "Revisiting Spacetrack Report #3" (more info here).

That being said, I am still interested in verifying the library against the C implementation found on the page linked above, and will provide updates here when I've determined the results.

[joshuaferrara]

Just spun up STK 11, and I'm getting much closer results than you were:

       Time (UTCG)             x (km)           y (km)          z (km)       vx (km/sec)    vy (km/sec)    vz (km/sec)
------------------------    ------------    -------------    ------------    -----------    -----------    -----------
28 Jul 2017 02:55:06.000    -6722.945053    -14092.617044    21272.547248       3.643982      -1.353283       0.302741
28 Jul 2017 02:55:07.000    -6719.301008    -14093.970175    21272.849754       3.644128      -1.352977       0.302280
28 Jul 2017 02:55:08.000    -6715.656818    -14095.323000    21273.151799       3.644273      -1.352671       0.301818
28 Jul 2017 02:55:09.000    -6712.012482    -14096.675519    21273.453382       3.644419      -1.352366       0.301357
28 Jul 2017 02:55:10.000    -6708.368000    -14098.027733    21273.754503       3.644564      -1.352060       0.300895
28 Jul 2017 02:55:11.000    -6704.723373    -14099.379641    21274.055163       3.644710      -1.351754       0.300434
28 Jul 2017 02:55:12.000    -6701.078601    -14100.731243    21274.355362       3.644855      -1.351448       0.299972
28 Jul 2017 02:55:13.000    -6697.433683    -14102.082539    21274.655099       3.645000      -1.351142       0.299511
28 Jul 2017 02:55:14.000    -6693.788620    -14103.433530    21274.954374       3.645146      -1.350837       0.299049
28 Jul 2017 02:55:15.000    -6690.143411    -14104.784214    21275.253188       3.645291      -1.350531       0.298588

[akraj31]

But deviation is in kilometres, and its substantial

STK Result:

28 Jul 2017 02:55:06.000    -6749.036399    -14064.485321    21282.805742
28 Jul 2017 02:55:07.000    -6745.397433    -14065.853241    21283.102965

Your Output:

28 Jul 2017 02:55:06.000    -6722.945053    -14092.617044    21272.547248
28 Jul 2017 02:55:07.000    -6719.301008    -14093.970175    21272.849754

[joshuaferrara]

I agree that it's quite a large deviation, though I am unable to verify it against anything other than the code provided in AIAA-2006-6753.zip and the results from STK that I was able to obtain. That being said, I have verified the results with the linked version of the library (C++) and the results (with slight deviation from that of node-sgp4) can be seen below. Here's a link to run the code I generated these results with: https://repl.it/MrjE/1

--- SGP4 Test Application ---
Initialized satellite record with NORAD catalog ID: 20959
Start mfe = 1.81497e+06 - Stop mfe = 1.81497e+06
2017 7 28 2:55:6	-6729.5866813	-14090.1927045	21271.9693662
2017 7 28 2:55:7	-6725.9428845	-14091.5463272	21272.2727591
2017 7 28 2:55:8	-6722.2989419	-14092.8996443	21272.5756905
2017 7 28 2:55:9	-6718.6548535	-14094.2526557	21272.8781605
2017 7 28 2:55:10	-6715.0106193	-14095.6053614	21273.1801690
2017 7 28 2:55:11	-6711.3662395	-14096.9577614	21273.4817160
2017 7 28 2:55:12	-6707.7217141	-14098.3098557	21273.7828016
2017 7 28 2:55:13	-6704.0770433	-14099.6616443	21274.0834257
2017 7 28 2:55:14	-6700.4322271	-14101.0131270	21274.3835883
2017 7 28 2:55:15	-6696.7872656	-14102.3643039	21274.6832894

node-sgp4 is made to replicate the library linked above, and as it is replicating those results, this does not seem to be an issue with node-sgp4.

My only other thought is that STK is using something other than WGS84 for the propagation constants. If anyone has any further information, I would love to hear it.