| ID |
Date |
Author |
Subject |
|
110
|
Tue Oct 12 03:53:37 2010 |
Jinhong Wang | Reference design for DRS4 active input buffer |
| Stefan Ritt wrote: |
|
The design of high frequency differential input stages with the DRS4 is a challenge, since the chip draws quite some current at the input (up to 1 mA at 5 GSPS), which must be sourced by the input buffer. A simple transformer as used in the DRS4 Evaluation Board 2.0 limits the bandwidth to 220 MHz. In meantime two active input stages have been worked out and successfully been tested, both utilizing the THS4508 differential amplifier. The first design is AC-coupled and uses less power, the second design is DC-coupled and uses more power with the benefit of delivering a higher bandwidth.
Both designs use a clamping diode at the input as a protection against high voltage spikes at the input. We used a RCLAMP0502B diode from SEMTECH, but any fast voltage suppressor diode will do the job.
The CMOFS input to the THS4508 set the common mode of the differential amplifier. In the AC version the level is set to mid-rail (2.5V), in the DC version it's set to 1.8V to match the input range of the DRS4.
The CAL+ and CAL- signals are used to bias the inputs to a well-defined DC level and can also be used to calibrate the chip. For bipolar inputs, they are both set to 0.8V. A positive 0.5V input pulse then drives DRS_IN+ to (0.8+0.25)V = 1.05V and DRS_IN- to (0.8-0.25)V = 0.55V. A negative 0.5V pulse then drives then DRS_IN+ to 0.55V and DRS_IN- to 1.05V. With ROFS=1.6V, the full dynamic range of the DRS4 is then used. Note that the THS4508 has a gain of 2, and the input has a -6dB voltage divider to compensate for that. To use other input ranges, such as -1V...0V, the CAL+ and CAL- signals can be adjusted accordingly. Note that the inputs of the DRS4 must always be between 0.1V and 1.5V.
AC-coupled version
(click to enlarge)
Power supply: +5 V 40 mA
Bandwidth (-3dB): 600 MHz
CMOFS: 2.5 V
Transfer function:
(click to enlarge)
The transfer function was measured by applying a fixed amplitude sine wave to the input, and measuring the peak-to-peak value of the read out waveform with the DRSOsc application.
DC-coupled Version
The DC-coupled version has a slightly higher power consumption since there is a constant current flowing through the output into the DRS4 chip. On the other hand, the bandwidth is a bit higher and the peaking around 400 MHz is a bit smaller. The input is still AC-coupled, so both positive and negative pulses can be accepted.
(click to enlarge)
Power supply: +5 V 115 mA
Bandwidth (-3dB): 800 MHz
CMOFS: 1.8 V
Transfer function:
(click to enlarge)
Achievable performance
With the active input stage, much faster rise- and fall times can be achieved. Following picture shows a signal from a external clock having a fall time of about 300 ps being recorded with the AC-coupled version of the active input stage. The fall time of the recorded signal is about 800 ps, which is about the minimum which can be achieved with the AC-coupled version. The DC-coupled version achieves about 700ps.
|
Hi, stefan,
In the DC coupled version of the analog drivers for DRS4 input in Eval. Board V3, you mentioned that CMOFS of THS4508 was set to 1.8V to match the input range of DRS4, however, will this clash with the requirements of DRS4 input voltage between 0.1 V ~1.5V ? The output of THS4508 can easily rise beyond 1.5V for CMOFS=1.8V. I also noticed the resister paris R13/R15, R14/R16 was added among the output of THS4508 and the inputs of DRS4, were these resister pairs were used to attenuate the level of THS4508 output signal (a half ? ) to match the input requirements of DRS4? Maybe I have some misunderstanding about it.
|
|
121
|
Mon Jul 4 05:06:00 2011 |
Jinhong Wang | Fixed Patter Timing Jitter |
| Stefan Ritt wrote: |
|
| Jinhong Wang wrote: |
|
Hi Stefan, can you give some suggestions on determination of fixed pattern timing jitter of DRS4? Thanks~
|
I will prepare some more detailed description of how to do this in the near future, but we are still learning ourselves constantly how to do that better.
So for the moment I only can recommend you to read the function DRSBoard::CalibrateTiming() and AnalyzeWF(). What you basically do is to define an array of "effective" bin widths t[i]. You start with the nominal bin width (let's say 500ps at 2 GSPS). Now you measure a periodic signal, and look for the zero crossings. If you have a 100 MHz clock, the time between two positive transitions (low-to-high) is 10.000ns. Now you measure the width as seen by the DRS chip, assuming the effective bin widths. The exact zero crossing you interpolate between two samples to improve the accuracy. Now you measure something different, let's say 10.1ns. So you know the ~20 bins between the zero crossings are "too wide", but you don't know which one of them is too wide. So you distribute the "too wide" equally between all bins, that is you decrease the effective width of these bins from 500ps to 500-0.1ns/20=499.995 ps. Then you do this iteratively, that is for all cycles in the waveform, and for many (1000's) of recorded waveforms. It is important that the phase of you measured clock is random, so that all bins are covered equally. Then you realize that the solution oscillates, which you can reduce by using a damping factor (called "damping" in my C code). So you do not correct to 499.995ps, but maybe to 499.999ps. If you iterate often enough, the solution kind of stabilizes.
The attached picture shows the result of such a calibration. Green is the effective bin width which in the end only slightly deviates from 500ps. But the "integral temporal nonlinearity" shows a typical shape for the DRS chip. It's defined as
n
Ti[n] = Sum (t[i]-500ps)
i=0
where t[i] is the effective bin width. So Ti[0] is zero by definition, but the deviation around bin 450 can go up to 1ns at 2 GSPS.
Now you can test you calibration, by measuring again the period of your clock. If you do everything correctly and have a low jitter external clock and no noise on your DRS4 power supply voltages, you should see a residual jitter of about 40ps.
Hope this explanation helps a bit. Let me know if I was not clear enough at some points.
- Stefan
|
Hi, Stefan,
I noticed other groups of SCA reported the technique to histogram the zero crossings of a sine wave, and use the bin occupancy to derive the effective aperture width. Recently , I tried this technique to DRS4. In my test, the frequency of the sine wave was selected uncorrelated to the domino frequency.The results were discouraging. Large variations of the domino tap delay was observed. Besides, I also tried to induce an external trigger, which is uncorrelated to the domino frequency, and histogram the stop positions. Unfortunately, large variations were obtained again. I knew there must be something wrong. Do you have any suggestions?
The attachment is the histogram of the stop positions (the vertical axis is the bin count, the horizontal axis is the bin number). First, I calculate the ration of each bin count to the total counts, supposed the total count is 10000, count of bin 37 is 12, so the corresponding ratio is 12/10000=0.0012. The bin delay is derived by multiplying its ratio to the whole domino period (1024*1/FSamp, eg., for 5 GSP/s, this period is 200ps *1024). (The bin delay i observed was with an variation of about 30 ps). If the external trigger is uncorrelated to the domino frequency, so, the stop positions are supposed to distribute equally to all bins? If this is true, can i calculate the bin delay via the histogram ?
thank you~
Wang Jinhong |
| Attachment 1: hist_stoppos.jpg
|
|
|
123
|
Tue Jul 12 09:49:08 2011 |
Jinhong Wang | Fixed Patter Timing Jitter |
| Stefan Ritt wrote: |
|
| Jinhong Wang wrote: |
|
| Stefan Ritt wrote: |
|
| Jinhong Wang wrote: |
|
Hi Stefan, can you give some suggestions on determination of fixed pattern timing jitter of DRS4? Thanks~
|
I will prepare some more detailed description of how to do this in the near future, but we are still learning ourselves constantly how to do that better.
So for the moment I only can recommend you to read the function DRSBoard::CalibrateTiming() and AnalyzeWF(). What you basically do is to define an array of "effective" bin widths t[i]. You start with the nominal bin width (let's say 500ps at 2 GSPS). Now you measure a periodic signal, and look for the zero crossings. If you have a 100 MHz clock, the time between two positive transitions (low-to-high) is 10.000ns. Now you measure the width as seen by the DRS chip, assuming the effective bin widths. The exact zero crossing you interpolate between two samples to improve the accuracy. Now you measure something different, let's say 10.1ns. So you know the ~20 bins between the zero crossings are "too wide", but you don't know which one of them is too wide. So you distribute the "too wide" equally between all bins, that is you decrease the effective width of these bins from 500ps to 500-0.1ns/20=499.995 ps. Then you do this iteratively, that is for all cycles in the waveform, and for many (1000's) of recorded waveforms. It is important that the phase of you measured clock is random, so that all bins are covered equally. Then you realize that the solution oscillates, which you can reduce by using a damping factor (called "damping" in my C code). So you do not correct to 499.995ps, but maybe to 499.999ps. If you iterate often enough, the solution kind of stabilizes.
The attached picture shows the result of such a calibration. Green is the effective bin width which in the end only slightly deviates from 500ps. But the "integral temporal nonlinearity" shows a typical shape for the DRS chip. It's defined as
n
Ti[n] = Sum (t[i]-500ps)
i=0
where t[i] is the effective bin width. So Ti[0] is zero by definition, but the deviation around bin 450 can go up to 1ns at 2 GSPS.
Now you can test you calibration, by measuring again the period of your clock. If you do everything correctly and have a low jitter external clock and no noise on your DRS4 power supply voltages, you should see a residual jitter of about 40ps.
Hope this explanation helps a bit. Let me know if I was not clear enough at some points.
- Stefan
|
Hi, Stefan,
I noticed other groups of SCA reported the technique to histogram the zero crossings of a sine wave, and use the bin occupancy to derive the effective aperture width. Recently , I tried this technique to DRS4. In my test, the frequency of the sine wave was selected uncorrelated to the domino frequency.The results were discouraging. Large variations of the domino tap delay was observed. Besides, I also tried to induce an external trigger, which is uncorrelated to the domino frequency, and histogram the stop positions. Unfortunately, large variations were obtained again. I knew there must be something wrong. Do you have any suggestions?
The attachment is the histogram of the stop positions (the vertical axis is the bin count, the horizontal axis is the bin number). First, I calculate the ration of each bin count to the total counts, supposed the total count is 10000, count of bin 37 is 12, so the corresponding ratio is 12/10000=0.0012. The bin delay is derived by multiplying its ratio to the whole domino period (1024*1/FSamp, eg., for 5 GSP/s, this period is 200ps *1024). (The bin delay i observed was with an variation of about 30 ps). If the external trigger is uncorrelated to the domino frequency, so, the stop positions are supposed to distribute equally to all bins? If this is true, can i calculate the bin delay via the histogram ?
thank you~
Wang Jinhong
|
One obvious problem in your method is your statistics. If you have n hits in a bin of the histogram, the error of n is sqrt(n). So if you measure 100 hits, this is more like 100+-10 hits. If you want a better precision, you need much higher statistics. I myself never used this method, but I attach a typical nonlinearity curve running at 2 GSPS, sot hat you know what you should expect. I do some smoothing between neighbor bins so that they do not scatter too much. As you can see, the integral nonlinearity goes almost up to +-2 ns. This value is smaller at higher sampling speeds.
- Stefan
|
Thank you, Stefan. It is really kind of you to offer suggestions or comments on our concern.
Recently, we input a sine wave to our DRS board. DRS works at about 5 GS/s. The frequency varies from 131 MHz to 231MHz. The attached picture shows the reconstructed points of sine wave (vertical is the amplitude, horizontal axis is the point numbers). We noticed that the variation of the length of the zero crossing segments is very large. The max. length is perhaps two times the length of the min. I marked in blue color in the picture. It means the corresponding sampling interval of the max. is two times of that of the min. If this is true, DNL of the DRS sampling interval would be very large. We know, for uniform sampling, the length of the zero crossing segments are assumed to be uniform. Do you have any comments? Thank you~ |
| Attachment 1: 131MHz.jpg
|
|
|
212
|
Thu Dec 27 00:12:12 2012 |
Jinhong Wang | variation of sampling capacitors | 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 |
|
214
|
Thu Dec 27 18:15:14 2012 |
Jinhong Wang | variation of sampling capacitors |
| Stefan Ritt wrote: |
|
| 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
|
Great to know this! Thanks~
Jinhong |
|
215
|
Fri Feb 1 17:43:48 2013 |
Jinhong Wang | variation of sampling capacitors |
| Jinhong Wang wrote: |
|
| Stefan Ritt wrote: |
|
| 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
|
Great to know this! Thanks~
Jinhong
|
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 |
|
886
|
Tue Jul 19 02:35:04 2022 |
Jingyu Zhang | Increase event rate, use ROI mode, and install sw from source in Mac | Dear experts,
We are trying to increase the event rate of the DRS4. We looked into the ROI but couldn’t figure out how to run in ROI mode. We are wondering if there is pre-existing firmware for this? We also tried to download and build the software from source on MacOS 12.4 but we were not successful. Can you kindly help us with these?
Best regards,
Jingyu |
|
590
|
Tue Mar 28 21:53:12 2017 |
Jim Freeman | drscl doesn't find eval board but drsosc does (Windows 7) | I cannot find the EVAL board using drscl version 5.06 while the drsosc works fine. I tried 2 different eval boards and 2 different computers and the same effect. I looked under device manager at the libusb and the drs4 was there, and checked the driver which was found to be up to date. |
|
229
|
Tue Mar 26 01:17:59 2013 |
Jill Russek | cascading -- DRS4 Osci.cpp & DRS.cpp |
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!!!!
|
|
232
|
Fri Apr 5 02:21:33 2013 |
Jill Russek | cascading -- DRS4 Osci.cpp & DRS.cpp |
| Stefan Ritt wrote: |
|
| 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
|
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
|
|
235
|
Wed Apr 10 22:41:21 2013 |
Jill Russek | cascading -- DRS4 Osci.cpp & DRS.cpp |
| 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 |
|
238
|
Thu Apr 11 23:32:57 2013 |
Jill Russek | cascading -- DRS4 Osci.cpp & DRS.cpp |
| Stefan Ritt wrote: |
|
| 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
|
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 |
|
832
|
Mon Sep 6 14:42:23 2021 |
Jiaolong | how to acquire the stop channel with 2x4096 cascading | Hi Steffan,
I have a question about how to acquire the stop channel:
Process: Configure the Write Shift Register with 00010001b to achieve 4-channel cascading, then after a trigger, set A3-A0 to 1101, sclk keeps 0.
Result: the WSROUT pin keeps 0, the SROUT pin has no clock pulse as written in datasheet, but keeps always 1 or 0. It can be seen the stop channel is channel 0 or channel 1, but no situation to represtent channel 3 or channel 4. And if set sclk with 8 pulses, the WSROUT and SROUT both keep 0.
What should I pay attention to? Looking forward to your reply.
Jiaolong |
|
Draft
|
Fri Nov 5 01:10:25 2021 |
Jiaolong | how to acquire the stop channel with 2x4096 cascading |
| Jiaolong wrote: |
|
Hi Steffan,
I have a question about how to acquire the stop channel:
Process: Configure the Write Shift Register with 00010001b to achieve 4-channel cascading, then after a trigger, set A3-A0 to 1101, sclk keeps 0.
Result: the WSROUT pin keeps 0, the SROUT pin has no clock pulse as written in datasheet, but keeps always 1 or 0. It can be seen the stop channel is channel 0 or channel 1, but no situation to represtent channel 3 or channel 4. And if set sclk with 8 pulses, the WSROUT and SROUT both keep 0.
What should I pay attention to? Looking forward to your reply.
Jiaolong
|
|
|
850
|
Fri Nov 5 01:12:10 2021 |
Jiaolong | how to acquire the stop channel with 2x4096 cascading | Thanks for your advice. The problem has been solved by setting the srin again while reading out from srout.
| Stefan Ritt wrote: |
|
The problem must be on your side, since the Write Shift Register readout works in other applications with the DRS4 chip. So I can only speculate what could be wrong:
- Do you really properly set the WSR? When you program it with 00010001b, add 8 more clock cycles and you should see the 00010001b pattern at WSROUT.
- Do all tests with an oscilloscope, to avoid potential problems in your FPGA firmware (like an input configures as an output by mistake).
- DWRITE must be high to see the contents of the WSR at the WSROUT pin, maybe that’s your mistake, see datasheet p 5 of 16.
- To see the contents of the WSR at SROUT, A0-3 must be 1101b, please check with your oscilloscope
- The addresses A0-A3 are simply connected to a multiplexer, so no clock is necessary after the addresses change
Stefan
| Jiaolong wrote: |
|
Hi Steffan,
I have a question about how to acquire the stop channel:
Process: Configure the Write Shift Register with 00010001b to achieve 4-channel cascading, then after a trigger, set A3-A0 to 1101, sclk keeps 0.
Result: the WSROUT pin keeps 0, the SROUT pin has no clock pulse as written in datasheet, but keeps always 1 or 0. It can be seen the stop channel is channel 0 or channel 1, but no situation to represtent channel 3 or channel 4. And if set sclk with 8 pulses, the WSROUT and SROUT both keep 0.
What should I pay attention to? Looking forward to your reply.
Jiaolong
|
|
|
|
842
|
Mon Oct 25 18:48:04 2021 |
Javier Caravaca | Trigger multiple boards independently | Hello,
I recently acquired 4 DRS4 boards and I wanted to ask if it was possible to trigger them independently from the same computer.
I know that you can daisy-chain boards and trigger them all at the same time, but in my case, each of my boards record independent events, so I want them to trigger when trigger conditions are met in each board. I currently use the provided DRSOSC software, that can trigger on only the board that is being displayed at that moment. I tried opening several instances of DRSOSC to associate each to each board, but that is not possible since the second instance already does not find the boards. I wonder if there is a way of triggering from each board independently without having to use four computers.
Thank you,
Javier. |
|
847
|
Tue Oct 26 23:18:32 2021 |
Javier Caravaca | Trigger multiple boards independently | Thank you Stefan. Actually I noticed that the source code of drs_exam was available after I started this thread, and that was the solution that occurred to me too. I'll give that a try.
A related question is: if the 4 boards are triggering at max rate (500Hz), would the total data throughtput (of the four boards together) be 2GHz (500Hz x 4)? Or is the limitation on the readout, rather than the triggering?
Best,
Javier.
| Stefan Ritt wrote: |
|
Unfortunately an independent operation from a single computer is not supported by the software. You can try to modify the drs_exam program and extend it. You can poll all boards in sequence and just read out that one which got a trigger, then start the loop again. But I don't know how good you are in programming. I needs a bit of experience to do that.
Stefan
| Javier Caravaca wrote: |
|
Hello,
I recently acquired 4 DRS4 boards and I wanted to ask if it was possible to trigger them independently from the same computer.
I know that you can daisy-chain boards and trigger them all at the same time, but in my case, each of my boards record independent events, so I want them to trigger when trigger conditions are met in each board. I currently use the provided DRSOSC software, that can trigger on only the board that is being displayed at that moment. I tried opening several instances of DRSOSC to associate each to each board, but that is not possible since the second instance already does not find the boards. I wonder if there is a way of triggering from each board independently without having to use four computers.
Thank you,
Javier.
|
|
|
|
898
|
Fri Jun 9 04:11:40 2023 |
Javier Caravaca | Different sampling rates in multi-board configuration | Hello,
Is it possible to have different sampling rates in multi-board configuration? I tried using the scope application but I am unable to change the sampling rate independently.
Best,
Javier. |
|
851
|
Tue Nov 16 01:27:51 2021 |
Jacquelynne Vaughan | V3 board, only one channel works, all components at each channel input working | Hi everyone,
I'm still looking through the forum for an answer to this question, but thought I'd go ahead and post anyway just in case it hasn't been answered yet. If it has I can take this post down.
I have a V3 board, and as far as I can tell only channel 2 gives an output. If I enable other channels using the DRS Oscilloscope software, they do show static but will not show a signal if I connect one to them (e.g. a series of subsequent square waves). A technician and I took the board out and tested all the components leading up to the microcontrollers for each channel, and everything seemed to be working fine. I thought maybe it was configured to only have one channel read an output, but I looked through the Config panel in the software and nothing seemed to indicate that.
I am a novice, and maybe I'm missing something that I didn't see in the manual. I can post screenshots if needed!
Thank you for your help! |
|
537
|
Thu Sep 29 17:26:13 2016 |
Jacob Hwang | Output Timing Drifting | Hello,
I have designed four DRS4 chips (36 channels) on my board running at 1GHz (REFCLK=488.28KHz) and ROI mode. All 4 chips' REFCLK, DWRITE, RSRLOAD, and SRCLK are buffer driven by the same source. SRCLK is set to 40MHz to reduce the readout time.
If I injected a sine waveform, buffered and splitted into all 36 channels,I noticed all 9 channels on each DRS4 chip output almost the same as expected. But the output phase from chip to chip is drifting as shown in attached picture which is from two different channels of different chips. From the few boards I have built, I found few chips are drifting more than the others and is different on every board.
The sympton look like the DRS4 internal PLL is drifting, but I checked the DTAP output on every chip and found it's dead-lock steady even I used persistance setting on my oscilloscope. Do you have any suggestion how to attack this problem? Thank you.
Jacob Hwang
|
| Attachment 1: Output_Drifting.jpg
|
|
|