ID 
Date 
Author 
Subject 
798

Wed Oct 7 10:56:03 2020 
Stefan Ritt  External triggering  The trigger is there only to trigger the chip, but cannot be used as a precise time reference. If you want to measure precise timing, do this always BETWEEN two inputs, never between an input and the trigger. You might want to split and delay your trigger signal and feed one copy to another input of the evaluation board as your reference.
Stefan
Elmer Grundeman wrote: 
Dear all,
I had a question about timing jitter and external triggering.
I trigger the board externally with a 3V pulse from a DG645 delay generator and as a test I use the gated charge function to integrate another pulse of the DG which goes into channel 1 (the timing jitter between different outputs of the DG is on the order of ~25 picoseconds).
The issue I’m encountering is that the signal on channel 1 is jittering in time with ~1 ns, which means the signal is jittering with respect to my integration gate (point A and B). If I look at the data it always starts at t = 0.000 but my signal (pulse) moves around in time.
If I don’t use the external trigger but trigger on channel 1 directly the signal does not move with respect to the gate, but I can see the start and end of the trace move in time. If I look at the data the first data point is not at t = 0.000 but some other time, which jitters with ~1 ns.
I did repeat the voltage and timing calibration, but that did not help either.
Do you know where this jitter comes from and if I can get rid of it?
Best regards,
Elmer


799

Wed Oct 7 11:17:52 2020 
Elmer Grundeman  External triggering  I will try that, thanks!
Stefan Ritt wrote: 
The trigger is there only to trigger the chip, but cannot be used as a precise time reference. If you want to measure precise timing, do this always BETWEEN two inputs, never between an input and the trigger. You might want to split and delay your trigger signal and feed one copy to another input of the evaluation board as your reference.
Stefan
Elmer Grundeman wrote: 
Dear all,
I had a question about timing jitter and external triggering.
I trigger the board externally with a 3V pulse from a DG645 delay generator and as a test I use the gated charge function to integrate another pulse of the DG which goes into channel 1 (the timing jitter between different outputs of the DG is on the order of ~25 picoseconds).
The issue I’m encountering is that the signal on channel 1 is jittering in time with ~1 ns, which means the signal is jittering with respect to my integration gate (point A and B). If I look at the data it always starts at t = 0.000 but my signal (pulse) moves around in time.
If I don’t use the external trigger but trigger on channel 1 directly the signal does not move with respect to the gate, but I can see the start and end of the trace move in time. If I look at the data the first data point is not at t = 0.000 but some other time, which jitters with ~1 ns.
I did repeat the voltage and timing calibration, but that did not help either.
Do you know where this jitter comes from and if I can get rid of it?
Best regards,
Elmer



31

Sun Jan 31 23:52:15 2010 
Hao Huan  Failure In Flashing Xilinx PROM  Hi Stefan,
I have an oldversion DRS4 evaluation board which doesn't have the latest firmware. I tried to flash the drs_eval1.ipf boundary scan chain into the XCF02S PROM with Xilinx IMPACT, and the firmware seemed to go through into the PROM. However, when I started the DRS command line interface to test the firmware it kept on reporting errors like
musb_write: requested 10, wrote 116, errno 0 (No error)
musb_read error 116
musb_write: requested 10, wrote 22, error 0 (No error)
musb_read error 116
and so on. Finally the program made a dumb recognition of the board as
Found mezz. board 0 on USB, serial #0, firmware revision 0
Do you have any idea which caused this problem? Thanks! 
32

Mon Feb 1 08:30:42 2010 
Stefan Ritt  Failure In Flashing Xilinx PROM 
Hao Huan wrote: 
Hi Stefan,
I have an oldversion DRS4 evaluation board which doesn't have the latest firmware. I tried to flash the drs_eval1.ipf boundary scan chain into the XCF02S PROM with Xilinx IMPACT, and the firmware seemed to go through into the PROM. However, when I started the DRS command line interface to test the firmware it kept on reporting errors like
musb_write: requested 10, wrote 116, errno 0 (No error)
musb_read error 116
musb_write: requested 10, wrote 22, error 0 (No error)
musb_read error 116
and so on. Finally the program made a dumb recognition of the board as
Found mezz. board 0 on USB, serial #0, firmware revision 0
Do you have any idea which caused this problem? Thanks!

A firmware update requires a power cycle of the evaluation board. Have you tried that? I attached for you reference the current drs_eval1.mcs file, which is meant to go into the XCF02S PROM. There were recent changes also in the DRS library, and I'm not sure if yous if recent enough. So I put also the current C files which go with the firmware. They contain also some improvements which should reduce the intrinsic noise of the board. 
104

