It looks like we both just got an email

I went and spoke to Julie Cooper up in the library today - they're going to pull it from the vault today and I'll get eyes on it hopefully tomorrow. If those pages are obviously better - I'll encourage them to re-digitize the whole thing....but I'll grab the pages you need with my phone in the mean time!

The Caltech lib-guide search suggests is here at the JPL library....I can visit them, see if I can get eyes on it.

Is it just those few miss-printed table values you need? Pages 73 to 82?

The exposure times will end up in the PDS delivery in a few months....but spoiler alert - for the 8 frames..

9.7, 9.8, 11.0, 14.6, 23.0, 35.6, 49.9, 68.8 seconds.

I’ll double check the exposure times when I get in to work tomorrow.....the last one we did a few sols ago they were 12 seconds or so. This time the images had a ‘wait’ between frames - but these could be several tens of seconds or longer.

They’re incredible. I’m sure Mark L and I will be conspiring to do more of these in the coming months.....I have ideas

If you do a row of shots from bottom to top - the little blast from each set of shots in turn scatters some grains back over the previous hole - leaving a little trench. The last hole doesn't get covered over.

We also took a complete Navcam deck pan to gap fill below the M34 imagery on the following sol at the same time of day

https://mars.jpl.nasa.gov/msl/multimedia/ra...mera=NAV_RIGHT_
https://mars.jpl.nasa.gov/msl/multimedia/ra...amera=NAV_LEFT_

Cunning trick for you. If you see a front hazcam from a given sol with the seqID fhaz00190 - then the drive aborted early as that's the off-nominal front hazcam image ( same with rhaz00190 on the rear hazcams ).

The post drive imaging will usually still execute, so you'll see fhaz00302 and rhaz00311 (the regular end of drive hazcams) but the *haz00190s are both in the best priority bin of any imaging, so will come down before anything else. If you see other post drive imaging and no 190's - then it usually means a drive completed normally.


FWIW - I think the 2365 drive was supposed to be a short bump of 2m or so - I think it ran fine ( I see no fhaz00190 )

We put up a smokey-bear type sign next to the RPs workstations.... ONLY YOU CAN PREVENT FHAZ00190

The paper itself contains nothing of merit beyond those images really.

That site seems to be accurate to within about 15seconds of what I'm seeing on the ground.

First frame took longer to execute as the mast had to slew from stowed up to the pointing, and then iterate the auto-exposure a couple of times.

Second frame was at 18:40:14, and the last at 18:43:13 - time between frames was around 7.5 seconds ( we didn't command a pause - that's just as quick as you can take images with the NavCams with some options turned off to speed things up)

Sunset was 18:40:26, but 'local' sunset behind the back of the Vera Rubin Ridge was probably a little earlier than that.

What my version of it using the raw JPGs looks like. And a whole thread of discussion about it right here : https://twitter.com/doug_ellison/status/1110748122831978496

Kudos to FredK for figuring it out before I'd even seen the images

Well spotted

Update : https://www.jpl.nasa.gov/news/news.php?feature=7339

They are. Apart from a bayer filter, they're the same as MER and MSL. Whilst they can be commanded with a manual exposure, they are almost always operated with an auto exposure algorithm that will look to reach a certain signal threshold. In excess or short of that threshold, the same image will automatically be attempted with another exposure either longer or shorter. This process will sometimes loop a couple of times before a 'good' image is acquired. The exposure time for THAT image is then carried forward as the seed exposure time for the next image on that camera.

If you look at the label of any engineering camera product submitted to the PDS you will see the parameters for this process set in the sequence that acquired the images.

Code could be written to process those images. Most of the image processing code that's used today is very very heavily derived from the code written pre-Voyager

What's not working are the cameras and scan platforms on the spacecraft. They were turned off decades ago to save power to avoid browning out the spacecraft.

I CAN'T FIND MY BOTTLE OF LIPOVITAN D

I don't really know what words to use.

Without MER - (and more specifically, with Steve and Jim committing to that policy of releasing all that raw imagery) there would be no UMSF.

Fromthe first image I ever posted here, this feels like the place where Opportunity and Spirit's adventures were documented more thoroughly, with more passion and dedication and creativity, than anywhere else. That wasn't my doing - it was this entire crazed community of like minded explorers.

Without UMSF I'd never have got the chance to meet people from MER and from JPL - I'd never have been invited to speak at conferences about we band of merry armchair astronauts exploring the solar system through the vicarious use of all the amazing data that gets thrown out into the digital ether

And they would never have been crazy enough to ask me to work at JPL back in 2010. I'd never have got to work on Eyes on the Solar System and the MSL landing animation and DSN Now and all the other cool projects I did in the EPO world here. I'd never have worked with the innovative folks in the OpsLab using the HoloLens to let people 'walk' on Mars. I'd never have started training for Ops as an ECAM PUL on MSL, and with those skills, become an ECAM/MI PUL on Opportunity, even if for a brief spell. We would never have taken that crazy selfie on Sol 5000. I don't think JunoCam would even exist without MER proving that the outside world can be entrusted to take good data and make great things with it.

And personally - because of the hospitality of people like Paolo, Alice, Veronica, Scott - Pasadena became home. Most specifically, without Scott I'd never have met my amazing wife Jenn, and our little girl Amelia - about to turn 14 months old - would not exist. MER was, in every way, life changing. And it was life changing for so many other people as well.

Today, at our farewell celebration press conference, I will wear my MER Sol 5000 shirt with immense pride.

How far we've all come.

I'll leave it with the note I left on Monday's on Quill ( MER's note taking and reporting portal for operations ) on the Engineering Camera page for Sol 5352

Indeed - she was not messing around- from that same Wiki Page...

And the deck pan you posted on the 22nd is designed to fill in the gap on the Mastcam mosaic you just posted

I got a note from MSL Dept.Proj. Scientist Joy Crisp on this.....

The DEM scale is M, so about 15cm across the entire thing. Incredibly flat.

I've done a V2 of my workspace model, complete with WebVR scaling - https://sketchfab.com/models/038d4924308f4c...00fe492b1450997 - I think it's to approx the right scale - I used the width of the blue margin in this image - https://photojournal.jpl.nasa.gov/catalog/PIA22874 - as a guide ( as the blue margin represents the radius of the SEIS WTS I believe )

As a result - take these with a pinch of salt - but an orthoimage and a dem with a 50cm grid overlay, attached.

This pdf -https://ttu-ir.tdl.org/ttu-ir/bitstream/handle/2346/59518/ICES-2014-64.pdf


Charts - especially on pages 14 and 15 - show the WTS, combined with a small heater on SEIS itself - makes quite a dramatic different to the temperature swings experiences by SEIS.

I had a quick go at generating a workspace model. It's incredibly flat. Pretty much the dream scenario for instrument deployment.

https://sketchfab.com/models/be1b893b28814b...9c35368b9508943

OK - Wow - that's pretty epic for a the Ka band in 12 U. Has anything like that flown yet? MarCO had the benefit of the investment in the IRIS Xband package developed for INSPIRE (which, ironically, is still on a shelf)