MSL data in the PDS and the Analyst's Notebook, Working with the archived science & engineering data Options

[Airbag]

An INDEX.TAB file would work (for instance I see one for APXS) , but there is no NAVCAM subdirectory at the MSL top level. I guess that data has not been added to the FTP area yet.

Airbag

[Greenish]

Question - is there a way to download (say) all the .LBL files for a specific instrument for a range of sols all at once instead of selecting them one by one manually?
Airbag

Not sure about LBL specifically but you can easily grab all or some of the data files for a specific instrument for a range of sols using the search tab. Enter the sols of interest, select the instrument (say navcam) and select the data types (e.g. EDR) if you only want certain data. Hit submit. Then you can use the checkboxes to add whole sols or expand the tree to add individual items to your cart. When you checkout you can get the whole thing zipped or ask for a webpage of links, which includes the data and LBL files separately. You can save all of those links or I know some download managers (i.e. DownloadThemAll or Flashgot) can then grab all the .LBL files. It also looks like in future it may provide an option for a FTP script to be generated.

I did see somewhere a wget option in a corner somewhere but haven't been able to find it again.

[kemcab2012]

Interesting. A quick look reveals that the headers on some of the NAVCAM .IMG files don't start with the standard LBLSIZE or PDS_VERSION_ID metadata labels like most VICAR/PDS formatted files do. These start with ODL_VERSION_ID, with LBLSIZE popping up 26k later in the file.

Looks like they updated the PDS imaging tools back in 2011 for this. I'll need to update my own software as well.

[Airbag]

Ah yes, thanks, the Atlas Search has exactly what I am looking for, and the wget script creation option lets me grep out just the .LBL files if needed later.

[Greenish]

The MSL .IMG files do seem to be viewable with the gimp by installing the PDS plugin (http://registry.gimp.org/node/1627 or http://areo.info/gimp/).

[Airbag]

This is the kind of thing I was looking for (just out of, well, curiosity...); some sample engineering data. In this example, the NAVCAM left instrument and CCD temperatures at the time each image was taken, for a range of sols. No big surprises here - the more the instrument is used, the warmer it gets - but it (or at least the sensor) cools down very quickly again when not in use. As for any good CCD camera, the CCD temperature is kept as low as possible. It is interesting to see how much colder the instrument was later in the day on sol 45 as compared to the more typical early afternoon images.

The data came from the .LBL files associated with each NAVCAM EDS product. Well, it's a hobby!



Airbag

[JohnVV]

NAVCAM .IMG files don't start with the standard LBLSIZE or PDS_VERSION_ID metadata labels like most VICAR/PDS formatted files do.

Mind you if you use the wget option
the labels might NOT work
there is a known bug , some of the closing "end sections" are missing and some vicar data is included
-- NOT every one but a lot are affected --

downloading the zip file might be better for use in ISIS3

The MSL .IMG files do seem to be viewable with the gimp by installing the PDS plugin

that is an ancient plugin for gimp2.2

you might want to use "gdal_translate " in GDAL or FWTools3
or Bjorn's "img2png"

the old gimp plugin outputs to a 8 bit INDEXED image
just like "nasaview"

[Greenish]

I was careful to say you could see the images, not necessarily use them for anything special:)
Seriously, though, thanks for the heads-up. So far as the plugin, there is a recent version 2.8 file so it is at least kept up to the Gimp releases... And since img2png didn't work at all I thought some folks might find it useful in the interim. The images are at least not contrast stretched like the jpgs. Since the readme specifically doesn't mention the rovers, I was pleasantly surprised it worked at all.
I didn't know about the gdal tool, will check that out at some point.

[kwan3217]

The EDL spice kernels are not up yet. Perhaps those are the files that are held up in ITAR?

Bummer, that and MEDLI are the interesting things to me on this mission.

[Gerald]

I wonder, whether these visualized sol 80 Boom 1 Wind counter data

based on this Sol 80 REMS file and the associated TAB-File indicate a vortex event.

EDIT: I think, I've got it: There is a gap of 15 seconds of recording after row 19099 (timestamp 404574363), which I didn't notice before. So the peak will probably be an artifact.

[Phil Stooke]

This is a comparison of the route map in the Analyst's Notebook (top, a set of screen shots) with the latest HiRISE image of tracks and my UMSF route map. My LPSC poster is a comparison like this for Spirit and Opportunity maps (to show the difference between localization using MOC, early in the mission, and HiRISE now). So I thought I would do this comparison with the new map in PDS.

Very interesting comparison. First, look at the right side. The rock Jake Matijevic can be seen in HiRISE and my map as a black dot (arrowed by the sol 45 marker at right edge, bottom map). On the PDS map it's offset to the north. Similarly a crater between sols 40 and 41 is offset to the north in the PDS map. Actually what's happening is, the PDS map has its traverse offset to the south a few meters relative to the HiRISE base. That persists along its whole length... except between sols 29 and 38. There, the PDS traverse is shifted north to exactly the right place, causing an offset at each end of that segment which clearly does not exist in the HiRISE tracks - it must be based on a different localization result.

(PS the similarity between my map and the HiRISE is not a coincidence, I edited my map to fit HiRISE)

Phil

[Gerald]

Based on REMS data:
"REFERENCE_COORD_SYSTEM_INDEX = 3" in "PLANET_DAY_NUMBER = 29" (subdirectory for Sol 28)
"REFERENCE_COORD_SYSTEM_INDEX = 4" in "PLANET_DAY_NUMBER = 30" (subdirectory for Sol 29)
May be, the offset has something to do with the switch from Coord System 3 to 4.

[Phil Stooke]

Yes, I expect so - the basic idea being that dead reckoning from the start of the previous coordinate system took them off track a bit, but then a new localization at the start of the new site coordinate system put them back where they should be. A new error crept in again later.

Phil

[Gerald]

Next error near Sol 58? There seems to be the switch from Frame 4 to 5.
A second mere coincidence should be unlikely.

[Phil Stooke]

No, the offset at sol 29 is 'corrected' by a second offset at sol 38, and after that the routes stay together pretty closely. There's just that one strange departure from the proper path. So it may have been caused initially by a change in coordinate systems, but most changes are fairly seamless.

Phil