Hello! My name is Dmitry. I am from SiPM Lab is NRNU MEPhI (Russia, Moscow). We bought DRS4 evaluation board V5 with firmware 21305. We use 5.0.4 build 21911 2015-11-23 software version (and before that we used 5.0.3 build 21508, 2014-10-15) with Windows 7 32bit.

We observe some strange behaviour. When we save waveforms (in xml or binary data) we see that some of them have the baseline shifted of about -5 mV.

The first picture (pic1) is 1000 waveforms which were glued in one. It is clearly see that baseline quite often has the shift.

The same effect can be seen without saving (writting): rarely when we use normal or auto trigger mode (pic3), and always in single trigger mode (pic2).

The images are attached.

Do you have any idea how it can be fixed?

Thanks, Dmitry.

We see quite some spikes in our DRS4 sampled data in FACT.  We see different types of spikes:

• single cell spikes, usually showing a large amplitude of 200mV
• double cell spikes, usually only in the order of 20mV.
• Even triple and quadro cell spikes are rarely seen.

The double cell spikes often occur as symmetrical double cell spikes mirrored at cell 512. quadro cell spikes seem to be nothing else, than connected symmetrical double cell spikes. For the triple cell spikes we have no idea.
Currently we use simple filters to get rid of these spikes, this workes rather well for the large single cell spikes, but with the occurance of tripples and quadros we started to worry about higher multiples and revived our DRS4 spike investigations.

Now I was told, that you Stefan know already where these spikes come from and even a paper exisits. Unfortunately so far I was unable to find it.
I wonder if it is possible to predict the occurance of these spikes, so one does not have to search for them anymore and can get rid of the filters.

Best regards

Dominik

Hello Stefan,

I just stumbled again over a phrase in the DRS4 datasheet I never really understood, but didn't find the time to ask.

On page 8 it says: "An internal circuit ensures that the write signal is always 16 cells wide."

So when I look at a single channel, do I understand correctly, that at any given time during sampling, always 16 cells are open, i.e. 16 cells are connected to the analog inputs? So when the domino frequency is e.g. 5GHz then each cell sees the analog input not for 200ps but for 3.2ns correct?

Hello Stefan,

some colleages told me a story, I was neither able to confirm nor find anything in the datsheet about. According to them:

For some internal reason of the DRS4, if the “stop capacitor” of the DRS4 is >= 767, the true stop channel is one before the stop channel read from the DRS4. In other words, the stop channel which returns the DRS4 shifts after sampling to the capacitor ID 766.

Can you confirm that, or even say a few words about that matter?

I wanted to confirm this by plotting the stop cell distribution for random triggered data, taken with one of the FACT boards. I assumed (possibly misunderstanding the matter), that this would lead to missing values in the area of stop cell 767, but cannot see any significant excess or lack of entries in that area.

Dear all,

I had a question about timing jitter and external triggering.

I trigger the board externally with a 3V pulse from a DG645 delay generator and as a test I use the gated charge function to integrate another pulse of the DG which goes into channel 1 (the timing jitter between different outputs of the DG is on the order of ~25 picoseconds).

The issue I’m encountering is that the signal on channel 1 is jittering in time with ~1 ns, which means the signal is jittering with respect to my integration gate (point A and B). If I look at the data it always starts at t = 0.000 but my signal (pulse) moves around in time.

If I don’t use the external trigger but trigger on channel 1 directly the signal does not move with respect to the gate, but I can see the start and end of the trace move in time. If I look at the data the first data point is not at t = 0.000 but some other time, which jitters with ~1 ns.

I did repeat the voltage and timing calibration, but that did not help either.

Do you know where this jitter comes from and if I can get rid of it?

Best regards,

Elmer

I will try that, thanks!

Hi,

I would like to use the DRS4 with my macbook pro running osx 10.6.8.
I have installed the wxWidgets and the libusb-1.0 libraries and I am using the Linux code vers. 4.0.1. After
compilation, the following errors come out:

ld: warning: in musbstd.o, file was built for unsupported file format which is not the architecture being linked
(i386)
ld: warning: in mxml.o, file was built for unsupported file format which is not the architecture being linked (i386)
....
....
ld: warning: in main.o, file was built for unsupported file format which is not the architecture being linked (i386)
Undefined symbols:
  "_main", referenced from:
      start in crt1.10.6.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make: *** [drsosc] Error 1


