DRS4 Forum
  DRS4 Discussion Forum, Page 11 of 40  Not logged in ELOG logo
ID Date Authordown Subject
  211   Fri Dec 14 21:49:29 2012 Stefan RittEVM rev4 board trigger change and drs_example

Martin Petriska wrote:

 I switched from rev 3 to rev 4 board, but have some problems with triggering, board is now waiting for trigger (rev.3 is working). How to do in drs_exam.cpp for example triggering on Ch0 && CH1 ?

Software 4.0.0, windows version.

Here is old trigger initialisation: 

b->EnableTrigger(0,1);

b->SetTriggerSource(0);

b->SetTriggerLevel(0.25, false);

b->SetTriggerDelayNs(0);

 

Btw. Is it possible to set up different trigger Levels for each channel ?

 

(If there is some interest here is my code in Qt, still aplha) http://sourceforge.net/p/qtpals/code

Sorry the late reply.

In V4, triggering has changed. You can trigger now on an OR or AND of channels. Therefore you have to supply a bitmask, where the 1st bit = CH1, 2nd bit = CH2 and so on. Have a look at the most recent drs_exam. It contains code:

 

   /* use following lines to enable hardware trigger on CH1 at 50 mV positive edge */
   if (b->GetBoardType() == 8) {     // Evaluaiton Board V4 
      b->EnableTrigger(1, 0);           // enable hardware trigger
      b->SetTriggerSource(1<<0);        // set CH1 as source
   } else {                          // Evaluation Board V3
      b->EnableTrigger(0, 1);           // lemo off, analog trigger on
      b->SetTriggerSource(0);           // use CH1 as source
   } 

So if you want CH1 && CH2, you look at the source code of SetTriggerSource. It contains

 

      // Set trigger configuration
   // OR  0=CH1, 1=CH2, 2=CH3, 3=CH4, 4=EXT
   // AND 8=CH1, 9=CH2, 10=CH3, 11=CH4, 12=EXT

 

So an AND between CH1 and CH2 needs a

    b->SetTriggerSource(1<<8 | 1<<9);

Your code looks interesting. Do you have a screenshot or can you explain what it does? 

  213   Thu Dec 27 09:49:17 2012 Stefan Rittvariation of sampling capacitors

Jinhong Wang wrote:

Hi Stefan,

A quick question, what is the typical variation of the sampling capacitors in DRS4?  Will this variation be significant to affect your sampling result?

 Best,

Jinhong 

The capacitors sample the input voltage, not the charge, so the actual size of the capacitors does not matter on first order (the variations might be in the order of 5%). A bigger effect is the variation of the analog switches in the front of the capacitors, which is about 15%. So the actual bandwidth each cell sees varies by maybe 20% (given by the R and the C), but this comes only into play when sampling steep edges.

Stefan

  216   Tue Feb 5 14:38:35 2013 Stefan Rittvariation of sampling capacitors

Jinhong Wang wrote:

Hi Dr. Stefan,

So the sampling capacitors store the input voltage instead of the charge. What about the readout circuits? I saw there is a buffer followed each sampling capacitor. Do you buffer the charge (like a charge sensitive amplifier)  or the voltage? From Fig.12, 14 in datasheet, it seems most probably the readout is a charging or discharging of a capacitor. Could you please add some comments on this? 

Cheers,

Jinhong

The buffer buffers the voltage, not the charge. The curves in Fig. 12, 14 indicate that the voltage followers take some time until they settle. 

Stefan

  218   Wed Feb 13 17:03:53 2013 Stefan RittNonuniform sampling

Martin Petriska wrote:

 Are there any plans to include reconstruction of nonuniform sampling  in DRS4 to get uniformly sampled data?

Im now reading article IEEE Trans on Circ. ans Systems I, Vol.55 No.8 sept. 2008 Reconstruction of Nonuniformly Sampled Bandlimited Signals Usinga Differentiator–Multiplier Cascade by Stefan Tertinek and Christian Vogel

and plan to implement it, but may be somebody has it done before me.

 

Interesting paper. I was not aware of this method. Sounds interesting. AFAIK, nobody has implemented it so far.

