ID |
Date |
Author |
Subject |
270
|
Sat Jul 6 06:10:38 2013 |
Stefan Ritt | Missing 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 Hits | cannot 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 Ritt | cannot 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 Hits | cannot 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 alon | add 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 Ritt | add 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 |
alonzi | Evaluation 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. |
277
|
Tue Jul 23 22:35:08 2013 |
Stefan Ritt | Evaluation 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 |
alonzi | Evaluation 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 Kuznetsov | Evaluation 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 alon | add 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 Ritt | add 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 Mathes | Repeated 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 Ritt | Repeated 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 Mathes | Repeated 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 alon | add 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 Ritt | add 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 Kuznetsov | Some 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_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_TRG_DELAY, 2);
reg = (reg & 0xFF) | (ticks << 8);
Write(T_CTRL, REG_TRG_DELAY, ®, 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. |
|