Do you have any idea on how to solve the problem ?? or maybe do you have a package working with osx 10.6 ? I
remember to have seen, long time ago, a package that could work with 10.6 (or 10.5 ?), but I cannot find it now
(but maybe I remember wrong).

Thanks for any help,

Enrico

> 
> Can it be that you have a old PowerPC MAC? I have no experience with that, but probably you have to adjust the Makefile
> ans set some flags correctly for PPC instead of Intel.
> 
> /Stefan


No, I have a MacBook Pro 2.8 GHz Intel Core 2 Duo.

> 
> it looks like 64bit vs 32bit problem, you have to compile all libraries for the same architecture. Maybe, make clean to 
> remove all precompiled object files .o and recompile it again. Try to compile first that simple example without wxWidgets.
> 
> Martin


Good point, but all libraries are already compiled to 32 bits, since the laptop is running at 32 bits. Unless you mean that I
have to convert to 64 bits, but this means to change all content of the PC, and I don't want to do this. Can the applications
run with 32 bits or do they need 64 ? 

Thanks,
Enrico

> > > 
> > > it looks like 64bit vs 32bit problem, you have to compile all libraries for the same architecture. Maybe, make clean to 
> > > remove all precompiled object files .o and recompile it again. Try to compile first that simple example without wxWidgets.
> > > 
> > > Martin
> > 
> > 
> > Good point, but all libraries are already compiled to 32 bits, since the laptop is running at 32 bits. Unless you mean that I
> > have to convert to 64 bits, but this means to change all content of the PC, and I don't want to do this. Can the applications
> > run with 32 bits or do they need 64 ? 
> > 
> > Thanks,
> > Enrico
> 


> There is no specific reason to run it on 64 bits, 

Good.

> so just all libraries have to match, that's all. But the original Makefile has been written for 64 bits, so it might need some 
> adjustments.

Ok, but I don't understand where is the point to correct. 64 bits do not appear explicitally (at least to me, who am not a drake of programming ...) 
neither in the Makefile neither in the (few) source files I have examined.

Thanks again,
Enrico

> > > 
> > > it looks like 64bit vs 32bit problem, you have to compile all libraries for the same architecture. Maybe, make clean to 
> > > remove all precompiled object files .o and recompile it again. Try to compile first that simple example without wxWidgets.
> > > 
> > > Martin
> > 
> > 
> > Good point, but all libraries are already compiled to 32 bits, since the laptop is running at 32 bits. Unless you mean that I
> > have to convert to 64 bits, but this means to change all content of the PC, and I don't want to do this. Can the applications
> > run with 32 bits or do they need 64 ? 
> > 
> > Thanks,
> > Enrico
> 
> There is no specific reason to run it on 64 bits, so just all libraries have to match, that's all. But the original Makefile has been written for 64 bits, so it might need some 
> adjustments.
> 
> /Stefan

Hi Stefan,
   I made some progress. Understood what was wrong in the make phase. You have only to add the option -arch i386 in the CFLAGS line of the makefile.
Then the make is ok, it produces the 3 executables. drs_exam and drscl seem to work correctly. 
DRSOsc.app does not work as app, in the sense that if you click it, an error message comes saying "You can't use this version of the application DRSOsc.app with 
this version of Mac OS X. You have Mac OSX 10.6.8. The application requires Mac OS X 10.7 or later. "
If you execute drsosc from the terminal, the graphical window pops up, the waveform is displayed, but you don't have access to the graphical interface, no button works, you can't do
anything. To quit the app, you have to kill it from the terminal with the kill command.
But anyway is a progress with respect to yestarday.
Any idea/suggestion to overcome the above problems ? I thought it is a problem with the graphical library (xwWidgets) but I have checked it, it's ok, I have also reinstalled it
(release 2.8.12_3) but nothing changed.

PS. the chip test output (done with the drscl ) is the following (see below). Is it normal or what ? THANKS.

B0> ct
Press 'q' to quit, any other key to repeat test.

Max. frequency is 5.1 GHz
Cell error on channel 1, cell 5: -137.6 mV instead 0 mV
Chip Error!

Max. frequency is 5.1 GHz
Cell error on channel 1, cell 5: -129.4 mV instead 0 mV
Chip Error!

