Hi Stefan:

  I'm still confused that althought the 8 bits buffer is enough,the FPGA receive the command through the uc_data_i register which is 16 bits wides.As we can see in the firmware, the locbus_addr is 32 bits wides. Does it means the locbus_addr[31:8] are always '0' because the address in buffer is only 8 bits. Does it means the usrbus_status_sel and usrbus_ram_sel are also '0' all the time .

thanks!

chen

The locbus_addr is indeed 32 bits wide, since the firmware was originally derived from some firmware running in a VME crate, and the VME bus has 32 bits or addressing. So you will still find some "historic" remnants from that era. In the USB firmware, lcobus_addr[32:8] is always zero. Sorry for the confusuion.

Stefan

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.

Thanks. I added your fix to the current 4.0.0 distribution.

- Stefan 

 Hi,

I am getting the following compilation error when trying to compile version 5.0.2 software:

---------------------------------------------------------------------------------------------

Full error report:

g++ -g -O2 -Wall -Wuninitialized -fno-strict-aliasing -Iinclude -I/usr/local/include -DOS_LINUX -DHAVE_USB -DHAVE_LIBUSB10 -DUSE_DRS_MUTEX -I/usr/lib64/wx/include/gtk

I don't get this error under gcc 4.4.7, so I guess you have a newer version. Each one becomes more picky. Just try to replace

str += filename; 

with

str += (wxString) filename;

in line 617 of DOFrame.cpp

/Stefan

Hi Stefan,

Unfortunately that did not work and from suggestions in the error I do see a good solution:

----------------------------

src/DOFrame.cpp: In member function ‘void DOFrame::LoadConfig(char*, int)’:

src/DOFrame.cpp:617:25: error: call of overloaded ‘wxString(char [1024])’ is ambiguous

src/DOFrame.cpp:617:25: note: candidates are:

/usr/include/wx-2.8/wx/string.h:722:3: note: wxString::wxString(const wxWCharBuffer&) <near match>

/usr/include/wx-2.8/wx/string.h:722:3: note:   no known conversion for argument 1 from ‘char [1024]’ to ‘const wxWCharBuffer&’

/usr/include/wx-2.8/wx/string.h:692:3: note: wxString::wxString(wxChar, size_t) <near match>

/usr/include/wx-2.8/wx/string.h:692:3: note:   no known conversion for argument 1 from ‘char [1024]’ to ‘wxChar {aka wchar_t}’

/usr/include/wx-2.8/wx/string.h:690:3: note: wxString::wxString(const wxString&) <near match>

/usr/include/wx-2.8/wx/string.h:690:3: note:   no known conversion for argument 1 from ‘char [1024]’ to ‘const wxString&’

/usr/include/wx-2.8/wx/string.h:682:3: note: wxString::wxString(int) <near match>

/usr/include/wx-2.8/wx/string.h:682:3: note:   no known conversion for argument 1 from ‘char [1024]’ to ‘int’

---------------------------------

let me know if you see one.

Thank you,

Dmitry.

_____________________________________________________________________________________________________________________________________________

Full error:

++ -g -O2 -Wall -Wuninitialized -fno-strict-aliasing -Iinclude -I/usr/local/include -DOS_LINUX -DHAVE_USB -DHAVE_LIBUSB10 -DUSE_DRS_MUTEX -I/usr/lib64/wx/include/gtk

2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -c src/DOFrame.cpp

src/DOFrame.cpp: In member function ‘void DOFrame::LoadConfig(char*, int)’:

src/DOFrame.cpp:617:14: error: invalid conversion from ‘char*’ to ‘wxChar {aka wchar_t}’ [-fpermissive]

In file included from /usr/include/wx-2.8/wx/memory.h:16:0,

                 from /usr/include/wx-2.8/wx/object.h:20,

                 from /usr/include/wx-2.8/wx/wx.h:16,

                 from include/DRSOscInc.h:9,

                 from src/DOFrame.cpp:9:

/usr/include/wx-2.8/wx/string.h:1413:13: error:   initializing argument 1 of ‘wxString& wxString::operator+=(wxChar)’ [-fpermissive]

[dmitry@kitkat ~]$ more error-drs4v5_2

