Spacecraft Set to Reach Milestone, Reports Technical Glitches Options

[mchan]

...affects on bleeding edge processes wasn't fully realized until after those chips were shipped. What happens to those same chips when you put them in space probably won't be fully realized until they spend 10e5 hours in space...

And yes, none of this has to do with MRO, likely. It's just me forecasting doom.

Agree that some leading edge commercial chips get released only to have customers find problems with them over time. It's the competitive nature of the business. If you extend the characterization and qualification to iron out more latent design issues, the competitors can eat your lunch. It's a judgement call on when to release. Hopefully, some workaround can be found for the problems that show up later.

Chips for space apps undergo much more rigorous environmental qualification tests, and are some years / generations behind the leading edge. I don't work on space HW, but I doubt there will be any bleeding edge _commercial_ processes used in space systems. E.g., you mentioned FPGA LUT's. The predominant commerical ones are based on SRAM configuration. I recall hearing disussions on how space HW would use lower density, lower performance devices based on permanent anti-fuse configuration rather than having to design the system to detect and recover from configuration SRAM corruption and to do it while staying at least partially online. And the MTTF in space is a lot higher than in Denver.

The actual cause of MRO's problems will be interesting to read about when it becomes publicly known. As for doom, when I saw Craig Covault's headline Mars Orbiting Imaging Halved, I read it as half full rather than half empty.

[GuyMac]

The images are really good, but in terms of frequency of releases, so far it seems that the "People's Camera" public releases have, on average, been occurring at about the same rate as the MOC daily captioned image releases.

Another thing that is going on is a move to a better web publishing system; we've got a new webmaster (I filled in temporarily in the latter part of '06) preparing that currently. I expect the dams will burst so to speak by the spring....

[slinted]

I'm having a hard time figuring out what the current status of HiRISE is from the myriad of articles currently being written. The NASA/JPL news release refers to "a significant increase in noise, such as bad pixels, in one of its 14 camera detector pairs." while the Nature story refers to "Seven of HiRISE's 14 detectors are sending back spurious data, the mission team reports, and one of the four colour detectors has stopped working completely."

Which color detector is lost? It would seem to be less damaging, from a public release standpoint, if it turned out to be one of the two infrared detectors, since the two blue/green detectors are what we have seen used for color images. Also, is the nature story exaggerating by referring to the color detector as completely stopped or is the JPL release euphemistically telling us that same thing?

A little disambiguation might go a long way here.

[mcaplinger]

the Nature story

I have no idea what the actual situation with HiRISE is, but it would be nice to get an official and unambiguous statement. The media reports do make it sound pretty bad.

From the Nature story: "A previous high resolution NASA camera was lost with the demise of MGS. The best camera currently in orbit around the red planet is on Mars Express, which arrived in December 2003."

Given that the SRC system on MEx hasn't performed to spec, I think that CTX on MRO at 6 meters/pixel wins the prize for next best camera, at least in terms of resolution.

[nprev]

This is more than a bit disconcerting; now I'm not even sure if we have an evolving situation or a fixed set of known problems. The MRO program office needs to issue some clarification, ASAP.

[tuvas]

the Nature story refers to "Seven of HiRISE's 14 detectors are sending back spurious data, the mission team reports, and one of the four colour detectors has stopped working completely."

That is a large exaggeration. Channel 1 of IR10 almost has completely stopped working, but channel 0 is working just fine. Looking at the articles that have been posted, I would point you to the space.com article and state that it seems to be the most informative and accurate, except for it's title. Quoting two parts of it which are totally true:

In late November 2006, the HiRISE team noticed a significant increase in noise, such as bad pixels, in one of its 14 camera detector pairs. Another detector that developed the same problem soon after MRO’s launch in August 2005 has worsened. Images from the spacecraft camera last month showed the first signs of this problem in five other detectors.

That warming, McEwen told SPACE.com, is sufficient to reduce the HiRISE problem to minor dropouts—easily interpolated—in RED 9, and no problems at all in other charge couple devices within the instrument except an infrared receiver channel (IR10 channel 1), where instrument specialists first saw this problem after MRO’s blastoff from Florida in August 2005.

These two statements are 100% correct. Just thought I'd point that out.

[Guest_Sunspot_*]

Well I hope they get a picture of the possible Beagle 2 and MPL crash sites before the camera dies. They should probably move them up the target list.

[ugordan]

Whoa... there are some black thoughts here, Sunspot.

[djellison]

