DRS4 Forum
  DRS4 Discussion Forum, Page 14 of 45  Not logged in ELOG logo
New entries since:Thu Jan 1 01:00:00 1970
ID Dateup Author Subject
  270   Sat Jul 6 06:10:38 2013 Stefan RittMissing methods in drs-4.0.1.tar.gz

Hermann-Josef Mathes wrote:

Hi,

while trying to create python bindings for the DRS stuff using SWIG 2.0.4, two undefined methods prevent the python interpreter from loading the generated shared library. These methods are:

  • int DRSBoard::SetADCActive(unsigned char)
  • bool ResponseCalibration::Calibrate(unsigned int,unsigned int,float *,float *,float,bool)

Can we safely removed those methods from the DRS header files or (what I have actually done) is it better to fake some empty implementation in the input file to SWIG?

Another minor issue is that the python interpreter always terminates with a SegFault after script termination. I had not yet time to track that down...

Thanks & regards

Hermann-Josef

 

Thanks for pointing that out. My C++ compiler does not complain about such errors. You can safely remove these functions. I did so as well, so future versions will not contain that any more.

/Stefan 

  271   Tue Jul 9 11:40:00 2013 Dmitry Hitscannot save in binary format

Hi,

I would like to save the waveform in a binary format. When I click Save then change format from xml to dat in the menu. I still get xml format but with dat extension.

what I am missing?

Thank you,

Dmitry.

 

  272   Tue Jul 9 12:23:06 2013 Stefan Rittcannot save in binary format

Dmitry Hits wrote:

Hi,

I would like to save the waveform in a binary format. When I click Save then change format from xml to dat in the menu. I still get xml format but with dat extension.

what I am missing?

Thank you,

Dmitry.

Version 4.0.1 has a problem there. Please use 4.0.0. If you can compile the program yourself, just change this line:

--- DOFrame.cpp (revision 20656)
+++ DOFrame.cpp (revision 20655)
@@ -517,7 +517,7 @@
       if (!filename.empty()) {
          m_btSave->SetLabel(_T("Close"));
          m_btSave->SetToolTip(_T("Stop saving waveforms"));
-         if (filename.Find(_T(".")) != wxNOT_FOUND) {
+         if (filename.Find(_T(".xml")) != wxNOT_FOUND) {
             m_WFfd = 0;
             m_WFFile = mxml_open_file(filename.char_str());
             if (m_WFFile)

 

  273   Tue Jul 9 14:00:49 2013 Dmitry Hitscannot save in binary format

Stefan Ritt wrote:

Dmitry Hits wrote:

Hi,

I would like to save the waveform in a binary format. When I click Save then change format from xml to dat in the menu. I still get xml format but with dat extension.

what I am missing?

Thank you,

Dmitry.

Version 4.0.1 has a problem there. Please use 4.0.0. If you can compile the program yourself, just change this line:

--- DOFrame.cpp (revision 20656)
+++ DOFrame.cpp (revision 20655)
@@ -517,7 +517,7 @@
       if (!filename.empty()) {
          m_btSave->SetLabel(_T("Close"));
          m_btSave->SetToolTip(_T("Stop saving waveforms"));
-         if (filename.Find(_T(".")) != wxNOT_FOUND) {
+         if (filename.Find(_T(".xml")) != wxNOT_FOUND) {
             m_WFfd = 0;
             m_WFFile = mxml_open_file(filename.char_str());
             if (m_WFFile)

 

 Thanks that fixed it!

Dmitry

  274   Tue Jul 16 10:02:28 2013 tmiron alonadd an average ability to the Scope

Stefan Ritt wrote:

tmiron alon wrote:

Stefan Ritt wrote:

tmiron alon wrote:

 

My problem is not with wxWidgets itself but with links your program is doing to the wxWidgets. if you can please tell me the wxWidget version you used, I'll use this one instead the version I'm using and I think it will solve the problem.

Tmiron.

I currently use version 2.9.4, but chances are high that it will work with 2.8.12.

/Stefan 

 but was version 2.9.4 the one you used when you built  Version 4.0.0 of the DRS4 oscilloscope program, or was it an erilar version, and if so, do you remeber what version it was?

tmiron.

I used 2.8.12 for Version 4.0.0.

/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

  275   Tue Jul 16 16:25:43 2013 Stefan Rittadd an average ability to the Scope

tmiron alon wrote:

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

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

  276   Tue Jul 23 22:31:08 2013 alonziEvaluation Board Behavior

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. 

Attachment 1: Screenshot.png
Screenshot.png
Attachment 2: data_problem.png
data_problem.png
  277   Tue Jul 23 22:35:08 2013 Stefan RittEvaluation Board Behavior

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 

  278   Tue Jul 23 22:42:31 2013 alonziEvaluation Board Behavior

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. 

  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.

  280   Sun Jul 28 09:52:25 2013 tmiron alonadd an average ability to the Scope

Stefan Ritt wrote:

tmiron alon wrote:

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

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

  281   Mon Jul 29 06:04:45 2013 Stefan Rittadd an average ability to the Scope

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.

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 

  282   Wed Aug 7 15:05:59 2013 Hermann-Josef MathesRepeated time calibration

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

 

  283   Wed Aug 7 15:10:57 2013 Stefan RittRepeated time calibration

Hermann-Josef Mathes wrote:

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

 

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

 

  284   Wed Aug 7 15:20:33 2013 Hermann-Josef MathesRepeated time calibration

Stefan Ritt wrote:

Hermann-Josef Mathes wrote:

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

 

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

  285   Mon Aug 12 15:08:17 2013 tmiron alonadd an average ability to the Scope

Stefan Ritt wrote:

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.

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 

 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.

  286   Mon Aug 12 22:18:39 2013 Stefan Rittadd an average ability to the Scope

tmiron alon wrote:

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?

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

  287   Tue Aug 27 16:14:49 2013 lengchongyang 

  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

 

  288   Wed Aug 28 04:05:48 2013 lengchongyang 

lengchongyang wrote:

  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

 

 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.

  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.

ELOG V3.1.5-fe60aaf