One would wish that for budget-exponentially-overrun taxpayer-funded infrastructure, there would be open-source decoding information available.
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.
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.
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.
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
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.
>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
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).
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
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://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.
https://twitter.com/usa_satcom
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..)
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.