DRS4 Forum
  DRS4 Discussion Forum, Page 2 of 45  Not logged in ELOG logo
New entries since:Thu Jan 1 01:00:00 1970
ID Date Authorup Subject
  683   Wed May 2 10:44:17 2018 Alessio BertiPeak at 0 mV in traces

Hi,

we modified drs_exam.cpp to read all 4 channels from the DRS4 and apply directly the spike removal (taken from Osci.cpp) during the acquisition phase. For test purposes, we don't save the data showing spikes and we focus on the data not having spikes (even if at the end we end up having triple and quadro spikes which are not removed by the spike removal routine, but they are rare). With this modified program we wanted to characterize the noise of the DRS4, so we took 30000 events at 5GSPS, triggering on channel 1 with a 10 MHz sine wave with 100 mV_pp (trigger level set at 10 mV), while channels 2,3 and 4 were left open without any input.

We then took a look at the data and plotted the noise histograms for channels 2,3 and 4, which you can find attached (without offset correction, named zero_peak_after_spike_removal_ch*.png). For completeness, we also attached the plot from ch1 (the sine wave). The selections in time and amplitude we applied had the goal to remove the high oscillations in amplitude occurring in the first and last samples and to discard the quadro spikes we had in the data.

We see that there is a peak at 0 mV in all histograms from all channels and scanning through the data, we saw that indeed the value 0 mV is stored many times for each event, thus originating the peak we see in the histograms. We also applied an offset correction to the data (taking the average of the first three most occuring amplitudes) of channels 2 (as an example) and the problem seems to be only partially removed.

We also noticed that this peak at 0 mV is present also when we acquired the data from the DRS4 with DRSosc saving the data in binary format.

So we had the following questions:

- why is the DRS4 saving so many times the value 0 mV (exactly 0 mV)?

- is there any way (in our case through software, preferably at acquisition time) to solve this problem?

Thank you for the help and best regards,

Alessio & Davide

 

Attachment 1: zero_peak_after_spike_removal_ch1.png
zero_peak_after_spike_removal_ch1.png
Attachment 2: zero_peak_after_spike_removal_ch2.png
zero_peak_after_spike_removal_ch2.png
Attachment 3: zero_peak_after_spike_removal_ch3.png
zero_peak_after_spike_removal_ch3.png
Attachment 4: zero_peak_after_spike_removal_ch4.png
zero_peak_after_spike_removal_ch4.png
Attachment 5: zero_peak_after_spike_removal_offset_correction_ch2.png
zero_peak_after_spike_removal_offset_correction_ch2.png
  685   Wed May 2 12:23:16 2018 Alessio BertiPeak at 0 mV in traces

Hi,

thank you for the quick reply. All the bins in the previous histograms have the same width. We also tried to plot the noise histogram for channel 2 with more bins (i.e. 1000, so that we can see almost discrete values), and the peak is still there.

Alessio & Davide

Stefan Ritt wrote:

I note that your peak at zero is exactly twice as high as the bins left and right, so this looks to me like a binning problem in your histogramming. Maybe your bin #0 goes from -1mV to +1mV, which all other bins are just 1mW wide. Can you check that?

Stefan

Alessio Berti wrote:

Hi,

we modified drs_exam.cpp to read all 4 channels from the DRS4 and apply directly the spike removal (taken from Osci.cpp) during the acquisition phase. For test purposes, we don't save the data showing spikes and we focus on the data not having spikes (even if at the end we end up having triple and quadro spikes which are not removed by the spike removal routine, but they are rare). With this modified program we wanted to characterize the noise of the DRS4, so we took 30000 events at 5GSPS, triggering on channel 1 with a 10 MHz sine wave with 100 mV_pp (trigger level set at 10 mV), while channels 2,3 and 4 were left open without any input.

We then took a look at the data and plotted the noise histograms for channels 2,3 and 4, which you can find attached (without offset correction, named zero_peak_after_spike_removal_ch*.png). For completeness, we also attached the plot from ch1 (the sine wave). The selections in time and amplitude we applied had the goal to remove the high oscillations in amplitude occurring in the first and last samples and to discard the quadro spikes we had in the data.

We see that there is a peak at 0 mV in all histograms from all channels and scanning through the data, we saw that indeed the value 0 mV is stored many times for each event, thus originating the peak we see in the histograms. We also applied an offset correction to the data (taking the average of the first three most occuring amplitudes) of channels 2 (as an example) and the problem seems to be only partially removed.

