Staying up late for the conference; looks like all the data from the descent was collected and is being processed (which will take a few days) and confirmation that ground radar was activated and that the rockets fired for at least a few seconds. So all key pieces of hardware did fire and they have telemetry (600 megs!). There will be attempts in the coming days to takes MRO images, but it may be a while to find something that small in the images.

Signal was lost about 50 seconds before planned touchdown. When parachute/backshell should have detached from the lander received telemetry started to deviated from expected. Multiple possibilities on what happened after, and they won't speculate yet. May try to send reset commands in a few days.
AMELIA instrument got science data though, so good news for them!

Hopefully the media will chalk this up as at least a partial success.

Arggh stream kept buffering so missed quite a bit, So the data from the AMELIA investigation was transmitted in real time and recorded on TGO??

hmm lots of interesteing info from Jonathon Amos , quote: Signal received for 19 secs after engines shut off...maybe in free fall.

"Schiaparelli Mars probe's parachute 'jettisoned too early'"




http://www.bbc.com/news/science-environment-37715202

To me this si more than a partial succes since all EDL instruments get activated.This means they've got it mostly right and they Will learn where they'll have to put more margins. They also said they don't rule out Schiaparelli was too low when engines fired. I understood that data started to deviate from previsions at the end of parachute work. Nevertheless they've got radar' and engines fired!
Experience tells that parachute and heat shield lands prety close to the landers. This will help finding the module...and we know where it is NOT sincy Oppy didn't catch it.
Go ESA, you're pretty close.

Sorry to tell that I never heard such assesments during the conference.

Not quite in so many words, however that is what they were indicating.

https://twitter.com/BBCAmos/status/789025342283456513

https://twitter.com/BBCAmos/status/789025867712307200

https://twitter.com/BBCAmos/status/789025046727684100


In the timeline parachute jettison/thruster firing should have occured just 30s before landing.

http://exploration.esa.int/mars/57464-exom...scent-sequence/

I think that it is a mistake that they tried to avoid giving any details on EDM altogether. All the questions they received afterwards
were about EDM. No-one doubts that the lion's share of the science will come from TGO and the EDM was a technology test.
However, one should also be mindful of the fact that the public, who is always footing the bill on these missions, need to be kept informed
(think of passengers in an airplane during an emergency). Coming across as evasive, which in my opinion is what happened here,
puts bees on the bonnet of public opinion, which then propagates to the elected representatives.

I did not like the idea of analogue interfaces when I read it 10 years ago from someone on this site so I am pleased that it is not true. The one thing that I would like to find out is how much of the ablative material was still present on opportunity's heat shield. There was speculation 10 years ago that heat shields could be made lighter in future if this information was known

Its always good to be patient in these situations, as hard as it may be. It is fun for us armchair engineers to try and piece together the clues and come up with our own guesses.

I watched the conference just now on livestream and was left wondering what the next step would be in disclosure of the analysis of the EDL. Looking forward to understanding more.

Either the shock wave or the thrusters should have created a darkish and less saturated patch of less surface dust on the ground, which should simplify the search in HiRISE images, if taken within the next days/sols.

Here is Mars Global Surveyor's first images of the Opportunity landing site in 2004 http://www.msss.com/mars_images/moc/2004/02/09/ Merdiani is very flat and has few features, I think it might be easier to find than other missing landers with MRO.

Also , here are the impact sites of the 75kg tungsten balance weights from Curiosity, which were very clearly seen in the MRO context camera images. https://www.nasa.gov/mission_pages/MRO/mult...a/pia16456.html Schiaparelli weighs about 500kg.

Let see if it enters the category of multiple landings as Phylae. It's possible that it had still some horizontal velocity when hiting the ground. MRO will tell

Question: Schiaparelli carried INRRI, a laser retroreflector. Would any current or planned near-future orbiter actually have come with a laser that could have used this within the next decade or so?

(i assume that dust storms would have made INRRI unusable relatively fast in comparison to units placed on the moon almost five decades ago)

