It's called a Molnya orbit. The Soviets started using it because it would provide good coverage of their very nordic territory, something geostationary sats would not do. Of course, the sats are not stationary (from the point of view of earth, so that excludes stationary parabolic antennas, as are very common with GEO sats) and you do need at least three for continuous coverage in time.
It took me a little bit of staring to realize all the dots are animated, and actually orbiting. That's rad. It would be neat if clicking on a satellite pulled up its picture from wikipedia and linked to the wiki page.
If you zoom out a bit, there are noticeable "holes" above the North and South Poles where the density of objects is lower. Does anyone know what is causing these holes?
* Those spots are the furthest possible distance from the equator (in angular terms), so they should be the most expensive places to put something in orbit (either you launch from a northerly/southerly latitude or spend a lot of fuel on maneuvering into that orbit either way that's expensive)
* Maybe Earth's magnetic field interferes with electronics (less protection from the sun's radiation)
* No one really lives there so there's fewer reasons to spend a lot of money putting something in orbit
Most satellite footprints (imagine a cone from the satellite to the earth) are quite big I'd guess, so the need to launch into a truly polar orbit to capture all of the poles isn't needed.
That said my knowledge comes from playing KSP with the scansat mod.
I think it's just a math artifact. There's lots of "holes" in the orbit inclinations -- their distribution is actually very non-uniform. But at a frozen moment in time, the object's latitude will be anywhere from -i to +i, so the latitude distribution is "smeared out" over the whole range. The gap in the polar inclinations is the only one that's not, so that's the latitude gap you see.
Here's a histogram of the orbit inclinations where you can see this:
Right - even though polar orbits are pretty useful, so there probably are quite a few satellites with inclinations close to 90 degrees, they spend less than 10/360 = 2.8% of their time within 5 degrees of the north pole. What's surprising is the sudden increase in the density of stuff around 80 degrees north.
One possible explanation is the combination of the iridium 33 collision debris field, which is in orbits with inclinations around 86 degrees, and Fengyun 1C debris, which is around 99 degrees (so, 81 degrees but going the opposite direction). The limit of the distributions of those two clusters might account for the clear 'edge' of the circle around the pole.
So, if you've ever seen anything that looks like this, but is also slowly spinning, the spinning isn't just to look cool. The spinning, even very slow and gentle, can help give a sense of the 3D depth of the space. Even just fractions of a degree/sec can be very helpful. I recommend trying to toss in some slow constant rotational motion and see if it helps get a sense of the space. At least based on my browser, you've got the performance for it to look pretty decent.
Edit: Klunky hack you can pop in the URL bar to make it go zoom:
Once you run that, screw with camYawIncr directly, rather than re-running that. Clicking a particular element causes jiggling as the klunky hack fights with the code tracking the element.
You may need something other than .001, depending on what frame rate you're getting.
(Edit edit: There's something to be said for this whole "web" thing sometimes. It's neat that we can hack on code like this....)
Oddly, I built something very similar a while ago. I haven't pushed an updated version anytime recently, so there isn't any UI, but here is an example of it:
This is awesome, thanks for the github link! I wonder what service is providing the data -- the lack of back-end in the repo and need for Web Workers makes me think it's something external. A brief tour of the source makes me think that the clue would be somewhere in satellites.js, but that is a doozy of a file.
This is so awesome, and render beautifully in Firefox, but I can't seem to get the "orbs" (the actual objects) to render themselves in Chrome. Is anyone else having this difficulty? Disabled all blockers and everything.
I see tiny little pulsating pixels in Chrome, which briefly show an orbit if you manage to mouse over their exact pixel. I was going to comment on the usability problem.
This reminds me that not only do you need to develop for different browsers, you also need to test the same browser on different operating systems. I can't count the amount of times Chrome has rendered stuff differently on PC and Mac (pure CSS things, don't even want to think about the differences in JS/WebGL).
Regardless of where the defect originates, if you want people to be able to use your product in different environments, you gotta test in different environments. The user won't care whether your product looks like crap because of a browser defect or because of a product defect; all they know is that it looks like crap. Of course, strike a balance; don't bother developing for IE6 on WinXP anymore.
No network traffic is generated after the initial load so my guess is that this JSON file is generated on the server from some other data source and is read on load and then continues to calculate positions from that initial load. The data on the server changes every 10 - 15 minutes it seems...must be a script updating it.
Assuming you were talking about debris, you can choose to stop tracking objects in the tracking station. This also destroys the object, unlike the pesky real world.
But if you've got that many stations/satellites that you want to keep, you're on your own :).
Great to see this. One of the very first examples of client-site Java put up years ago by JPL (or NASA?) was essentially this, but it went down a few years ago.
So simple, yet very powerful tool to grok intuitively quite a few things: geostationary orbits - and to see at a glance why latency is going to be a problem; the issue of coverage for satellite phones etc.
Edit: Looks like the NASA one still exists (http://science.nasa.gov/realtime/jtrack/3d/JTrack3D.html/) but it's a pain to get it to run because of Java security, and seems to be broken. Won't run in Chrome, broken display in IE and Firefox.
Yes! I always had this open on my Dad's computer quite some time ago. I always wanted to catch a glimpse of a satellite, or especially the ISS, as it traveled over-head.
I feel like this sort of visualization really makes us realize how much space there is out there. There is SO MUCH debris just flying out there and yet we manage to avoid any of it with nearly every launch we've made.
We did something similar at the Space Apps NYC hackathon this April where we tried to simulate the effects of cascading space debris collisions known as the "Kessler syndrome".
We ran out of time so it doesn't actually cascade but it shows the rather high likelihood of collisions if you fast-forward with the slider on the bottom left of the screen. Pull requests would be very welcome, the data from space-track.org generally is great fun to play around with (as is three.js and satellite.js).
That's really neat! Is the code available anywhere? Are you propagating the TLEs with the SGP4/SDP4 propagator? Gonna tweet this now to share within the EU project I'm in, focussed on asteroids and space debris, so there could definitely be some pull requests around the corner!
Awesome :) I've added the github repo to my comment!
And yes, we were using satellite.js [1] which provided us with the propagation functionality together with a static set of TLEs from space-track [2] - I'll add an github issue for adding support for dynamic aggregation of that data right away actually :)
Wow, your project and this hackathon looks super cool, wish I had known about it earlier to attend. Will definitely follow the Meetup for future events, thanks for sharing!
It was the most fun I've had in a long time, I would definitely encourage you to participate as it is a global hackathon [1] and anyone can join from anywhere actually :)
That said I'd still prefer to be on-location as there was such a wide range of people with different backgrounds who were all super inspiring and a joy to work with! There actually weren't enough programmers so I got to hook up a lidar to an Intel Edison for another team which ended up winning the Intel price - the team leader even gave me one of those Edisons and invited me to visit Google NYC.
Yupp, I'm a lucky bastard :) and I didn't even mention that Lord British gave a talk too [2] (he bowed when I thanked his honour for being an inspiration since my childhood).
If you are only slightly interested do participate in the next Space Apps Challenge!
literally came here to say the same thing, it is all about Kessler Syndrome (though I dont remember if they called it that in the book). Fascinating site and good work!
o/
Nikola here.
If anyone is interested in the engineering of the space junk removal device, you can contact me at vianikola@yahoo.com , or on Twitter (which I haven't checked in a long time >.<") @Manakias2
136 comments
[ 2.1 ms ] story [ 187 ms ] threadhttps://en.wikipedia.org/wiki/Molniya_orbit
They also used it to surveil/recon the United States as it can loiter in US airspace for a while.
https://youtu.be/heESAW2addo?t=29s
A few ideas:
* Those spots are the furthest possible distance from the equator (in angular terms), so they should be the most expensive places to put something in orbit (either you launch from a northerly/southerly latitude or spend a lot of fuel on maneuvering into that orbit either way that's expensive)
* Maybe Earth's magnetic field interferes with electronics (less protection from the sun's radiation)
* No one really lives there so there's fewer reasons to spend a lot of money putting something in orbit
* Some kind of international agreement/rules
Maybe someone more knowledgeable could weigh in!
That said my knowledge comes from playing KSP with the scansat mod.
Here's a histogram of the orbit inclinations where you can see this:
https://i.imgur.com/K9zsCy3.png
Here's the raw orbits data that the site uses:
http://stuffin.space/TLE.json
https://en.wikipedia.org/wiki/Two-line_element_set
One possible explanation is the combination of the iridium 33 collision debris field, which is in orbits with inclinations around 86 degrees, and Fengyun 1C debris, which is around 99 degrees (so, 81 degrees but going the opposite direction). The limit of the distributions of those two clusters might account for the clear 'edge' of the circle around the pole.
https://en.wikipedia.org/wiki/Sun-synchronous_orbit
98° inclination is the same as 82° in retrograde (against the earth's rotation).
Edit: Klunky hack you can pop in the URL bar to make it go zoom:
Once you run that, screw with camYawIncr directly, rather than re-running that. Clicking a particular element causes jiggling as the klunky hack fights with the code tracking the element.You may need something other than .001, depending on what frame rate you're getting.
(Edit edit: There's something to be said for this whole "web" thing sometimes. It's neat that we can hack on code like this....)
http://spacejunk.herokuapp.com/
I used the subset of the decaying data from spacetrack.
EDIT: But now Chromium at least is doing fine.
Doesn't this denote a defect on the browser's part?
http://stuffin.space/TLE.json
No network traffic is generated after the initial load so my guess is that this JSON file is generated on the server from some other data source and is read on load and then continues to calculate positions from that initial load. The data on the server changes every 10 - 15 minutes it seems...must be a script updating it.
Some of the API names from space-track match what's in TLE.json, so it's probably just fetched and post-processed every couple minutes.
http://www.n2yo.com/database/?q=skynet
hold me...
But if you've got that many stations/satellites that you want to keep, you're on your own :).
So simple, yet very powerful tool to grok intuitively quite a few things: geostationary orbits - and to see at a glance why latency is going to be a problem; the issue of coverage for satellite phones etc.
Edit: Looks like the NASA one still exists (http://science.nasa.gov/realtime/jtrack/3d/JTrack3D.html/) but it's a pain to get it to run because of Java security, and seems to be broken. Won't run in Chrome, broken display in IE and Firefox.
We ran out of time so it doesn't actually cascade but it shows the rather high likelihood of collisions if you fast-forward with the slider on the bottom left of the screen. Pull requests would be very welcome, the data from space-track.org generally is great fun to play around with (as is three.js and satellite.js).
http://spaceappsnyc.com/KesslerSyndrome
https://github.com/spaceappsnyc/KesslerSyndrome
And yes, we were using satellite.js [1] which provided us with the propagation functionality together with a static set of TLEs from space-track [2] - I'll add an github issue for adding support for dynamic aggregation of that data right away actually :)
[1] https://github.com/shashwatak/satellite-js
[2] https://www.space-track.org
That said I'd still prefer to be on-location as there was such a wide range of people with different backgrounds who were all super inspiring and a joy to work with! There actually weren't enough programmers so I got to hook up a lidar to an Intel Edison for another team which ended up winning the Intel price - the team leader even gave me one of those Edisons and invited me to visit Google NYC.
Yupp, I'm a lucky bastard :) and I didn't even mention that Lord British gave a talk too [2] (he bowed when I thanked his honour for being an inspiration since my childhood).
If you are only slightly interested do participate in the next Space Apps Challenge!
[1] https://2015.spaceappschallenge.org
[2] https://twitter.com/musha68k/status/587000418095464448