Changeset 17209 for trunk/Mars/msimcamera
- Timestamp:
- 10/11/13 14:25:47 (11 years ago)
- Location:
- trunk/Mars/msimcamera
- Files:
-
- 3 edited
Legend:
- Unmodified
- Added
- Removed
-
trunk/Mars/msimcamera/MSimCamera.cc
r17197 r17209 185 185 { 186 186 MPedestalPix &ped = (*fElectronicNoise)[i]; 187 if (fDefaultOffset>0) 188 ped.SetPedestal(fDefaultOffset); 187 ped.SetPedestal(fDefaultOffset); 189 188 if (fDefaultNoise>0) 190 189 ped.SetPedestalRms(fDefaultNoise); -
trunk/Mars/msimcamera/MSimReadout.cc
r17148 r17209 214 214 215 215 const Float_t offset = 0;//128; 216 const UInt_t max = fData->GetMax(); 216 // FTemme: Don't need this anymore: 217 // const UInt_t max = fData->GetMax(); 218 // const UInt_t min = fData->GetMin(); 219 217 220 218 221 // FIXME: Take this into account … … 232 235 for (Int_t j=0; j<nslices; j++) 233 236 { 234 Float_t slice = j+trig>=(Int_t)sig.GetSize() ? offset : 235 sig[j+trig] * fConversionFactor + offset; 236 237 // FIXME: Handle/Implement saturation! 238 if (slice>max) 239 slice = max; 240 if (slice<0) 241 slice = 0; 242 243 // We have a 16 bit FADC. The resolution of the DRS4 is just about 11.5 bit. 244 // Therefore the last 4.5 bits (~22.5) are gaussian noise (is this right?) 245 buffer[nslices*i + j] = TMath::Nint(slice); 237 238 Float_t slice = 0; 239 if (j+trig >= (Int_t)sig.GetSize()) 240 { 241 // DN: This, IMHO can never happen, since the check in line 205 242 // already took care for this. 243 // DN: But I don't understand why Thomas did this? 244 // We need to add noise at least ?! 245 slice = offset; 246 } 247 else 248 { 249 // normal case 250 251 // Why do we add 'offset' when it is a hardcoded zero? 252 // And why do we multiply, while this value *may* be changed 253 // by a user, but it should not? Why do we care? 254 // Because we can? 255 slice = sig[j+trig] * fConversionFactor + offset; 256 } 257 258 259 // Saturation in FACT is done as follows: 260 // If the digitized signal is larger than an upper limit 'max' 261 // the ADC does set a special bit! The overflow bit ... 262 // So while we say we have a 12bit ADC ... in fact we sometimes 263 // also use a 13th bit ... 264 // but this does not increase our resolution by a factor of 2! 265 266 // There are different binary formats for signed integers, 267 // however the 'Two's complement' format 268 // http://en.wikipedia.org/wiki/Two%27s_complement 269 // is increadibly common, and this is also what is used by FACTs ADCs. 270 271 // A normal 12bit (two's complement formatted) signed integer 272 // goes from -2048 to +2047 and is coded like this: 273 // from -2048 = 0x800 = 1000.0000.0000 274 // to +2047 = 0x7FF = 0111.1111.1111 275 // 276 // But on a normal PC we store these 12 bit numbers in a space, that 277 // was designed for 16bit numbers. This is no problem for the positive numbers 278 // 12bit: 0x7FF = 0111.1111.1111 --> 16bit: 0x07FF = 0000.0111.1111.1111 279 // This bit combination is always understood as +2047 .. no problem! 280 // But the negative numbers: 281 // 12bit: 0x800 = 1000.0000.0000 --> 16bit: 0x0800 = 0000.1000.0000.0000 282 // This *would* normally be understood as +2048, because we need to 283 // 'enlarge' the 'sign bit' 284 // so our largest negative number written into a 16bit storage space 285 // should look like this: 286 // 0xF800 = 1111.1000.0000.0000 --> -2048 287 288 // The enlargement of the sign bit is autotically done on the FACT FAD 289 // board already before the data is send to any PC, because we can do it 290 // damn fast on that board, and a PC would need to touch every incoming 291 // data word again.... 292 // But now since we have enlarged the 12th bit ... the sign bit into 293 // the space of bits 13,14,15 and 16 ... where did the overflow-bit go? 294 // 295 // Well .. we still have plenty of bit-combinations, which are normally 296 // forbidden for a 12bit ADC, and these we can use to encode both, 297 // the positive and negative overflow. 298 // we decided to do this: 299 // positive overflow 300 // 0000.1000.0000.0000 --> interpreted by a PC as +2048 and thus out of 12 bit range! 301 // negative underflow 302 // 1111.0111.1111.1111 --> interpreted by a PC as -2049 and thus out of 12 bit range! 303 304 // we will simulate exactly the same behaviour here! 305 306 // max and min can be set, by the user currently .. 307 // but I don't see why this should be possible. 308 Int_t digitized_value = TMath::Nint(slice); 309 if (digitized_value > 2047) // positive overflow 310 buffer[nslices*i + j] = 0x0800; // <-- +2048 311 else if (digitized_value < -2048) 312 buffer[nslices*i + j] = 0xF7FF; // <-- -2049 313 else 314 buffer[nslices*i + j] = digitized_value; 246 315 } 247 316 } -
trunk/Mars/msimcamera/MSimTrigger.cc
r9574 r17209 337 337 } 338 338 339 if (fDiscriminatorThreshold<=0)340 {341 *fLog << err << "ERROR - Discriminator threshold " << fDiscriminatorThreshold << " invalid." << endl;342 return kFALSE;343 }339 // if (fDiscriminatorThreshold<=0) 340 // { 341 // *fLog << err << "ERROR - Discriminator threshold " << fDiscriminatorThreshold << " invalid." << endl; 342 // return kFALSE; 343 // } 344 344 345 345 if (fElectronicNoise && !fRouteAC.IsEmpty() && !fRouteAC.IsDefaultCol())
Note:
See TracChangeset
for help on using the changeset viewer.