Dates can effect propagation drasitically

I’m using satellite-js in a 3d view. It takes the currentTime and and a delta and creates a point in the future filling a VBO. When it works it works wonderfully.

If try to created new buffer per frame I’m getting very odd behavior

Correct:

Bad:

When the trails are short it looks like “popping” but its much clearer at this scale that it’s very wrong. The only thing changing in these 2 screenshots is the Date used in propagate. I’m using new Date(milliseconds). Is there something about that resolution that’s cause floating point errors or do I need to clamp to some interval?

Video

https://user-images.githubusercontent.com/438252/104109619-a27a0b00-5284-11eb-9748-c94b9441950f.mp4

https://user-images.githubusercontent.com/438252/104109620-a4dc6500-5284-11eb-8f80-95d721234e8d.mp4

Thanks for your time.

[thkruz]

Nope that was my mistake - I was thinking about satrec.t (which is what is input into sgp4 after you call propagate). The #75 issue is in invjday which you have to call manually. So confirming the milliseconds may not matter.

I copied that chunk of code from my library and forget the initialization for now. You need const now = Date.now() towards the top of that code. You are getting false because now is undefined and that is messing everything up.

I agree with your point that adding a few milliseconds should only cause a small adjustment (~7km/s for most LEO satellites in your picture).

One other idea we can try to narrow down the problem. Use const now = new Date(2021,1,10,0,0,0) * 1 in my above example and add a `console.log(pos) inside the loop. If you post the results of that console.log and the TLEs from the satellite you chose as your example I should be able to put that same TLE and date in on my end and get the same position values. If I am getting different results that would narrow down the issue. If we are getting the exact same results then I can rule out most of satellite.js.

[delaneyj]

So I built a whole new app just to test satellite.js in isolation. TL;DR… I get no significant distance errors. My current theory is the translation from world space to normalized coordinates (KM_NORMALIZED for example) is the heart of the issue and with vast scale changes causing the root issues. So I’ll need to do all the math in ECEF and at the very end plot back down. or move scene to use global scale and deal with the depth buffer / z-fighting

Thanks again @thkruz for your help