Help - Search - Members - Calendar
Full Version: MSL data in the PDS and the Analyst's Notebook
Unmanned Spaceflight.com > Mars & Missions > MSL
Pages: 1, 2, 3, 4, 5
Phil Stooke
"February 27, 2013. MSL Release 1, part 1, Sols 0-89.

The first release of MSL data takes place in two parts.

Part 1, February 27, 2013, includes raw data products (EDRs) acquired on Sols 0 through 89, August 6 through November 5, 2012, for these instruments: APXS, ChemCam, DAN, Hazcam, Navcam, and REMS, along with SPICE data.

Part 2, March 20, 2013, will include the derived data products (RDRs) for Sols 0 though 89 for the APXS, ChemCam, DAN, Hazcam, Navcam, and REMS instruments, along with both the EDRs and RDRs for the CheMin and RAD instruments, and the RDRs for the SAM instrument.

Release 1 does not include data from the MAHLI, MARDI, or Mastcam instruments. These instrument teams have not yet delivered data products to PDS.

Some documents in the MSL archives are awaiting clearance by JPL Document Review and/or the JPL Import/Export Control Office. They will be posted online as soon as clearance has been received, and announced on this web site."


Phil

Phil Stooke
"Mars Science Laboratory (MSL) #1 On HOLD by the MSL Project

February 26, 2013: The first MSL EDRs (Sols 0-89) for Hazcam and Navcam is pending. "



Still not quite there yet! - not in the planetary image atlas anyway. But at Geosciences, ChemCam images are in.

Phil
renee
MSL Release 1 Announcement:

The NASA Planetary Data System announces the first release of data from the Mars Science Laboratory (MSL) mission, covering data acquired on Sol 0 through Sol 89, August 6 through November 5, 2012.

This release takes place in two parts. Part 1, February 27, 2013, is the release of raw data sets from the following instruments:

Alpha Particle X-ray Spectrometer (APXS)
Chemistry & Micro-Imaging (ChemCam)
Dynamic Albedo of Neutrons (DAN)
Hazard Avoidance Cameras (Hazcam)
Navigation Cameras (Navcam)
Rover Environmental Monitoring Station (REMS)
Spacecraft, Planet, Instrument, Pointing C-Matrix, and Event kernels (SPICE)

Part 2, March 20, 2013, will include derived data sets for the above instruments, along with these additional data sets:

Chemistry and Mineralogy (CheMin) raw and derived data
Radiation Assessment Detector (RAD) raw and derived data
Sample Analysis at Mars (SAM) derived data

Release 1 does not include data from the MAHLI, MARDI, or Mastcam instruments.

Links to all MSL data sets may be found on the PDS Geosciences Node web site http://pds-geosciences.wustl.edu/missions/msl/. The data may also be reached from the main PDS home page, http://pds.nasa.gov/. MSL data are archived at the PDS Atmospheres, Planetary Plasma Interactions (PPI), Geosciences, Imaging, and Navigation and Ancillary Information Facility (NAIF) Nodes.

PDS offers two services for searching the MSL archives:

The Planetary Image Atlas at the Imaging Node allows selection of MSL image data by specific search criteria.
http://pds-imaging.jpl.nasa.gov/search.

The MSL Analyst's Notebook at the Geosciences Node allows searching and downloading of all MSL data in the context of mission events.
http://an.rsl.wustl.edu/msl. The Analyst's Notebook will be available starting February 28, 2013.

Some documents in the MSL archives are awaiting clearance by JPL Document Review and/or the JPL Import/Export Control Office. They will be posted online as soon as clearance has been received, and announced on the web site http://pds-geosciences.wustl.edu/missions/msl.

To receive email announcements of future releases of MSL data, please sign up on the PDS Subscription Service at http://pds.jpl.nasa.gov/tools/subscription_service/top.cfm.

The PDS Team
Phil Stooke
Yes, folks, now the nav and haz images are in the Planetary Image Atlas!

