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

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 

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?

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!!!!

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?

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 

Nope. 

Hello, Stefan. Have you implemented pulse counting yet?

Best, Osip.

> 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

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.

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.

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

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);

…

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 

 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.

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

 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

 Great to know this! Thanks~

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

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