Not sure, but they would take that into account in the design. And there is talk of one being added to Insight as well. Something must be intended but I'm not sure of all the details. I have seen talk of laser reflectors before, and it's possible that a network of them would be built up over time, perhaps allowing very accurate rotation data to be collected to monitor precession (for instance).

MOD NOTE: Two posts set invisible for inciting (and responding to) a debate re the 'success' of this mission-- see rule 2.6.

We're not doing that.

http://russianspaceweb.com/exomars2016-edm-landing.html#mro

Found this via https://twitter.com/cosmos4u/status/789484298143408128

It appears that they may recover the data from AMELIA (the descent instruments). So they might learn something about the atmosphere, and they will certainly have some info about the technology. Not a success, but not a total failure either. Seems Mars-6 (sent back atmospheric data during descent, then crashed) would be a better comparison than Mars 3 (20 seconds of useless signal).

Im guessing this would be in a COntext Camera Image.... all the Curiosity EDL hardware is visible in it too.

Yes, its a CTX image; low res, but that settles it... http://www.esa.int/Our_Activities/Space_Sc...li_landing_site

HiRISE images next week.

This is an extreme "cup half full" interpretation, but the chance to observe impacts of known mass and velocity helps very much to interpret the natural impacts which are regularly observed on Mars, the mass and velocity of which are unknown. So, while this outcome was not desired, there is a benefit. The operational failure is a disappointment, but scientifically, the observation of this impact partially offsets the few days' of surface operations that were lost.

There were repeated remarks that the landing would be attempted during the dust season, a first. So how much dusty was the atmosphere at the landing area? Is there any data from Opportunity? And how could it have influenced the EDL?
Fernando

Yes, that's a good point JHReling. I seem to recall the HiRISE images of Curiosity's tungsten counterweights and interplanetary cruise stage impacts were useful in that regard. Saving the AMELIA data is also another bit of silver lining to this cloud.

Small consolation to the rest of the team though; they must be going through something none of us laypersons can imagine. Even I'm having mixed feelings about seeing the high res images next week...

