In this case, the "corrections on the fly" refer to all of the real-time responses that the software makes without ground involvement. In the case of a solar limb sensor detecting the sun, the probe will abandon its data collection for that near approach, and go into an emergency response that has been made as straightforward and deterministic as possible, to maximize the chances of recovery for all single-fault and some double-fault scenarios.
To answer your question about software upload, the PSP has 3 redundant CPUs (primary, hot spare, backup spare), and each has multiple boot images. To upload software, the team uploads it to an inactive image of the backup spare CPU, promotes it to hot spare for long enough to collect the data it needs, reboots it into the new image, and then rotates it into the primary role, which is a seamless transition unless something goes wrong, and then the new hot spare takes over again within a second. Once they're sure the software is working, they can update the other CPUs. Before any of this, new software is tested on identical hardware set up on the ground with physics simulations.
It seems like you want to discredit NASA now ("shouldn't melt") vs some imagined possibility("won't melt" but it does). With the amount of design, analysis, testing, and independent review and verification of the systems, backup systems, triply redundant systems, and autonomy, we can be as sure of it not melting as we can be sure of anything. And we certainly spent a large amount of money on this (about 1/10th of the World Cup), but in performance and value per $, it's a great deal.
Not at all. I expect NASA has done as much due diligence, planning, testing, and verification as possible. I just don’t think they are being upfront as they should be about the possible risks for a previously unattempted scientific endeavor. We’ve had massive failures (including NASA itself), in environments that are much better understood and with systems that have actually had exposure to those environments.
I also didn’t intend on “shouldn’t melt” to be taken sarcastically. I was trying to show how I would like something changed in the article. Probably a bad use of quotes on my part...
(former software engineer on PSP here) It's a certainty that it will melt eventually, but that's not a satisfying answer to the question "why won't it melt?" The satisfying answer is "for the time period when it won't melt, it won't melt because of..."
It's been a traditional at JPL (and other NASA centers) to wear matching polos for quite some time now, at least years, before the Rosetta landing. Not saying that NASA is better than ESA as far as women or PR goes, but this wasn't a reactionary move.
It appears to be a photo post (i.e. images uploaded to FB natively) as opposed to a link post, where FB chooses a thumbnail for you (or not, if it's a YouTube link). I've been seeing posts like this when friends upload image albums (if more than 4 images, you get a 'see more' box in the lower right)
As someone tech-savvy and having used WireShark, even, I'm curious to know from my sibling commenters, what are you thinking? Of course you start by buying hardware or modifying a router. Parent comment is specifically asking for "good information" and something that "clearly defines how this is done." IMO, xfalcox and lewiseason come closest to actually answering the question, because their links mention specific software.
But simply installing software isn't enough, it needs to be configured. How does one set up OpenWRT or WireShark to filter for this kind of information? What pitfalls might one encounter? Do you need a CS degree in order to interpret the data? What keywords should one use when searching for more information?
With vague answers like the ones so far, you're just making it seem more difficult and intimidating for anyone that has little to no experience in this area. If we want people to be more concerned about their privacy, it needs to be as easy (or easier) for people to take control of their information as it is for them to give it away.
Edit: smtddr has the right idea, thumbs up. Should have hit refresh one more time before posting.
> See the "Guidance and Control" and "Communications" section of the NH
> Spacecraft Systems page for a detailed answer.
>
> The short version is that it uses a combination of star trackers and IMUs
> (Inertial Measurement Units). The star trackers analyze pictures of the
> surrounding star field to determine how it is pointing instantaneously, and
> the IMUs track how it is rotating in between each of those instants. This
> determines the attitude (which way it is pointing).
>
> For position determination, "ranging" tones are sent from the earth and
> echoed back by the craft. This combined with the angle that the dish is
> pointing at to get the strongest signal tells the operators where the craft
> is in space. This information is fed back to the craft, which has an on-
> board physics simulation, and predicts where it will be until the next
> ranging event.
>
> Now, you might have noticed that I didn't mention Pluto once. That is
> because this system (minus the exact details) is used by pretty much every
> spacecraft, from those around Earth, to New Horizons, and beyond.
Source on that? Even the Tajectory Correction Maneuvers (TCMs) are planned in advance, and it's just the details of the TCM that are finalized in the lead-up to those events.
As far as the final approach goes, the core sequence started July 7[1], and no adjustments were made to it. They even had a TCM opportunity before that in case of a possible collision, that I heard was skipped.
To answer your question about software upload, the PSP has 3 redundant CPUs (primary, hot spare, backup spare), and each has multiple boot images. To upload software, the team uploads it to an inactive image of the backup spare CPU, promotes it to hot spare for long enough to collect the data it needs, reboots it into the new image, and then rotates it into the primary role, which is a seamless transition unless something goes wrong, and then the new hot spare takes over again within a second. Once they're sure the software is working, they can update the other CPUs. Before any of this, new software is tested on identical hardware set up on the ground with physics simulations.
See also, "Solar Probe Plus Flight Software - An Overview" from http://flightsoftware.jhuapl.edu/files/_site/workshops/2015/