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

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.

#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.

  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.

 I checked my project today and I think I need the file USR_LIB_VEC_IOFD_CPE_NALL.I don't know if is it a VHD files or a IP core.

I'll be extremely grateful.

  Hello everyone！I'm a new user of DRS4 board,but it seems that some files are missing in my demo project.So I hope someone could help me by sending a correct VHDL hardware project to my Email:lcyiss900@gmail.com.Thanks in advance!

T

The Domino wave anyhow is always active in mode 1, but you have to enable the writing to the memory cells (via the DENABLE signal). This is done with the b->StartDomino(). You are right that this call takes about 1ms over USB 2.0, so avoiding it would speed up the DAQ by about a factor of two. I have some plans to implement an automatic restart in firmware of the evaluation board, but I won't have time for that until fall of this year.

/Stefan

 hallo stefan,

I managed to fixed the problem. The problem was with the number I inserted to the function "b->SetTriggerSource" th get external trigger (it suppose to be "16" and not "4" or "12" as I understood from the function's comments).

Right now I'm trying to speed up the number of wavefrom  per second. I'm using your  drs_exam.cpp program you wrote as my basic program. When you wrote it you used the function "b->StartDomino()" inside the loop, which means that before every trigger you gave him a command to start the domino-wave.

From  the "DRS4 datasheet" (page 8) I understand that I can bypass the need to restart the  domino-wave by using "b->SetDominoActive(1)" and "b->SetDominoMode(1)", but when I tried it didn't work (the waveform I got every readout remain the same which means the dominowave froze after the first readout).

Am I understanding wrong or do I need to add somthing more\else so the domino-wave will not stop after each readout? is there any hazard by doing that, as mentiond in page 8 of the the datasheet?

thanks again,

Tmiron.

 Hi Stefan,

thanks for the quick reply, I know that this solution works with drscl but not within my code.

I tried to track it down, but gave up very soon. Seems as if AnalyzeWF() which is called by CalibrateTiming() finds to much zero-crossings when it is called the second time.

Regards

  -- Hermann-Josef

Ups, this is certainly a bug. Try to restart drscl between calibrations. Anyhow the calibration is poor (~20ps), so in a month or two we will have a much better one (~3ps), but that needs a new board (then will be called V5).

/Stefan

Hi,

is there any (obvious) reason why it is not possible (or not indended) to repeat the time calibration of a DRS4 eval board several times. I get the shown error message from the 'drscl' tool as well when I try to call the corresponding method in the support library:

mathes@ikauger5:~/src/DRS4> drs-4.0.1/drscl
DRS command line tool, Revision 20430
Type 'help' for a list of available commands.

Found DRS4 board  0 on USB, serial #2362, firmware revision 17662

B0> tcalib
Enter calibration frequency [GHz]: 5
Creating Timing Calibration of Board #2362
[==================================================]
B0> tcalib 5
Creating Timing Calibration of Board #2362
Error performing timing calibration, please check waveforms

As I will be in holidays, the answer is not urgent.

Thanks

 -- Hermann-Josef

No. IsBusy() is the only way the hardware trigger is checked. If there is no hardware trigger, you can issue a "fake" trigger (called software trigger) to stop the acquisition. This happens for example if you switch DRSOsc to "Auto" trigger instead of "Normal" trigger, very similar than a normal oscilloscope does.

/Stefan 

Hi satefan,

I did some debug on the DRSOsc program and saw that everywhere you used the function "IsBusy()", you used it with "SoftTrigger()", which (to my understanding) create a software trigger. did you used another function, other than "ISBusy", that check the hardware trigger?

have a nice day,

Tmiron.

 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.

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

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 

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. 

The function b->IsBusy() returns true if there has been no trigger. So "while (b->IsBusy());" is simply an endless loop until the board triggered. Please check your signals and trigger configuration. Maybe you have to adjust the trigger level or polarity via b->SetTriggerLevel(). Try signals with lower event rates. Verify that the board triggers with the DRSOsc program, you can then read off the optimal trigger level from there. 

/Stefan

 Hi Stefan.

I managed to add the averaging possibility to the oscilloscope program, but it runs too slow, so now I'm tring to add this option to the example file you attached to the program (drs_exam.cpp).
My problem is that when I run the file is not passing  the stage of getting the trigger. (it just wait after writing the line "Waiting for trigger...")
When testing the software, I work with a signal of up to 10 MHz, limited in voltage to the DRS Eval 4 ability, and I connect the signal to channel 1,from it by default is supposed to get the trigger. I also tried to change the channel settings to other channels or external trigger, and use them,  but it still not working.

I found out that the problem is related to the line "while (b->IsBusy());" in the code, but I have a problem understanding what the function "IsBusy" do and how it's work.

Can you please explain me a bit what this function does?

have a nice day,

Tmiron

 Thanks that fixed it!

Dmitry