XLUM-file Format Documentation

version: 1.0 [2023-03-20] |   download as PDF

1 Motivation and principles

This document details the XLUM format, an XML based file format for long-term data preservation and exchange of luminescence data. The format is readable by humans and machines, and the data can be easily checked with any text reader on any major operating system. This design allows a platform-independent operation. The following documentation provides essential information on the file XLUM format and accounts for the needs for individual flexible data analysis, even with self-written software applications.

Three simple design principles underpin the format specification:

  • Stored are data recorded over time or time derived instances,
  • stored are data on a technical component level,
  • data stored in a file are self-consistent.

2 General description

The XLUM-format is an XML derivative. The base data structure is a tree with five nodes types storing the data. Each level has its unique denotation.

The levels and a short introduction is given in the table below. A detailed description can be found in the following sections. Nodes represent each level in the structure. Only <curve> nodes contain physical quantities, such as luminescence data all other nodes are parent nodes of <curve> to structure the dataset and ship additional metadata.

The first level, xlum is a root node to enable storage of luminescence data in arbitrary files following the XML scheme. As a side effect this also allows custom file endings different from *.xlum.

Node overview
Node nameNumber of samplesNumber of aliquotsNumber of recordsNumber of data curves

A node has a name, attributes, and data stored in it. The data stored in the attributes describe the state of this level. The stored data in the node describes the process(es) assigned to the node. A minimal example is shown in the listing. The documentation provides an overview starting with the leaf node description and going up to the root from there. Further notes:

  • The format version bases on XML version 1.0 (Fifth Edition)
  • File encoding should always be UTF-8
  • This specification lists only mandatory attributes. Additional, custom attributes are explicitly supported.
  • Parser supporting the XLUM format must not crash when encountering non-specified node attributes. However, they may skip them.
<?xml version="1.0" encoding="utf-8"?>
          1 2 ... n

3 Detailed description

3.1 The <curve/> level

The <curve/> level is the deepest node (leaf) and has no further sub-levels. A curve holds the predefined/simulated or measured output of one single technical component. For example, a typical thermoluminescence measurement may consist of one or many curves.

  1. The one curve example: Time against temperature. In this case temperature is a processed quantity, because measurements happen over a time instant. However, for compatibility reasons, this would be allowed although it is not preferred.

  2. The three curve example: (a) Time against temperature recorded by a thermocouple (temperature sensor), (b) time against photon counts recorded by a photomultiplier tube, (c) time against a predefined heating ramp.

In both cases, all mentioned <curve/> nodes belong to one parent <record/>. In case 1, the record contains one curve and three in case 2. Ideally, curves represent technical components and not processed quantities.

3.1.1 Value storage

Numerical values in the <curve/> node are stored white space separated. Only quantities detected by a detector/sensor are stored in this node. This includes simulated values. Figure 3.1 shows three types of (luminescence) detectors, distinguished by their capacity to record spatially resolved information. Regardless of the detector, recorded quantities are stored in the <curve/> node separated by white space. Example:

<curve>59.5167 109.5164 149.7003 109.5170 156.2654</curve>

Values in the node are real numbers (-1e-307 \(\leqslant x \leqslant\) 1e+307; \(x \in \mathbb{R}\)). Scientific ‘E’/‘e’ notations of numbers are explicitly allowed, example: 1e+2 for 100 or 1e-2 for 0.01. Decimal separator is a . (dot). Other separators, for instance to separate groups of numbers are not allowed to avoid decimal delimiter problems. Examples:

  • 10000.00 -> OK
  • 10 000.00 -> NOT OK
  • 10,000.00 -> NOT OK

To reduce the size of the file, for instance for image data, the string in <curve/> can be stored using base64 encoding. It is up to the parser to decide whether the string was encoded or not! Encoding in other places (attributes) is not supported and must not be expected by the parser.

Please note that the XSD document does not specify binary encoding because it considers all values in <curve/> strings (which can represent encoded values).

