MSSS DELIVERS FIRST SCIENCE INSTRUMENT TO JPL FOR 2009 MARS ROVER MISSION PAYLOAD

http://www.msss.com/press_releases/mardidelivery/index.html

Even if the Isps were 285 and 340, that's only a 20% advantage for biprop, which could easily be offset by the mass of tankage, pressurant, plumbing, and thermal control to keep the propellant from freezing. I'd say solids were still viable based on that.

According to various analyses I've done in the past, the Isp of solids is better than that of monoprop hydrazine and competitive with biprop hydrazine/NTO (in the range of 300 s). Biprop might be a little better, but the advantage is not huge.

More expert opinions welcome. I would love to see a good design for a MAV, but I'm not sure I have seen one yet. The original MiniMAV was very attractive but in hindsight too optimistic.

One reason is because Orion may well be dead six months from now. Another is that the engineering problems aren't very similar even if VSE does ultimately end up going to Mars. Think of Apollo compared to Luna 16.

I think the point John is making, and it's an important one which I have little reason to doubt the validity of, is that the MAV will require a great deal more technology development than many in the Mars community seem to be assuming. For this and many other reasons, I am very pessimistic that we will see MSR any time soon.

AFAIK, your examples are not of "of an approximately similar performance envelope". Go back and read post 90 of this thread, and many of John's subsequent posts. ASATs aren't getting into orbit.

Presumably people who are interested in flight software read slashdot, but if not, this article was featured today: http://news.oreilly.com/2008/07/the-softwa...the-mars-p.html

Great article, thanks.

I actually attended the Critical Design Review for CHIPSat, which was built here in San Diego by a team at SpaceDev. The mission was an excellent example of doing something real on a small budget. The fact that no one thinks you can fly a real mission for less than hundreds of millions of dollars is a depressing aspect of how spaceflight has evolved in the past decade or so. One can hope that the pendulum will swing back eventually.

Strictly speaking, it isn't. The operating system is VxWorks. The stuff that runs the mission is essentially an application that runs on top of VxWorks and is not encumbered by Wind River (as far as I know -- IANAL.)

If somebody wants to write an open-source version of VxWorks, that'd be swell, and not all that hard, since it's a very simple system that basically only provides basic interrupt handing, a task model and intertask communication primitives. But even if that happened, I wouldn't count on the spacecraft-specific code being made available.

I don't think we need to get into a debate about the virtues of open source versus the alternatives on this forum.

AFAIK, MSL isn't using the DOS filesystem. For the cameras, I wrote my own filesystem (the cameras don't use an OS, the software runs on the bare metal.)

The core set of VxWorks functionality is so small that I don't know that we're missing that much. Sometimes I'd be happier if they didn't keep "upgrading" things.

Yes. Triana.
http://en.wikipedia.org/wiki/Triana_%28satellite%29

Google is your friend. http://blogs.windriver.com/deliman/2008/05...ou-watch-i.html confirms that Phoenix uses VxWorks 5.2.

As for SEUs, the RAD6000 is not very subject to SEUs: http://www.baesystems.com/BAEProd/groups/p..._eis_sfrwre.pdf says 7.4e-10 errors/bit-day in 90% worst-case GEO. Of course, each system costs about a million dollars IIRC.

From http://mars.jpl.nasa.gov/MPF/nasa/pipfaq.html -- this is old Pathfinder data, but the general concept is the same.

How is data acquired by the spacecraft stored in the central computer and prioritized for return to Earth?

Answer:

All Pathfinder downlink data are packetized and assigned to APID ("Application Process IDentifier") queues, from which data is downlinked in FIFO (first in first out) order. The packetization and assignment takes place immediately as a result of execution of commands which acquire data -- separate commands to packetize and enqueue the data are not used. APIDs can be configured as rings, where old data is overlayed, or as queues, where new data is rejected if the size limit is exceeded. APIDs are identified by both name and number (0-42). Specific data formats are permanently assigned to specific classes of queues. For instance, one queue is for rover health data, and only data of that format can be assigned to it. There are multiple queues for IMP image data. Any IMP image can be assigned to any of these IMP queues, and within limits, the assignment is negotiable.

Within a single downlink session, APIDs are prioritized according to a two-dimensional priority matrix called a DPT ("Downlink Priority Table"). The DPT structure is used to make sure the most important data gets in the front of the downlink stream, regardless of when it is acquired, with the proviso that downlink from individual queues is FIFO. In the DPT, APIDs can be assigned to completely override others in priority (ie, completely prevent other APIDs from getting any downlink so long as any data is left in the higher priority APID), or they can be assigned to share a priority level on a percentage-of-bits basis.

Different downlink sessions can be governed by different DPTs, and within limits, the DPT organization is negotiable.