Why move them up the list? Even if HiRISE were known to be about to expire ( and we know that actually, the media is overhyping this enormously and in actual fact, HiRISE is not about to expire ) - why reprioritise targets? The most important targets are the most important targets if HiRISE is fine, unwell or broken.

Personally - if (and we know this is not the case ) there were 'X' shots left in the HiRISE lifespan - I would give one shot each to B2 and MPL (the supposed B2 target and the previous MPL target ) and then move on to geologically interesting targets instead of duck-shoots for targets of unknown locations.

The point is moot anyway - MPL couldn't be imaged until the southern Summer and we're not there yet - hence the large numbers of northern polar imaging targets

Doug

[Guest_Analyst_*]

Some questions to better understand the situation:

tuvas said channel 1 of IR10 (Why 10, there are only two IR detectors?) is almost dead, channel 0 working fine. Are these channels redundant and we are using the backup now? Or are they complementary and something is lost already?

How does the warming happen? Are there heaters or is this done just by operating the detectors?

Analyst

[mcaplinger]

tuvas said channel 1 of IR10 (Why 10, there are only two IR detectors?) is almost dead, channel 0 working fine. Are these channels redundant and we are using the backup now? Or are they complementary and something is lost already?

I believe that they number the CCDs from 1 to 14, with a prefix that indicates which filter it has. So there are two IR sensors, called IR10 and IR11. See http://hirise.seti.org/epo/hirise_lesson1.htm and http://marsoweb.nas.nasa.gov/HiRISE/papers...ISE_InstDev.pdf

I surmise that each CCD has two output channels that are separately processed. It's pretty typical for linear CCDs to have such arrangements: the MOC NA, for example, had two channels for its single CCD (one for even pixels, one for odd). These are not redundant; if you lost one you'd have to interpolate every other pixel.

From what I've read now on this forum from UofA, the media accounts are fearmongering to some degree.

http://isis.astrogeology.usgs.gov/Applicat...issance_Orbiter might give some insight into the processing required for HiRISE images.

Disclaimer: this information is all from public sources.

[monitorlizard]

mcaplinger, IIRC you are involved with the MRO CTX camera. Could you provide us with a small comfort by verifying that CTX is working correctly. Not seeing any images on MSSS since October makes me wonder how it's doing.

[tuvas]

I believe that they number the CCDs from 1 to 14, with a prefix that indicates which filter it has. So there are two IR sensors, called IR10 and IR11. See http://hirise.seti.org/epo/hirise_lesson1.htm and http://marsoweb.nas.nasa.gov/HiRISE/papers...ISE_InstDev.pdf

I surmise that each CCD has two output channels that are separately processed. It's pretty typical for linear CCDs to have such arrangements: the MOC NA, for example, had two channels for its single CCD (one for even pixels, one for odd). These are not redundant; if you lost one you'd have to interpolate every other pixel.

These points are almost correct. The CCDs actually are numbered 0 to 13, RED0-9, IR10,11, and BG12,13. Each of them has two channels which are individually processed, as you stated. They aren't even/odd pixels, but rather one half of the channel followed by the other. With the exception of the focal plane stuff, there is redundancies on HiRISE, exactly what I couldn't tell you.

I can tell you that HiRISE is working quite well at the moment, http://hiroc.lpl.arizona.edu/images/PSP/di...PSP_002281_2115 is a picture that was only taken 21-Jan-2007, well after the problems had first appeared. In fact, to even detect any problems at all with 3 of the CCDs, we had to chill the camera to lower-than-normal temperatures, two others barely show any signs at all. HiRISE still has a lot more time, the degradation on the newest CCDs to show is very minimal, I beleive the level hasn't changed reasonably since first noticed.

As to what would happen if HiRISE was found to only have x number of pictures, I would bet that as many as can be taken of MSL potential landing sites would be taken, as much as HiRISE would like to be used as a geographical instrument, where it really comes in handy is for photographic potential landing sites to search for a safe place to land.

[Guest_vjkane2000_*]

Can you confirm the Nature report that one of the color detectors has failed? I'm not reading anything near as severe as that elsewhere, so I suspect that this was an error in this report.

Also, when you say things are redundant, are the two channels in the detectors redudancies? I.e., losing one still allows you to read the data from the detector array through the other channel?

[slinted]

Tuvas, thanks for the clarification. It's good to know the detector isn't completely lost, and I did breathe a slight sigh of relief to hear that it is the IR-color channel that is having the most problems. Not to belittle its contribution, but if I'm not mistaken, we've never seen a public release that even shows data from the 2 IR ccds. If there were one to lose, I suppose that would be it.