g++ -g -O2 -Wall -Wuninitialized -fno-strict-aliasing -Iinclude -I/usr/local/include -DOS_LINUX -DHAVE_USB -DHAVE_LIBUSB10 -DUSE_DRS_MUTEX -I/usr/lib64/wx/include/gtk

2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -c src/DOFrame.cpp

src/DOFrame.cpp: In member function ‘void DOFrame::LoadConfig(char*, int)’:

src/DOFrame.cpp:617:25: error: call of overloaded ‘wxString(char [1024])’ is ambiguous

src/DOFrame.cpp:617:25: note: candidates are:

In file included from /usr/include/wx-2.8/wx/memory.h:16:0,

                 from /usr/include/wx-2.8/wx/object.h:20,

                 from /usr/include/wx-2.8/wx/wx.h:16,

                 from include/DRSOscInc.h:9,

                 from src/DOFrame.cpp:9:

/usr/include/wx-2.8/wx/string.h:722:3: note: wxString::wxString(const wxWCharBuffer&) <near match>

/usr/include/wx-2.8/wx/string.h:722:3: note:   no known conversion for argument 1 from ‘char [1024]’ to ‘const wxWCharBuffer&’

/usr/include/wx-2.8/wx/string.h:692:3: note: wxString::wxString(wxChar, size_t) <near match>

/usr/include/wx-2.8/wx/string.h:692:3: note:   no known conversion for argument 1 from ‘char [1024]’ to ‘wxChar {aka wchar_t}’

/usr/include/wx-2.8/wx/string.h:690:3: note: wxString::wxString(const wxString&) <near match>

/usr/include/wx-2.8/wx/string.h:690:3: note:   no known conversion for argument 1 from ‘char [1024]’ to ‘const wxString&’

/usr/include/wx-2.8/wx/string.h:682:3: note: wxString::wxString(int) <near match>

/usr/include/wx-2.8/wx/string.h:682:3: note:   no known conversion for argument 1 from ‘char [1024]’ to ‘int’

make: *** [DOFrame.o] Error 1 

I just tried with the current Ubuntu version (gcc version 4.8.2, wxWidgets 3.0.1) and it worked without any problem. So please upgrade to wxWidgets 3.0.1

/Stefan

Hi Stefan,

Is either some example code or a detailed written description available for the improved DRS4 timing-calibration algorithm described by Daniel Stricker-Shaver at MIC 2012?  I think you told me that you had verified the results with your own test set-up, so I figure there must be at least two sets of code in existence to implement this calibration.  (I have Daniel's presentation slides.)

I managed to find a ping-pong distribution of cell widths that looks quite similar to that shown in Daniel's slides, using an algorithm similar to the technique one uses to find radial offsets in a tracking chamber (i.e. using residuals weighted by track slope), but I'd rather use the method with which you and Daniel have already found good results.  (The attached graph shows in black the histogram of cell widths for essentially the algorithm used in DRS.cpp/DRSBoard::AnalyzeWF, and in blue the histogram of cell widths extracted from the slope-weighted residuals for a periodic reference signal.)

By the way, since Daniel finds a FWHM coincidence-timing resolution around 20-25ps at 5 GSPS (for perfectly identical pulses), should I expect a FWHM resolution (for synthesized, ideal pulses) of around 50-65ps at 2 GSPS?

(I'm posting here instead of writing you both privately because I figure there may be broader interest in Daniel's algorithm.)

-Bill

Hi Bill,

there are several reasons why we have not yet published Daniel's method (I'm in constant contact with him).

1. The method still changes, becomes simpler and more accurate. Originally he used sine waves with varying frequency, which you only get from an external function oscillator. Currently, we found that a single frequency could do a similar, maybe even better job. The current result is much better than the 20-25ps quoted at MIC 2012.

2. Daniel found out that for the ultimate resolution you have to calibrate each channel inside a chip separately. I do understand in meantime the reason for that. So I plan for a V5 evaluation board, which contains means of sending a log-jitter clock to all channels. This board is in test phase and will be made available once it's working as expected.

