Acknowledged. Added it to the code. 

Hi,

the latest software drs-5.0.0.tar.gz fails to compile on my freshly installed SuSE 13.1 whereas the previous 4.0.1 is compiling out-of-the-box.

My system has the wxWidgets 2.8.12 which is probably together with gcc 4.8.1 the reason of the problem. I applied a number of corrections, mainly some sort of proper (?) typecasts, a patch file is attached.

Maybe you could consider to take them into account for the next patch release?

Thanks and best regards

Hermann-Josef

Thank you very much for the corrections. I know it in principle, but neither my Mac OSX nor the Windows compiler complains, so I usually don't see this errors. It's fixed now.

/Stefan 

Hi everyone,

Did anyone have a "missing sliders problem" in GUI (see attachment)  accompanied by the following message in the terminal.

(drsosc:4611): Gtk-WARNING **: 14:05:11.249: Negative content width -4 (allocation 20, extents 12x12) while allocating gadget (node scale, owner GtkScale)

(drsosc:4611): Gtk-WARNING **: 14:05:11.249: Negative content width -2 (allocation 0, extents 1x1) while allocating gadget (node trough, owner GtkScale)

If yes, how did you solve it?

All ideas are appreciated!

Cheers,

Dmitry

Hello:

A bit of background:  I am working on a project that is utilizing the DRS4 Evaluation board as a prototype platform for a dedicated, special use capture. We will only be utilizing one channel of the ADC capture, and the 1024 samples is more than enough. 

What I will need to do, however, is do some preprocessing on the incoming ADC data, running some calculation on the fly, possibly some filtering and other transformations before putting the data into the FPGA block memory for transfer to the host via the Cypress USB interface. I will be modifying the "drs4_eval5" VHDL file and doing a new FPGA build.

It will be essential that I be able to simulate this, from the ADC input to the data flow to the Cypress chip. I have "eval board files" which includes the VHDL source files, Xilinxe ISE project files and some very basic simulation testbenches.

Unfortunately, the simulation testbenches call out a "drs4_eval1" module while the Xilinx project uses a "drs4_eval5" module, and the module ports are a little different. I think I can work around that, however.  I have run the simulatilon "drs4_eval1_tb", which does a simple write to a Control Register. I need to expand this simulation so that it will initiate a full capture and then transfer the data from the RAM to the Cypress chip.

What I am most confused about is how the Cypress chip sucks out the data from the FPGA block ram. I would expect it to use a burst mode data transfer rather than the cumbersom CSR read/write, but I haven't found any documentation on how this interface works. 

Q1: Is there a simulation testbench file available that does the 1024 sample data transfer?

Q2: Is there a waveform diagram that shows the protocol / signal handshake between the FPGA and Cypress chip for this data transfer?

Thank you

Rod McInnis

The Cypress has its own firmware, contained in the distribution under firmware/CY7C68013A/drs_eval.c. There you can see how the data is fetched. I kind of forgot how exactly it worked, since I wrote that code back in 2011. But most if the Cypress code is just the configuration of the USB, the communication with the FPGA is kind of straight forward in the Cypress implementation. But you have to read the manual of that chip to understand it.

Unfrtunately there is no full testbench for the firmware, since I didn't have a VHDL Model of the Cypress, so I implemente dit the "hard" way ;-)

Best,
Stefan

Several people asked for s simple application to guide them in writing their own application to read out a DRS board. Such an application has been added in software revions 2.1.1 and is attached to this message. This example program drs_exam.cpp written in C++ does the following necessary steps to access a DRS board:

• Crate a "DRS" object and scan all USB devices
• Display found DRS boards
• Initialize the first found board and set the sampling frequency to 5 GSPS
• Enable internal trigger on channel #1 with 250 mV threshold
• Start acquisition and wait for a trigger
• Read two waveforms (both time and amplitude)
• Repeat this 10 times

I know that we are still missing a good documentation for the DRS API, but I have not yet found the time to do that. I hope the example program is enough for most people to start writing own programs. For Windows users (MS Visual C++ 8.0) there is a drs.sln project file, and for linux users there is a Makefile which can be used to compile this example program.

One note: The program drs_exam.cpp published in the previous message needs the current version of the DRS library in DRS.cpp and DRS.h. They are contained in the software release 2.1.1 which has to be downloaded. For simplicity, I attached the two files to this message.

 Hi, Stefan,