Phil

jmknapp
The recent PDS release included some NAIF files for sols 0-89. Not sure how absolutely accurate they are yet, but here's an animation based on them, from sol 34, I think the first time the robotic arm was used extensively (MAHLI took some images from underneath the rover):

http://www.youtube.com/watch?v=-kxF6Fo-EOg
elakdawalla
Oh that is cool. You can see them imaging the cal target and pointing APXS at its cal target toward the end, I think.
Phil Stooke
Nice! And I see that the rock Jake Matijevic was originally called Musk Ox... I'm collecting some new feature names.

Phil

fredk
Joe, could you compare an actual mahli image that shows some of the rover with a render from the model mahli at the corresponding time? I'm curious how accurate the rendered view of the rover will be. Of course you may see differences due to the optical distortions in the (real) mahli system.
jmknapp
Well, I don't have a way as yet to automatically set up the animation software to show the view of a particular camera, but as a manual test take this MAHLI shot:

0034MH0067001000E1_DXXX 10SEP2012 01:36:28 UT.

Positioning the RA per the NAIF files at that moment gives this:

Click to view attachment

A wire frame sketch of the model "movie" camera is shown above, which I positioned by hand to more or less match the MAHLI orientation. Here's another angle:

Click to view attachment

OK, so, drum roll, here's how the scene is rendered by that camera:

Click to view attachment

Not too far off! I used the MAHLI focal length of 21mm and f/9.8. The aspect ratio is different.

fredk
Nice job! Did you spin the model wheels manually so the morse cutouts matched the real positions?
djellison
So as of now, img2png + MSL Navcam IMG's = no joy.

I'd imagine Bjorn's already on it smile.gif

Airbag
I'm just lost in the flood of information available there; the Mission Manager and SOWG documents alone could keep my busy for a long time.

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
elakdawalla
You can do it via FTP, right? http://geo.pds.nasa.gov/dataserv/anonftp.html
Airbag
Well, only to some extent it seems - for instance, when I go to ftp://pds-geosciences.wustl.edu/msl/ (or ftp://geo.pds.nasa.gov/msl/) there are no Navcam entries there while they are available via the Analyst's Notebook. Am I looking in the wrong place?

Airbag
elakdawalla
I usually don't use FTP; I download the INDEX.TAB file in the INDEX folder and use that info to build lists of things that I want that I then use wget to grab. I haven't tried this for the MSL data, but there's got to be a way.
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
QUOTE (Airbag @ Mar 1 2013, 01:55 PM) *
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!

Click to view attachment

Airbag
JohnVV
QUOTE
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

QUOTE
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
Click to view attachment
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
Click to view attachment

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
jmknapp
They released some more sol 0-89 data to the PDS today:

The NASA Planetary Data System announces Part 2 of the first release of data from the Mars Science Laboratory (MSL) mission, covering data acquired on Sol 0 through Sol 89, August 6 through November 5, 2012. Part 2 consists of derived data products. Release 1, Part 1, took place on February 27, 2013, and consisted of raw data products.

Part 2 consists of derived data sets from the following instruments:
Alpha Particle X-ray Spectrometer (APXS)
Chemistry and Mineralogy (CheMin)
Hazard Avoidance Cameras (Hazcam)
Navigation Cameras (Navcam)
Rover Environmental Monitoring Station (REMS)
Sample Analysis at Mars (SAM)

Release of the following data sets has been delayed. The data sets will be released as soon as they are made available to PDS.

Chemistry & Micro-Imaging (ChemCam) derived data
Chemistry and Mineralogy (CheMin) raw data
Dynamic Albedo of Neutrons (DAN) derived data
Radiation Assessment Detector (RAD) raw and derived data

Release 1 does not include data from the MAHLI, MARDI, or Mastcam instruments.