For consistency reasons, the value in the node span an array with dimensions defined through the node attributes xValues, yValues and tValues (see Fig. 3.1).

The three cases for data storage depending on the detector. The black solid arrows indicate how the array is constructed from the values stored in the node.

Figure 3.1: The three cases for data storage depending on the detector. The black solid arrows indicate how the array is constructed from the values stored in the node.

  1. The simplest form is a detector that records no spatial information. For instance, a photomultiplier tube only knows about count recorded over time. Alternatively, the detector can be any sensor, measuring, e.g., temperature, pressure or current.

  2. A spectrometer (here a camera in front of a spectrograph) is another type of detector with spatial information, here wavelengths split by the spectrograph hitting different pixel areas of the detector.

  3. The most complex from is a detector that records events (e.g., luminescence), spatially resolved. Such as a camera.

In the examples and Fig.3.1 the detectors detect luminescence. However, any type of sensor, electronic component recording information of relevance for the measurement of luminescence are suitable. Typical examples:

  • Temperature sensor (thermocouple), recording the temperature of the heating element
  • Photo diode, monitoring the optical power density at the sample position
  • Resistor, measuring the current of a LED
  • Pressure sensor, monitoring the atmosphere in the measurement chamber
  • Inductive sensor, monitoring closing and opening of a shutter

3.1.2 Node attributes

Specified curve attributes. Attributes in [] are optional, hence NA is not allowed.
IdentifierTypeAllows NA?ExampleInformation
componentstringyes"EMI 9235QB15"name of the technical component. NA allowed only for "predefined"
startDatedateTimeno"2021-07-14T22:59:35.0Z"ISO 8601-1:2019: YYYY-MM-DDThh:mm:ss[.mmm]Z recalculated to Zulu time
curveTypestringno"predefined"Values allowed are only "predefined" or "measured"
durationnumberno"20.000"Duration of the detection in seconds or a fraction of it
offsetnumberno"10.000"Before the detection starts in seconds or a fraction of it
xValueslist unsignedIntno"1 2 3"x-coordinate values of the detector; 0 indicates that that this parameter is not used
yValueslist unsignedIntno"1 2 3"y-coordinate values of detector; 0 indicates that that this parameter is not used
tValueslist doubleno"1. 2.0 3.0"time values in seconds or fractions of it. Values must be positive
vLabelstringno"Luminescence"Measured physical quantity
xLabelstringyes"pixel"label of the x-coordinate values
yLabelstringyes"pixel"label of the y-coordinate values
tLabelstringno"time"label of t-values, usually ‘time’
vUnitstringno"cts"label of the v-values, for luminescence usually photon counts
xUnitstringyes"nm"SI unit or equivalent for x-values
yUnitstringyes"px"SI unit or equivalent for y-values
tUnitstringno"s"SI unit or equivalent for t-values
detectionWindowstringyes"375"Centre wavelength if applicable. can be set to NA
filterlist (string)yes"Hoya U340; Delta BP 365/50EX"Filter names separated by ;

3.1.3 Example

In order to define a suitable standard only a few attributes are required. A few of them are useful for every kind of component, others are only meaningful in combination. For instance, providing information on the detection window is not meaningful for a heating element.

  <curve component="heating element" startDate="2021-02-14T22:57:00.0Z" 
    curveType="predefined" duaration="5" 
    offset="0" xValues="NA" yValues="NA" 
    tValues="1 2 3 4 5" xLabel="NA" yLabel="NA"
    tLabel="time" vLabel="temperature" xUnit="NA" yUnit="NA" vUnit="K" tUnit="s">
        293 303 313 323 333
  <curve component="thermo couple" startDate="2021-02-14T22:57:00.0Z" 
    curveType="measured" duaration="5" 
    offset="0" xValues="NA" yValues="NA" tValues="1 2 3 4 5" xLabel="NA" yLabel="NA"
    vLabel="temperature" tLabel="time" xUnit="NA" yUnit="NA" vUnit="K" tUnit="s">
        293 303 313 323 333
  <curve component="EMI 9123QB15" startDate="2021-02-14T22:57:00.0Z" 
    curveType="measured" duaration="5" offset="0" xValues="NA" yValues="NA" 
    tValues="1 2 3 4 5" xLabel="NA" yLabel="NA"
    vLabel="luminescence" tLabel="time" xUnit="NA" yUnit="NA" vUnit="cts" 
    tUnit="s" detectionWindow="380 nm" filter="Hoya U340 + Delta 365/40">
        20 25 32 41 46