It is not possible to reorder packets within the queue, nor is it possible to move data packets between queues. Data packets can be deleted from the front of the queue up to a commanded time (the time when they were acquired) or by specific packet number at any point in the queue. It is not currently possible to delete specific data reliably from the center of a queue, but further study could mitigate this problem.

I found this http://www.fabtech.org/content/view/6540/ which says the panel efficiency is 28.3%.

http://atk.mediaroom.com/index.php?s=press...es&item=821

"Each Ultraflex array unfolded like an oriental fan into a circular shape 2.1 meters in diameter and will generate 770 watts of power from sunlight at the distance Earth is from the sun. Since Mars is approximately 1.5 times farther from the sun, the solar arrays will produce less than half the power possible on Earth."

My guess is that they meant both panels together (6.92 m2) generate a peak of 770 watts at 1 AU without atmospheric losses, which would put the efficiency at around 23%, which seems believable.

The bug was with reading IMU data and MARDI data simultaneously. Now that the IMUs are turned off and unused, there's no risk in operating MARDI. The spacecraft guidance system isn't very challenged just sitting on the ground.

But I think it's unlikely this will happen until all other mission objectives are met, if then. It could take a nice image of the stuff underneath the rover, and I'm not sure the RAC can see that area (MARDI is on the other side of the met mast.)

Disclaimer: this post is based on public information. Any opinions are my own.

http://www.jpl.nasa.gov/news/news.cfm?release=2008-074a

Times in ERT, subtract OWLT of 15m20s for SCET. So chute deploy would have been at 23:34:55 SCET. Of course, since HiRISE is a line scanner you need to figure out the linetime of the line that has PHX in it, not the image start time.

If there are better timings available yet, I haven't seen them.

Chutes are subject to partial opening ("squidding") in some speed regimes. I'm wondering if this may be some evidence of that.

True, but in the case of MPL, the landing-leg deployment switch bug was high-probability and its fix is obviously correct.

AFAIK there were no changes to the control algorithms. There may have been some made to the radar processing. http://www.nasa.gov/mission_pages/phoenix/...x-20080508.html

The probability that the software bug with the leg deployment on MPL caused its failure is something greater than 50%. The probability that the MARDI/PACI issue caused it is a very small number (1:100000 would be my off-the-cuff guess). So I'm going with the software bug (which has also already been addressed for PHX.)

From the spacEurope Peter Smith Q&A:
Q: using the MARDI camera has been cancelled. Do you think that the MARDI microphone will be used later on in the mission to record some sounds?

A: The MARDI instrument was found to interfere with the guidance system under rare circumstances forcing the difficult decision to turn it off during the descent. The microphone does work and may be used later in the mission to hear the sounds of the RA scraping on the Martian ice.

[To clarify this answer: the card in the Lockheed-Martin spacecraft computer that handles MARDI data also handles guidance system data, and the problem was with this card, not with MARDI itself.]

From the spacEurope Barry Goldstein Q&A:

Q: Will MARDI and the Mic be used post-landing at all?

A: The MARDI will not be used.

Goldstein's answer certainly sounds definitive and final.

So, best of luck to Phoenix, a mission I used to have something to do with.

Disclaimer: this is all information from public sources. Opinions, if any, are my own.

Glendower:
I can call spirits from the vasty deep.

Hotspur:
Why, so can I, or so can any man;
But will they come when you do call for them?

Sure, but you could argue that the suborbital tourism market was something that might make financial sense. It's far less clear to me that there is any source of revenue that could make commercial lunar missions on the scale of the GLXP worthwhile: the NASA data buy idea has been discussed in many contexts over the years and hasn't gone anywhere in any of them that I can think of.

As the saying goes, "the best way to make a small fortune in aerospace is to start with a big fortune."

But as noted, I could be wrong

If there is any possible way to make money winning the Google Lunar X Prize, I can't think of it. Then again, I didn't get rich in the dotcom boom, either.

Where's D.D. Harriman when you need him?
http://en.wikipedia.org/wiki/D._D._Harriman

I'd bet that there were less than a dozen critical measurements made (age dating and isotopic abundance stuff, primarily), and a whole bunch of essentially trivial and unimportant ones. But I'm not a geologist.

I've been doing pretty much nothing but Mars stuff for twenty years, and I, perhaps more optimistically, view it as job security.

I think you make a very good argument, but I think to really do the tradeoff you have to have a better idea of the kinds of measurements you want to make at a given time and how best to make them. It's often hard to sell big expenditures without knowing what you hope to learn more specifically. It would be more clear-cut if sample return could be done for the cost of, say, 3-4 rover missions, instead of the current estimates, which are in the tens at least.