drs_exam.cpp is working good to read-out one board.

Now I would like to read-out two boards at the same time using the same trigger( external or internal).

I'm trying to understand and modify the original code for control two board.

Meantime, it would be very appreciated if you give any tips for this.

Thanks,

Heejong

The evaluation boards are not really made for multi-board applications. What you have to do is to maintain an external trigger which synchronizes the boards. So you need:

- two boards connected to two USB ports

- an external flip-flop connected to the two trigger inputs of both boards

If a trigger is sent to the flip-flop, it sends a trigger to both evaluation boards. You poll on one of the boards to see if it has triggered (vis IsBusy()), then you read out both boards. Now you have to reset the external flip-flop somehow from the computer. If you have a CAMAC I/O board or some other means of sending a logical signal to it, that could do the job. From the software point, you get a "DRS" object upon initialization, which contains then two "DRSBoard" objects, over which you can iterate. Look at the "drscl" program from the distribution on how to do that.

Hello,

is it possible to set a completely negative input range like -1 to 0 or -0.95 to 0.05 ?

See elog:531

Thank you

Hi Stefan,

    in the DRS4 datasheet I read that the optimal frequency for SRCLK is 33MHz. However in the evaluation board firmware SRCLK is toggled at rising edges of the internal 33MHz clock, i.e. the frequency of SRCLK itself is 16.5MHz instead. Is that frequency better than 33MHz?

    Thanks!

The reason for the 16.5 MHz is the following:

After each block of 32 bins, the DRS4 chip switches an internal segment, which causes some small spike at the analog output of the chip. This spike is a bit wider than 30ns, so if everything is digitized with 33 MHz, then you see small spiked each 32 cells. The appropriate solution would be to modify the firmware to digitize all cells with 30ns (33 MHz) and all cells with the spike with ~50 ns (20 MHz). If you do the ROI readout mode, you don't know for the first 10 cells if one of them belong to this class, since the cell address takes 10 cycles to be read out. So you would first have to read 10 cells, and then if you realize that one of them is one of the problematic ones (cell number modulo 32 is zero), you have to re-read the first 10 cells, and digitize the problematic cell with a longer settling time. Now this is a bit complicated to implement in the firmware, so I was just too lazy to do it and decided to digitize everything with 16.5 MHz. But if you are worried about the dead time, you should consider implementing the mentioned algorithm. 

 Thanks! The suggested algorithm looks promising. However, if the spikes take place only for those specific cells, is it possible to absorb them into the offset calibration?

No, since they are not constant. The bus segments charge up between readouts with a time constant of about 0.5s. So if you do the readout with 1Hz event rate and with 100Hz event rate, the peaks will differ by a factor up to 10, so a constant offset correction cannot take care of that.

Hi. I'm trying to evaluate livetime of the evaluation board with the hardware scaler. I'm facing a strange issue.

I took the rate with the function, DRS->GetScaler(int channel).
I guess that channels 0--3 mean the rate for the channel, and channel 4 means the counter of the trigger.
I took the 1,000 pulses generated by a pulse generator with 50 Hz.
The scaler values are ~ 39.83, not 50.
The timestamp difference between the initial event and the final event is 19.98 seconds.
1000/19.98 ~ 50, thus, the evaluation board took the pulses with enough livetime.

Can we believe the scaler value for the livetime evaluation?

The scalers are read out 10x per seconds, so they have an accuracy of 10 Hz. I tried a 50 Hz pulser, and measured 40 Hz, I tried 52 Hz and measured 50 Hz. This is about what you can expect.

The scaler rate is measured after the discriminator of the trigger, so the trigger level also affects the scaler reading. If you have a 100 mV pulse and your threshold is 200 mV, your scaler rate drops to zero. That can be seen best with the DRSOsc and sliding the trigger value. If you have a 50 Hz pulse with narrow (< us) pulses, things are fine. But if you use a 50 Hz square wave, then you get distorted signals due to the AC coupling which can also be confusing. See for example here: https://www.daqarta.com/dw_gg0o.htm

Thank you very much for your explanation.

I would like to show you a pulse example ('black line is the threshold).

Still, pulse generator rate and DRS4 rate are a bit different more than 10 Hz.