One curve is related to one technical device. To define a accurate time window, the parameters duration and offset should be used. These parameters are related to the start of the parent <record/> node.

3.2 The <record/> level

A <record> defines one process involving many components, hence <record> may contain \(1\leq n\leq Inf; n \in \mathbb{Z}\) <curve> nodes. A record can also be understood as one step in a measurement sequence, e.g., a TL measurement. All curves within the record should have been detected within the same time frame defined through the attributes <startDate> and the duration of the step.

3.2.1 Attributes

Allowed attributes for <record> node.
IdentifierTypeAllows NA?ExampleInformation
recordTypestringno"TL"valid values according to the recordType table
sequenceStepNumberunsignedIntyes5index in the sequence
sampleConditionstringyesdosevalid values according to the table below

The recordType names are not carved in stone, but should be chosen to best describe a record in one word or using an accepted abbreviation (e.g., OSL for optically stimulated luminescence). However, it is important to keep in mind that the recordType makes no claim on the technical components involved, but is solely set to ease the understanding of the record. The hard physical information is stored in the <curve> node.

Valid recordTypes
"bleaching"any kind of bleaching
"irradiation"irradiation with ionising source
"atmosphereExchange"atmosphere exchange
"heating"heating without signal detection
"camera"camera, e.g. any kind of imaging other than spectrometry
"TL"thermoluminescence measurement
"ITL"isothermal luminescence
"IRSL"infrared stimulated luminescence
"TM-OSL"thermally modulated optically stimmulated luminescence
"UV-RF"radiofluorescence with detection in the UV wavelength range
"IR-RF"radiofluorescence with detection in the infrared wavelength range
"IR-PL"infrared photoluminescence
"OSL"optically stimulated luminescence (wavelength unspecified)
"BSL"blue-light optically stimulated luminescence
"GSL"green-light optically stimulated luminescence
"VSL"violet-light optically stimulated luminescence
"YSL"yellow-light optically stimulated luminescence
"POSL"pulsed optical stimulated luminescence
"custom"any undefined or custom record type not listed above

Valid entries for for sampleConditions are given in the following table:

Valid values for sampleConditions
"Natural"natural luminescence signal
"Natural+Dose"natural luminescence signal with additive dose
"Bleach"artificially depleted luminescence
"Bleach+Dose"artificially depleted luminescence with an additive dose
"Nat.(Bleach)"artificially bleached natural luminescence signal
"Nat.+Dose(Bleach)"artificially bleached natural luminescence with added dose
"Dose"artificially irradiated sample

Please note that the attribute sampleCondition is of informative nature, accounting for information stored in BIN/BINX-files. The field can be set to NA.

3.2.2 Example

The following examples consists of two records.

    <record recordType="GSL" sequenceStepNumber="1" sampleCondition="NA">
      <curve ...>
      <curve ...>
    <record recordType="bleaching" sequenceStepNumber="2" sampleCondition="NA">
      <curve ...>

3.3 The <sequence/> level

A sequence describes multiple measurements sequentially used at one aliquot, for instance as cup/disc with multiple grains or a single grain. Hence, another aliquot from the same sample and the sample sequence needs to be wrapped in a new <sequence/> node. Naturally the information stored an that level can be very verbose, but are limited to
a few required attributes only. In the luminescence context a sequence can fit, e.g., a SAR protocol, but also a succession of protocols measured on one aliquot.

3.3.1 Attributes