We also noticed that this peak at 0 mV is present also when we acquired the data from the DRS4 with DRSosc saving the data in binary format.

So we had the following questions:

- why is the DRS4 saving so many times the value 0 mV (exactly 0 mV)?

- is there any way (in our case through software, preferably at acquisition time) to solve this problem?

Thank you for the help and best regards,

Alessio & Davide

 

 

 

Attachment 1: zero_peak_after_spike_removal_ch2_1000_bins.png
zero_peak_after_spike_removal_ch2_1000_bins.png
  691   Tue May 8 12:15:54 2018 Alessio BertiPeak at 0 mV in traces

Hi Stefan,

following your example, we tried to perform the same measurement, using drs_exam and taking 1000 events. The results we obtained are in the plots attached (both in log and linear scale). We tried two different binnings:

    - the first is the same as the one used in your example, that is 0.1 mV (corresponding to the plots having 81 bins)

    - the second is a more wide binning equal to 0.35 mV, that is (2^(-11.5)) mV, 11.5 being the effective number of bits given in the DRS4 spreadsheet (corresponding to the plots having 23 bins)

With the fine binning we see that in the bin centered around 0 there is a little excess of events (the effect is more visible in the log scale histograms). This excess is not present in the wide binning case.

Is the problem we had before (and also here in the fine binning case) lying in the fact that we were trying to have bins with a width smaller than the effective resolution of the instrument (0.35 mV)?

We also noticed that in drs_exam, the values for the waveform are printed in the ASCII file with 1 digit after the decimal point, but when trying to print more digits the resolution is not improved (i.e. the decimal digits from the second one on are 0). This means that the values are rounded to a resolution of 0.1 mV when they are saved through the GetWave() routine (and in fact the member fPrecision is set to 0.1 -mV- in DRS.cpp, line 7502, and also in DRS.h, line 757, GetPrecision() returns 0.1). Why is that so? How does it reconcile with the effective number of bits giving a resolution of 0.35 mV?

Thank you,

Alessio & Davide

 

 

Stefan Ritt wrote:

I tried the following:

- trigger on a 10 MHz sine wave on CH0, CH1 was open

- run drs_exam.cpp program and write data.txt with a few events

- imported the event into Excel

- did a histogram on (empty) CH1

What I see is a nice Gaussian distribution centered around 1mV, but with no spike around zero. See attachment. So I still believe that you have either a binning or a rounding problem. Like you round value -0.99 to +0.99 all to zero mV, and 1.00 to 1.99 mV to one mV.

Stefan

Alessio Berti wrote:

Hi,

thank you for the quick reply. All the bins in the previous histograms have the same width. We also tried to plot the noise histogram for channel 2 with more bins (i.e. 1000, so that we can see almost discrete values), and the peak is still there.

Alessio & Davide

Stefan Ritt wrote:

I note that your peak at zero is exactly twice as high as the bins left and right, so this looks to me like a binning problem in your histogramming. Maybe your bin #0 goes from -1mV to +1mV, which all other bins are just 1mW wide. Can you check that?

Stefan

Alessio Berti wrote:

Hi,

we modified drs_exam.cpp to read all 4 channels from the DRS4 and apply directly the spike removal (taken from Osci.cpp) during the acquisition phase. For test purposes, we don't save the data showing spikes and we focus on the data not having spikes (even if at the end we end up having triple and quadro spikes which are not removed by the spike removal routine, but they are rare). With this modified program we wanted to characterize the noise of the DRS4, so we took 30000 events at 5GSPS, triggering on channel 1 with a 10 MHz sine wave with 100 mV_pp (trigger level set at 10 mV), while channels 2,3 and 4 were left open without any input.

We then took a look at the data and plotted the noise histograms for channels 2,3 and 4, which you can find attached (without offset correction, named zero_peak_after_spike_removal_ch*.png). For completeness, we also attached the plot from ch1 (the sine wave). The selections in time and amplitude we applied had the goal to remove the high oscillations in amplitude occurring in the first and last samples and to discard the quadro spikes we had in the data.

We see that there is a peak at 0 mV in all histograms from all channels and scanning through the data, we saw that indeed the value 0 mV is stored many times for each event, thus originating the peak we see in the histograms. We also applied an offset correction to the data (taking the average of the first three most occuring amplitudes) of channels 2 (as an example) and the problem seems to be only partially removed.

