Well, the way this works for the team (and I was pretty involved in this for MPL, PHX, and MSL) is that hundreds of Monte Carlo runs are done and the probability distribution of when major events could happen is calculated. Some parts of the descent are pretty locked down (for example, powered descent duration can't vary by much because you run out of fuel if it goes too long and you crash if it goes too short) whereas some parts are highly variable (time spent on parachute, for example).

BTW, I can't download the attachment from my last message and maybe you can't either (some forum issue?), but I guess you're not interested anyway.

Attached is a text file with 1-minute sampling from the SPK file https://naif.jpl.nasa.gov/pub/naif/INSIGHT/...e09o_edl_v1.bsp -- items are J2000 time, distance from Mars center in km, and XYZ position and velocity in km from Mars center and km/sec, both in Mars body-fixed (iau_mars) reference frame.

Most of the SPK files on NAIF don't appear to have the landing portion modeled in them, they fly past Mars (atmosphere unmodeled, maybe.)

 edl.txt ( 34.22K ) Number of downloads: 852

Presumably you are still seeing the rotation rate of Mars in the Phoenix data.

However, I'm not sure what the point of doing anything with the Phoenix data is anyway unless you are going to pretend that the Insight trajectory is exactly the same, which of course it won't be.

One could write a very simple program to extract position from the Insight SPK files using the SPICELIB spkezr function, but I don't know how accurately those files try to model EDL.

There are SPICE predict files at https://naif.jpl.nasa.gov/pub/naif/INSIGHT/kernels/ but I don't know how well they model the final descent.

The raw IMU data from Phoenix including angles and rates is at https://atmos.nmsu.edu/pub/PDS4/Version_1.1...ndle_1100/data/ but it's quite difficult to do anything with the raw data.

It would require a large engine and a lot of fuel to get into orbit first, but Viking did do that. You still need a parachute.

If you're talking about aerocapture to get into orbit, I'm not sure why you think it would help landing.

https://marsnext.jpl.nasa.gov/scieng_eng.cfm says that the Mars2020 landing site, for example, has to be below -0.5 km MOLA elevation, with respect to the MOLA geoid. So you can forget about landing on the volcanoes unless you are using purely propulsive landing (no parachutes.)

No.

Not to rain on your parade, but this is extremely unlikely to happen. For past missions the EDL data were released to PDS years after the landing. Even the MSL landing simulation on Eyes wasn't based on realtime data AFAIK.

https://www.nytimes.com/2018/10/26/science/...arsia-mons.html
"The clouds form when water-laden air is pushed upward along a mountain. Cooler, thinner air cannot hold as much water, causing some of the moisture to condense and freeze, forming clouds."

Presumably Arsia gets these clouds more often due to its specific topography and its location relative to the winds driven by global circulation. All of the volcanoes get clouds at times. See "The seasonal behavior of water ice clouds in the Tharsis and Valles Marineris regions of Mars: Mars Orbiter Camera Observations", Benson et al, https://www.sciencedirect.com/science/artic...019103503001751 (paywalled, unfortunately.)

They are files that capture the position and orientation of spacecraft and solar system bodies, used for mission planning and data analysis. https://naif.jpl.nasa.gov/naif/aboutspice.html

If NASA Horizons does what you want, then by all means use it. I'm not certain how frequently it's updated, however.

There are SPICE kernels for Orex at https://naif.jpl.nasa.gov/pub/naif/ORX/kernels/ -- AFAIK this is what the flight team is using.

Case in point:

https://www.theguardian.com/science/2018/oc...s-sample-return

Paywalled, but this is the most technical description I could find.
https://ieeexplore.ieee.org/document/7119257

Near as I can tell, most of these flash issues have been more about software and less about hardware. For the internal flash in our instruments on MSL, I intentionally used the simplest possible flash management code, all written in-house, instead of a more featureful but more complex file system. So far, so good. Our application, by design, is not very stressing. For example, erasing is pretty rare.

A lot more to it than that -- see https://www.nasa.gov/audience/formedia/fact..._factsheet.html and (for more technical details) https://descanso.jpl.nasa.gov/monograph/ser...er4--141029.pdf .

Compressed data was stored on the tape recorder; some particles and fields data was stored in memory buffers. There was a tape recorder anomaly early in the mission that would have further degraded data return, but they managed to work around it.

Galileo. They didn't solve the problem and the mission only returned a tiny fraction of the planned data. They compressed the data heavily to try to get back as much as possible. [Mods, obviously this thread is misplaced.]

ADMIN: Not anymore.

Yes. Making them cross-strapped would have added more complexity.

When I first read this I assumed that there was an error in the captions: at a little under 10,000 km range Bennu is only 3.7 pixels in Polycam? But it's true, and that just goes to show how dinky Bennu is. Polycam's IFOV is 13.5 urad so at range R Bennu (246 meters mean radius) subtends 0.246*2/(R*13.5e-6) pixels.

I think it's simply a coincidence. Even if dust got into the rovers, the electronics are conformally coated to protect against shorts from loose metallic particles.

Some significant fraction of martian dust is magnetic, so it's probably also electrically conductive.

Pretty much the same way you calibrate anything, you use calibrated blackbody sources of known temperatures and then you assume the camera stays stable over operating conditions, or you calibrate it over those conditions in ground testing.

While I'm sure you appreciated this, it's worth noting that the uncertainty only applies to the START_TIME, the interframe time is set by the JDEA and has nothing to do with the spacecraft clock.

For on-orbit images, I've had some luck characterizing the START_TIME by doing limb fitting of the first image that contains the limb. It would be interesting to know if there are any systematics of the error, but none were apparent in my brief look at it. The cruise star imaging appeared to be behaving differently with regard to the error.

Neither, sort of? It's complicated. The software sends the command to start imaging over a 57600 baud UART and that command is received and imaging starts based on the free-running oscillator in the JDEA. Meanwhile, back in the spacecraft computer, there is then a potentially variable delay before the timestamp is captured from the spacecraft clock.

Yes, the spacecraft clock is quantized, but the delay is of order 20 msec for reasons having nothing to do with that. The delay could be 20 msec and it could be 40 msec and it could, perhaps, be anywhere in between or even longer. I don't think it can be shorter but I can't swear to that.

I can't go into this in more detail, sorry.

It's a software issue having to do with when the timestamp is captured relative to when the command to start imaging is sent.

Selective quoting on your part?



The fact of the matter is that not much can be determined from the HiRISE image, but clearly people want to believe that the rover is very dusty, since that's an explanation for why it hasn't woken up yet.

Read https://descanso.jpl.nasa.gov/DPSummary/Des...MSL_Telecom.pdf although unlike the MER equivalent it was written pre-launch and doesn't have any of the post-launch experience data.



The RLGA on MSL is quite limited for downlink as the mission was designed to be mostly reliant on the HGA and on UHF passes. The RLGA can support 40 bps to the 34m net for some Earth-Mars ranges but at some ranges it can't even manage 10 bps (see figure 4-11).

But I don't know if they've been using the LGA or, if so, how much.

Go back and read the last update and note that it said "Because the amount of data coming down is limited, it might take some time for the engineering team to diagnose the problem".

You don't want to rush these things.