Mon Jul 19 12:07:04 2010 
Jinhong Wang  Fixed Patter Timing Jitter  Hi Stefan, can you give some suggestions on determination of fixed pattern timing jitter of DRS4? Thanks~ 
105

Mon Jul 19 12:47:17 2010 
Stefan Ritt  Fixed Patter Timing Jitter 
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 (lowtohigh) 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 5000.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 
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 (lowtohigh) 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 5000.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 
122

Tue Jul 5 10:09:43 2011 
Stefan Ritt  Fixed Patter Timing Jitter 
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 (lowtohigh) 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 5000.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 
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 (lowtohigh) 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 5000.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~ 
124

Wed Jul 13 04:26:52 2011 
Stefan Ritt  Fixed Patter Timing Jitter 
Jinhong Wang wrote: 
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 (lowtohigh) 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 5000.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~

The length of the segments is a combination of the sampling jitter and the voltage noise. If you signal contains some noise (and all signals do) it will translate to timing jitter. The DNL of the DRS sampling interval shows a variation from the mean of typically 30%. After you correct for it, it will of course become much smaller. As I said, some people measured 10 ps timing with the DRS4 after careful timing calibration. 
117

Thu Apr 14 18:23:53 2011 
Bob Hirosky  Fixes to DOScreen.cpp for recent built on linux  Hello,
I was just building version 3.1.0 and ran into some problems in DOScreen.cpp. Basically the conversions from
char* to wxString were generating "ambiguous overload" errors (in gcc 4.4.3, wx2.8)
The simple fix is given in the following diff output.
Cheers,
Bob
diff drs3.1.0_o/src/DOScreen.cpp drs3.1.0/src
237c237
< wxst = wxString(m_frame>GetOsci()>GetDebugMsg(),wxConvUTF8); //BH

> wxst = m_frame>GetOsci()>GetDebugMsg();
246c246
< wxst = wxString(m_debugMsg,wxConvUTF8); //BH

> wxst = m_debugMsg;
477c477
< wxst = wxString("AUTO",wxConvUTF8); //BH

> wxst = "AUTO";
479c479
< wxst = wxString("TRIG?",wxConvUTF8); //BH

> wxst = "TRIG?";

118

Fri Apr 15 08:28:54 2011 
Stefan Ritt  Fixes to DOScreen.cpp for recent built on linux  > Hello,
>
> I was just building version 3.1.0 and ran into some problems in DOScreen.cpp. Basically the conversions from
> char* to wxString were generating "ambiguous overload" errors (in gcc 4.4.3, wx2.8)
>
> The simple fix is given in the following diff output.
>
> Cheers,
>
> Bob
>
> diff drs3.1.0_o/src/DOScreen.cpp drs3.1.0/src
> 237c237
> < wxst = wxString(m_frame>GetOsci()>GetDebugMsg(),wxConvUTF8); //BH
> 
> > wxst = m_frame>GetOsci()>GetDebugMsg();
> 246c246
> < wxst = wxString(m_debugMsg,wxConvUTF8); //BH
> 
> > wxst = m_debugMsg;
> 477c477
> < wxst = wxString("AUTO",wxConvUTF8); //BH
> 
> > wxst = "AUTO";
> 479c479
> < wxst = wxString("TRIG?",wxConvUTF8); //BH
> 
> > wxst = "TRIG?";
>
Thanks for mentioning this. I always overlook this because I develop under Windows where this warning does not show
up. I fixed that in the current version. Usually I just use _T() instead wxString() because this is shorter and
recommended by the developers.
Cheers, Stefan. 
138

Fri Dec 9 17:45:48 2011 
Michael Büker  Fixes to DOScreen.cpp for recent built on linux  > I was just building version 3.1.0 and ran into some problems in DOScreen.cpp. Basically the conversions from
> char* to wxString were generating "ambiguous overload" errors (in gcc 4.4.3, wx2.8)
>
> The simple fix is given in the following diff output.
Today, I ran into the same problem and was happy to find your fix. I've incorporated it into a unified diff file,
that can easily be applied with the patch program by saving it into a file ('drsosc3.1.0wxfix.patch', say), and
in the drs3.1.0 directory running:
patch 1 < drsosc3.1.0wxfix.patch
This is the file:
 src/DOScreen.cpp.orig 20111209 15:49:48.682201902 +0100