We also noticed that this peak at 0 mV is present also when we acquired the data from the DRS4 with DRSosc saving the data in binary format.

So we had the following questions:

- why is the DRS4 saving so many times the value 0 mV (exactly 0 mV)?

- is there any way (in our case through software, preferably at acquisition time) to solve this problem?

Thank you for the help and best regards,

Alessio & Davide

 

 

 

 

 

Attachment 1: 20180508_drs4_drs_exam_1000_events_81_bins_linear.png
20180508_drs4_drs_exam_1000_events_81_bins_linear.png
Attachment 2: 20180508_drs4_drs_exam_1000_events_81_bins_log.png
20180508_drs4_drs_exam_1000_events_81_bins_log.png
Attachment 3: 20180508_drs4_drs_exam_1000_events_23_bins_linear.png
20180508_drs4_drs_exam_1000_events_23_bins_linear.png
Attachment 4: 20180508_drs4_drs_exam_1000_events_23_bins_log.png
20180508_drs4_drs_exam_1000_events_23_bins_log.png
  696   Mon May 14 09:21:29 2018 Alessio BertiWIndows Connection problem with drs507 SOLVED

Hi,

I have a machine with Windows 10 and the solution provided by Steven works fine. To give more details, the driver installed in my case is WinUSB (i.e. libusb, v6.1.7600.16385).

Cheers,

Alessio

Alec Shackleford wrote:

Thank you for this fantastic solution. I had almost reinstalled windows 7 to see if that would solve the issue!

 

All the best,

Alec

Stefan Ritt wrote:

Dear Steven, many thanks for this information, this is very useful. I know of people having problems on Windows 10, maybe this will also help them.

Stefan

Steven Block wrote:

Hello All,

I too have been struggling with trying to get the drs4 (507) to work on my windows machine and I found it to be a problem with the libusb library. My solution is as follows and has worked on multiple PC's. I ran this solution after I first plugged in the drs4 and installed 507.

Go to http://zadig.akeo.ie/ and install the corresponding software.

After that, you will need to plug in the DRS4 to your computer. From there go to ‘Options’, and select ‘List all Devices’.

Finally, choose the DRS4 evaluation board from the list and press install driver and let it run. You should be fine after that. 

Best,

Steven

 

 

 

  805   Thu Dec 17 09:29:43 2020 Alex Myczkodrs sources on github?
