I don't see any signal in the shadow in the raw images that is any brighter than the stray light from the instrument.

Stay tuned, the later images show the shadow even better.

As part of the amusingly-named "straighten up and fly right" (SUFR) maneuver. See https://trs.jpl.nasa.gov/bitstream/handle/2...629/10-1775.pdf

Images have started appearing on missionjuno.

ISRO has their own network, I don't even know if DSN will be used operationally. https://directory.eoportal.org/web/eoportal...s/chandrayaan-2 I couldn't find anything about specific data rates.

On Ka-band, LRO can send data at 100-300 Mbps.

I haven't been able to find very much technical information about this camera beyond this phone image of an old viewgraph about it which I've enhanced a little. I'll be very curious to see how well this performs; the high resolution coupled with a large number of TDI stages (oddly high, actually, I've no idea why they need so many) presents a lot of challenges. LROC NAC was a much more conservative design in most respects.

You're operating under the misperception that the science community is somehow "in charge" of mission architecture decisions. They aren't, except for some inputs at a very high planning level like the decadal survey, NAS, MEPAG, etc. I have already bemoaned the fact that IMHO there is a lot of unwarranted credulity displayed when technologists present to these bodies.

Even at the level of a single science instrument, science input is much more about capability than implementation.

There is every evidence that NASA HQ is making a good faith effort to accomplish MSR under significant budgetary and political constraints. In an ideal world, the MAV would be established and proven technology before such an effort was even planned. In reality, there doesn't seem to be enough money to do that development. So it will have to be done as part of the mission implementation itself, with concomitant cost and schedule risk.

I could go on, but I don't want to run afoul of rule 2.4 ("do not rant").

This is a highly-informed guess but I have never done this specifically myself so I may be mistaken about the details.

camera_origin is the position of the camera in the rover frame (so-called RNAV frame, X pointed forward, Z pointed down), which varies only slightly as a function of pointing and can probably be ignored. camera_vector is the camera pointing vector in the rover frame. To get to actual compass direction you have to account for how the rover is oriented. That's given in rover_attitude as a quaternion that transforms from RNAV to the local level (LL) frame, where X axis points north and Z axis points at the center of Mars. rover_xyz is the position of the rover in the "site frame" which is zeroed every once in a while when dead-reckoning errors have built up beyond some threshold (or something, I don't really understand the details, but which site is current is in the JSON also.)

In SPICE it would take a few function calls to turn rover_attitude into a rotation matrix (q2m) and transform camera_vector into LL (mxv), and then it's just some trig to go from the vector to az/el (or SPICE reclat and some arithmetic.)



I'm less sure what frame the CAHVOR ( https://agupubs.onlinelibrary.wiley.com/doi...29/2003JE002199 ) parameters are in (C is just a copy of camera_origin, looks like), but you don't need those to just get the pointing, they describe the camera field of view, distortion, etc and can be safely ignored unless you were doing detailed photogrammetry.

I suspect that there is very little about the design that is finalized at this point, and many things will be evaluated during development and may end up different.

Discussion about what might change could be interesting, or not.

What kind of pointing information are you looking for?

I daresay a combination of 1) people only being interested in their own little niches, combined with 2) a parade of technologists overselling their capabilities. Not many people seem aware of how immature the specifics of the MAV design are.

That said, I do remain convinced that this is a solvable problem, if the groups involved were given unambiguous direction and funding to solve it. Nothing clarifies a development activity like the opening of a launch window approaching on the calendar. Though I suspect if this ever happens there will be missteps and blind alleys along the way.

From https://dragonfly.jhuapl.edu/News-and-Resou...4_03-Lorenz.pdf (which answers a lot of questions):

In all fairness, I believe this article was written in response to some ESA effort to develop a baseline for the Earth return spacecraft. I've never heard of an international mission where the MAV was provided by ESA.

That said, I agree with you that the MAV continues to get little attention. Maybe JPL is working on it and just not saying much about the effort.

There was a big conference about MSR in Berlin in 2018 (I'm sure discussed on this thread but I haven't checked) -- https://atpi.eventsair.com/QuickEventWebsit...ple-return/home -- which was entirely about how wonderful MSR was going to be without any real mention of the MAV at all.