My (old) plan was to linearly interpolate samples (something you could do in an FPGA as well), but this will introduce (small) errors. The next best thing would be to do some spline interpolation, but this is time consuming and not suited for an FPGA.

If you get good results with the method above, please let others know about it.

/Stefan 

  220   Fri Feb 22 11:56:57 2013 Stefan RittDRS4 trigger, different polarity

Yury Golod wrote:

I need to synchronize two signals. These signals have a different polarity.

I can set triggers on different levels. But I can't set different polarity of triggers.

Now I can set (T1 and T2), I need to set (T1 and (not T2))

Is it possible?

 

           

 

d->SetTriggerLevel(-0.4,0.4,0.0,0.0,false);

d->EnableTrigger(1, 0);  // Enable trigger

d->SetTriggerSource(1<<8 | 1<<9);  // T1 and T2

 

file DRS.cpp:

int DRSBoard::SetTriggerLevel(double voltage1,double voltage2, double voltage3,double voltage4,bool negative)

{

      SetDAC(fDAC_TLEVEL1, voltage1/2 + 0.8);

      SetDAC(fDAC_TLEVEL2, voltage2/2 + 0.8);

 

There is no way to select different polarities, it is not implemented in the firmware. Like your digital oscilloscope has also only one polarity switch.

The only way to do it is to use a (passive) inverter, so that you have two signals of the same polarity. Something like this:

http://www.phillipsscientific.com/pdf/460ds.pdf

 

  224   Thu Feb 28 12:58:44 2013 Stefan Rittclock and trigger outs
> Hi,
> I am considering using the DRS4 evaluation board as an ADC card for the wire chamber in the physics lab (VP) experiment at ETH. However, the wire 
> chamber has 8 outputs, so I would need to have two of such boards. Is it possible to synchronise them, online or offline? From the website, it looks 
> like yes, but the documentation says that these features (trigger and clock out) may not have been implemented in firmware yet. Could you tell me 
> the status?
> 
> Thank you very much,
> 
> Dmitry.

I'm right now working on it. If you only need 2-3 ns accuracy  between the two boards then you can do this already now without firmware upgrade. The software for this is in principle ready, but I have to 
finish the documentation. Since I'm on a business travel right now this might take me some time (weeks?). 

If you want better timing (O(100ps)) between the boards, then you will need a firmware update. Or you wait until we ship boards with the new firmware. I will announce this through this forum.

Stefan
  226   Wed Mar 6 12:37:14 2013 Stefan RittDRS4- analog pulse counting

Osip Lishilin wrote:

Hello, Stefan. Have you implemented pulse counting yet?

Best, Osip.

Nope. 

  227   Wed Mar 6 13:08:03 2013 Stefan RittChip Test - Cell Error

Georg Winner wrote:

When starting Chip Test in DRS Command Line Interface, I receive the following message:

Cell error on channel 1, cell 5: -154.4 mV instead 0 mV

Chip Error!

What does this mean? The maximal peak-to-peak Amplitude given to channel was for a short time 10V.

The graphical interface shows no artefacts when using channel 1.

 

The "Chip Test" command is made for a special test board we use for chip testing. This command will not work with the evaluation board, since only four of the 8 DRS channels are connected there. So just ignore it and verify the board functionality by looking at the graphical interface.

/Stefan 

  230   Thu Apr 4 11:21:04 2013 Stefan RittDifferences in Source Code

Georg Winner wrote:

I have noticed some differences in the source code between Windows (4.0.0) and Linux (4.0.1) Version.

drs_exam.cpp: In the windows version when setting the trigger there is no part "if (b->GetBoardType() == 8) {...} else {...}" like in Linux version. So under Windows drs_exam does not start readout of DRS 4 Evalutation Board V4, because it does not get the trigger, under linux the board can be read out succesfull. I have found out, that adding the missing part solves the problem for the windows version.

drs.cpp (Windows Version), line 2101, function "int DRSBoard::SetTriggerDelayNs(int delay)":

There is no operation which  calculates the variable "fTriggerDelayNs" out of variable "ticks" like in function "int DRSBoard::SetTriggerDelayPercent(int delay)" (Line 2073). So "fTriggerDelayNs" can get diverse values when using one of the Trigger Setting Functions. Was this intended?

 

Thanks for reporting the problem in drs_exam.cpp. The windows and linux versions sometimes differ a bit. I'm working right now on a complete new version, wich will bring both together again.

Concerning fTriggerDelayNs and ticks, they are correlated. One tick is a single delay unit in the FPGA. On the newest boards the unit is 4.8ns long. So

ticks = fTriggerDelayNs / 4.8

fTriggerDelayNs = ticks * 4.8

fTriggerDelayNs gets set at the first line of SetTriggerDelayNs:

int DRSBoard::SetTriggerDelayNs(int delay)
/* set trigger delay in nanoseconds */
{
   short ticks, reg;
   fTriggerDelayNs = delay;

So I cannot see how fTriggerDelayNS should get diverse values?

 

  231   Thu Apr 4 11:32:21 2013 Stefan Rittcascading -- DRS4 Osci.cpp & DRS.cpp

Jill Russek wrote:

 

All I'm trying to do is cascade one input signal, though all available channels, so that I end up with 8*1024 bins per event.

Here is the read out on my board/chip:

Mezz. Board index:    0
DRS type:             DRS4
Board type:           8
Serial number:        2249
Firmware revision:    17662
Temperature:          35.2 C
Input range:          -0.5V...0.5V
Calibrated range:     -0.5V...0.5V
Calibrated frequency: 5.120 GHz
Status reg.:          0000001A
Control reg.:         00000010
  DMODE circular
Trigger bus:          00000000
Frequency:            5.120 GHz

 

What I've tried thus far:

In Osci.cpp, in the method/function  SelectSource(int board, int firstChannel, int chnSection), I added a line.. (in bold)

//----------------------------------------------------------------------------------------------------------------------------------------------

 if (b->GetBoardType() == 5 || b->GetBoardType() == 7 || b->GetBoardType() == 8) {
         
        
             if (chnSection == 2)
                b->SetChannelConfig(0, 8, 4);
             //added
             else if(chnSection == 1)
                 b->SetChannelConfig(0, 8, 2);
             //added

             else
                b->SetChannelConfig(0, 8, 8);

//----------------------------------------------------------------------------------------------------------------------------------------------

I've also tried doing settings such as SetChannelConfig(0, 8, 1);   , SetChannelConfig(0, 8, 2); , SetChannelConfig(0, 1, 2); , etc..

Which always ends up making the run fail.. and sometimes I get index errors..

As far as I understanding the program now, this is what I know:

fChannelCascading determines getChannelCascading,
this determines the  if (casc == 2) line in configDialogue.cpp, which sets:
 b->SetChannelConfig(config, 8, 4);

fChannelCascading is being set by:
 switch (nConfigChannels) {
      case 1:
         fChannelConfig = 0x01;
         fChannelCascading = 8;
         break;
      case 2:
         fChannelConfig = 0x11;
         fChannelCascading = 4;
         break;
      case 4:
         fChannelConfig = 0x55;
         fChannelCascading = 2;
         break;
      case 8:
         fChannelConfig = 0xFF;
         fChannelCascading = 1;
         break;
      default:
         printf("Invalid channel configuration\n");
         return 0;
      }

which is being set by nConfigChannels in DRS.cpp, in the method:
SetChannelConfig(int firstChannel, int lastChannel, int nConfigChannels)

SetChannelConfig is being called in the ConfigDialogue.cpp,  but the default Osci program is such that you can't do a configuration for a cascade of one signal using all the channels. At least, not that I am aware of. 

So what buttons do I need to enable, or what do I need to call, or write, so that I can cascade a signal to end up with 8*1024 bins per event?

This has had me going in circles for weeks, so thank you for your help!!!! 

Sorry for my late reply, I was away for some days.

To use channel cascading, you have to physically connect one input to all eight channels. This is not possible with the evaluation board, you have to make your own board. What you could do however is to split a signal externally and feed it to all four inputs, given that the signal delay is the same for every channel. But then you will hit the hard-wired limit in Osci.cpp. This code was never foreseen to cover 8*1024 bins (since it does not make much sense with the evaluation board). Some arrays are only 2*1024 bins wide, so you would have to rewrite code at many places.

The easiest way to get what you want is to modify drs_exam.cpp. You need SetChannelConfig(0, 8, 1) as you realised correctly, and then you have to retrieve all 8 channels via b->GetWave() and concatenate them correctly.

/Stefan 

  233   Fri Apr 5 08:54:37 2013 Stefan Rittcascading -- DRS4 Osci.cpp & DRS.cpp

Jill Russek wrote:

Would it be possible to just hardcode a few lines in the SetChannelConfig in DRS.cpp method as such:

     fChannelConfig = 0x01; //gives me eight
      d = fChannelConfig | (fDominoMode << 8) | (1 << 9) | (fWSRLoop << 10) | (0xF8 << 8);

      Write(T_CTRL, REG_CHANNEL_CONFIG, &d, 2);
      fChannelDepth = 8 * (fDecimation ? kNumberOfBins/2 : kNumberOfBins);// gives eight times the bins

 

then modify the GetWave method/function to include another else if statement similar to  "else if (fChannelCascading == 2) {"  but would be modifidied for fChannelCascading == 8?

 

By, "But then you will hit the hard-wired limit in Osci.cpp" do you mean  hard-coded? Would changing the hard code just amount to resizing all of the arrays, and replacing all the '2*kNumberBins"  with '8*kNumberBins' ?

 

I'm afraid of drs_exam.cpp because it doesn't come with all the perks of Osci.cpp. It seems less daunting to just modify Osci.cpp then to try understanding everything I need to include in drs_exam.cpp because I'm also using an external trigger, and saving the waveform to an external text file.

Thanks!

/Jill

Sure it would be possible to code it, but it's not just a few lines. Besides Osci.cpp you have to massage DOScreen.cpp, Measurement.cpp and probably more since they all rely on the array size of the waveform. So if I would do it it would take me probably a couple of days including the debugging, which I don't have right now. Furthermore, as I said you have to combine all eight channels properly. For two channels, it's already pretty complicated (see lines 3537+ in DRS.cpp). I had to make myself a visual scheme in order to understand it correctly, which I attached. For eight channels, the write shift register (WSR) can have values 0-7, depending in which channel you got a trigger. Then you have to sort it out again to get one linear array with the proper order of the fragments. So you see, it's not just changing a few lines of code. In principle it's possible, but it's lots of work.

Best regards,

Stefan

Attachment 1: Screen_Shot_2013-04-05_at_8.51.53_.png
Screen_Shot_2013-04-05_at_8.51.53_.png
  236   Thu Apr 11 08:39:12 2013 Stefan Rittcascading -- DRS4 Osci.cpp & DRS.cpp

Jill Russek wrote:

Stefan Ritt wrote:

Jill Russek wrote:

Would it be possible to just hardcode a few lines in the SetChannelConfig in DRS.cpp method as such:

     fChannelConfig = 0x01; //gives me eight
      d = fChannelConfig | (fDominoMode << 8) | (1 << 9) | (fWSRLoop << 10) | (0xF8 << 8);

      Write(T_CTRL, REG_CHANNEL_CONFIG, &d, 2);
      fChannelDepth = 8 * (fDecimation ? kNumberOfBins/2 : kNumberOfBins);// gives eight times the bins

 

then modify the GetWave method/function to include another else if statement similar to  "else if (fChannelCascading == 2) {"  but would be modifidied for fChannelCascading == 8?

 

By, "But then you will hit the hard-wired limit in Osci.cpp" do you mean  hard-coded? Would changing the hard code just amount to resizing all of the arrays, and replacing all the '2*kNumberBins"  with '8*kNumberBins' ?

 

I'm afraid of drs_exam.cpp because it doesn't come with all the perks of Osci.cpp. It seems less daunting to just modify Osci.cpp then to try understanding everything I need to include in drs_exam.cpp because I'm also using an external trigger, and saving the waveform to an external text file.

Thanks!

/Jill

Sure it would be possible to code it, but it's not just a few lines. Besides Osci.cpp you have to massage DOScreen.cpp, Measurement.cpp and probably more since they all rely on the array size of the waveform. So if I would do it it would take me probably a couple of days including the debugging, which I don't have right now. Furthermore, as I said you have to combine all eight channels properly. For two channels, it's already pretty complicated (see lines 3537+ in DRS.cpp). I had to make myself a visual scheme in order to understand it correctly, which I attached. For eight channels, the write shift register (WSR) can have values 0-7, depending in which channel you got a trigger. Then you have to sort it out again to get one linear array with the proper order of the fragments. So you see, it's not just changing a few lines of code. In principle it's possible, but it's lots of work.

Best regards,

Stefan

 Stefan, thanks for your help so far. If I go with your plan A of just modifying drs_exam.cpp, is there a quick way to get it to save the data from the wave, like how osci.cpp spits out an xml file? (Ignoring the cascading aspect for now)

Thanks again :)

/Jill

Well, you have to learn C programming, I won't do it for you. drs_exam.cpp contains already code to write to the ASCII file data.txt, so you just can use that or modify it to your needs.

/Stefan

  239   Fri Apr 12 08:25:05 2013 Stefan Rittcascading -- DRS4 Osci.cpp & DRS.cpp

Jill Russek wrote:

Stefan Ritt wrote:

Jill Russek wrote:

 Stefan, thanks for your help so far. If I go with your plan A of just modifying drs_exam.cpp, is there a quick way to get it to save the data from the wave, like how osci.cpp spits out an xml file? (Ignoring the cascading aspect for now)

Thanks again :)

/Jill

Well, you have to learn C programming, I won't do it for you. drs_exam.cpp contains already code to write to the ASCII file data.txt, so you just can use that or modify it to your needs.

/Stefan

 Ha! So then the answer is no, there isn't a ready made function/method to pull out the timing and voltage,  like how it was done in osci.cpp. That's all I wanted to know. (Not whether you would write it for me! Only trying to save time!) Thanks!

/Jill

You misunderstood. The answer is yes. drs_exam.cpp contains already code to write to an ASCII file. If you actually look into the file, you see:

   f = fopen("data.txt", "w");
   ...
   b->GetTime(0, b->GetTriggerCell(0), time_array);
   ...
   b->GetWave(0, 0, wave_array[0]);
   ...
   fprintf(f, "%5.2f %6.2f\n", time_array[i], wave_array[0][i]);

which actually pulls out the timing and voltage and writes it to the file.

  240   Fri Apr 12 08:38:17 2013 Stefan Rittcode/details for optimal DRS4 timing calibration?

Bill Ashmanskas wrote:

Hi Stefan,

Is either some example code or a detailed written description available for the improved DRS4 timing-calibration algorithm described by Daniel Stricker-Shaver at MIC 2012?  I think you told me that you had verified the results with your own test set-up, so I figure there must be at least two sets of code in existence to implement this calibration.  (I have Daniel's presentation slides.)

I managed to find a ping-pong distribution of cell widths that looks quite similar to that shown in Daniel's slides, using an algorithm similar to the technique one uses to find radial offsets in a tracking chamber (i.e. using residuals weighted by track slope), but I'd rather use the method with which you and Daniel have already found good results.  (The attached graph shows in black the histogram of cell widths for essentially the algorithm used in DRS.cpp/DRSBoard::AnalyzeWF, and in blue the histogram of cell widths extracted from the slope-weighted residuals for a periodic reference signal.)

By the way, since Daniel finds a FWHM coincidence-timing resolution around 20-25ps at 5 GSPS (for perfectly identical pulses), should I expect a FWHM resolution (for synthesized, ideal pulses) of around 50-65ps at 2 GSPS?

(I'm posting here instead of writing you both privately because I figure there may be broader interest in Daniel's algorithm.)

-Bill

 

Hi Bill,

there are several reasons why we have not yet published Daniel's method (I'm in constant contact with him).

1. The method still changes, becomes simpler and more accurate. Originally he used sine waves with varying frequency, which you only get from an external function oscillator. Currently, we found that a single frequency could do a similar, maybe even better job. The current result is much better than the 20-25ps quoted at MIC 2012.

2. Daniel found out that for the ultimate resolution you have to calibrate each channel inside a chip separately. I do understand in meantime the reason for that. So I plan for a V5 evaluation board, which contains means of sending a log-jitter clock to all channels. This board is in test phase and will be made available once it's working as expected.

So my plan is to finish the V5 board and implement the best possible timing calibration on it. Daniel achieved already <5 ps RMS (!) independent of the delay between the two optimal pulses (up to 50 ns). This is actually better than what you can do with a high-end oscilloscope, since scopes have internal interleaving and similar problems due to aliasing etc. than the DRS chip, but scope manufacturers do not put such an emphasis on accurate timing measurements. Once we can reproduce the 5 ps result with the evaluation board, we will publish it. When we found the optimal method, we plan to write a paper about it and explain everything in great detail. We will also be at Seoul for MIC 2013. I'm topic convener there for the session "Digitalization, Acquisition, and Signal Processing Technologies". So probably we will put the DRS4 timing talk there, since it's of more general interest not only to medical applications (and honestly, for a 150 ps TOF-PET you do not need a 5 ps electronics resolution). So stay tuned!

/Stefan

  242   Mon Apr 22 15:52:53 2013 Stefan Ritteffect of jitter/alignment between SRCLK and ADC clock

Benjamin LeGeyt wrote:

Hello!
let me apologize in advance if this has already been covered somewhere and I missed it. 


I have a question about a statement made regarding the ADC clock in the evaluation board v4.0 manual.  At the bottom or page 23 there is a mention of jitter between the SRCLK signal and the ADC clock causing a baseline variation in the sampled output of up to a few mV.  Is there any more information out there about this?  I find this confusing for the following reason: If the DRS output has mostly settled after 28ns and the signal that is being sampled is a DC signal, I don't understand why an aperture jitter in the sampling ADC should cause a voltage error in the measured signal.  I already know about the possibility of noise spikes every 32 samples if these clocks are not properly aligned, though I don't know the origin of those spikes.  are these two things related?

Many Thanks!

Hi Benjamin,

In principle you are right, for a DC signal that should not matter. But in reality the DRS4 output signal is not constant even for a DC signal. When you switch from one sampling cell to another during readout, there is something called "charge injection". This causes the output to change up to several 10 mV. After 28 ns this is mostly settled, but not completely, since the DRS4 output driver has a relatively low bandwidth (~50 MHz). Furthermore, the signal line between the DRS4 and the ADC is not terminated, so you have some reflections going forth and back. In addition, you have some crosstalk from the SRCLK signal. So it's better that you sample on each cycle at exactly the same time. Here you see a plot of that (green: DRS4 output, blue: ADC clock, yellow SRCLK):

adc_phase.jpg 

  247   Tue May 21 13:25:41 2013 Stefan Rittmac osx 10.6
> Hi,
> 
> I would like to use the DRS4 with my macbook pro running osx 10.6.8.
> I have installed the wxWidgets and the libusb-1.0 libraries and I am using the Linux code vers. 4.0.1. After
> compilation, the following errors come out:
> 
> ld: warning: in musbstd.o, file was built for unsupported file format which is not the architecture being linked
> (i386)
> ld: warning: in mxml.o, file was built for unsupported file format which is not the architecture being linked (i386)
> ....
> ....
> ld: warning: in main.o, file was built for unsupported file format which is not the architecture being linked (i386)
> Undefined symbols:
>   "_main", referenced from:
>       start in crt1.10.6.o
> ld: symbol(s) not found
> collect2: ld returned 1 exit status
> make: *** [drsosc] Error 1
> 
> 
> Do you have any idea on how to solve the problem ?? or maybe do you have a package working with osx 10.6 ? I
> remember to have seen, long time ago, a package that could work with 10.6 (or 10.5 ?), but I cannot find it now
> (but maybe I remember wrong).
> 
> Thanks for any help,
> 
> Enrico

Can it be that you have a old PowerPC MAC? I have no experience with that, but probably you have to adjust the Makefile
ans set some flags correctly for PPC instead of Intel.

/Stefan
  251   Tue May 21 17:51:09 2013 Stefan Rittmac osx 10.6
> > 
> > it looks like 64bit vs 32bit problem, you have to compile all libraries for the same architecture. Maybe, make clean to 
> > remove all precompiled object files .o and recompile it again. Try to compile first that simple example without wxWidgets.
> > 
> > Martin
> 
> 
> Good point, but all libraries are already compiled to 32 bits, since the laptop is running at 32 bits. Unless you mean that I
> have to convert to 64 bits, but this means to change all content of the PC, and I don't want to do this. Can the applications
> run with 32 bits or do they need 64 ? 
> 
> Thanks,
> Enrico

There is no specific reason to run it on 64 bits, so just all libraries have to match, that's all. But the original Makefile has been written for 64 bits, so it might need some 
adjustments.

/Stefan
  254   Fri May 24 18:20:14 2013 Stefan Rittmac osx 10.6
> I made some progress. Understood what was wrong in the make phase. You have only to add the option -arch i386 in the CFLAGS line of the makefile.
> Then the make is ok, it produces the 3 executables. drs_exam and drscl seem to work correctly. 
> DRSOsc.app does not work as app, in the sense that if you click it, an error message comes saying "You can't use this version of the application DRSOsc.app with 
> this version of Mac OS X. You have Mac OSX 10.6.8. The application requires Mac OS X 10.7 or later. "
> If you execute drsosc from the terminal, the graphical window pops up, the waveform is displayed, but you don't have access to the graphical interface, no button works, you can't do
> anything. To quit the app, you have to kill it from the terminal with the kill command.

To run an executable as an app, you have to put it into a certain directory structure. The Makefile has the target "make app" which exactly does that. It executes following code:

DRSOsc.app: drsosc
        -mkdir DRSOsc.app
        -mkdir DRSOsc.app/Contents
        -mkdir DRSOsc.app/Contents/MacOS
        -mkdir DRSOsc.app/Contents/Resources
        -mkdir DRSOsc.app/Contents/Resources/English.lproj
        echo 'APPL????' > DRSOsc.app/Contents/PkgInfo
        cp drsosc.xcodeproj/Info-processed.plist DRSOsc.app/Contents/Info.plist
        cp drsosc DRSOsc.app/Contents/MacOS/DRSOsc
        cp drsosc.xcodeproj/DRSOsc.icns DRSOsc.app/Contents/Resources

You can also do this manually. You will then see the subdirectly DRSOsc.app actually as an App icon (you don't see it as a subdirectory in the Finder).  That's the way Apple has chosen to do this.

The chip test facility has been made for a certain test board we use for chip testing. It has a feature that is not present in the evaluation board. I have to disable that command there.

Best regards,
Stefan
  256   Sat May 25 21:03:22 2013 Stefan RittDRS4- analog pulse counting

Osip Lishilin wrote:

Stefan Ritt wrote:

Osip Lishilin wrote:

Hello, Stefan. Have you implemented pulse counting yet?

Best, Osip.

Nope. 

 Will it be done in the foreseeable future?

Yes. I will announce it in the forum. 

  258   Fri Jun 7 10:22:48 2013 Stefan Ritt 

tmiron alon wrote:

Hallo,
I'm using DRS4 Evaluation Board Rev 4.0 and I'm trying to change the output of the samples to be an average of  #  measurements (1000 or even more)
during the process I have encountered some difficulties I hope you will be able to help me  with:

1. the DRS chip have 8 channels but the Evaluation board have only 4 channels. does the default mode of the DRS in the Evaluation Board is 1024 bins for each channel or 2048?

2. in the readout mode, does it samples all the 1024 bins waveform from a channel and then move to the next one, or after each bin it move to the next channel?

3. In the file "drs4_eval4_app.vhd", I have a problem finding the names of the signals that represents the registers bits which tell me what is the number of the bin (1-1024) the ADC is reading from the DRS, and the signals

that represents registers A0-A3. can you send me their names? 

 

4. In another matter- is the -0.5V to 0.5V is the  upper and lower  limit of the input (or just a working range), and if not what is the limit for AC?  is there a fuse on the board in case of overload from the input? (I didn't see  it in the User's Manual, but I didn't know if you will mention it there in case there is one).

thanks in advance and have a nice day,

Tmiron

1. All 8 channels are read out, but only 4 are displayed in the oscilloscope.

2. It reads all 1024 bins from a channel, then switch to the next channel.

3. The ADC readout happens in lines 1576+. The register for the sample count is drs_sample_count, and the signal for the address is drs_addr.

4. The evaluation board manual explicitly mentions the maximum allowed input range on page 5.

/Stefan 

ELOG V3.1.4-80633ba