Are there plans to add the drs software to github? (asking because I have users @ethz.ch that want to use it on debian,
thus I'm creating official debian packages of it, if license allows so, but talking to upstream (the developers) would be
much easier on github (or irc) than on this "DRS4 Discussion Forum".

Best,
  863   Tue Feb 15 11:59:22 2022 Alex Myczkoapt install drs4eb

drs4b is now officially on these distributions:

https://repology.org/project/drs4eb/versions

enjoy

  549   Wed Oct 26 21:15:35 2016 Alexey LubinetsProblems with DRS command line
Hello, everybody

I have installed the software for the DRS4 Evaluation Board.
When I run the DRS Oscilloscope, it works OK (at least, my computer "knows", that the board is connected). But when I run the DRS Command Line Interface, it writes "USB successfully scanned, but no boards found
No DRS boards found".
How can I manage with this problem? The drivers for the DRS Evaluation Board are installed.

Regards, Alexey Lubinets
  567   Thu Nov 24 00:40:38 2016 Alexey LubinetsPLL did not lock

Hello, everybody!

I installed DRSosc and DRScl. Command line works normally (at least, it can "see" the board). But when I start the oscilloscope, I have an error: "PLLs did not lock on USB board #0, serial number #...". In Info section I can see the board type = 9 (and in the error message I have "USB board #0").

After that I have a warning: "Board on USB0 has invalid voltge calibration. Only raw data will be displayed". I tried to execute voltage calibration using DRSosc and DRScl, but it did not help.

Did anybody face such broblems? Does anybody know, how to fix them?

Thank you. Alexey.

  570   Mon Nov 28 16:48:15 2016 Alexey LubinetsPLL did not lock

The serial number is 2586. This board is about two years old, and it might be in use (but I do not know exactly).

Stefan Ritt wrote:

Which serial number has the board? Has it been in use before or is it a new board?

Stefan

Alexey Lubinets wrote:

Hello, everybody!

I installed DRSosc and DRScl. Command line works normally (at least, it can "see" the board). But when I start the oscilloscope, I have an error: "PLLs did not lock on USB board #0, serial number #...". In Info section I can see the board type = 9 (and in the error message I have "USB board #0").

After that I have a warning: "Board on USB0 has invalid voltge calibration. Only raw data will be displayed". I tried to execute voltage calibration using DRSosc and DRScl, but it did not help.

Did anybody face such broblems? Does anybody know, how to fix them?

Thank you. Alexey.

 

 

  753   Thu Jun 20 01:36:48 2019 Andrew PeckEvaluation firmware wait_vdd state

Dear Stefan,

I am working with others at UCLA on a custom made board built around the DRS4. We are in the process of writing firmware so I am adapting the readout state machine from the evaluation board firmware.

I see in the state machine of the eval board firmware that after a trigger is received, the FPGA goes into the start readout state and then into "wait_vdd", where the FPGA waits "~120 us for vdd to stabilize" before reading out the ADC.

Our application is sensitive to deadtime and this wait_vdd state adds very significantly.  I am trying to find anything explaining the necessity of wait_vdd in the documentation / elog and have only found so far your old forum posting, https://elog.psi.ch/elogs/DRS4+Forum/12

Does this forum posting explain wait_vdd or is there a another purpose that I have missed?

If this post is relevant to wait_vdd, does the advice of large capacitance and an LDO with fast transient response still apply or are there any new recommendations?

Thank you,

Andrew Peck

  755   Mon Jun 24 23:07:35 2019 Andrew PeckEvaluation firmware wait_vdd state

Dear Stefan, 

Thanks so much for clarifying this. We made wait_vdd a parameter controlled by software and will try to experiment with it to find some compromise between deadtime and the offset added by the droop in VDD. 

Best regards, 

Andrew

Stefan Ritt wrote:

Dear Andrew,

the posting you mention is still accurate. Any power supply will drop when you start the Domino wave, no matter how big your capacitor is. Unfortunately the output signal of the DRS4 scales with VDD. So if your VDD drops by 40 mV and you get a trigger and you immediately start the readout, the output baseline will also be shifted by about 40 mV. If you are sensitive to dead time, you can remove the wait_vdd state completely, but then you have to deal with varying baseline shifts. If you have narrow signals sitting on a broad baseline, you can correct for this by measuring the baseline outside your signal, then subtracting it before integrating your pulse. If you have lots of pile-up in your signals, it might sometimes be hard to evaluate the baseline on an event-by-event basis.

Stefan

Andrew Peck wrote:

Dear Stefan,

I am working with others at UCLA on a custom made board built around the DRS4. We are in the process of writing firmware so I am adapting the readout state machine from the evaluation board firmware.

I see in the state machine of the eval board firmware that after a trigger is received, the FPGA goes into the start readout state and then into "wait_vdd", where the FPGA waits "~120 us for vdd to stabilize" before reading out the ADC.

Our application is sensitive to deadtime and this wait_vdd state adds very significantly.  I am trying to find anything explaining the necessity of wait_vdd in the documentation / elog and have only found so far your old forum posting, https://elog.psi.ch/elogs/DRS4+Forum/12

Does this forum posting explain wait_vdd or is there a another purpose that I have missed?

If this post is relevant to wait_vdd, does the advice of large capacitance and an LDO with fast transient response still apply or are there any new recommendations?

Thank you,

Andrew Peck

 

 

  168   Sat Jun 23 00:29:52 2012 Andrey Kuznetsovtriger for measuring time between pulses in channels

Stefan Ritt wrote:

On the evaluation board, yes. This board is not optimized for high readout rate. If you do your own electronics, like GBit Ethernet, you could be much faster. 

 What is the readout rate via GBit Ethernet that you have achieved?

Where is the bottleneck in ethernet?

What is the proposed scheme by which the GBit Ethernet will be implemented, will the DRS4 Eval Board have to wait for the computer to respond before sending the data (wouldn't this make the readout much slower?), or will the DRS4 Eval Board keep sending the data to the computer?

  243   Wed May 8 06:07:52 2013 Andrey KuznetsovDRS4 v2.0 Eval Board running on higher versions of DRS Oscilloscope program

Hi,

I have an old v2.0 board that I just upgraded firmware on using v4.0.0 download package which has a drs4_eval1.bit for v2.0 boards containing firmware 15158. So I would like to use the latest DRS Oscilloscope program, due to the faster acquisition speeds and advanced calibration techniques, however I seem to be running into a problem.

v4.0 DRS Oscilloscope program displays flat lines in any configuration instead of a pulse that I provide to it (I can't tell if calibration works because all my traces are flat and nothing triggers) but provides ~460Hz. Any idea why v4.0.0 DRS Oscilloscope program does not work with DRS4 Eval Board v2.0 fw:15158?

 

v3.0 DRS Oscilloscope program actually works and displays the pulse that I input (calibration also works), however it only has 64Hz speed due to v3.0.0 not having multithreading capability which is provided in v3.1.0 software version of the program.

 

Can you please upload and post on the website the latest software packages for v2 and v3? I would like to use v3.1.0 DRS Oscilloscope version. (Both Linux and Windows, but Linux preferably)

 

Also, I would like to report that for some reason, I don't know if it happens with v3.0 program used on v2.0 board only or a general issue, but after each calibration of voltage and timing, the trigger does not work. I have to exit the oscilloscope program, and run it again, then the trigger works fine, and the device is calibrated.

Thank you

  244   Wed May 8 19:50:01 2013 Andrey KuznetsovDRS4 installation on Windows 8 issues

I'm also having trouble installing drivers and running DRSOsc program on another computer running Windows 8.


The issue with the driver is that it's not digitally signed.


The issue with the DRSOsc is that it's failing to find libusb0.dll. libusb-win32 seemed to have installed upon DRS4 software install, however the supplied version is Windows 7/8 incompatible, so on Windows 7 computer I had to download libusb_win32 v1.2.6.0 from the official website and install it directly, then everything worked fine. However in Windows 8, I am unable to install libusb-win32 because in  libusb-win32 Inf Wizard installation program when you select for which device the libusb should be used, it asks to install a driver, but when I point to DRS' driver, it says "Unknown Error: 1" and that's that. One way around the libusb issue is to copy the required dll and sys file directly where the .exe is stored.


I will attempt to disable signed driver signature requirement, and see if the driver installs then, but this should really be fixed instead.

  279   Thu Jul 25 01:31:29 2013 Andrey KuznetsovEvaluation Board Behavior

alonzi wrote:

Stefan Ritt wrote:

alonzi wrote:

Working with the DRS evaluation board we noticed some funny behavior: See attatchment 1. In about 1% of scope traces we see the first and last bin take on a value substantially different from the baseline, note the small spikes on the end of the traces. These spikes occur across all channels and either appear in all channels or in none. Attachment two shows what several thousand scope traces look like. You can clearly see that some of the traces are offset from the normal base line. Has anyone observed this behavior before? Any ideas?

see https://muon.npl.washington.edu/elog/g2/Detectors/550 for full discussion. 

Actually the first and last sample are even more off the baseline, so I cut them out in software in the DRSOscilloscope. So actually the chip has only 1022 "usable" cells. It might happen in some rare cases that more cells are affected, although I have not yet seen this (maybe I did not look close enough). So I propose that you cut out one more bin at the beginning and the end, so a total of 1020 cells, and you should be fine.

/Stefan 

 Thanks for the quick reply. Our quick fix was to do just that. 

 We've encountered similar issues with board v2.0. Cell #2 across all channels would occasionally go full negative amplitude (0 I guess).

I don't remember if calibration fixed the problem, might have.

  289   Wed Aug 28 13:07:51 2013 Andrey KuznetsovSome bug fixes and questions

  For http://www.psi.ch/drs/DocumentationEN/manual_rev20.pdf:

0 0x02 15..8 board_type 5 for DRS4 USB Evaluation Board 1.1 ---> should instead say Evaluation Board 2.0 ?

 I've been reviewing DRS.cpp v4.0.1

1) if(i==100) should be if(i==1000) in function int DRSBoard::SetFrequency(double demand, bool wait)

Otherwise if PLL did not lock, i = 1000, and the if statement is evaluating it against 100, not 1000 so it never gets triggered and the error goes unnoticed.

      if (wait) {
         StartDomino();
         for (i=0 ; i<1000 ; i++)
         if (GetStatusReg() & BIT_PLL_LOCKED0)
            break;
         SoftTrigger();
         if (i==100) {
            printf("PLL did not lock for frequency %lf\n", demand);
            return 0;
         }
      }


2) int DRSBoard::RegulateFrequency(double demand) does not seem to work at all, the frequency does not lock for either 2 or 5 GHz, tested using DRS4 v2.0 eval board with DRS v4.0.1 and v2.0.1 software's drscl tool.


3) In int DRSBoard::SetTriggerDelayPercent(int delay) and int DRSBoard::SetTriggerDelayNs(int delay), what is the purpose of Read and setting of "reg" if it's not being used or exported anywhere else outside of that function? Seems like Read and reg are called for nothing.

      Read(T_CTRL, &reg, REG_TRG_DELAY, 2);
      reg = (reg & 0xFF00) | ticks;
      Write(T_CTRL, REG_TRG_DELAY, &ticks, 2);