Mandatory attributes <sequence> node
IdentifierTypeAllows NA?ExampleInformation
positionnumericno"42"position of aliquot in the reader, can be 0 in case samples are changed manually, i.e. the equipment has only one single measurement position
namestringyes"SAR measurement"name of the sequence
fileNamestringyes"SAR_OSL.seq"sequence file so far applicable
softwarestringyes"Sequence Editor 4.4"software used to write the sequence if applicable
readerNamestringyes"Risø OSL/TL"name of the luminescence reader employed for the measurement
readerSNstringyes"234-23"reader serial number
readerFWstringyes"reader OSL 12.3"reader firmware version

3.3.2 Example

<sequence position="1" name="SAR measurment" 
  fileName="Testsequence.seq" software="DeviceStudio, 2.37">
  <record ...>
    <curve ...>

3.4 The <sample/> level

The sample constitutes the top level for one particular sample. The sample level may contain an infinite number of sequences measured for one sample.

3.4.1 Attributes

Mandatory attributes <sample> node
IdentifierData typeAllows NA?ExampleInformation
namenumberyes"LUM-21321"unique sample identifier
mineralstringyes"quartz"dominant mineral composition of the sample
latitudenumericyes"52.4091392"latitude in decimal degrees of the sample origin
longitudenumericyes"-4.0702446"longitude in decimal degrees of the sample origin
altitudenumericyes"50"altitude in m above see level
doianyURIyes"10.1016/j.radmeas.2017.02.003"valid DOI with further information on the sample, if applicable

3.4.2 Example

  <sample name="LUM-21321" mineral="quartz" latitude="52.4091392" longitude="-4.0702446"
   altitude="50" doi="10.1016/j.radmeas.2017.02.003">
    <sequence ...>
      <record ...>
       <curve ...>

3.5 The <xlum/> level

The <xlum> is the format parent node and it can contain an infinite number of samples. Only this level allows to set a license for the distribution and usage of the data. All data within a particular <xlum> are considered distributed under the license. You have to create new instances of the <xlum> to set different licenses.

3.5.1 Attributes

Mandatory attributes of <xlum> node
IdentifierTypeAllows NA?ExampleInformation
xmlnsnamespacenopredefinedFormat specific namespace
langstringnopredefinedISO 639-1 language code, must not be changed
versionnumericno"1.0"the xlum format version number relevant
flavourstringno"generic"allows to specify a particular flavour of the format, for instance for particular equipment
authorlist(string)yes"Max Planck; Marie Curie"names of the author(s) of this dataset
licensestringyes"CC BY 4.0"license for the distribution of the dataset.
doianyURIyes"10.5281/zenodo.596252"A digital document identifier referencing the dataset already archived in a data repository
Allowed license types
licenseLicense nameReferenceComment
"CC BY"Creative commonshttps://creativecommons.orgall flavours of the creative commons license scheme (e.g., CC BY-SA, CC BY-NC)
"CC0"Creative Commons Public Domain Dedicationhttps://creativecommons.orgyou give up the copyright on your data and make it public domain. Please note this cannot be revoked!
"Copyright"Copyright protected-Data are copyright protected and cannot be used or distributed without the creator’s agreement

3.5.2 Example

<xlum xmlns:xlum="xlum.org" lang="en" 
  formatVersion="1.0" flavour="generic" author="Marie Curie; Max Planck" 
  license="CC BY 4.0" doi="NA">
  <sample ...>
    <sequence ...>
      <record ...>
        <curve ...>

3.6 General parameters (all nodes)

A few attributes are available on all node levels except the root node <xlum>. These attributes are mainly of technical nature to ease the sequential data storage during the measurement process (such as parentID).

Attributes valid in all nodes
IdentifierData typeAllows NA?ExampleInformation
statestringyes"recording"defines the state of the node; only used by equipment manufactures
parentIDtokenyes"201007145551910"uniquely identifying the parent node, the root node has the ID 0, this is usually not needed but may help to store data
commentStringyes"what a wonderful sample"comment field

