# Why does this site show Starman's position so far from what Horizons gives?

As this answer mentions, there have been several questions about the data represented on the whereisroadster site within the Space Exploration Stack Exchange site.

One about wrong distances has been deleted (but is still viewable to higher rep users here), another about roadster standing-still for eleven days in chat, and a third Why does this plot show Starman's speed relative to the Sun fluctuating so often? has been very well received and highly up voted. There are many other Q&A referencing this site here as well.

I thought I'd do a spot check to see how it's doing.

I grabbed the Horizons output for the Roadster object as a target using Heliocentric and Geocentric positions as the origin getting the position and velocity vectors from those origins. 8PM (20:00:00) here in UTC+8 is 12:00:00 UTC which is when Julian Date passes zero (within tens of seconds at least).

I missed the screen shot exactly at the hour, but nailed the one at 20:01:00. I've squished the windows to make them both fit within a 640 pixel width so they show nicely in this SE site without manipulations. time.gov is from NIST and attempts to synchronize over the connection through ping timing.

I refreshed the windows a few minutes before just to make sure things were updated internally.

However, the whereisroadster site gets a significantly different distance between Earth and Roadster than Horizions gives, and this is supposed to be the data engine from which the site derives its data.

Why is it off by so much?

pos_rel_Earth = np.array([-1.064812011604053E+07, -8.608116821810877E+06, -2.355098230429459E+06])

r_rel_Earth = np.sqrt((pos_rel_Earth**2).sum())

print r_rel_Earth

13893474.1839

• That is 13,893,484 km (Horizons)
• versus 13,789,239 km (website)

That's a 1% difference in distance, ~100,000 kilometers

With respect to the Sun:

pos_rel_Sun = np.array([-1.591862416706663E+08, -2.299106450849950E+07, -2.353784956702188E+06])

r_rel_Sun = np.sqrt((pos_rel_Sun**2).sum())

print r_rel_Sun, v_rel_Sun

160855179.861 31.3143577616

• That is 160,855,179 km (Horizons)
• versus 160,696,811 km (website)

That's also an ~100,000 kilometer difference.

## Raw Data:

Ephemeris / WWW_USER Mon Mar 26 11:34:36 2018 Pasadena, USA      / Horizons
*******************************************************************************
Target body name: SpaceX Roadster (spacecraft) (-143205) {source: tesla_s9}
Center body name: Earth (399)                     {source: DE431mx}
Center-site name: BODY CENTER
*******************************************************************************
Start time      : A.D. 2018-Mar-26 12:00:00.0000 TDB
Stop  time      : A.D. 2018-Mar-26 12:01:00.0000 TDB
Step-size       : 1 minutes
*******************************************************************************
Center geodetic : 0.00000000,0.00000000,0.0000000 {E-lon(deg),Lat(deg),Alt(km)}
Center cylindric: 0.00000000,0.00000000,0.0000000 {E-lon(deg),Dxy(km),Dz(km)}
Center radii    : 6378.1 x 6378.1 x 6356.8 km     {Equator, meridian, pole}
Output units    : KM-S
Output type     : GEOMETRIC cartesian states
Output format   : 2 (position and velocity)
Reference frame : ICRF/J2000.0
Coordinate systm: Ecliptic and Mean Equinox of Reference Epoch

$$SOE 2458204.000000000, A.D. 2018-Mar-26 12:00:00.0000, -1.064791354593495E+07, -8.608024506708045E+06, -2.355071522438325E+06, -3.442810011828843E+00, -1.538588913186599E+00, -4.451354722214971E-01, 2458204.000694444, A.D. 2018-Mar-26 12:01:00.0000, -1.064812011604053E+07, -8.608116821810877E+06, -2.355098230429459E+06, -3.442860173393305E+00, -1.538581181359120E+00, -4.451308989758778E-01,$$EOE