Also, I don't understand why in int DRSBoard::SetSyncDelay(int ticks), the code changes to 
      Read(T_CTRL, &reg, REG_TRG_DELAY, 2);
      reg = (reg & 0xFF) | (ticks << 8);
      Write(T_CTRL, REG_TRG_DELAY, &reg, 2);
In particular, reg = (reg & 0xFF00) | ticks; and reg = (reg & 0xFF) | (ticks << 8);  I'm not really sure but doesn't Read() with size 2 return a value that has a maximum value of 0xFF, or 8bits? But ticks << 8, since ticks == 255 max, makes 255 << 8 => 65280, which is now a 16bit value and size 4. No? I might be wrong here, and if I am then I don't understand what's going on. Can you please explain? In v2.0.1 the ticks were a maximum of 511 or 9bits, why did it change to 8bits?

4) A function is being called incorrectly in GetWave() in DRS.cpp

int DRSBoard::GetWave(unsigned int chipIndex, unsigned char channel, float *waveform)
{
   return GetWave(chipIndex, channel, waveform, true, fStopCell[chipIndex], false, 0, true);
}

The return is calling the following overloaded function:
int DRSBoard::GetWave(unsigned int chipIndex, unsigned char channel, float *waveform, bool responseCalib, int triggerCell, int wsr, bool adjustToClock, float threshold, bool offsetCalib)
the problem is that int wsr is not passed to the function and it thus causes implicit conversions where false is being cast into int, 0 into bool, and true into float.

 