So my plan is to finish the V5 board and implement the best possible timing calibration on it. Daniel achieved already <5 ps RMS (!) independent of the delay between the two optimal pulses (up to 50 ns). This is actually better than what you can do with a high-end oscilloscope, since scopes have internal interleaving and similar problems due to aliasing etc. than the DRS chip, but scope manufacturers do not put such an emphasis on accurate timing measurements. Once we can reproduce the 5 ps result with the evaluation board, we will publish it. When we found the optimal method, we plan to write a paper about it and explain everything in great detail. We will also be at Seoul for MIC 2013. I'm topic convener there for the session "Digitalization, Acquisition, and Signal Processing Technologies". So probably we will put the DRS4 timing talk there, since it's of more general interest not only to medical applications (and honestly, for a 150 ps TOF-PET you do not need a 5 ps electronics resolution). So stay tuned!

/Stefan

Hi,
I am considering using the DRS4 evaluation board as an ADC card for the wire chamber in the physics lab (VP) experiment at ETH. However, the wire 
chamber has 8 outputs, so I would need to have two of such boards. Is it possible to synchronise them, online or offline? From the website, it looks 
like yes, but the documentation says that these features (trigger and clock out) may not have been implemented in firmware yet. Could you tell me 
the status?

Thank you very much,

Dmitry.

> Hi,
> I am considering using the DRS4 evaluation board as an ADC card for the wire chamber in the physics lab (VP) experiment at ETH. However, the wire 
> chamber has 8 outputs, so I would need to have two of such boards. Is it possible to synchronise them, online or offline? From the website, it looks 
> like yes, but the documentation says that these features (trigger and clock out) may not have been implemented in firmware yet. Could you tell me 
> the status?
> 
> Thank you very much,
> 
> Dmitry.

I'm right now working on it. If you only need 2-3 ns accuracy  between the two boards then you can do this already now without firmware upgrade. The software for this is in principle ready, but I have to 
finish the documentation. Since I'm on a business travel right now this might take me some time (weeks?). 

If you want better timing (O(100ps)) between the boards, then you will need a firmware update. Or you wait until we ship boards with the new firmware. I will announce this through this forum.

Stefan

Hello,

Indeed you only need R99-R106 to be installed. Unfortunately the firm/software cannot know if the resistors are there, that's why we introduced R142/R143, which connect J44 of the FPGA optionally to low. So if J44 is low (R143 installed), this tells the system that we are in 2048 bin mode. Unfortunately you need firmware revision 21305 or later to support this bit, which you apparently do not have. So you can either upgrade the firmware (if you have a download cable) or "fake" the 2048 bin mode in software. Go to line 4345 of DRS.cpp and look for DRSBoard::Is2048ModeCapable(). This function just returns the status of this bit. If you installed R99-R106, you could modify this function to always return "1" instead of "0". Then the DRSOsc program will display 2048 bins for each of the four channels.

Best regards,

Stefan 

All I'm trying to do is cascade one input signal, though all available channels, so that I end up with 8*1024 bins per event.

Here is the read out on my board/chip:

Mezz. Board index:    0
DRS type:             DRS4
Board type:           8
Serial number:        2249
Firmware revision:    17662
Temperature:          35.2 C
Input range:          -0.5V...0.5V
Calibrated range:     -0.5V...0.5V
Calibrated frequency: 5.120 GHz
Status reg.:          0000001A
Control reg.:         00000010
  DMODE circular
Trigger bus:          00000000
Frequency:            5.120 GHz

What I've tried thus far:

In Osci.cpp, in the method/function  SelectSource(int board, int firstChannel, int chnSection), I added a line.. (in bold)