Links to all MSL data sets may be found on the PDS Geosciences Node web site http://pds-geosciences.wustl.edu/missions/msl/. The data may also be reached from the main PDS home page, http://pds.nasa.gov/. MSL data are archived at the PDS Atmospheres, Planetary Plasma Interactions (PPI), Geosciences, Imaging, and Navigation and Ancillary Information Facility (NAIF) Nodes.

PDS offers two services for searching the MSL archives:
The Planetary Image Atlas at the Imaging Node allows selection of MSL image data by specific search criteria.
http://pds-imaging.jpl.nasa.gov/search.

The MSL Analyst's Notebook at the Geosciences Node allows searching and downloading of all MSL data in the context of mission events.
http://an.rsl.wustl.edu/msl.

Some documents in the MSL archives are awaiting clearance by JPL Document Review and/or the JPL Import/Export Control Office. They will be posted online as soon as clearance has been received, and announced on the web site http://pds-geosciences.wustl.edu/missions/msl.

To receive email announcements of future releases of MSL data, please sign up on the PDS Subscription Service at http://pds.jpl.nasa.gov/tools/subscription_service/top.cfm.

The PDS Team

Mailto: pds_operator@jpl.nasa.gov
PaulH51
QUOTE (jmknapp @ Mar 21 2013, 03:13 AM) *
They released some more sol 0-89 data to the PDS today:

Thanks Joe,

I am going through the PDS learning curve, and learning a little, but still have a lot to learn. Can I ask if you have found any "REMS Ground Temperature" info in the PDS? I saw your posts in another thread regarding 'REMS Air Temperature' Thought it best to post here this time.
Gerald
The ground temperature may most likely be provided by some of the thermopiles. With thermopiles you can measure temperature from a distance.
jmknapp
Haven't looked at it closely myself yet, but I think the column definitions are in this file:

http://atmos.nmsu.edu/PDS/data/mslrem_1001/LABEL/ENVRDR1.FMT

...and as Gerald says, look for the thermopile data, such as:

QUOTE
COLUMN_NUMBER = 17
NAME = "BRIGHTNESS_TEMP_A"
UNIT = "KELVIN"
FORMAT = "F7.2"
DESCRIPTION = "Brightness temperature of the GTS Thermopile A
(band 8-14 um)"
DATA_TYPE = ASCII_REAL
START_BYTE = 187
BYTES = 7


So that looks like it might even be calibrated to temperature (K), although it's brightness temperature which I gather is not the same as "real" ground temperature ("kinetic temperature") from this reference:

Description of the REMS Ground Temperature Sensor aboard MSL NASA mission to Mars

PaulH51
QUOTE (jmknapp @ Mar 22 2013, 03:16 AM) *
...and as Gerald says, look for the thermopile data, such as:

Many thanks Gerald and Joe smile.gif
jmknapp
OK, here's a taste of some calibrated REMS data, the brightness temperature of ground temperature sensor A during sol 89:

Click to view attachment

The sensor looks at the infrared in the band 8-14 um. Looks pretty noisy, particularly at night. Note that brightness temperature is different than actual temperature. There must be some conversion formula?

The data file for that is:

RME_405347393RNV00890000000_______P1.TAB


Generally the files with the temperature readings have "RNV" in the file name.

The column definitions are here:

ENVRDR1.FMT
mcaplinger
QUOTE (jmknapp @ Mar 25 2013, 09:47 AM) *
Note that brightness temperature is different than actual temperature. There must be some conversion formula?

You need to know, or assume, the emissivity of the surface in order to do that conversion. The brightness temperature is the temperature that a black body of the observed IR radiance would have.
jmknapp
That would explain how it's a bit high.

According to the reference above:

QUOTE
The use of two different bands to measure ground temperature allows the estimation of the emissivity of the surface by means of colour pyrometry algorithms.


...so the ground temperature reading is evidently a function of the thermopile A & B readings.
Gerald
You'll be close to a solution by dividing the two values, because (by gray-assumption) the emissivity cancels out, see http://en.wikipedia.org/wiki/Pyrometer.