There is currently a significant amount of dust in the Martian atmosphere, at least. Apparently, weather radars are capable of picking up dust storms on Earth, and rain can reduce the performance of radar altimeters. Whether a radar altimeter with poor software or performance could get thrown off by the current amount of dust in the Martian atmosphere is to me an interesting question (and whether Mars' dryness would be relevant here).

EDIT: it's not the altimeter, apparently

53 km's from Oppy, I bet she could reach it.

Lemmon posts very regular tau measurements here. Tau has climbed from its winter low, but at ~0.9 is on the low side compared with previous years.

I looked at Oppy's new images on Midnight Planets and spotted this pic I've not seen yesterday: http://www.midnightplanets.com/web/MERB/im...RP2857L6M1.html

Do you think the two bright spots above the horizon could be Schiaparelli and its parachute? I circled them:
Click to view attachment

Time of acquisition seems too early (2:44:13 PM UTC) but Mike specifies that acquisition times are approximate.

We know from the CTX images that it landed near the middle of the landing ellipses, way below the local horizon, so it can't be. I also withdraw my own speculation from earlier in the thread, given the ground truth.

On top of that, with the landing site over 50 km from Oppy, the pancam pixel scale would mean that those two specks were about 2.4 km apart! (So I guess theoretically possible if taken just after the parachute/backshell separated.)

I see a couple of possibly interesting features on the after CTX image. Marked with the black ellipse is some faint dark streaking that roughly aligns with the main lander splat. And circled is a small dark spot. Both weren't in the before image:
Click to view attachment
It's easiest to see them by flipping between the before and after images. Even though the image is very noisy, both features appear to rise above the noise fluctuations but still could be extreme fluctuations or other artifacts.

Perhaps the streaks, being dark and so perhaps due to removed dust, are associated with the engine firing, and the dark spot the heat shield?

Indeed, I pointed those two out here

They appear to be downrange of the crash site. That's what you would expect for something that continues on ahead of the decelerating EDM.

If the retro-rockets were firing, wouldn't they show up as a streak even in a short exposure?

When pancam auto-exposes images through each filter, it does so until it reaches a specified DN value. If I recall, that is about a DN of 3000. So Images taken with L2 or R2 would have a lower exposure time then say images taken with L6, L7 or R1. You can even see this in the raws as you approach the blue and UV end, the images start to get more noiser from CR hits and hot pixels since it takes more time to reach the specified DN. So I'd expect L6 images would be in the few second range and If schiaparelli went through the FOV (which is now extremely unlikely if not ruled out since we know where it landed), I would think it would leave a small streak. Images taken with R2 would be a fast exposure and would likely not show a streak at all.

These images were likely not autoexposed, but you're ignoring the fact that these are frame transfer cameras and would show artifacts with anything moving in the scene, which would probably lead to some kind of streaking for fast-moving objects regardless of exposure time. That said, the team looked at these images and said they saw nothing but cosmic-ray hits, so I'd say leave it at that.

A minuscule tribute to the ExoMars team. I have updated the kml file with the latest CTX images and also reviewed and extended the text of the several item's descriptions. Zoom in to see the "after" image. Enable (check) the "Hardware" to get small icons of Schiaparelli and its parachute.
Fernando
Click to view attachment

One way to rule out the streak in

http://qt.exploratorium.edu/mars/opportuni...ARP2857L6M1.JPG

as being from Schiaparelli is to examine the times involved. From the filename, the above image was taken at 530160694 seconds in the epoch beginning on January 1, 2000 at 11:58:55.816 UTC. Using a J2000 calculator and subtracting the 64.2 seconds until 12:00:00 would put the image acquisition at 2016-10-19 14:50:29.799 UTC. However, the loss of signal from the Schiaparelli lander reportedly occurred about a minute before the scheduled landing time of 14:48 GMT (= UTC). Thus, the lander would have already crashed before the image was taken, unless I have made some error in my calculation.

The time in the file name is an SCLK value and drifts around in a way tabulated by the NAIF group http://naif.jpl.nasa.gov/pub/naif/MER/kernels/sclk/mer1.tsc . According to the quick Python program I just wrote (below) this time corresponds to 2016 OCT 19 14:51:27. But your conclusion is right. I'm not sure how the imaging times for the MER imaging were commanded but this seems late.

The images were taken with fixed exposure times to minimize a streak. The contrast was expected to be low, even in the unlikely event the lander came to a part of the sky where Opportunity had a line of sight. So, spreading the sub-pixel feature over lots of pixels would just further reduce it.

The few red images were to mitigate against model error or tau change--the contrast was predicted to go through 0 within the Pancam bandpass. But they were few due to bits and to image timing. Pancam is slow; slower still in the rover's current operational mode. Tests ahead of time struggled to demonstrate a way to go fast--generally, when the images have gone fast, subframes were used. So, after the first 5 images (4 L, 1 R), there was no chance. I was expecting ~6 L images, and was betting the descent would be a little later and farther downrange (not having a better option--imaging from inside the crater was like looking for your keys under the streetlight, even if you thought you might have dropped them off in the dark spot off to the left).

Reported in Anatoly Zak's website:

"By October 24, engineers narrowed down a possible culprit to an error in the software of the Schiaparelli's Doppler radar altimeter, which misled the main computer into thinking that the spacecraft had already reached the landing altitude."

That sounds like something you should catch during testing on the ground (Earth ground, that is)

Maybe the radar caught the heatshield flying down in its line of sight...

It might be, but the way the sentence is phrased points to a coding issue instead.
A simple unit conversion problem, for instance: alt=4km -> alt=4m.
Not to suggest that this is actually the culprit, just an example.

That would be mind blowing if the sequences of landing were placed entirely within the control of the just switched on radar without some background logic going on dealing with the timing of the descent. I would think that even if the craft overshot or undershot its target a bit, the overall timing of events would still end up within a few seconds of the expected and any results coming back from the radar which were way out of those parameters should be considered suspect. I'm a computer programmer but have never been involved in code for spacecraft so I'm talking only from the standpoint of someone that has written code where mistakes could cost a lot of money. You put in what ifs and alternate paths for the logic in those critical events. Of course I have the luxury of not having the decisions come at me over a very short span of time. I'm curious how NASA would handle this in code. Radar would seem to be a critical component but what would software do if the results from it made no sense?

I've been writing code since 1970 (when the world was "young and uncomplicated" ), but I never dealt with real-time, or near-real-time handling code which, I suspect, Schiparelli must use, and imposes a lot of constraints on code, including path-length (the time available for a given algorithm to execute).

I red somewhere that it has been mathematically proved that, except for simple cases, it cannot be demonstrated that a program is 100% correct. So, given one has to live with errors, what can be done to minimize them? Software building, coding methodologies can be used. "Proven" code can be reused - as long as the context of the proof remains valid for the case at hand and people are aware of it. And, of course, testing. A lot of testing. Automated testing can catch some errors, and test cases are specifically created. Can one foresee everything? Every possible combination of inputs? Some errors are caught by sheer luck, others may remain hidden for a long time, until a rare set of conditions manifests itself. Every time an error is caught its correction is included in the next release of the software. It works for the relatively forgiving environments of every day life. Space is much, much more harsh.

I'm just offering my own experience, not excusing anyone or anything. Sometimes, getting the kinks out of a program, feels harder than landing on Mars [pun intended].
Fernando

According to this audio (transcript) from Deutschlandradio, there was a timeout in the radar altimeter that ultimately made the onboard computer think it was on the ground far too early.

The transcript link above also links:

the EDM mission overview
a paper on the tests performed with the radar
(both in English)

As a career software engineer, I doubt very much if either logical correctness or speed of execution are much of an issue here. The logic of the program is almost certainly a small matter compared to the complexity of the dynamic situation with multiple hardware systems operating in a complex and partly uncertain physical world. Even if a program were proven "correct," if that meant correct given that your radar behaved normally and during the actual landing, the radar experienced a glitch, then the correctness of the program could prove irrelevant.

The speed of modern microprocessors probably exceeds the requirements by more than one order of magnitude.

My take, from the outside looking in, is how to make a system that can save the spacecraft if physical events and the performance of sensor hardware go a bit beyond expected limits. If they go radically outside of expected limits, then the software might not be the problem anyway. But if they go moderately beyond normal expectations, then an ideal system might save the spacecraft whereas a good one might not.

I don't know which, if any, of those possibilities apply here. It seems, though, that telemetry took place past the point when things went wrong, so there's a good chance that we'll eventually know the root cause.

I would like to know if ESA released a test article out of an airplane at 20K feet to test the system in real-time/real-world....
I would love to see that film...

Logical correctness is always an issue. As an unrelated example, MPL failed because of a lack of proper software debounce in the contact sensor that detected landing. I guess you can call that dynamics, but I'd call it a logical failure. At any rate, however you characterize them, software errors can be stupid and simple or extremely subtle or anywhere in between. If I had to make mistakes, I'd prefer to make subtle ones, but failure is failure and nothing much would surprise me in this case.

English language article saying main hunch is a computer glitch; it may have thought it was on the ground already, and the scientific instruments even turned on!

http://www.nature.com/news/computing-glitc...-lander-1.20861

At least it should be easier to fix than a hardware problem (all of which seemed to perform flawlessly).

One of the difficulties of landing on Mars (among others) is the inability to do a full EDL rehearsal on Earth. Software verification and validation is all well and good, but if you cannot test your system in its entirety, all bets are off. We just don't know what happened (yet), it could be a subtle logical error only apparent in Mars environment or a simple error like the big-endian/little-endian mix up that doomed MGS. However, the whole point of Schiaparelli EDM lander was an end-to-end testing of the EDL system, and as such, it was a very successful test.