Decoding James Webb Space Telescope
destevez.net
destevez.net
[0]: https://en.wikipedia.org/wiki/SpaceWire [1]: https://ntrs.nasa.gov/api/citations/20030025278/downloads/20...
2.0 % observation calibration
4.9 % instrument calibration
7.9 % solar system (comets, asteroids, kuiper belt objects, etc)
16.1 % exoplanets
17.2 % nearby galaxies
20.4 % galactic (debris disks, etc)
31.5 % distant galaxies and cosmology
This doc was drafted in 2012, and so this might've already changed or will be: https://www.stsci.edu/jwst/about/history/science-operations-...
https://webbtelescope.org/quick-facts/mission-launch-quick-f...
> After reaching its orbit, Webb undergoes science and calibration testing. Then, regular science operations and images will begin to arrive, approximately six months after launch. However, it is normal to also take a series of "first light" images that may arrive slightly earlier.
It will take about a month for it to get out to the Sun-Earth L2 point which is 1.5M km (0.01 AU) from the Earth. For comparison, the Moon is 384k km away. The telescope will be 4x further away from the Earth than the Moon is.
The frequencies that can be used for communicating with a satellite or space probe are governed by how far away it is. The cut off for this is 2.0M km.
https://en.wikipedia.org/wiki/Deep_space_bands
And so, the JWST is still considered near earth and can't use the deep space bands.
(I'm asking why the band used is significant in any way)
6 Months is the time frame for regular science operations. It is likely NASA will share some images well before that from the calibration phase as part of mission PR.
As regular joe's on the internet we are only interested in those PR images, regular science operations are more important for astronomers applying for time on the telescope.
Beyond those initial PR images, we can perhaps expect some PR worthy research papers (i.e. kind of papers that will get posted here) maybe a year from now, given the first projects will get access 6 months from now.
The amount of unpacking involved as this thing deploys is insane.
On the data rate thing, satellites usually have a low data rate system with omnidirectional antennas, used for command and positioning. Then they have a high data rate system with directional antennas for whatever it is they do.
(The USAF used to have a strict separation between the two. This reflects the USAF's pilot-oriented mentality. The USAF is pilots, and then everybody else. The low data rate system belonged to the piloting operation, which used to be in the Blue Cube in Sunnyvale CA and is now at Schriever Space Force Base, formerly Falcon AFB, in Colorado Springs CO. They "drive the bus", managing orbital insertion and station keeping. The high data rate system belonged to the payload, and once the piloting operation had it turned on and aimed, it was turned over to the agency that owned the payload. Private satellite operators usually don't make that distinction.)
That's from this link:
https://www.jwst.nasa.gov/content/webbLaunch/deploymentExplo...
I feel so spoiled that NASA provides video clips of each specific deployment step.
For reference, MRO is capable of downlinking at up to 5 Gbit/sec with a 3.0-meter HGA [1].
[0] https://jwst-docs.stsci.edu/jwst-observatory-hardware/jwst-s... [1] https://descanso.jpl.nasa.gov/DPSummary/MRO_092106.pdf, table 4-7
In Reed-Solomon only mode, MRO can transmit about 6.6 Mbps but at typical Mars-Earth range the data rate is much lower.
They will make up for the smaller numbers of pixels per (long) exposure by running the thing constantly.
Check out the sort of images they produced with the 128x128 pixel sensor on spitzer: https://upload.wikimedia.org/wikipedia/commons/a/a5/Andromed...
The real imaging data would require a much more significant dish to even receive (i can’t immediately find what it’s going to use, but I’m guessing something like a 40 meter dish) so there are approximately zero amateurs who could use such open source information.
The mission-specific parameters ("managed parameters") used by any given mission are usually more tightly controlled, as are the payload specifications for each telemetry channel.
> This is just telemetry data which doesn’t have much general or scientific interest
My understanding is that "telemetry" and "telecommand" stand for the downlink and uplink directions of a space link. I mostly worked upstream of telecommand, but I understood "telemetry" to refer to received data of any kind -- e.g. in CCSDS 130.1-G-3, an informational report on the design of the CCSDS telemetry system. https://public.ccsds.org/Pubs/130x1g3.pdf
By the by, I've been continually impressed with the quality of the CCSDS' documents. The "green books" (informational reports, like the one above) are extremely approachable and well-written.
And it doesn't help that some missions manage their own archives differently, and there's a lot of terminology to learn on your own. One of the complete opposites of that, which was a joy, was the New Horizons archive which, at one point, you could download from a torrent! For example, if you wanted to see V3 of the Arrokoth encounter from 2019, you'd go to: https://pdssbn.astro.umd.edu/holdings/nh-a-lorri-3-kem1-v3.0...
Again, New Horizons is a bit of a rare case in which they went for super accessible data for everyone. PDS itself is a great system, but many missions will just upload a bit of data to PDS and then manage the rest some other way (Cassini for example has only a couple of instruments on PDS, and you have to go to some other URL if you want uncalibrated but automatically processed images on JPEG format[0], but yet another place (to which I've lost the link to and I can't find on mobile) for the full, science-grade dataset).
A great resource is OPUS[1] too, however I find it's UI a bit difficult, and in the end I prefer to download full datasets and just explore them on my own rather than going with those online browsers. For example, if you wanted to check the Voyager images of Neptune, you'd go to this massive URL[2]. Quick tip: once you've configured the filter you want to apply, the Search button is on the top left -- this is the kind of usability thing I mentioned, buttons and links aren't quite where you'd expect them. Oh and there's a limit to how many things you can select for download at once. And it's all dynamically loaded, and on and on and on. Which is why, as I said before, I generally prefer to just download the full GB sized dataset and explore it on my own.
[0] https://solarsystem.nasa.gov/raw-images/raw-image-viewer/?or...
[1] https://opus.pds-rings.seti.org/opus/
[2] https://opus.pds-rings.seti.org/opus/#/instrument=Voyager+IS...
I thought that was the case, but it's been so long since I've been on a mission proper (Cassini, student co-op) that I didn't want to say so without basis. Thanks!
As I'm just "playing" with the files, I don't mind waiting a few months/years to get access to full "scientific grade" readings from incredible complex machines and systems. And if the "raw" data is not easily available, they also usually do provide processed images as part of the missions public outreach campaigns (usually the ones that are found on Wikipedia).
>To keep up with the high downlink, the recorder data gets sent directly to the Ka-band transmitter
Currently aws groundstation doesn't support KA band so no luck there. It's apparently going to do a transmission once a day so you would need to time it right with the ground station.
And really, it's the perfect place for aws to enter, add glue, and provide a service to let you do your core business. Feels like the future man.
It's a little bit annoying finding information about jwst as info could potentially be old and out of date. Another document that I read mentioned using XML as the database format because XML was an emerging standard :S
In many ways, an open project is cheaper to do than a behind-closed-doors project where every new contractor needs to get access to only the bits of the project they need access to, and misunderstandings happen because not everyone has enough of the big picture.
The only bit that needs to be secret is one private key used to sign the commands sent to the satellite, just so one random Mallory can't 'steal' it.
I'm sure they could actually do that without too much fuss. But it would require significant amounts of scientist time to document those datasets to enable others to use them for any arbitrary dataset. I'm sure we'll see fully open data sets from JWST appear, but lots of the stuff it collects isn't going to be interesting enough that it's reasonable to spend scientist time documenting it.
Once the data is collected and downloaded it is added to the catalog with all of that metadata attached. Then it's a matter of opening up that catalog to the public, although I'm guessing the downloads will be quite sizeable so the bandwidth could be an issue.
The trick to making this work is to integrate the publishing into the workflow so it doesn't require any additional effort on the part of anyone.
[1] https://jwst-docs.stsci.edu/jwst-opportunities-and-policies/... [2] https://archive.stsci.edu/missions-and-data/jwst
Something published has been checked by a few team members, written with care, and represents the opinion of the authors and project.
Something made available has no guarantees of correctness, might not represent the projects opinion, and might just be random matlab scripts made by a JWST scientist in their lunchtime that they thought was fun.
In the open source world, what is 'published' is probably the projects homepage, and code. What is 'made available' is random chatter on their discord or IRC channel.
I hope that more government projects 'make available' everything done by all the workers - every file saved on every PC, with the understanding that there is no guarantee of correctness.
I guess it's the same idea as being able to see into the kitchen from a restaurant. You might see the chef making mistakes or juggling the saucepans, but you'll also see the work being done as it's done, and being able to view doesn't delay the chefs work.
Plus, it will be pretty much useless im practice since you'd have to be an expert in that niche yourself to know what's correct (you're not getting any extra docs or context) and probably most of it will be some kind of incorrect, possibly very subtly. The only people who could profit tremendously are the competition who aim to snipe that particular paper. Science is pretty dirty and ruthless often as not, I totally could see this happen.
This was to prevent others from also getting the data and publishing before the requesting scientist.
Assuming this continues to be true, they probably wouldn't want to handle the data by publishing it to a FTP server immediately on receipt.
STScI is a major contributor to astropy etc. (https://github.com/astropy), and has their own space with more tools/software: https://github.com/spacetelescope.
It's unclear what else you'd actually want, unless you want to build a clone of the actual satellite (it wouldn't surprise me that a majority of the software for the satellite is open source, just not put together somewhere publicly for people to download).
Much satellite technology is classified or at least export controlled (ITAR). The major difference between a space telescope and a spy satellite is which direction you point.
Does anyone know if there is typically encryption on the downlink? How about uplink commands? I guess we want those to be secured so only authenticated control can send commands
https://www.arrl.org/news/fcc-special-counsel-laura-smith-sa...
In a more recent post (which includes good suggestions for experimenters):
> The ham bands aren’t full of whacked-out haters looking to get rid of everybody else, but hams are very accustomed to people using the bands without a license or not following the band plans, causing interference problems.
https://thesilicongraybeard.blogspot.com/2020/09/a-ham-radio...
Usually the 'self-policing' by hams (it's usually very effective) is done gently. They get that the frequencies are free of $$cost, and don't want to lose (any more of) them.
The primary risk would be that the US would hit back and attempt to sabotage something important to China (and with China's sprawling global interests now, there are a vast number of soft, highly exposed targets). The US Government can be quite vindictive depending on the context, it will hit you back if it can. The responsible agency wouldn't seek publicity for any successful sabotage, but China would know who did it and what it was for.
(sorry, I'm just now reading into the drama with the fbi and gov. whitmer..)
There is unlikely any non-state actors[1] that has the ability to transmit signals to L2 . Just receiving signals even now (only 2 out of 30 days to l2) the OP used a 6 meter dish. Most of interplanetary mission signals are handled by the DSN.
Any sort of encryption will add both b/w requirements and compute requirements . The CPU/network budgets on such missions are very very limited. Every bit and cycle counts.
Finally standard encryption libraries, algorithms et al, are not likely suitable . I am no expert, but I have not read of any modern algorithms with very low network overhead + compute requirements designed for these kind of use cases, that is also secure from brute force or other attacks.
Mission risk is also a factor, even handshake failures can jeopardize the mission. It is one thing a website did not load because of TLS negotiation failures and $10 B mission overshot its orbit because handshake failures on the encryption layer.
[1] Threats from state actors for science missions is different category of concern, harder to quantify and with not much history of actual attacks. Collateral risks like from the ASAT Russian test to ISS, or in dual use missions would perhaps not apply here .Usually science teams collaborate well even if there is lot of tension in political sphere.
Authentication of commands to satellites is very, very necessary
You could do authentication over plain text. For popular example http basic auth.
It is not recommended for regular use cases, but is not out of realm of possibility in satelite given the constraints.
You said that was unnecessary and too taxing on constrained hardware. That is incorrect. Authentication is both necessary and not excessively taxing, when both considering the risk to the spacecraft's operation or even not considering it, since, as you said yourself, authentication schemes can be reasonably lightweight.
"Not out of the realm of possibility in satellites" What are you talking about? Of course it isn't! Authentication to satellites is recommended and implemented all the time, for obvious reasons. You think they risk a multi million dollar investment to save some clock cycles? How many commandeered satellites do you read about daily? Do you have sources to back up any of this?
https://twitter.com/usa_satcom
Inside the project there must be an established data infrastructure running or ready to run. It probably has a raw layer and a transformed layer with well defined tabular schemas for the metadata of each image. It would be fun to see how both layers work and play around with the data.
Would the instrument itself have a fixed set of metadata attributes assigned to all imaging, or is it programmable and changeable during the service life?
https://www.stsci.edu/jwst/science-execution/data-analysis-t...
Even in CS papers directly dealing with a piece of software there is no obligation to publish code.
If you make it clear it must be reproducible from the start and threaten to not publish if it can't be then they'll get in line - the kind of projects I'm thinking of are < 5k lines usually.
If I see a paper claiming remarkably good predictive capabilities of (say) the performance of a basic block, and no discussion of it's flaws you bet I'm assuming they didn't test it well enough.