Then by applying Planck's, or for simplicity, Wien's law you may get close to the absolute temperature, see http://en.wikipedia.org/wiki/Wien_approximation.

My rough approximative ad-hoc idea is, to divide the values of Wien's (or better Planck's) law for the respective mean measured wavelengths for any given fixed temperature, and compare it with the measured quotient.
More accurately, Planck's curve for a fixed temperature multiplied by the sensivity of the respective thermopile (as a function of wavelength) has to be integrated over the wavelength.

The underlying principle is, that the quotient of the emissions of a black or grey body at two fixed wavelengths is temperature-dependent, and provided by Planck's law. Restricted to an appropriate temperature interval the quotient determines temperature uniquely.

Some adjustment might be necessary due to IR absorption by CO2 or dust coating. This may be a second step.

EDIT: By the two values I meant the sensor values as defined in raw data, B1_IR_OUT_2 and B1_IR_OUT_3, rover-induced fluctuations removed, and calibrated for power or radiance. It's not easy, nevertheless.
jmknapp
I had a feeling calculus might be involved--a more direct route would be to get the paper submitted to the EGU by Gomez-Elvira et al, maybe they said exactly what they do.

Failing that, wouldn't the brightness temperatures in effect already be the result of integration or other analysis of the raw data? I.e., a sample at a particular time says that the ground looks like a gray body radiating at 265K for the A band (8-14 um) and 273K for the B band (16-20 um). Maybe the conversion to actual temperature from those data points isn't too involved.

P.S. I'm trying to track down this reference cited by the authors:

http://www.ncbi.nlm.nih.gov/pubmed/16642125
mwolff
If you are after ground temperature, then the Zorzano reference will not really help. They are using measurements at two different temperatures (and two channels) to reduce the uncertainty associated with the instrument calibration. They are interested in the time series of temperature differences because this is the more important quantity in sensible heat flux characterization. As mentioned by M. Caplinger above, you need to know the emissivity of the material to get absolute temperature. The observed radiance is equal to the emissivity times the Planck function (ignoring atmospheric effects); calculus not needed if you believe your assessments of radiance and emissivity. The hard part, and the subject of the Zorzano paper, is dealing with getting radiance accurately from the instrument measurements. If you want to send me a message, I am sure that one can find you a copy of that paper.
jmknapp
The thing is, the emissivity can't be determined a priori, right?

Thanks for the offer, but I was able to get a copy of the paper. By taking the measurements at two different temperatures (in practice, two different times of day) and two wavelength bands it looks like they were able to get within maybe 6K on the individual measurements and less than 1K for the difference.
Gerald
The paper can be read online here.
Now I understand better how the thermopiles work internally.
But I didn't find an answer, how to estimate the emissivity; there is mentioned an estimate of somewhere between 0.9 and 1.0, depending on the composition of the ground.
A 10% uncertainty means up to about 27K near 0°C.
The influence of reflected sun light is estimated to be below 0.5%.

As quotient of the Planck function for Kelvin temperature T, and two different wavelengths frequencies nu and mu, I got
(nu/mu)^3 x exp(4.8 x 10^-11 x [(mu-nu)/T] s K),
s = second, K = Kelvin, 4.8 x 10^-11 is Planck's constant h divided by Boltzmann's constant k.
(no errors assumed)
This avoids emissivity by cancelling out, if it is assumed to be the same for both wavelength frequency bands.

By taking 11 um for mean wavelength thermopile A and 18 um for mean wavelength thermopile B, one could try to avoid calculus in a first attempt.

Using the brightness temperatures instead of the radiance sounds good, especially because they will already be calibrated. I'll need to think a bit, how to do it exactly.

EDIT: The above formula just shows, how emissivity cancels out, but to be useful, integrals of the Planck function over the respective wavelengths have to be divided, with the same cancellation effect. Hard to avoid calculus or a numerical solution at the end.