I'll post more if I have any questions or spot any more bugs.

  290   Thu Sep 5 10:01:00 2013 Andrey KuznetsovSome bug fixes and questions

#11 0x080589de in DRSBoard::GetWave (this=0xb7456008, chipIndex=0, channel=0 '\000', waveform=0x40f24000, responseCalib=true, triggerCell=207, wsr=0, adjustToClock=false, threshold=1, offsetCalib=true) at src/DRS.cpp:3380

This is calling:

int GetWave(unsigned int chipIndex, unsigned char channel, float *waveform, bool responseCalib, int triggerCell = -1, int wsr = -1, bool adjustToClock = false, float threshold = 0, bool offsetCalib = true);

from DRS.cpp:
return GetWave(chipIndex, channel, waveform, true, fStopCell[chipIndex], false, 0, true);

false=0
true=1

As you can see offsetCalib ends up being defined by default, threshold set to 1 because of true, adjustToClock is false set by 0, wsr is 0 set by false, however threshold is never used with DRS4 eval board. So although it doesn't affect data retrieval, it's just dumb luck the function ends up being called with parameters that matter being exactly what they were meant to be.

  291   Mon Sep 9 06:49:36 2013 Andrey KuznetsovSome bug fixes and questions

The DRSCallback *pcb is missing an if statement in the code when DRS Oscilloscope software isn't used when calibrating in function: int DRSBoard::CalibrateTiming(DRSCallback *pcb)

I had to add if (pcb != NULL) before each pcb call, like other functions are using so that the program doesn't segfault when the function is called like b->CalibrateTiming(NULL);

 

That's the only function that's missing this if statement for DRSCallback *pcb call, and there are 2 calls in this function to pcb that need fixing.

  293   Wed Sep 11 02:41:28 2013 Andrey KuznetsovUSB connection stops
Hi,

although I don't have a chance to test your code, it looks very similar to what I am using.