4 Special cases

This section provides suggestions for attributes for particular types of measurements. These attributes are not compulsory, but if needed should be used for the sake of consistency.

Please note: these metadata are not required to store and analyse the data!

4.1 Pulsing data (optional)

In measurements with pulsed light stimulation, data processing usually requires summations of photon counts on the hardware level using so-called field-programmable gate arrays (FPGA). It is neither meaningful nor feasible to store single counts in separate curves for photon arrival times of \(10^{-6} \leq \tau \leq 10^{-3}\) s. Hence, multiple detectors <curve/> data may be stored per <record/>, one for each (x) pulse(-s). In those cases, the <record/> node contains additional metadata that may help understand the data and pre-processing by the hardware level better. All attributes are optional.

Additional metadata <record/> node pulsing data
IdentifierData typeExampleInformation
onTimenumeric"1E-01"on time of stimulation per pulse, [s]
offTimenumeric"1E-01"on time of stimulation per pulse, [s]
nPulsesnumeric"10"number of stimulation pulses total
summationsnumeric"2"how many consecutive pulse records are summed (e.g. 10 pulses, 2 summations -> 5 records)
channelsPerPulsenumeric"1000"number of channels that are recorded in one curve
countsNormalisednumeric"1"if not 0, counts per channel are normalized to counts per second (helpful with uneven distributed channel times)

Also the curves contain additional metadata

Additional metadata <curve> node pulsing data
IdentifierData typeExampleInformation
pulseIDnumeric"1"current pulse number

5 Practical examples

This section contains detailed examples for particular curve types in order to provide usable examples for the data format.

<?xml version="1.0" encoding="utf-8"?>
<xlum lang="en" version="1.0" flavour="xlum" doiRef="">
 <sample ...>
  <sequence ...>
   <record ...>
    <curve ...>
     12 23 23 23 13 23

6 Appendix

6.1 Risø BIN/BINX to XLUM metadata argument matching

Risø BIN/BINX files consist of a metadata header block and a data block. Some of the metadata serves the sole purpose of describing the structure of the data block, others return the specific equipment status but are non-relevant for the data analysis.

Most BIN/BINX metadata is covered by the XLUM format by design and hence finds their expression implicitly. The following argument list contains all possible arguments in BIN/BINX files, however, not all BIN/BINX file versions support all arguments. Covered here are BIN/BINX files between versions 03 to 08.