Ephemeris / WWW_USER Mon Mar 26 11:55:30 2018 Pasadena, USA      / Horizons
*******************************************************************************
Target body name: SpaceX Roadster (spacecraft) (-143205) {source: tesla_s9}
Center body name: Sun (10)                        {source: DE431mx}
Center-site name: BODY CENTER
*******************************************************************************
Start time      : A.D. 2018-Mar-26 12:00:00.0000 TDB
Stop  time      : A.D. 2018-Mar-26 12:01:00.0000 TDB
Step-size       : 1 minutes
*******************************************************************************
Center geodetic : 0.00000000,0.00000000,0.0000000 {E-lon(deg),Lat(deg),Alt(km)}
Center cylindric: 0.00000000,0.00000000,0.0000000 {E-lon(deg),Dxy(km),Dz(km)}
Center radii    : 696000.0 x 696000.0 x 696000.0 k{Equator, meridian, pole}
Output units    : KM-S
Output type     : GEOMETRIC cartesian states
Output format   : 2 (position and velocity)
Reference frame : ICRF/J2000.0
Coordinate systm: Ecliptic and Mean Equinox of Reference Epoch

$$SOE 2458204.000000000, A.D. 2018-Mar-26 12:00:00.0000, -1.591861789254073E+08, -2.298918688322970E+07, -2.353758256452293E+06, -1.045906639864063E+00, -3.129377652430419E+01, -4.450064271997949E-01, 2458204.000694444, A.D. 2018-Mar-26 12:01:00.0000, -1.591862416706663E+08, -2.299106450849950E+07, -2.353784956702188E+06, -1.045601993918644E+00, -3.129373246832911E+01, -4.450019025748677E-01,$$EOE

• I can't see why you've chosen to highlight the "Not Secure" and "Secure" of the two different sites, especially given that the author of the site has outlined why they've chosen not to make there site https compatible Mar 26 '18 at 13:52
• @Edlothiad I guess when I see Not Secure I just feel "red", that's just me. Is "Not Secure" in any way incorrect? The important question is how the users feel about the site being Not Secure, not how the site manager feels about it, right? It's so rare for me to even see a url that's Not Secure anymore, it really stands out.
– uhoh
Mar 26 '18 at 15:03
• @uhoh: "Not secure" means that anyone snooping on general Internet traffic can deduce the highly compromising information that you are trying to determine the position of the Starman, and with sufficient skill and access, can even inject false data maliciously presenting you with incorrect position of the Starman. Truly, if the information ever leaked to the public, or worse, you got the falsified records!
– SF.
Mar 26 '18 at 17:08
• @SF. Since the positions are indeed incorrect, are you suggesting that this is what's happened? I think that's a bit extreme. Anyway, a discussion like that should be elsewhere, in chat, meta, or another SE site. Comments here are not the best place to explain how the internet works.
– uhoh
Mar 26 '18 at 17:12
• @uhoh: I believe the positions are inaccurate (I'd say calling 1% error outright "incorrect" is a litthe too harsh) for the same reason why the site is insecure: the author didn't care. It's a piece of space junk in orbit that is of no threat to anything; who cares if the data is 1% off or the connection is insecure? (well, you do - but why??)
– SF.
Mar 26 '18 at 17:48

The site is an approximation. In order to reduce the amount of data sent, each object has it's data stored relative to the Sun. This is what allows for the plots to be included with the same data source as it used to find the distance. The data is generated using the "Vector" mode. In addition, it uses linear interpolation between points on a day by day basis.

That being said, the error amounts are just too large to be due to that, which should only be a few hundred km at worst case, not 100,000 km or more. It turns out that there is a correction for time zones in the code. At the current speed of 3.6 km/s, that means that if time zones are incorrect, the error could be 12960 km/hour. Remove the code incorrectly correcting for time zones, and you have the right value.

• I don't think the vector between Roadster and Earth would be 100,000 km different due to light-time corrections or astronomical aberration, that's a nearly 1% difference, but I'm not 100% sure yet. I'll look into it too.
– uhoh
Mar 26 '18 at 13:31
• As long as you don't use an old installation like I did, SciPy's interp1d returns a handy spline interpolate object that works nicely!
– uhoh
Mar 26 '18 at 13:36
• The problem is I'm using the vector from Roadster-> Sun and Earth-> Sun. Mar 26 '18 at 13:36
• I would have to have a spline work in Javascript. Mar 26 '18 at 13:36
• That is in theory what I am doing. I'm not sure why there is a difference, will have to check a few things when I get a chance. Mar 26 '18 at 17:41