With the very rough assumptions and the formula above, and without calculus, I get
T = 509 K / ln (0.228 q), with q = I(18 um) / I(11 um).
Still to solve is, how to calculate I(18 um) and I(11 um) from the brightness temperatures.

P.S.: In the meanwhile I found the calculus version here. (The paper uses the wavelength version of Planck's law.)
mwolff
QUOTE (jmknapp @ Mar 27 2013, 10:11 AM) *
The thing is, the emissivity can't be determined a priori, right?


Not in the way you are suggesting. With wavelength resolution and broad enough coverage, IR remote sensing has "exploited" the Christiansen frequency to have a region where the emissivity was ~1. You are probably aware of the TES products, but just in case:
(http://tes.asu.edu/products/). This approach is much more applicable from orbit, unfortunately.
jmknapp
Just going by some comments in the Zorzano paper.

QUOTE
Let us perform two measurements... with two sensors operating at different wavelengths... Standard two-color pyrometric techniques use the ratio...

All the geometrical dependencies cancel out, but any wavelength-dependent factor remains. (For instance, the medium absorption, sensor response, and target emissivity may differ from one wavelength to the other.)


Also, they say regarding the Planck equation:

QUOTE
This is true for a perfect blackbody radiator, but in the general case the radiance must be multiplied by the emissivity. The emissivity is a wavelength-dependent quantity that depends mostly on the material’s exact composition as well as the surface roughness, angle of observation, surface oxidation and contamination, particle size, level of compaction, etc. These factors are difficult to be known accurately a priori...

The user must know the emissivity to get the correct temperature value; thus this technique is not useful to explore unknown targets. In ratio pyrometry intensities are measured simultaneously at two different wavelengths and divided. The resulting representative equation is solved for temperature assuming that the spectral emissivities in both ranges are equal and are canceled in the division. This method works only if the emissivity is the same at both wavelengths, but, again, it is not useful for a general case.


They don't talk about Christiansen frquency but that sounds interesting. Thanks for the link to the TES maps.
Gerald
Planck's function isn't linear, and it's dependent of the absolute temperature. So it should be possible to infere the absolute temperature from the brightness temperatures at two known wavelengths and two different temperatures...
Under ideal conditions, in theory.
Before doing theory in detail, I first checked the data to find out, whether it can work in practice.
The intermediate answer is: Not in a straightforward way.
Emissivity seems to change with time, and in a different way for the two frequency bands A and B.
The first reason I could isolate is warm-up. Here some statistical analysis of 18 warm-ups on sol 89 for brightness temperature A, based on this Sol 89 REMS RDR file:
Click to view attachment

The first diagram shows brightness temperature A for the first 100 seconds of 18 warm-ups, adjusted by average and stretched by respective standard deviations.
The second diagram averages over these 18 curves.
The third diagram smoothes the latter curve by averaging over a window of 10 seconds.
It shows a significant average increase of brightness temperature A during warm-up.

So a first step to get better data, will be to apply the last column (column 63) of the referenced table, indicating warm-up, not just to pressure data as described in this FMT file, but also to brightness temperatures.

EDIT: Some number-crunching later: Radiance at 250K and 11um seems to be much less (about factor 5) sensitive to emissivity near 1 than to absolute temperature (use Planck function with 250K at 11um as brightness temperature, and divide it by the value at 255K as absolute temperature; the result is the corresponding emissivity). So an emissivity of 0.9 will lead to an absolute temperature 5K above brightness temperature (near 250K). I overestimated emissivity in the beginning. Although I didn't yet investigate, how the emissivity quotient influences measurement of absolute temperature by dividing radiances of two wavelength bands (two-colour pyrometer).
Gerald
Here the simplified theoretical principle for the two-colour pyrometer to calculate absolute temperature and the emissivities at two wavelengths from brightness temperatures, as far as I could infere it from Planck's law:

Input data: Take the (measured) brightness temperatures Tb_11 and Tb_18 at two frequencies nu_11 = c/11um and nu_18 = c/18um.

Algorithm:
Apply Planck's function to retrieve measured radiances I_11 := I(nu_11, Tb_11) and I_18 := I(nu_18, Tb_18).
The graph of the according Planck functions is shown in the left of the two diagrams:
Click to view attachment

Now start an iteration with initial emissivities E_11 = E_18 = 1:
Calculate a modified radiance quotient by Q := (I_11 / E_11) / (I_18 / E_18).

Calculate absolute temperature T_abs := T_abs(Q) for a given radiance quotient Q by applying the inverse function of the quotient I(nu_11,T)/I(nu_18,T) of the Planck functions (restricted to an appropriate temperature interval).
The graph of I(nu_11,T)/I(nu_18,T) is shown in the right of the two diagrams above.

Apply the Planck function to T_abs, to get the black body radiances I(nu_11, T_abs) and I(nu_18, T_abs) at T_abs for nu_11 and nu_18.
Calculate E_11 := I_11/I(nu_11, T_abs) and E_18 := I_18/I(nu_18, T_abs) to get better approximatives for the emissivities.
Repeat the iteration until T_abs changes less than a given epsilon; abort with an error, if it doesn't converge after an upper bound of iterations.

If the iteration converges, we get absolute temperature, and emissivities at both wavelengths.
jmknapp
Have you tried this on the time series yet? In one of the press conferences they had a chart of ground temperature vs. time that could be used as a rough check. Another issue would be how best to deal with the noisy raw data.

On the "warm up" effect--what does that refer to exactly? Like when the readings are taken after an idle time of an hour or so? Looks like they normally take readings every second for a few minutes every hour, with occasional longer stretches.
Gerald
I'll answer the easy questions first:
Most of the noise can be averaged away by appropriate low-pass filters, if it is purely statistical, because temperature changes are slow; the simplest way to do it, is just averaging over a few dozens of samples; a more advanced way is using appropriate regression curves.
Example for simple averaging over 40 samples:
Click to view attachment
Again based on this Sol 89 REMS RDR file.

About warm-up I know just that little info from the FMT-file; it referes to pressure data:

QUOTE
OBJECT = COLUMN
COLUMN_NUMBER = 63
NAME = "PS_CONFIDENCE_LEVEL"
DESCRIPTION = "String representing the confidence level for the
pressure sensor; 0 = bad; 1 = good;
- Byte 0: Warm up effect (only for barocap 1)
0 = warm up effect; 1 = no warm up effect;
- Byte 1: Shadow effect; 0 = shadow effect;
1 = no shadow effect;"
DATA_TYPE = CHARACTER
START_BYTE = 568
BYTES = 8
END_OBJECT = COLUMN


Warm-up seems to take 180 seconds at the beginning of each series of measurements, at least on sol 89.
Gerald
QUOTE (jmknapp @ Apr 1 2013, 05:11 PM) *
Have you tried this on the time series yet? In one of the press conferences they had a chart of ground temperature vs. time that could be used as a rough check.

The simplified answer is: No, not yet, but a good idea for a better calibration.

A little more detailed: I also looked at the UV data. They are less noisy. I tried to get a 5-point absorption spectrum of atmospheric trace gases, that form or degrade after sunrise. For this I had to do a very detailed analysis. Doing this, I also found a jiggering caused by truncation of numeric values, and indications for superposed sinus oscillations with a period of about 300 to 350 seconds of unknown origin, might be due to my way of data analysis, may be due to data analysis done by the REMS team, or due to technical properties of the sensors, like a combination of inductivity and capacity.
Similar systematic errors may also occur for brightness temperature data. Accurate results for absoute temperatures can only be obtained, after those systematic effects are annihilated. Therefore I was focussed on that.
The only thing I had been doing, was dividing the Sol 80 EDR raw thermopile A/B data to see, whether they can be used as two-band pyrometer data, and it looked good, but calibration wasn't available to me.
It will take me a while to elaborate things in more detail.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2018 Invision Power Services, Inc.