#BIN/BINX argumentExpression in XLUMRemarks
01VERSIONNONEnumber of BIN/BINX file version
02PREVIOUSimplicitcovered through XLUM structure
03NPOINTSimplicitcan be calculated from data
04RECTYPENONEfile format internal metadata
05RUNimplicitstructure through order in <sequence/>
06SETimplicitstructure through order in <sequence/>
07POSITIONpositionin <sequence/> node
08GRAINimplicita grain is considered a sample
09GRAINNUMBERimplicita grain is considered a sample
10CURVENOimplicitthrough structure
11XCOORDNONEconsidered non-relevant
12YCOORDNONEconsidered non-relevant
13SAMPLEnamein <sample/> node
14COMMENTcommentallowed argument in every node
15SYSTEMIDreaderSNin <sequence/> node
16FNAMEfileNamein <sequence/> node
17USERauthorin <xlum/> node
18TIMEstartDatein <curve/> node (ISO 8601-1:2019)
19DATEstartDatein <curve/> node (ISO 8601-1:2019)
20DTYPEsampleConditionin <curve/> node
21BL_TIMEimplicitcan be expressed as <curve/>
22BL_UNITimplicitexpressed in <curve/> metadata
23NORM1implicitshould be part of <curve/> representation
24NORM2implicitshould be part of <curve/> representation
25NORM3implicitshould be part of <curve/> representation
26BGimplicitcan be expressed as <curve/>
27SHIFTimplicitpart of curve information
28TAGNONEnon-relevant internal metadata
29LTYPErecordTypein <record/> node
30LIGHTSOURCEimplicitcan be added in comment fields
31LPOWERimplicitcan be expressed as <curve/>
32LIGHTPOWERimplicitcan be expressed as <curve/>
33LOWimplicitnot needed, part of <curve/>
34HIGHimplicitnot needed, part of <curve/>
35RATEimplicitnot needed, part of <curve/>
36TEMPERATUREimplicitexpressed as <curve/>
37MEASTEMPimplicitexpressed as <curve/>
38AN_TEMPimplicitexpressed as <curve/>
39AN_TIMEimplicitexpressed as <curve/>
40TOLDELAYimplicitexpressed as <curve/>
41TOLONimplicitexpressed as <curve/>
42TOLOFFimplicitexpressed as <curve/>
43IRR_TIMEimplicitexpressed as <curve/>
44IRR_TYPENONEcan be added as comment
45IRR_UNITtUnitin <curve/> node
46IRR_DOSERATENONEeither as curve or comment
47IRR_DOSERATEERRNONEonly as comment possible
48TIMESINCEIRRimplicitcalculated from time stamps
49TIMETICKimplicitderived from onTIME and offTIME
50ONTIMEonTIMEin <record/> node
51OFFTIMEoffTIMEin <record/> node
52STIMEPERIODimplicitthrough nPulses in <record/> node
53GATE_ENABLEDNONEconsidered non-relevant
54ENABLE_FLAGSNONEconsidered non-relevant
55GATE_STARTNONEconsidered non-relevant
56GATE_STOPNONEconsidered non-relevant
57PTENABLEDNONEconsidered non-relevant
58DTENABLEDNONEconsidered non-relevant
59DEADTIMENONEconsidered non-relevant
60MAXLPOWERimplicitrepresented as <curve/>
61XRF_ACQTIMEimplicitrepresented as <curve/>
62XRF_HVimplicitrepresented as <curve/>
63XRF_CURRimplicitrepresented as <curve/>
64XRF_DEADTIMEEFNONEpossible as comment
65DETECTOR_IDcomponentin <curve/> node
66LOWERFILTER_IDfilterin <curve/> node
67LOWERFILTER_IDfilterin <curve/> node
69MARKPOS_X1implicitcan be expressed as <curve/> or comment
70MARKPOS_Y1implicitcan be expressed as <curve/> or comment
71MARKPOS_X2implicitcan be expressed as <curve/> or comment
72MARKPOS_Y2implicitcan be expressed as <curve/> or comment
73MARKPOS_X3implicitcan be expressed as <curve/> or comment
74MARKPOS_Y3implicitcan be expressed as <curve/> or comment
75EXTR_STARTNONEusage unknown
76EXTR_ENDNONEusage unknown
77SEQUENCEnamein <sequence/> node

Note: metadata tagged with “considered non-relevant” or “usage unknown” indicate that they are not considered (yet) as relevant enough for long-term data preservation and are hence not to be included as a compulsory argument in the XLUM format definition. However, they can still be stored in the XLUM format regardless.

6.2 Freiberg Instruments XSYG argument matching

