Log of /yoda/techmodel/physics/S4Reader.cpp
Parent Directory
| 
Revision Log
Revision
6.1 -
(
view)
(
download)
(
annotate)
-
[select for diffs]
Wed Aug 16 08:20:30 2006 UTC
(18 years, 4 months ago)
by
kusanagi
Branch:
MAIN
CVS Tags:
HEAD,
YODA6_3/06,
YODA6_3/07,
YODA6_3/08,
YODA6_3/09,
YODA6_3/10,
YODA6_3/11,
YODA6_3/12,
YODA6_3/13,
YODA6_3/14,
YODA6_3/15,
YODA6_3/16,
YODA6_3/17,
YODA6_3/18,
YODA6_3/19,
YODA6_3/20
Changes since
6.0: +3 -4 lines
Diff to
previous 6.0
Hardware bug in the Neutron Detector.
Volodia wrote:
"There is a bug in ND hardwer. Because of this
the patter of ND sometimes could be changed from '00 00 00 0F'
to '00 00 01 0F'. You can see this in files 915, 917 for 99% events.
I saw also '00 00 16 0F' in several cases.
At the same time S4 QL was also crushed for this files. Why?
I am afraid that it is neseccary to make some correction in
YODA to take into account this problem.
May be , it would be better to check '?? ?? ?? 0F ?? ?? ?? 0F ?? ?? ?? OF'"
Revision
6.0 -
(
view)
(
download)
(
annotate)
-
[select for diffs]
Tue Feb 7 17:11:11 2006 UTC
(18 years, 10 months ago)
by
kusanagi
Branch:
MAIN
CVS Tags:
YODA6_0/00,
YODA6_1/00,
YODA6_2/00,
YODA6_2/01,
YODA6_3/00,
YODA6_3/01,
YODA6_3/02,
YODA6_3/03,
YODA6_3/04,
YODA6_3/05,
yodaPreTermistores2_0/00,
yodaPreTermistors2_1/00
Branch point for:
PreThermistores2
Changes since
5.1: +3 -3 lines
Diff to
previous 5.1
Several new features in this revision:
a) all the packets are conform to the Mass Memory Format specifications (http://people.roma2.infn.it/~cpu/Mass_Memory_Format.html)
b) unpacking either using the old files structure OR the new one file unpacking.
c) parametrized root files compression factor
d) deleting of the following packet: TofTest, TrkTest, TrkEvent.
e) the Tracker routines now work without the use of temp files.
The point a) allow Yoda to unpack in the root file all the packets generated by the CPU. According to the MassMemoryFormat; that is three possible data are available:
1) almost explicit structure of the packet (like for Log, Tracker, Mcmd, etc....);
2) dummy data collection structure (InitHeader, InitTrailer, CalibHeader, CalibTrailer);
3) just the data of the packet (almost all Alarm and Init procedures). The class regarding this packets have only one parameters, a TArrayC class, which contain the data-block included in the packet (tat is the data below the packet Header).
The point b) has been implemented as a consequence of an agreement about a more compact structure of the unpacked data. Up to now the structure of each unpacked data consisted of a folder, named after the packet type, and three files: xxx.Header.root, xxx.NamePacket.root, xxx.Registry.root.
Starting from this release YODA, by default will unpack the data in a unique root file. The structure of this file will consist of:
- several TTree(s) named after the packet type;
- into each TTree are foreseen three TBranche(s):
- 'Header' (the old xxx.Header.root file)
- 'NameOfThePacket' (the old xxx.Event.root file or the xxx.Event.DETECTOR.root)
- 'Registry' (the old xxx.Registry.root file)
Anyway is still possible, but deprecated, to unpack using the old structure, passing to the "yoda" command the optional parameter "-multifile"
The point c) has been implemented because is well know that writing time in a TTree is as much fast as much lower is the compression factor for the root file; anyway for a PAMELA dat file, a compression equal to 0 will generate a root file which will be more than two times the original size. To modify the compression parameter just add the optional parameter "-c [0-9]" to the yoda command line.
Revision
5.1 -
(
view)
(
download)
(
annotate)
-
[select for diffs]
Sat Feb 4 12:37:46 2006 UTC
(18 years, 10 months ago)
by
kusanagi
Branch:
MAIN
Changes since
5.0: +3 -3 lines
Diff to
previous 5.0
Several new features in this release:
a) all the packets are conform to the Mass Memory Format specifications (http://people.roma2.infn.it/~cpu/Mass_Memory_Format.html)
b) unpacking either using the old files structure OR the new one file unpacking.
c) parametrized root files compression factor
d) deleting of the following packet: TofTest, TrkTest, TrkEvent.
e) the Tracker routines now work without the use of temp files.
The point a) allow Yoda to unpack in the root file all the packets generated by the CPU. According to the MassMemoryFormat; that is three possible data are available:
1) almost explicit structure of the packet (like for Log, Tracker, Mcmd, etc....);
2) dummy data collection structure (InitHeader, InitTrailer, CalibHeader, CalibTrailer);
3) just the data of the packet (almost all Alarm and Init procedures). The class regarding this packets have only one parameters, a TArrayC class, which contain the data-block included in the packet (tat is the data below the packet Header).
The point b) has been implemented as a consequence of an agreement about a more compact structure of the unpacked data. Up to now the structure of each unpacked data consisted of a folder, named after the packet type, and three files: xxx.Header.root, xxx.NamePacket.root, xxx.Registry.root.
Starting from this release YODA, by default will unpack the data in a unique root file. The structure of this file will consist of:
- several TTree(s) named after the packet type;
- into each TTree are foreseen three TBranche(s):
- 'Header' (the old xxx.Header.root file)
- 'NameOfThePacket' (the old xxx.Event.root file or the xxx.Event.DETECTOR.root)
- 'Registry' (the old xxx.Registry.root file)
Anyway is still possible, but deprecated, to unpack using the old structure, passing to the "yoda" command the optional parameter "-multifile"
The point c) has been implemented because is well know that writing time in a TTree is as much fast as much lower is the compression factor for the root file; anyway for a PAMELA dat file, a compression equal to 0 will generate a root file which will be more than two times the original size. To modify the compression parameter just add the optional parameter "-c [0-9]" to the yoda command line.
Revision
5.0 -
(
view)
(
download)
(
annotate)
-
[select for diffs]
Mon Aug 29 09:46:13 2005 UTC
(19 years, 3 months ago)
by
kusanagi
Branch:
MAIN
CVS Tags:
YODA5_0/00,
YODA5_0/01,
YODA5_0/02
Changes since
4.4: +2 -2 lines
Diff to
previous 4.4
Starting form this version:
1) includes are defined with relative (not absolute) path respect to the YODA aplication
2) RegistryEvent class is foreseen to contain post-unpack data.
Revision
4.4 -
(
view)
(
download)
(
annotate)
-
[select for diffs]
Sat May 28 10:44:13 2005 UTC
(19 years, 6 months ago)
by
kusanagi
Branch:
MAIN
Changes since
4.2: +2 -2 lines
Diff to
previous 4.2
Main features of this release are:
- updated classes documentations;
- major changes on the calibration fortran routine for the calorimeter
- update on the TMTC thermistors
- removed old classes as CalibTrkBoth and CalibTrd
Revision
4.1 -
(
view)
(
download)
(
annotate)
-
[select for diffs]
Wed Mar 16 16:36:23 2005 UTC
(19 years, 9 months ago)
by
kusanagi
Branch:
MAIN
Changes since
4.0: +19 -26 lines
Diff to
previous 4.0
Upgrade: The routine to check IF and WHERE are the S4 data as been completly refactored
- to check even the presence or not of the Neutron data
- the check of S4 data is no more done scanning a buffer but reading at fixed positions
Revision
3.0 -
(
view)
(
download)
(
annotate)
-
[select for diffs]
Fri Mar 4 15:54:11 2005 UTC
(19 years, 9 months ago)
by
kusanagi
Branch:
MAIN
Changes since
2.5: +2 -2 lines
Diff to
previous 2.5
Error proof version.
Implemented all detectors packets plus all the main telemetries packets.
Missing all the Init and Alarm packets.
Disabled CRC control on VarDump, ArrDump, TabDump for CPU debugging needs
(the data formats seems correct even if CRC get wrong)
Revision
2.5 -
(
view)
(
download)
(
annotate)
-
[select for diffs]
Fri Feb 11 16:40:19 2005 UTC
(19 years, 10 months ago)
by
kusanagi
Branch:
MAIN
Changes since
2.4: +68 -11 lines
Diff to
previous 2.4
Fix: the data were read not correctly in case the NeutronDetector data was missing.
Now S4Reader check for a specific pattern of 3 Bytes.
To be done: add a CRC check on the last S4 byte of data
This form allows you to request diffs between any two revisions of this file.
For each of the two "sides" of the diff,
select a symbolic revision name using the selection box, or choose
'Use Text Field' and enter a numeric revision.
