The Top of Vera Rubin Ridge Part 2, Site 67-73, sol 1944-2297, 24 Jan 2018-22 Jan 2019 Options

[PaulH51]

Drive during 1944, L-NavCam pan roughly stitched in MS ICE be should be good to help pinpoint the location. (the plan called for a 25 meter drive south)
(delete after proper version is posted)

[PaulH51]

I realise that MSL has lost chunks of memory from both of its A and B computers, and can only presume that this is connected to the recent swing to nearly all the new full frame colour images from the mast cameras (since the last computer glitch) being placed on the public server as compressed bayer encoded files. I also realise that its more than a little late in the mission to expect JPL to create a pipeline to de-bayer these before compressing them to colour jpeg's prior to placing them on the public server like they have done with the MAHLI images since landing. It's a huge pity as I believe it's an enormous loss in outreach, take the R-MastCam images from sol 2287 as a prime example, I can only imagine how wonderful they are with the artefacts I get during de-bayer.
So I'm hanging up my hat for the time being on MSL and will leave all the processing of mast camera panoramas / mosaics to those with the skills to do justice to these images. Hopefully they will put something in place for the images from the 2020 rover, fingers crossed they will be friendly for those amateur image processors like me or even the public who browse the mission image server only to find the vast majority of the images in 'apparent' B&W, without knowing that most of them are actually in glorious colour, but sadly masked by the bayer filters...

[mcaplinger]

I realise that MSL has lost chunks of memory from both of its A and B computers, and can only presume that this is connected to the recent swing to nearly all the new full frame colour images from the mast cameras (since the last computer glitch) being placed on the public server as compressed bayer encoded files.

It's unrelated to the memory problems (whatever they are, I haven't heard the details and "lost chunks of memory" may not be accurate). If the downlink volume allows it, people would rather have the raw data than JPEG.

As I've said before, I've complained myself about the inappropriate use of JPEG on Bayer encoding to everyone who would listen, but it's not up to me obviously. Complaining about it here is not productive and probably a rule 2.6 violation.

[PaulH51]

Re memory loss I refer to Emily Lakdawalla's recent Curiosity Blog (Sol 2163-2256) link

I have highlighted pertinent sections of Emily's post

The B-side Anomaly:
On September 15 (sol 2172), engineers noticed the rover behaving oddly: it was not transmitting any saved science or engineering data, but could transmit engineering data acquired in real time as long as it was communicating with the Deep Space Network or an orbiter. The rover was perfectly healthy, having no issues running any of its vital systems, but had lost access to the part of its memory where it stores data for later retrieval. The data structure of that part of the rover’s memory had become corrupted, and the rover couldn’t access it. This was, clearly, a serious problem for science, but fortunately didn’t threaten the safety of the rover.

Still, the fact that the rover couldn’t store information for later retrieval made it very difficult to troubleshoot the issue. The mission determined that the best course of action was to swap to the backup computer; once they were on the backup, they'd be able to troubleshoot the (formerly) main computer. Curiosity has been operating on its B-side computer for nearly 2000 sols, ever since sol 200, when a serious problem occurred in the A-side computer’s flash memory. It took until sol 772 to recertify the A-side computer for use as a backup to the B-side computer; a software patch now prevents the A-side computer from using half of its flash memory.

Curiosity returned to limited operations by sol 2204, and had resumed science planning with the full team on sol 2216. This is a remarkably fast recovery, given the ridiculous quantity of work the team had to do -- and how carefully they had to do it -- to return the rover to its A-side computer. Meanwhile, unlike with the sol 200 anomaly, the B-side computer is still available as a backup to the A-side one, if anything happens; Curiosity would be safe running on the B-side one, it just wouldn’t be able to do science.

Since Emily's update, further diagnostics on the B-side computer anomaly were planned over the long holiday period at the end of 2018 link. I have not seen any news re those planned diagnostics over the holidays. So the way I understand the current situation is we have only 50% of the original flash memory on the A-side. The B-side computer can not currently be used for science, because we cant read from its memory. Hence my comment of missing 'chunks of memory'.

Re: (jccwrt) The multispectral observations can readily be identified by the associated thumbnails which are stored as colour jpeg's, so I dont count those, but there has been an increase in the numbers of compressed bayer files. We are even seeing compressed bayer encoded R-MastCam frames that that are acquired to provide context for the RMI images of ChemCam targets (eg link)

My post was not an attempt to break rule 2.6, just noting the obvious change in the ratios of images being received since the anomaly which precludes folk like me who have extremely limited skills and very limited software tools to do the processing that can be done with those compressed /encoded images by others members. And the hope that this situation is avoided on future missions for outreach purposes. If my post breaks rule 2.6 by criticizing this mission on the basis of hindsight and/or incomplete information, I'm only using the publicly available information I am aware of from Planetary Society blog posts and JPL mission updates.