Changeset 17209 for trunk/Mars/msimcamera/MSimReadout.cc

Timestamp:

10/11/13 14:25:47 (11 years ago)

Author:

ftemme

Message:

Implemented 12 bit ADC

File:

• trunk/Mars/msimcamera/MSimReadout.cc (modified) (2 diffs)

trunk/Mars/msimcamera/MSimReadout.cc

@@ -214 +214 @@
 
     const Float_t offset    = 0;//128;
-    const UInt_t  max       = fData->GetMax();
+    // FTemme: Don't need this anymore:
+//    const UInt_t  max       = fData->GetMax();
+//    const UInt_t  min       = fData->GetMin();
+
 
     // FIXME: Take this into account
@@ -232 +235 @@
         for (Int_t j=0; j<nslices; j++)
         {
-            Float_t slice = j+trig>=(Int_t)sig.GetSize() ? offset :
-                sig[j+trig] * fConversionFactor + offset;
-
-            // FIXME: Handle/Implement saturation!
-            if (slice>max)
-                slice = max;
-            if (slice<0)
-                slice = 0;
-
-            // We have a 16 bit FADC. The resolution of the DRS4 is just about 11.5 bit.
-            // Therefore the last 4.5 bits (~22.5) are gaussian noise (is this right?)
-            buffer[nslices*i + j] = TMath::Nint(slice);
+
+            Float_t slice = 0;
+            if (j+trig >= (Int_t)sig.GetSize())
+            {
+                // DN: This, IMHO can never happen, since the check in line 205
+                // already took care for this.
+                // DN: But I don't understand why Thomas did this?
+                //      We need to add noise at least ?!
+                slice = offset;
+            }
+            else
+            {
+                // normal case
+
+                // Why do we add 'offset' when it is a hardcoded zero?
+                // And why do we multiply, while this value *may* be changed
+                // by a user, but it should not? Why do we care?
+                // Because we can?
+                slice = sig[j+trig] * fConversionFactor + offset;
+            }
+
+
+            // Saturation in FACT is done as follows:
+            // If the digitized signal is larger than an upper limit 'max'
+            // the ADC does set a special bit! The overflow bit ...
+            // So while we say we have a 12bit ADC ... in fact we sometimes
+            // also use a 13th bit ...
+            // but this does not increase our resolution by a factor of 2!
+
+            // There are different binary formats for signed integers,
+            // however the 'Two's complement' format
+            // http://en.wikipedia.org/wiki/Two%27s_complement
+            // is increadibly common, and this is also what is used by FACTs ADCs.
+
+            // A normal 12bit (two's complement formatted) signed integer
+            // goes from -2048 to +2047 and is coded like this:
+            // from -2048 = 0x800 = 1000.0000.0000
+            // to   +2047 = 0x7FF = 0111.1111.1111
+            //
+            // But on a normal PC we store these 12 bit numbers in a space, that
+            // was designed for 16bit numbers. This is no problem for the positive numbers
+            // 12bit: 0x7FF = 0111.1111.1111 --> 16bit: 0x07FF = 0000.0111.1111.1111
+            // This bit combination is always understood as +2047 .. no problem!
+            // But the negative numbers:
+            // 12bit: 0x800 = 1000.0000.0000 --> 16bit: 0x0800 = 0000.1000.0000.0000
+            // This *would* normally be understood as +2048, because we need to
+            // 'enlarge' the 'sign bit'
+            // so our largest negative number written into a 16bit storage space
+            // should look like this:
+            // 0xF800 = 1111.1000.0000.0000  --> -2048
+
+            // The enlargement of the sign bit is autotically done on the FACT FAD
+            // board already before the data is send to any PC, because we can do it
+            // damn fast on that board, and a PC would need to touch every incoming
+            // data word again....
+            // But now since we have enlarged the 12th bit ... the sign bit into
+            // the space of bits 13,14,15 and 16 ... where did the overflow-bit go?
+            //
+            //  Well .. we still have plenty of bit-combinations, which are normally
+            // forbidden for a 12bit ADC, and these we can use to encode both,
+            // the positive and negative overflow.
+            // we decided to do this:
+            // positive overflow
+            // 0000.1000.0000.0000 --> interpreted by a PC as +2048 and thus out of 12 bit range!
+            // negative underflow
+            // 1111.0111.1111.1111 --> interpreted by a PC as -2049 and thus out of 12 bit range!
+
+            // we will simulate exactly the same behaviour here!
+
+            // max and min can be set, by the user currently ..
+            // but I don't see why this should be possible.
+            Int_t digitized_value = TMath::Nint(slice);
+            if (digitized_value > 2047) // positive overflow
+                buffer[nslices*i + j] = 0x0800; // <-- +2048
+            else if (digitized_value < -2048)
+                buffer[nslices*i + j] = 0xF7FF; // <-- -2049
+            else
+                buffer[nslices*i + j] = digitized_value;
         }
     }