//----------------------------------------------------------------------------------------------------------------------------------------------

 if (b->GetBoardType() == 5 || b->GetBoardType() == 7 || b->GetBoardType() == 8) {
         
        
             if (chnSection == 2)
                b->SetChannelConfig(0, 8, 4);
             //added
             else if(chnSection == 1)
                 b->SetChannelConfig(0, 8, 2);
             //added
             else
                b->SetChannelConfig(0, 8, 8);
//----------------------------------------------------------------------------------------------------------------------------------------------

I've also tried doing settings such as SetChannelConfig(0, 8, 1);   , SetChannelConfig(0, 8, 2); , SetChannelConfig(0, 1, 2); , etc..

Which always ends up making the run fail.. and sometimes I get index errors..

As far as I understanding the program now, this is what I know:

fChannelCascading determines getChannelCascading,
this determines the  if (casc == 2) line in configDialogue.cpp, which sets:
 b->SetChannelConfig(config, 8, 4);

fChannelCascading is being set by:
 switch (nConfigChannels) {
      case 1:
         fChannelConfig = 0x01;
         fChannelCascading = 8;
         break;
      case 2:
         fChannelConfig = 0x11;
         fChannelCascading = 4;
         break;
      case 4:
         fChannelConfig = 0x55;
         fChannelCascading = 2;
         break;
      case 8:
         fChannelConfig = 0xFF;
         fChannelCascading = 1;
         break;
      default:
         printf("Invalid channel configuration\n");
         return 0;
      }

which is being set by nConfigChannels in DRS.cpp, in the method:
SetChannelConfig(int firstChannel, int lastChannel, int nConfigChannels)



SetChannelConfig is being called in the ConfigDialogue.cpp,  but the default Osci program is such that you can't do a configuration for a cascade of one signal using all the channels. At least, not that I am aware of. 

So what buttons do I need to enable, or what do I need to call, or write, so that I can cascade a signal to end up with 8*1024 bins per event?

This has had me going in circles for weeks, so thank you for your help!!!!

Sorry for my late reply, I was away for some days.

To use channel cascading, you have to physically connect one input to all eight channels. This is not possible with the evaluation board, you have to make your own board. What you could do however is to split a signal externally and feed it to all four inputs, given that the signal delay is the same for every channel. But then you will hit the hard-wired limit in Osci.cpp. This code was never foreseen to cover 8*1024 bins (since it does not make much sense with the evaluation board). Some arrays are only 2*1024 bins wide, so you would have to rewrite code at many places.

The easiest way to get what you want is to modify drs_exam.cpp. You need SetChannelConfig(0, 8, 1) as you realised correctly, and then you have to retrieve all 8 channels via b->GetWave() and concatenate them correctly.

/Stefan 

 Would it be possible to just hardcode a few lines in the SetChannelConfig in DRS.cpp method as such:

     fChannelConfig = 0x01; //gives me eight
      d = fChannelConfig | (fDominoMode << 8) | (1 << 9) | (fWSRLoop << 10) | (0xF8 << 8);

      Write(T_CTRL, REG_CHANNEL_CONFIG, &d, 2);
      fChannelDepth = 8 * (fDecimation ? kNumberOfBins/2 : kNumberOfBins);// gives eight times the bins

then modify the GetWave method/function to include another else if statement similar to  "else if (fChannelCascading == 2) {"  but would be modifidied for fChannelCascading == 8?

By, "But then you will hit the hard-wired limit in Osci.cpp" do you mean  hard-coded? Would changing the hard code just amount to resizing all of the arrays, and replacing all the '2*kNumberBins"  with '8*kNumberBins' ?

I'm afraid of drs_exam.cpp because it doesn't come with all the perks of Osci.cpp. It seems less daunting to just modify Osci.cpp then to try understanding everything I need to include in drs_exam.cpp because I'm also using an external trigger, and saving the waveform to an external text file.

Thanks!

/Jill

Sure it would be possible to code it, but it's not just a few lines. Besides Osci.cpp you have to massage DOScreen.cpp, Measurement.cpp and probably more since they all rely on the array size of the waveform. So if I would do it it would take me probably a couple of days including the debugging, which I don't have right now. Furthermore, as I said you have to combine all eight channels properly. For two channels, it's already pretty complicated (see lines 3537+ in DRS.cpp). I had to make myself a visual scheme in order to understand it correctly, which I attached. For eight channels, the write shift register (WSR) can have values 0-7, depending in which channel you got a trigger. Then you have to sort it out again to get one linear array with the proper order of the fragments. So you see, it's not just changing a few lines of code. In principle it's possible, but it's lots of work.

Best regards,

Stefan

 Stefan, thanks for your help so far. If I go with your plan A of just modifying drs_exam.cpp, is there a quick way to get it to save the data from the wave, like how osci.cpp spits out an xml file? (Ignoring the cascading aspect for now)

Thanks again :)

/Jill

Well, you have to learn C programming, I won't do it for you. drs_exam.cpp contains already code to write to the ASCII file data.txt, so you just can use that or modify it to your needs.

/Stefan