I can confirm that the DRS4 communication breaks down if the program talking to the DRS4 is closed abruptly or before is has a chance 
to properly execute "delete drs" where it closes the USB connection.

For me if I terminate the program that's using DRS4, the next time I might or might not be able to connect to the DRS4 because I would 
get a magic number or the program would just stop. The DRS4 eval board needs to be restarted via pulling the plug if the orange LED is 
not ON.

I have tried to power down the DRS4 board via software under SL6 linux, but the reality is that the DRS4 eval board is powered directly 
by the 5V USB rail off the computer, and you cannot software control that, you can only suspend the communication of the USB 
port/device.

So I don't have a solution to fix this issue, but my best advice is to change your software such that it calls "delete drs" to 
terminate the USB connection before you close or terminate the program.

Oh and I have not tried running multiple programs at the same time to see if that might be causing the issue as well. The usb library 
might simply error out saying the device is inaccessible because it's being used.

> Hello the DRS4 team,
> 
> I and some of my colleagues are using DRS4 evaluation boards (ver. 3) for the R&D of the Cherenkov Telescope Array project. During 
> our PMT measurements, we have encountered a problem which is probably related to USB connection. In fact, I cannot reproduce this 
> problem with my Linux virtual machine (Scientific Linux 5 64 bit), but other colleagues from three different universities in Japan 
> reported the same problem with their real machines.
> 
> === Short Summary ===
> DRSBoard::SetFrequency occasionally stops
> 
> === Environment ===
> - drs-3.0.0
> - Scientific Linux 5.5 (32 bit)
> - lib-usb-devel-0.1.12-5.1.i386
> 
> === Steps to Reproduce the Problem ===
> 1. Compile the attached file drs_simple.cpp with drs-3.0.0
> 2. Repeat the following command several times from a terminal
> 
> $ drs_simple -0.05 1000 ./outputfilename.dat true 2.
> 
> 3. The above command may stop. In that case, you need to kill the command by Ctrl-C.
> 
> === Comments ===
> - Once the command stops, we cannot run the above command properly.
> - If we unplug and plug the USB cable again, the command can be executed again.
> - It seems that the program stops inside DRSBoard::SetFrequency
> 
> I would very appreciate it if you could give me any advise. If you need further information, please let me know.
> 
> Akira
  130   Fri Sep 16 22:06:07 2011 Andriy Zatserklyaniycompilation error for version 4.0.0 on linux

Hi Stefan,

When I compiled DRS4 software version 4.0.0 on Linux (Debian Squeeze) I got this compilation error:

g++ -g -O2 -Wall -Wuninitialized -fno-strict-aliasing -Iinclude -DOS_LINUX -DHAVE_LIBUSB -DUSE_DRS_MUTEX musbstd.o mxml.o strlcpy.o DRS.o ConfigDialog.o DOFrame.o DOScreen.o DRSOsc.o MeasureDialog.o Measurement.o Osci.o InfoDialog.o DisplayDialog.o AboutDialog.o EPThread.o rb.o main.o -o drsosc -lpthread -lutil -lusb -pthread   -lwx_gtk2u_richtext-2.8 -lwx_gtk2u_aui-2.8 -lwx_gtk2u_xrc-2.8 -lwx_gtk2u_qa-2.8 -lwx_gtk2u_html-2.8 -lwx_gtk2u_adv-2.8 -lwx_gtk2u_core-2.8 -lwx_baseu_xml-2.8 -lwx_baseu_net-2.8 -lwx_baseu-2.8
DOFrame.o: In function `DOFrame':
/srv/zatserkl/work/drs4/drs-4.0.0/src/DOFrame.cpp:237: undefined reference to `TriggerDialog::TriggerDialog(wxWindow*)'
/srv/zatserkl/work/drs4/drs-4.0.0/src/DOFrame.cpp:237: undefined reference to `TriggerDialog::TriggerDialog(wxWindow*)'
collect2: ld returned 1 exit status
make: *** [drsosc] Error 1

 

To fix it I added TriggerDialog.o into CPP_OBJ line of the Makefile:

 

CPP_OBJ       = DRS.o ConfigDialog.o DOFrame.o DOScreen.o DRSOsc.o MeasureDialog.o Measurement.o Osci.o InfoDialog.o DisplayDialog.o AboutDialog.o EPThread.o rb.o TriggerDialog.o

 

Best,

Andriy.

ELOG V3.1.5-fe60aaf