> > I made some progress. Understood what was wrong in the make phase. You have only to add the option -arch i386 in the CFLAGS line of the makefile.
> > Then the make is ok, it produces the 3 executables. drs_exam and drscl seem to work correctly. 
> > DRSOsc.app does not work as app, in the sense that if you click it, an error message comes saying "You can't use this version of the application DRSOsc.app with 
> > this version of Mac OS X. You have Mac OSX 10.6.8. The application requires Mac OS X 10.7 or later. "
> > If you execute drsosc from the terminal, the graphical window pops up, the waveform is displayed, but you don't have access to the graphical interface, no button works, you can't do
> > anything. To quit the app, you have to kill it from the terminal with the kill command.
> 
> To run an executable as an app, you have to put it into a certain directory structure. The Makefile has the target "make app" which exactly does that. It executes following code:
> 
> DRSOsc.app: drsosc
>         -mkdir DRSOsc.app
>         -mkdir DRSOsc.app/Contents
>         -mkdir DRSOsc.app/Contents/MacOS
>         -mkdir DRSOsc.app/Contents/Resources
>         -mkdir DRSOsc.app/Contents/Resources/English.lproj
>         echo 'APPL????' > DRSOsc.app/Contents/PkgInfo
>         cp drsosc.xcodeproj/Info-processed.plist DRSOsc.app/Contents/Info.plist
>         cp drsosc DRSOsc.app/Contents/MacOS/DRSOsc
>         cp drsosc.xcodeproj/DRSOsc.icns DRSOsc.app/Contents/Resources
> 
> You can also do this manually. You will then see the subdirectly DRSOsc.app actually as an App icon (you don't see it as a subdirectory in the Finder).  That's the way Apple has chosen to do this.
> 
> The chip test facility has been made for a certain test board we use for chip testing. It has a feature that is not present in the evaluation board. I have to disable that command there.
> 
> Best regards,
> Stefan

Hi Stefan,
yes, the makefile has already the recipe to create the app. For OSX 10.6 a obvious modification must be done in the info.plist file. Then everything goes right. Now I have the DRSOsc application
running on my mac with 10.6.
Thanks for the help.
Best regards,
Enrico

Hello everybody!

After some times i init my board, or if i stop the program during the acquisition, i get the error message "Invalid magic 0000". The only way i can solve this problem is to physically disconnect and plug in again the USB cable.

What's the point? Is there a bash command / code i could use to reset it?

Thank you very much

Hello, thanks for your answer. Unluckily if i try to reset in this way it keeps hanging

musb_write: requested 10, wrote 0, errno -7 (Unknown error 18446744073709551609)
musb_read error 0
musb_write: requested 10, wrote 0, errno -7 (Unknown error 18446744073709551609)
musb_read error 0
Invalid magic number: 0000
musb_write: requested 10, wrote 0, errno -7 (Unknown error 18446744073709551609)
musb_read error 0
musb_write: requested 10, wrote 0, errno -7 (Unknown error 18446744073709551609)
musb_read error 0

I also tried with sudo tee /sys/bus/usb/drivers/usb/unbind and binding again; same thing happens. It seems the board needs to be reset when this happens. Is there a way to do that - to reset the board instead of usb?

Thank you

Hello, thanks for your answer. Unluckily if i try to reset in this way it keeps hanging

musb_write: requested 10, wrote 0, errno -7 (Unknown error 18446744073709551609)
musb_read error 0
musb_write: requested 10, wrote 0, errno -7 (Unknown error 18446744073709551609)
musb_read error 0
Invalid magic number: 0000
musb_write: requested 10, wrote 0, errno -7 (Unknown error 18446744073709551609)
musb_read error 0
musb_write: requested 10, wrote 0, errno -7 (Unknown error 18446744073709551609)
musb_read error 0

I also tried with sudo tee /sys/bus/usb/drivers/usb/unbind and binding again; same thing happens. It seems the board needs to be reset when this happens. Is there a way to do that - to reset the board instead of usb?

Thank you

Hello,

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

Thank you

Hello there,

is it possible to setup trigger in double AND configuration (a pair in and or other pair in and). 

eg (CH 1 AND CH 2 ) OR ( CH 3 AND CH4)

Thank you

How to configure DRS oscilloscope for the oscillations with an amplitude greater than the value of the exposed
in the trigger (internal). 

Can I adjust the internal trigger DRS oscilloscope for signal extraction 0.5 volts (for example) from any of the four channels. In our case, there is a lot of noise with low amplitude, which must be removed during the registration. We need to record the individual pulses of higher amplitude than the noise. So we want to use the internal trigger DRS oscilloscope to cut this noise by setting up its threshold amplitude noise.