+++ src/DOScreen.cpp 20111209 15:51:45.666000111 +0100
@@ 234,7 +234,7 @@ void DOScreen::DrawWaveform(wxDC& dc, wx
// display optional debug messages
if (*m_frame>GetOsci()>GetDebugMsg()) {
 wxst = m_frame>GetOsci()>GetDebugMsg();
+ wxst = wxString(m_frame>GetOsci()>GetDebugMsg(),wxConvUTF8);
dc.SetPen(wxPen(*wxLIGHT_GREY, 1, wxSOLID));
dc.SetBrush(*wxGREEN);
dc.SetTextForeground(*wxBLACK);
@@ 243,7 +243,7 @@ void DOScreen::DrawWaveform(wxDC& dc, wx
dc.DrawText(wxst, m_x1+4, m_y1+2);
}
if (m_debugMsg[0]) {
 wxst = m_debugMsg;
+ wxst = wxString(m_debugMsg,wxConvUTF8);
dc.SetPen(wxPen(*wxLIGHT_GREY, 1, wxSOLID));
dc.SetBrush(*wxGREEN);
dc.SetTextForeground(*wxBLACK);
@@ 474,9 +474,9 @@ void DOScreen::DrawWaveform(wxDC& dc, wx
if (m_osci>GetNumberOfBoards() && m_osci>IsIdle()) {
dc.SetTextForeground(*wxGREEN);
if (m_osci>GetTriggerMode() == TM_AUTO)
 wxst = "AUTO";
+ wxst = wxString("AUTO",wxConvUTF8);
else
 wxst = "TRIG?";
+ wxst = wxString("TRIG?",wxConvUTF8);
dc.GetTextExtent(wxst, &w, &h);
dc.DrawText(wxst, m_x2  w  2, m_y1 + 1);
} 
185

Mon Oct 29 18:30:28 2012 
Martin Petriska  GetWave  I have some question according to GetWave function. In drs_exam.cpp simple GetWave(0,0,wave_array[]) etc...is used. Is there primary (cell) calibration, secondary calibration (Readout) and remove Spikes used, as in DRS Oscilloscope application? 
192

Tue Nov 13 11:26:32 2012 
Stefan Ritt  GetWave 
Martin Petriska wrote: 
I have some question according to GetWave function. In drs_exam.cpp simple GetWave(0,0,wave_array[]) etc...is used. Is there primary (cell) calibration, secondary calibration (Readout) and remove Spikes used, as in DRS Oscilloscope application?

Yes, yes, no. To get spike removals, you need the function RemoveSpikes from Osci.cpp in the DRSOsc project. 
409

Wed May 13 00:52:51 2015 
Cosmin Deaconu  Getting Trigger Source  I'd like to be able to know which channel (0,1,2,3 or external) was responsible for the trigger. DRSBoard::GetTriggerSource() seems to always return 1. Is there a way to get this information? Using the DRS4 evaluation board and software version 5.0.3.
Thanks,
Cosmin

411

Wed May 13 08:19:53 2015 
Stefan Ritt  Getting Trigger Source  DRSBoard::GetTriggerSource() simply returns what has been enabled via DRSBoard::SetTriggerSource(). The actual source which causes the trigger is not stored in the hardware of the board, because I can be reconstructed easily from the waveforms. So just look which of the channels is above your trigger threshold. If none of the channels has a waveform obove the threshold, then the trigger must have been come from the external trigger.
Cosmin Deaconu wrote: 
I'd like to be able to know which channel (0,1,2,3 or external) was responsible for the trigger. DRSBoard::GetTriggerSource() seems to always return 1. Is there a way to get this information? Using the DRS4 evaluation board and software version 5.0.3.
Thanks,
Cosmin


33

Wed Feb 10 02:57:55 2010 
pepe sanchez lopez  Hello  hello i am an student and i want to do my final project with drs4 board and i really can´t find how to open waveform file and how can i save or opened many of them quickly.
if you can tell me how i will be very grateful.
thanks,
kind regards. 
34

Wed Feb 10 15:35:09 2010 
Stefan Ritt  Hello 
pepe sanchez lopez wrote: 
hello i am an student and i want to do my final project with drs4 board and i really can´t find how to open waveform file and how can i save or opened many of them quickly.
if you can tell me how i will be very grateful.
thanks,
kind regards.

There is no builtin possibility to open waveform files, you have to write your own programs to do that. 
87

Wed May 26 19:18:09 2010 
Hao Huan  High Frequency Input for DRS  Hi Stefan,
I read in the DRS datasheet that the bandwidth for the transparent mode OUT+ is only 200MHz which I think cannot be improved by any active input buffer; so if you want to operate the chip for really high frequency input, would it be better to feed onboard discriminators not from the output of DRS but from the input end?
Thanks!

