I'm a bit shocked at how low bandwith was allocated. 421 Megabytes per day is the theoretical upper limit. 16 Terabytes for the entire mission. I have more bulk storage in my desktop.
Decoding James Webb Space Telescope
21–30 of 98 posts
Re: Decoding James Webb Space Telescope
#22Does anyone know offhand when we should receive the first images?
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.
Re: Decoding James Webb Space Telescope
#23Earlier quoted context omitted.
This is just telemetry data which doesn’t have much general or scientific interest, i guess they could publish the protocol spec (honestly it probably is aquirable) but most of the fun for the kinds of people who want this data is going to be doing this reverse engineering themselves. 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…
But in a really open project, the design of the whole lot would be on the web, and the data sent back would be sitting on an FTP server somewhere for anyone to download and use. 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…
Re: Decoding James Webb Space Telescope
#24I'm a bit shocked at how low bandwith was allocated. 421 Megabytes per day is the theoretical upper limit. 16 Terabytes for the entire mission. I have more bulk storage in my desktop.
Re: Decoding James Webb Space Telescope
#25I'm a bit shocked at how low bandwith was allocated. 421 Megabytes per day is the theoretical upper limit. 16 Terabytes for the entire mission. I have more bulk storage in my desktop.
Re: Decoding James Webb Space Telescope
#26I'm a bit shocked at how low bandwith was allocated. 421 Megabytes per day is the theoretical upper limit. 16 Terabytes for the entire mission. I have more bulk storage in my desktop.
Re: Decoding James Webb Space Telescope
#27Earlier quoted context omitted.
But in a really open project, the design of the whole lot would be on the web, and the data sent back would be sitting on an FTP server somewhere for anyone to download and use. 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…
> the data sent back would be sitting on an FTP server somewhere for anyone to download and use 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…
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.
Re: Decoding James Webb Space Telescope
#28I'm a bit shocked at how low bandwith was allocated. 421 Megabytes per day is the theoretical upper limit. 16 Terabytes for the entire mission. I have more bulk storage in my desktop.
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
Re: Decoding James Webb Space Telescope
#29One would wish that for budget-exponentially-overrun taxpayer-funded infrastructure, there would be open-source decoding information available.
This is just telemetry data which doesn’t have much general or scientific interest, i guess they could publish the protocol spec (honestly it probably is aquirable) but most of the fun for the kinds of people who want this data is going to be doing this reverse engineering themselves. 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…
>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.
Re: Decoding James Webb Space Telescope
#30Earlier quoted context omitted.
I actually don’t know if they want to protect the data. I can imagine they might not want China or other countries listening in and potentially sending commands to the craft. 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
Yes, CCSDS Magenta and Blue reference books mandate AES-256-GCM as a minimum for data encryption and mandate that encryption and authentication should be used, particularly for commands/uplink. Sliding scale of requirements based on application of course - your cubesat's imaging system is less critical than the flight termination system on a manned mission, for instance.