The most recent NASA/ESA-proposed mission ( http://www.planetary.org/blogs/guest-blogs...t-msr-plan.html ) would launch the sample into Mars orbit in spring 2029 (Earth spring) and leaves it in orbit for 6 months until the Earth return spacecraft grabs it and returns to Earth in spring 2032 using solar-electric propulsion.

You have to get into Mars orbit anyway, so to limit the MAV's time on the surface, just launch the sample and let it wait in orbit.

Of course I'm not holding my breath for any of this to happen.

The Galileo antenna problem was caused by loss of lubricant from multiple truck shipments to and from JPL and KSC, not heating. From https://www.cpp.edu/~gkuri/classes/ece431/G...Workarounds.pdf



That said, it is true that there are thermal impacts from using Venus flybys. Another option that's been discussed is using solar electric propulsion for the sample return.

Based on the limits we had to test the instruments to, I expect temperatures at Jezero to be pretty similar to those at Gale -- lows about -70C min in the summer, -90C in the winter. That doesn't seem like a huge driver to me but it depends on the sensitivity of the MAV.

I haven't worked out what the terminal velocity of the aeroshell would be before chute deploy, have you? The vehicle has to be slowed enough for the deployment/unfolding sequence to work in the first place.

That said, as a rule, autogyros require forward motion to generate lift. You may be thinking of what's called an autorotation in a helicopter. To do an autorotation, you need blade pitch control to reduce your descent rate from the fairly high rate needed to keep the blades turning to a rate low enough for landing, and of course you have very little choice about where you land (you have to commit to a landing spot pretty high up). Dragonfly has no blade pitch control and the small diameter props of a quad don't have enough momentum to do autorotations, on Earth anyway.

The battery is charged at the start of EDL so there's no particular advantage to landing unpowered anyway. The mission profile calls for a long flight traverse before the first landing to find the best landing site.

As I mentioned upthread, even if there weren't export controls it's unclear if ESA would ask or JPL would respond in detail if they did.

There's a certain amount of open-literature info about US Mars parachute development from Viking on. All the failures on LDSD indicate that there are limits to our knowledge on this, though all the ASPIRE testing makes one feel pretty confident in the MSL parachute design.

AFAIK, there's no information yet about this most recent failure, and only a little about the problems in May: https://www.esa.int/Our_Activities/Human_an..._and_challenges



Why the Exomars EDL system needs four separate parachutes when MSL/M2020 only needs one I don't know.

To oversimplify, parachute failures come in two flavors: the parachute fabric tears (sometimes catastrophically), or the parachute fails to inflate ("squidding"). I seem to recall both types of failure in MSL testing, but I don't recall for sure at the moment.

https://en.wikipedia.org/wiki/Not_invented_here

I know this was a joke, but since I'm an engineer I have to point out that an MSL drill hole is about 17mm in diameter and 4 cm deep, and the HP3 mole is 27mm in diameter, so this wouldn't work even if the sites weren't 600 km apart.

https://www.nasa.gov/feature/small-satellit...ars-and-beyond/

I'm not sure if the Psyche launch is available for these and it doesn't really say.

The last image from PJ21 is on missionjuno now.

Mass spectrometry has that limitation, but AFAIK gas chromatography doesn't. And SAM has many wet-chemistry and evolved-gas modes for perchlorates as well.

See, for example, "Evidence for perchlorates and the origin of chlorinated hydrocarbons detected by SAM at the Rocknest aeolian deposit in Gale Crater"
https://agupubs.onlinelibrary.wiley.com/doi...1002/jgre.20144

Correct. Image 33 taken 04:32:27. The dropout is small but goes right across the GRS in one channel (of course.) I'd expect it to be pushed by mid-week next week one way or another.

Beautiful work as always, Kevin. Interesting to compare this to what Damien Peach saw back in June -- http://damianpeach.com/jup19/2019-06-03-0500_3-RGBdp.jpg -- doesn't look all that different except that scalloped stuff to the east seems to have smoothed out.