The XYSG file format by Freiberg Instruments is already an XML-based file format . It can be somewhat considered the predecessor of the XLUM format. The structure was developed in February 2013 but never formally published, and attributes are not necessarily followed. The main differences are:

  • The XSYG file format consists of only four nodes instead of five. Parent node xlum exists only for the XLUM format
  • Nodes start with a capital letter (e.g., <Sample>, instead of <sample> in XLUM)
  • The individual curves values are stored as a pair-list with values separated by a semicolon ;, in the <Curve> node, i.e., x0 , y0 ; x1 , y1 ; x2 , y2 ; x3 , y3. XLUM uses attributes instead, and values are stored separately through white space
  • For spectrometer data, the XSYG format defines an alternative storage format of values in the <Curve> node of form 1.0 ,[554|555|559|553|556|550| {...}. Contrary, XLUM maintains a consistent storage format.
  • The chosen date format was not ISO conform yyyyMMddhhmmss instead of ISO 8601-1:2019: YYYY-MM-DDThh:mm:ss[.mmm]Z recalculated to Zulu time.

In the following, the XYSG to XLUM argument matching is listed node-wise.

6.2.1 <Curve/> vs <curve/>

#XSYG attributeExpression in XLUMRemarks
01startDatestartDatenote the format difference
06curveDscripterxLabel, yLabel, tLabel, vLabel, xUnit, yUnit, tUnit, vUnitneeds to be split and matched separately
07offsetimplicitcan be encode through the tValues
09filterIDsNONEpurely manufacture related ID
10filterNamesfilterfilter names separated by ;

6.2.2 <Record/> vs <record/>

#XSYG attributeExpression in XLUMRemarks
01startDatestartDatenote the format difference
02endDateimplicitcan be calculated from other attributes
04nameNONEencoded through recordType + comment
06metaIrrTypeimplicitencode through component in <curve/>
07metaIrrDurationimplicitthrough <curve/> node

6.2.3 <Sequence/> vs <sequence/>

#XSYG attributeExpression in XLUMRemarks
02creationDateimplicitthrough startDate of <record/> and <curve/>
04protocolimplicitin name
05mineralNONEvalue to be entered in <sample/> node

6.2.4 <Sample/> vs <sample/>

#XSYG attributeExpression in XLUMRemarks
02userNONEAuthor can be entered in <xlum/> node
03startDateimplicitthrough values in other <curve/> and <record/> nodes
04sampleCarrierNONEentry in general attribute comment possible
05lexsygIDimplicitentry in attributes in <sequence/> node attributes
06lexStudioVersionimplicitentry in attributes in <sequence/> node attributes
07firmwareVersionimplicitentry in attributes in <sequence/> node attributes
08osNONEhowever, entry in comment attribute possible

6.2.5 General attributes

#XSYG attributeExpression in XLUMRemarks

6.3 SUERC PSL argument matching

PSL files are produced by portable luminescence readers produced by the Scottish Universities Environmental Research Centre (SUERC). PSL files are loosely structured ASCII files without format descriptions.

Measured values are stored in essentially five columns (three columns, but total count and count values per cycle include uncertainties), example:

Time (s)        Total Count           Counts per Cycle  
--------   ---------------------   ---------------------
   1              0 +/-    4              0 +/-    4
   2             -2 +/-    6             -2 +/-    4
   3             12 +/-    8             14 +/-    5

These values can be represented in the XLUM format using <curve/> nodes, one <curve/> for the counts per cycle and another for the uncertainties. This solution is safer than adding uncertainties as attributes and more consistent because the uncertainties must have been estimated using a component.

Columns under “Total Count” represent cumulative data that can be recalculated from the values under “Counts per Cycle” should not be stored explicitly in XLUM.

Additionally, PSL provides arguments that can be extracted from those files. The matching listed below is non-exhaustive and represents the current state-of-knowledge about the PSL format.

#PSL metadataExpression in XLUMRemarks
01Run Nameimplicitthrough comment
02Sample nonamethrough name in <sample/> node
03Sequence namenamethrough name in <sequence/> node
04FilenamefileNamein <sequence/> node
05Dark Countimplicitas <curve/> node
06Light Countimplicitas <curve/> node
07Dark Count CorrectionNONEthis is a logical attribute, which can part of comment if needed in the <curve/> node
08Offset SubractNONEthis can be part of comment in <curve/> node
09Datafile PathNONEnot considered relevant
10Summary PathNONEnot considered relevant
11Run Sequenceimplicitthrough name in <sequence/> node
12TimestampstartDatein <curve/> node, please note the different format
13MeasurementrecordTypein <record/> node
14StimrecordTypein <record/> node
15On/Off(us)onTime, offTimein <curve/> node
16Cycle(ms), NonPulsesin <curve/> node

Please note: as for the data formats above, in principle, all arguments can be carried over directly. However, for the sake of consistency, the matching should be applied.