DRS4 Forum
  DRS4 Discussion Forum, Page 9 of 15  Not logged in ELOG logo
Entry  Tue May 19 14:14:45 2015, Ilja Bekman, DRS4 firmware UCF constraints  
Hello, I'm using two DRS4 rev.5 boards for 8ch readout and triggering.

I needed to modify the trigger logic and implement some tweaks in the firmware, and noticed that 
the firmware source in drs-5.0.2 (and 5.0.3, SVN:5339) while still compiling fine with Xilinx ISE 10, stops
doing so in the ISE 14.7 (also already in 13.2)

While the Synthesis is running through (in the new ISE it complains about using more than 100% of resources.)
The Mapping fails due to constraints (firmware/ucf/drs4_eval5.ucf) complaining about an illegal IOSTANDARD
for P_IO_PMC_USR<55> (LVDS_25).

In the newer version the wild-cards (lines 67..69 ) are not properly dealt with, it seems, and if I move the
property by hand to all the wild-carded NETs it start to recognise the LVDS_25.
But after that Place&Route fails with messages about locked Banks due to incompatible VCCO.

I'm trying to adapt the ucf file and am reading about the changes in the ISE software and constraints files, but
want to ask if some of you guys have seen the same issue and resolved it out "officially".
    Reply  Fri May 22 14:25:45 2015, Stefan Ritt, DRS4 firmware UCF constraints  firmware.zip
> Hello, I'm using two DRS4 rev.5 boards for 8ch readout and triggering.
> 
> I needed to modify the trigger logic and implement some tweaks in the firmware, and noticed that 
> the firmware source in drs-5.0.2 (and 5.0.3, SVN:5339) while still compiling fine with Xilinx ISE 10, stops
> doing so in the ISE 14.7 (also already in 13.2)
> 
> While the Synthesis is running through (in the new ISE it complains about using more than 100% of resources.)
> The Mapping fails due to constraints (firmware/ucf/drs4_eval5.ucf) complaining about an illegal IOSTANDARD
> for P_IO_PMC_USR<55> (LVDS_25).
> 
> In the newer version the wild-cards (lines 67..69 ) are not properly dealt with, it seems, and if I move the
> property by hand to all the wild-carded NETs it start to recognise the LVDS_25.
> But after that Place&Route fails with messages about locked Banks due to incompatible VCCO.
> 
> I'm trying to adapt the ucf file and am reading about the changes in the ISE software and constraints files, but
> want to ask if some of you guys have seen the same issue and resolved it out "officially".

The current firmware compiles nicely under 14.7. I attached it. It also has one modification which you probably need:

When the board triggers, the TRG OUT goes high and stays high until the board has been read out and restarted. So it can be used as a "busy" signal for an external trigger logic.

Best regards,
Stefan
       Reply  Tue May 26 11:27:27 2015, Felix Bachmair, DRS4 firmware UCF constraints  
> > Hello, I'm using two DRS4 rev.5 boards for 8ch readout and triggering.
> > 
> > I needed to modify the trigger logic and implement some tweaks in the firmware, and noticed that 
> > the firmware source in drs-5.0.2 (and 5.0.3, SVN:5339) while still compiling fine with Xilinx ISE 10, stops
> > doing so in the ISE 14.7 (also already in 13.2)
> > 
> > While the Synthesis is running through (in the new ISE it complains about using more than 100% of resources.)
> > The Mapping fails due to constraints (firmware/ucf/drs4_eval5.ucf) complaining about an illegal IOSTANDARD
> > for P_IO_PMC_USR<55> (LVDS_25).
> > 
> > In the newer version the wild-cards (lines 67..69 ) are not properly dealt with, it seems, and if I move the
> > property by hand to all the wild-carded NETs it start to recognise the LVDS_25.
> > But after that Place&Route fails with messages about locked Banks due to incompatible VCCO.
> > 
> > I'm trying to adapt the ucf file and am reading about the changes in the ISE software and constraints files, but
> > want to ask if some of you guys have seen the same issue and resolved it out "officially".
> 
> The current firmware compiles nicely under 14.7. I attached it. It also has one modification which you probably need:
> 
> When the board triggers, the TRG OUT goes high and stays high until the board has been read out and restarted. So it can be used as a "busy" signal for an external trigger logic.
> 
> Best regards,
> Stefan

Hi Stefan,
Thanks a lot for the new firmware. We are testing it at the moment in a beam test at PSI (PiM1) and we realized that this doesn't seem to work 100%.
We need to extend the death time after a trigger by approx. 200 mus in order to not loose triggers.
It seems that under certain circumstances a trigger within that window is ignored. 
We do a handshake after each trigger so we are able to recognize such ignored events. This can happen quite often (within the first few hundered events) when we do not increase the deadtime.
Do you have any idea what could be the reason for that issue?
Best regardds
Felix 
          Reply  Fri Jun 5 12:07:38 2015, Stefan Ritt, DRS4 firmware UCF constraints  
I presume you have several evaluation boards and want to run them in sync, right?

This can be either made in daisy-chain mode (see manual page 25). In this case only the master board can trigger the slave boards. If you need to trigger on SEVERAL boards (like a coincidence between two boards), you have to do this with an external trigger and busy logic. This is rather 
complicated and needs detailed explanations. So come to my office and I will teach you.

Best,
Stefan
             Reply  Fri Jun 5 13:15:35 2015, Felix Bachmair, DRS4 firmware UCF constraints  
Hi Stefan,
No we only use one evaluation board. We use the evaluation board as a part of our beam test setup. It includes a telescope based on the current PSI46V2.1 CMS Pixel chip and a trigger logic board for triggering the telescope and the evaluation board. This includes a 
handshake between every device and the tlu
e.g. the tlu expects an answer for each trigger.
If the trigger comes within this first 200 mus it seems that not every trigger is accepted.
In this moment our readout would 'die' since the tlu is waiting for the handshake.
Cheers
Felix

> I presume you have several evaluation boards and want to run them in sync, right?
> 
> This can be either made in daisy-chain mode (see manual page 25). In this case only the master board can trigger the slave boards. If you need to trigger on SEVERAL boards (like a coincidence between two boards), you have to do this with an external trigger and 
busy logic. This is rather 
> complicated and needs detailed explanations. So come to my office and I will teach you.
> 
> Best,
> Stefan
                Reply  Fri Jun 5 13:29:55 2015, Stefan Ritt, DRS4 firmware UCF constraints  
Do the following: 

Use the TRG OUT of the evaluation board as a "busy". Only if this signal goes low (meaning that the readout of the board is complete and the board has been restarted), then re-enable triggers in your trigger logic.

/Stefan

> Hi Stefan,
> No we only use one evaluation board. We use the evaluation board as a part of our beam test setup. It includes a telescope based on the current PSI46V2.1 CMS Pixel chip and a trigger logic board for triggering the telescope and the evaluation board. This includes a 
> handshake between every device and the tlu
> e.g. the tlu expects an answer for each trigger.
> If the trigger comes within this first 200 mus it seems that not every trigger is accepted.
> In this moment our readout would 'die' since the tlu is waiting for the handshake.
                   Reply  Fri Jun 5 13:32:03 2015, Stefan Ritt, DRS4 firmware UCF constraints  
Actually we should take this offline not to pester other DRS users which are not interested in this topic. Please call me directly (3728) at PSI.

/Stefan
Entry  Sun May 24 09:34:27 2015, Peter Steinberg, Peculiar behavior of time values for Rev5 DRS4 EB 

Hi -

I am setting up a new DRS4 rev5 but using drivers and software we were recently using with a Rev4 (with a recent release of the drs4 code, from mid-2014). 

I am writing since I see peculiar behavior of the calibrated times when I read them back from the Rev 5.  I get events where the first time returns 0 (which was always the case on my Rev 4), but the following time is negative -- this seems to be wrong since the times should always increase.

Is it a problem with my running the time calibration or a problem with the board itself?  For the record, the integral nonlinearity displayed during time calibration "looks" very different when running with the same (recent) drsosc on the two boards.  The rev5 has apparently a much larger amplitude.

- peter

    Reply  Wed Jun 3 09:07:38 2015, Stefan Ritt, Peculiar behavior of time values for Rev5 DRS4 EB 

First of all, you should not use new boards with old software. I try to keep the current software compatible with old boards, but not vice versa. Please use the DRS.cpp library from the current V5 software, otherwise your time calibration will not work.

If you then do the calibration with the V5 software and the V5 board, you will see that the bin widhts of the DRS chips are not the same. Actually they are "oscillating" between ~130 ps and ~270 ps if you run at 5 GSPS. Some bins are even negative, this means that the next bin sees the signal before the previous bin. This is correct and due to the specific layout of the chip which is not perfect. Using the new time calibration with the current software, you should be able to make time measurements with a few ps accuracy.

Stefan

 

Peter Steinberg wrote:

Hi -

I am setting up a new DRS4 rev5 but using drivers and software we were recently using with a Rev4 (with a recent release of the drs4 code, from mid-2014). 

I am writing since I see peculiar behavior of the calibrated times when I read them back from the Rev 5.  I get events where the first time returns 0 (which was always the case on my Rev 4), but the following time is negative -- this seems to be wrong since the times should always increase.

Is it a problem with my running the time calibration or a problem with the board itself?  For the record, the integral nonlinearity displayed during time calibration "looks" very different when running with the same (recent) drsosc on the two boards.  The rev5 has apparently a much larger amplitude.

- peter

 

Entry  Wed May 13 09:31:18 2015, Chenfei Yang, transparent-mode voltage tek00000_.png

Hello Mr. Stefan Ritt

  For DRS4 differential inputs ranges form 500mV to 1100mV, with ROFS set to 1.55V, O_OFS set to 1.3V, the outputs of DRS4 is shown in the attachment.

  The left part of the waveform,DRS4 works in transparent mode, and then the readout take place. The DMV of transparent mode is bigger then the readout mode, and that makes ADC sampling harder.How may I solve this problem?

  Best wishes!

                                 Chenfei Yang

    Reply  Wed May 13 09:45:51 2015, Stefan Ritt, transparent-mode voltage 

The ROFS signal has no effect in the transparent mode, so you have to adjust O_OFS between sampling and transparent mode accordingly. Either use a DAC or two voltages with an analog switch.

Chenfei Yang wrote:

Hello Mr. Stefan Ritt

  For DRS4 differential inputs ranges form 500mV to 1100mV, with ROFS set to 1.55V, O_OFS set to 1.3V, the outputs of DRS4 is shown in the attachment.

  The left part of the waveform,DRS4 works in transparent mode, and then the readout take place. The DMV of transparent mode is bigger then the readout mode, and that makes ADC sampling harder.How may I solve this problem?

  Best wishes!

                                 Chenfei Yang

 

       Reply  Wed May 13 09:55:09 2015, Chenfei Yang, transparent-mode voltage 

Here's the problem. My external ADC has 2Vpp differtial input voltage range. And the common-mode voltage of the inputs need to be 1.3V. I cannot make both the transparent-output and the readout-output meet the ADC input requirement.

Stefan Ritt wrote:

The ROFS signal has no effect in the transparent mode, so you have to adjust O_OFS between sampling and transparent mode accordingly. Either use a DAC or two voltages with an analog switch.

Chenfei Yang wrote:

Hello Mr. Stefan Ritt

  For DRS4 differential inputs ranges form 500mV to 1100mV, with ROFS set to 1.55V, O_OFS set to 1.3V, the outputs of DRS4 is shown in the attachment.

  The left part of the waveform,DRS4 works in transparent mode, and then the readout take place. The DMV of transparent mode is bigger then the readout mode, and that makes ADC sampling harder.How may I solve this problem?

  Best wishes!

                                 Chenfei Yang

 

 

          Reply  Wed May 13 10:16:40 2015, Stefan Ritt, transparent-mode voltage 

I see your point. Actually I will soon have the same issue since we design right now a board with an AD9637 using the transparent mode. Which one are you using? The common mode range given in the datasheet is limited to guarantee optimal performance. But some ADCs allow a slightly bigger common mode range with reduced performance, but which might still be ok for some application. A "real" solution would be to put switchable level shifters between the DRS and the ADC, but that requires 8 additional chips which is bad. Alternative the ADC could pick up the signal not at the DRS output but at the DRS input, but that would aslo require additional chips for multiplexing. So unfortunately no perfect solution for that...

Chenfei Yang wrote:

Here's the problem. My external ADC has 2Vpp differtial input voltage range. And the common-mode voltage of the inputs need to be 1.3V. I cannot make both the transparent-output and the readout-output meet the ADC input requirement.

Stefan Ritt wrote:

The ROFS signal has no effect in the transparent mode, so you have to adjust O_OFS between sampling and transparent mode accordingly. Either use a DAC or two voltages with an analog switch.

Chenfei Yang wrote:

Hello Mr. Stefan Ritt

  For DRS4 differential inputs ranges form 500mV to 1100mV, with ROFS set to 1.55V, O_OFS set to 1.3V, the outputs of DRS4 is shown in the attachment.

  The left part of the waveform,DRS4 works in transparent mode, and then the readout take place. The DMV of transparent mode is bigger then the readout mode, and that makes ADC sampling harder.How may I solve this problem?

  Best wishes!

                                 Chenfei Yang

 

 

 

             Reply  Wed May 13 10:27:43 2015, Chenfei Yang, transparent-mode voltage 

I'm using an AD9252, 0.9V common mode voltage is suggested and I already use 8 un-switchable level shifters. Just as you said, this common mode range is recommended for optimum performance and the device can function over a wider range with reasonable performance. So I think I could adjust O_OFS to a minor level during transparent output.

Stefan Ritt wrote:

I see your point. Actually I will soon have the same issue since we design right now a board with an AD9637 using the transparent mode. Which one are you using? The common mode range given in the datasheet is limited to guarantee optimal performance. But some ADCs allow a slightly bigger common mode range with reduced performance, but which might still be ok for some application. A "real" solution would be to put switchable level shifters between the DRS and the ADC, but that requires 8 additional chips which is bad. Alternative the ADC could pick up the signal not at the DRS output but at the DRS input, but that would aslo require additional chips for multiplexing. So unfortunately no perfect solution for that...

Chenfei Yang wrote:

Here's the problem. My external ADC has 2Vpp differtial input voltage range. And the common-mode voltage of the inputs need to be 1.3V. I cannot make both the transparent-output and the readout-output meet the ADC input requirement.

Stefan Ritt wrote:

The ROFS signal has no effect in the transparent mode, so you have to adjust O_OFS between sampling and transparent mode accordingly. Either use a DAC or two voltages with an analog switch.

Chenfei Yang wrote:

Hello Mr. Stefan Ritt

  For DRS4 differential inputs ranges form 500mV to 1100mV, with ROFS set to 1.55V, O_OFS set to 1.3V, the outputs of DRS4 is shown in the attachment.

  The left part of the waveform,DRS4 works in transparent mode, and then the readout take place. The DMV of transparent mode is bigger then the readout mode, and that makes ADC sampling harder.How may I solve this problem?

  Best wishes!

                                 Chenfei Yang

 

 

 

 

             Reply  Wed May 13 12:34:49 2015, Stefan Ritt, transparent-mode voltage 

There might be a solution. How do you bias th input of the DRS4 chip? If you use a scheme as described in elog:84, you can bias DRS_IN+ and DRS_IN- as desired. Take for example a board input range of 0-1V. For a 0V input, you bias DRS_IN+ and DRS_IN- both with 0.9V. A 1V input signal then puts DRS_IN+ to 1.4V and DRS_IN-to 0.4 V. In the transparent mode, DRS_OUT+ = DRS_IN+ and DRS_OUT- = O-OFS - DRS_OUT+. So if you put O-OFS to 0.9V, you get for a 0V board input signal DRS_OUT- = 2*0.9V - DRS_OUT+ = 0.9V. So DRS_OUT+   = DRS_OUT- = 0.9 V which is in the middle of your ADC range. 

If you do now a DRS readout, you need a ROFS of roughly 0.9V. For a 0V input, the storage capacitors have a zero differential voltage (DRS_IN+ = DRS_IN- = 0.8V), so DRS_OUT+ = (0.8V - 0.8V) + ROFS  = 0.9V, and since you have O-OFS=0.9V, you will also get DRS_OUT- = 2*0.9V - DRS_OUT+ = 0.9V. So you ranges for transparent mode nad DRS readout mode will be roughly the same.

                Reply  Wed May 13 12:52:22 2015, Chenfei Yang, transparent-mode voltage 

Yes. I use exactly the same scheme as you mentioned. I'll try your solution.

Stefan Ritt wrote:

There might be a solution. How do you bias th input of the DRS4 chip? If you use a scheme as described in elog:84, you can bias DRS_IN+ and DRS_IN- as desired. Take for example a board input range of 0-1V. For a 0V input, you bias DRS_IN+ and DRS_IN- both with 0.9V. A 1V input signal then puts DRS_IN+ to 1.4V and DRS_IN-to 0.4 V. In the transparent mode, DRS_OUT+ = DRS_IN+ and DRS_OUT- = O-OFS - DRS_OUT+. So if you put O-OFS to 0.9V, you get for a 0V board input signal DRS_OUT- = 2*0.9V - DRS_OUT+ = 0.9V. So DRS_OUT+   = DRS_OUT- = 0.9 V which is in the middle of your ADC range. 

If you do now a DRS readout, you need a ROFS of roughly 0.9V. For a 0V input, the storage capacitors have a zero differential voltage (DRS_IN+ = DRS_IN- = 0.8V), so DRS_OUT+ = (0.8V - 0.8V) + ROFS  = 0.9V, and since you have O-OFS=0.9V, you will also get DRS_OUT- = 2*0.9V - DRS_OUT+ = 0.9V. So you ranges for transparent mode nad DRS readout mode will be roughly the same.

 

                Reply  Wed May 13 16:13:07 2015, Chenfei Yang, transparent-mode voltage 

If using a ROFS of 0.9V, the input would not between 1.05V~2.05V better non-linearity area. Is that appropriate?

Stefan Ritt wrote:

There might be a solution. How do you bias th input of the DRS4 chip? If you use a scheme as described in elog:84, you can bias DRS_IN+ and DRS_IN- as desired. Take for example a board input range of 0-1V. For a 0V input, you bias DRS_IN+ and DRS_IN- both with 0.9V. A 1V input signal then puts DRS_IN+ to 1.4V and DRS_IN-to 0.4 V. In the transparent mode, DRS_OUT+ = DRS_IN+ and DRS_OUT- = O-OFS - DRS_OUT+. So if you put O-OFS to 0.9V, you get for a 0V board input signal DRS_OUT- = 2*0.9V - DRS_OUT+ = 0.9V. So DRS_OUT+   = DRS_OUT- = 0.9 V which is in the middle of your ADC range. 

If you do now a DRS readout, you need a ROFS of roughly 0.9V. For a 0V input, the storage capacitors have a zero differential voltage (DRS_IN+ = DRS_IN- = 0.8V), so DRS_OUT+ = (0.8V - 0.8V) + ROFS  = 0.9V, and since you have O-OFS=0.9V, you will also get DRS_OUT- = 2*0.9V - DRS_OUT+ = 0.9V. So you ranges for transparent mode nad DRS readout mode will be roughly the same.

 

                   Reply  Wed May 13 16:25:24 2015, Stefan Ritt, transparent-mode voltage 

To get the good linearity, you need indeed ROFS = 1.05V. With a O-OFS of 0.9V, a zero input signal would give you DRS_OUT+=1.05V and DRS_OUT-=0.75V. I think this is till in the range of your ADC, right? So it's a tradeoff between linearity and available range. I do not know how nonlinear the DRS4 will be for ROFS < 1.05V, you have to try. If it's getting too bad, you still can correct for this off-line. 

Chenfei Yang wrote:

If using a ROFS of 0.9V, the input would not between 1.05V~2.05V better non-linearity area. Is that appropriate?

Stefan Ritt wrote:

There might be a solution. How do you bias th input of the DRS4 chip? If you use a scheme as described in elog:84, you can bias DRS_IN+ and DRS_IN- as desired. Take for example a board input range of 0-1V. For a 0V input, you bias DRS_IN+ and DRS_IN- both with 0.9V. A 1V input signal then puts DRS_IN+ to 1.4V and DRS_IN-to 0.4 V. In the transparent mode, DRS_OUT+ = DRS_IN+ and DRS_OUT- = O-OFS - DRS_OUT+. So if you put O-OFS to 0.9V, you get for a 0V board input signal DRS_OUT- = 2*0.9V - DRS_OUT+ = 0.9V. So DRS_OUT+   = DRS_OUT- = 0.9 V which is in the middle of your ADC range. 

If you do now a DRS readout, you need a ROFS of roughly 0.9V. For a 0V input, the storage capacitors have a zero differential voltage (DRS_IN+ = DRS_IN- = 0.8V), so DRS_OUT+ = (0.8V - 0.8V) + ROFS  = 0.9V, and since you have O-OFS=0.9V, you will also get DRS_OUT- = 2*0.9V - DRS_OUT+ = 0.9V. So you ranges for transparent mode nad DRS readout mode will be roughly the same.

 

 

Entry  Wed May 13 00:52:51 2015, Cosmin Deaconu, Getting Trigger Source 

I'd like to be able to know which channel (0,1,2,3 or external) was responsible for the trigger.  DRSBoard::GetTriggerSource() seems to always return 1.  Is there a way to get this information?  Using the DRS4 evaluation board and software version 5.0.3.

Thanks,

Cosmin

 

    Reply  Wed May 13 08:19:53 2015, Stefan Ritt, Getting Trigger Source 

DRSBoard::GetTriggerSource() simply returns what has been enabled via DRSBoard::SetTriggerSource(). The actual source which causes the trigger is not stored in the hardware of the board, because I can be reconstructed easily from the waveforms. So just look which of the channels is above your trigger threshold. If none of the channels has a waveform obove the threshold, then the trigger must have been come from the external trigger.

Cosmin Deaconu wrote:

I'd like to be able to know which channel (0,1,2,3 or external) was responsible for the trigger.  DRSBoard::GetTriggerSource() seems to always return 1.  Is there a way to get this information?  Using the DRS4 evaluation board and software version 5.0.3.

Thanks,

Cosmin

 

 

Entry  Wed May 13 01:07:36 2015, Cosmin Deaconu, DRS4 Evaluation Board + Powered USB Hub 

I am trying to use 4 evaluation boards with a powered USB hub (since eventually, I will have to do this on a laptop).  It seems like destroying the DRS object is insufficent to properly close the boards when on the hub (i.e. I get usb read errors next time I run my program). When all the boards are plugged into the computer, all is fine.  This is on Linux using libusb1. My guess is something about resetting the port doesn't work properly (but maybe that's this particular hub's fault?).  Has anyone else experienced a similar issue. If not, can someone recommend a hub that is known to work?

Entry  Sun Apr 5 22:16:48 2015, Julien Wulf, DRS4 Evaluation Board Baseline/Voltage Calibration  

Hi,

I`m trying to calibrate my DRS4 evoluation board to an input range of 0-1V but it doesn`t work.

1) First I tried to calibrate it with the drsosc (version 5.0.3) Software. The -0.5V - 0.5V calibration works, but during the 0 - 1V calibration the Software crashes.

2) I also tried to calibrate the input range with a C++ DAQ Package (based on drs_exam). Here the code of the calibration:

    ....

    b->SetInputRange(0.) (Center at 0 V )

    b->CalibrateVolt(NULL);

   ....

   Calibration Works

   ....

   b->SetInputRange(0.5) (Center at 0.5 V )

   b->CalibrateVolt(NULL);

  ....

   Results in: Found 4096 stuck pixels on this board.

Did I do a mistake or is this a normal behaviour of the board? Also the board often crashes and I get a magic number 0000 after restarting the DAQ. Then the board needs to be restarted via pulling the plug. ( I ensured that I terminate the USB connection before I close the program with "delete drs"). Is there a possibility to avoid this error?

My OS: Ubuntu 14.04 LTS.

Ciao,

Julien

    Reply  Tue Apr 21 12:52:18 2015, Stefan Ritt, DRS4 Evaluation Board Baseline/Voltage Calibration  

1) I tried to cablirate a V5 board with drsosc 5.0.3 and it just worked fine for me. No idea what went wrong in your case.

2) The "found 4096 stuck pixels on this board" can be safely ignored. It comes from the fact that the standard evaluation board has four cannels unconnected (the DRS4 chip has 8 channels, four are connected to in the evaluation board and four are unconnected). So the software sees wrong values on four channels because they are unconnected and thinks something is wrong. Unfortunately the software cannot determine if the channels are connected or not. So just ignore it.

3) I heard several people having to reset their boards under Linux in a similar way than you. This is probalby due to some instability in the USB part of the linux kernel, since the problem does not occur on other systems (Windows, Mac OSX). So I cannot do anything from the software side.

/Stefan

Julien Wulf wrote:

Hi,

I`m trying to calibrate my DRS4 evoluation board to an input range of 0-1V but it doesn`t work.

1) First I tried to calibrate it with the drsosc (version 5.0.3) Software. The -0.5V - 0.5V calibration works, but during the 0 - 1V calibration the Software crashes.

2) I also tried to calibrate the input range with a C++ DAQ Package (based on drs_exam). Here the code of the calibration:

    ....

    b->SetInputRange(0.) (Center at 0 V )

    b->CalibrateVolt(NULL);

   ....

   Calibration Works

   ....

   b->SetInputRange(0.5) (Center at 0.5 V )

   b->CalibrateVolt(NULL);

  ....

   Results in: Found 4096 stuck pixels on this board.

Did I do a mistake or is this a normal behaviour of the board? Also the board often crashes and I get a magic number 0000 after restarting the DAQ. Then the board needs to be restarted via pulling the plug. ( I ensured that I terminate the USB connection before I close the program with "delete drs"). Is there a possibility to avoid this error?

My OS: Ubuntu 14.04 LTS.

Ciao,

Julien

 

       Reply  Tue Apr 21 13:03:38 2015, Daniel Stricker-Shaver, DRS4 Evaluation Board Baseline/Voltage Calibration  

I also use Ubuntu 14.04 LTS and for my V3 borad I have to use drsosc 4.x or ealier to perform the calibration.

Stefan Ritt wrote:

1) I tried to cablirate a V5 board with drsosc 5.0.3 and it just worked fine for me. No idea what went wrong in your case.

2) The "found 4096 stuck pixels on this board" can be safely ignored. It comes from the fact that the standard evaluation board has four cannels unconnected (the DRS4 chip has 8 channels, four are connected to in the evaluation board and four are unconnected). So the software sees wrong values on four channels because they are unconnected and thinks something is wrong. Unfortunately the software cannot determine if the channels are connected or not. So just ignore it.

3) I heard several people having to reset their boards under Linux in a similar way than you. This is probalby due to some instability in the USB part of the linux kernel, since the problem does not occur on other systems (Windows, Mac OSX). So I cannot do anything from the software side.

/Stefan

Julien Wulf wrote:

Hi,

I`m trying to calibrate my DRS4 evoluation board to an input range of 0-1V but it doesn`t work.

1) First I tried to calibrate it with the drsosc (version 5.0.3) Software. The -0.5V - 0.5V calibration works, but during the 0 - 1V calibration the Software crashes.

2) I also tried to calibrate the input range with a C++ DAQ Package (based on drs_exam). Here the code of the calibration:

    ....

    b->SetInputRange(0.) (Center at 0 V )

    b->CalibrateVolt(NULL);

   ....

   Calibration Works

   ....

   b->SetInputRange(0.5) (Center at 0.5 V )

   b->CalibrateVolt(NULL);

  ....

   Results in: Found 4096 stuck pixels on this board.

Did I do a mistake or is this a normal behaviour of the board? Also the board often crashes and I get a magic number 0000 after restarting the DAQ. Then the board needs to be restarted via pulling the plug. ( I ensured that I terminate the USB connection before I close the program with "delete drs"). Is there a possibility to avoid this error?

My OS: Ubuntu 14.04 LTS.

Ciao,

Julien

 

 

          Reply  Tue Apr 21 13:06:39 2015, Stefan Ritt, DRS4 Evaluation Board Baseline/Voltage Calibration  

Sure, for a V3 board you need a pre-V5 software, but I assumed Julien had a V5 board. 

Daniel Stricker-Shaver wrote:

I also use Ubuntu 14.04 LTS and for my V3 borad I have to use drsosc 4.x or ealier to perform the calibration.

Entry  Thu Apr 9 11:46:33 2015, Felix Bachmair, DRSBoard::SetTriggerSource 

Hi

I have a question about the function SetTriggerSource in the class DRSBoard (DRS.h/DRS.cpp)

In the implementation there is the following comment:

// Set trigger configuration

// OR 0=CH1, 1=CH2, 2=CH3, 3=CH4, 4=EXT

// AND 8=CH1, 9=CH2, 10=CH3, 11=CH4, 12=EXT

 

What does this exactly mean? I am assuming that this are the bits which are set?

e.g

source = 1 ==> CH1

source = 4352 = 0x1100 ==> CH1 and ext

How is the AND/Or logic implemented?

When i have:

source = 0x1803 (bit 12,11,1,0)

what is the right way to set the brackets to expalin the logic?

(EXT and CH4 ) or CH2 or CH1 ?

 

Cheers Felix Bachmair

ETH Zurich

    Reply  Tue Apr 21 12:01:45 2015, Stefan Ritt, DRSBoard::SetTriggerSource 

Your first assumption is correct, e.g.

source = 00000000'00000001 = 0x0001 ==> CH1

source = 00010001'00000000 = 0x1100 ==> CH1 and EXT

So the lower byte is the "OR" block, and the upper byte is the "AND" block. Both blocks are combined via an "OR" so

source = 00011000'00000011 = 0x1803 is (EXT and CH4) OR (CH1 or CH2)

The "OR" combination between the two blocks is fixed in the firmware and cannot be changed without changing the firmware, but theoretically any logical combination between five inputs would be possible if you touch thr firmware.

/Stefan

 

Felix Bachmair wrote:

Hi

I have a question about the function SetTriggerSource in the class DRSBoard (DRS.h/DRS.cpp)

In the implementation there is the following comment:

// Set trigger configuration

// OR 0=CH1, 1=CH2, 2=CH3, 3=CH4, 4=EXT

// AND 8=CH1, 9=CH2, 10=CH3, 11=CH4, 12=EXT

 

What does this exactly mean? I am assuming that this are the bits which are set?

e.g

source = 1 ==> CH1

source = 4352 = 0x1100 ==> CH1 and ext

How is the AND/Or logic implemented?

When i have:

source = 0x1803 (bit 12,11,1,0)

what is the right way to set the brackets to expalin the logic?

(EXT and CH4 ) or CH2 or CH1 ?

 

Cheers Felix Bachmair

ETH Zurich

 

Entry  Wed Oct 15 10:14:32 2014, Simon Weingarten, Clock settings in daisy chain DAQ 

Hi,

I'm currently working on a little DAQ system with four DRS evaluation boards. Do i need to apply any specific settings when using the clock in/out connectors for synchronization? I do not see anything like that in the drs_exam_multi example.

Any help would be greatly appreciated!

Best,

Simon

    Reply  Wed Oct 15 10:52:58 2014, Stefan Ritt, Clock settings in daisy chain DAQ 

Simon Weingarten wrote:

Hi,

I'm currently working on a little DAQ system with four DRS evaluation boards. Do i need to apply any specific settings when using the clock in/out connectors for synchronization? I do not see anything like that in the drs_exam_multi example.

Any help would be greatly appreciated!

Best,

Simon

Right, I did not yet put any code there. What you need on all slave boards is

b->SetRefclk(true);

b->SetFrequency(...);

Set SetFrequency() is needed to restart the boards with the external clock.

This works of course only if you have the clock signals connected as written in the manual. If not, the boards won't work after you switch the reference clock.

Best regards,
Stefan 

       Reply  Wed Oct 15 11:34:43 2014, Simon Weingarten, Clock settings in daisy chain DAQ 

Stefan Ritt wrote:

Simon Weingarten wrote:

Hi,

I'm currently working on a little DAQ system with four DRS evaluation boards. Do i need to apply any specific settings when using the clock in/out connectors for synchronization? I do not see anything like that in the drs_exam_multi example.

Any help would be greatly appreciated!

Best,

Simon

Right, I did not yet put any code there. What you need on all slave boards is

b->SetRefclk(true);

b->SetFrequency(...);

Set SetFrequency() is needed to restart the boards with the external clock.

This works of course only if you have the clock signals connected as written in the manual. If not, the boards won't work after you switch the reference clock.

Best regards,
Stefan 

Thank you so much for the fast reply! I'll give it a try.

 

Best regards,

Simon

       Reply  Wed Oct 15 12:15:58 2014, Stefan Ritt, Clock settings in daisy chain DAQ drs_exam_multi.cpp

Here is the full version of the program with clock daisy-chaining. Before switching to the external clock, it checks if the clock really is there (by reading an internal scaler), and only then enables it. Note that the code also works without clock daisy-chaining. But without clock daisy-chaining your have some 400 ps time resolution between boards, and with clock daisy-chaining you get some 60 ps.

          Reply  Fri Apr 17 10:07:38 2015, Simon Weingarten, Clock settings in daisy chain DAQ 

Hi Stefan,

do you know how these numbers (400ps and 60ps) scale with the sampling rate? The manual says they are for 5GS/s, do they change with slower sampling?

Thanks and best regards,

Simon

Stefan Ritt wrote:

Here is the full version of the program with clock daisy-chaining. Before switching to the external clock, it checks if the clock really is there (by reading an internal scaler), and only then enables it. Note that the code also works without clock daisy-chaining. But without clock daisy-chaining your have some 400 ps time resolution between boards, and with clock daisy-chaining you get some 60 ps.

 

             Reply  Mon Apr 20 13:08:24 2015, Stefan Ritt, Clock settings in daisy chain DAQ 

The resolution coming from the sampling rate goes into these numbers, but just marginally. At 5 GSPS, you get a few ps reolution, while at 1 GSPS, you get like 15 ps. If you convolve 15 ps with 400 ps, you get 400.3 ps, which is not significantly worse than 400 ps.

Simon Weingarten wrote:

Hi Stefan,

do you know how these numbers (400ps and 60ps) scale with the sampling rate? The manual says they are for 5GS/s, do they change with slower sampling?

Thanks and best regards,

Simon

Stefan Ritt wrote:

Here is the full version of the program with clock daisy-chaining. Before switching to the external clock, it checks if the clock really is there (by reading an internal scaler), and only then enables it. Note that the code also works without clock daisy-chaining. But without clock daisy-chaining your have some 400 ps time resolution between boards, and with clock daisy-chaining you get some 60 ps.

 

 

Entry  Mon Mar 16 16:07:39 2015, Hermann-Josef Mathes, Running 2 instances of a DRS DAQ program 

Hi,

we want to run two instances of our little DRS DAQ program but obviously the first instance started always claims all DRS boards for itself and the other one exits with an error. The 2 boards used in the example below have the serial number # 2413 and #2414 and are v5 boards.

The first one:

mathes@ikauger5:~/src/DRS4/Cpp> ./drsdaq -b 2413
DRSController: found board with serial number #2413
DRSController: found board with serial number #2414
DRSController: using board with serial number #2413
CalibratedFrequency= 1.00721
====================================
DRS type:            DRS4
Board type:          9
Serial number:       2413
Firmware revision:   21260

...
And the second one:

mathes@ikauger5:~/src/DRS4/Cpp> ./drsdaq -b 2414
musb_open: usb_set_configuration() error -6
musb_open: Found USB device 0x04b4:0x1175 instance 0, but cannot initialize it: please check permissions on "/proc/bus/usb/1/7" and "/dev/bus/usb/1/7"
USB successfully scanned, but no boards found
...


How can our goal be achieved?

Thanks

Hermann-Josef

    Reply  Tue Mar 17 02:53:26 2015, Stefan Ritt, Running 2 instances of a DRS DAQ program 

I never had in mind running two systems in parallel, that's why the code claims all interfaces when started. You have to dig into the usb code which is located in musbstd.c at function musb_open(). There you will find a line libusb_claim_interface() which requests exclusive access to the usb subsystem. The code is there because I copied it from some standard example for the libusb library. You have to read the documentation for libusb (http://libusb.sourceforge.net/api-1.0/) and see if you can get rid of that. Probaby you have to claim/release the interface on each access, but I never tried that.

Stefan

Hermann-Josef Mathes wrote:

Hi,

we want to run two instances of our little DRS DAQ program but obviously the first instance started always claims all DRS boards for itself and the other one exits with an error. The 2 boards used in the example below have the serial number # 2413 and #2414 and are v5 boards.

The first one:

mathes@ikauger5:~/src/DRS4/Cpp> ./drsdaq -b 2413
DRSController: found board with serial number #2413
DRSController: found board with serial number #2414
DRSController: using board with serial number #2413
CalibratedFrequency= 1.00721
====================================
DRS type:            DRS4
Board type:          9
Serial number:       2413
Firmware revision:   21260

...
And the second one:

mathes@ikauger5:~/src/DRS4/Cpp> ./drsdaq -b 2414
musb_open: usb_set_configuration() error -6
musb_open: Found USB device 0x04b4:0x1175 instance 0, but cannot initialize it: please check permissions on "/proc/bus/usb/1/7" and "/dev/bus/usb/1/7"
USB successfully scanned, but no boards found
...


How can our goal be achieved?

Thanks

Hermann-Josef

 

       Reply  Thu Mar 19 07:37:52 2015, Daniel Stricker-Shaver, Running 2 instances of a DRS DAQ program 

I don't know if it helps, but we measured the time resolution between two independendly running v3 boards using a single PC (latest software) in Linux. (http://arxiv.org/abs/1405.4975)

You start the DRS DAQ program with only one USB board connected, first. Afterwards connect the second board and start another session. If you externally trigger (global) both boards with less than 1 Hz, you can garantee that both programs save the same events independently (from two individual DRS boards).

Daniel

Stefan Ritt wrote:

I never had in mind running two systems in parallel, that's why the code claims all interfaces when started. You have to dig into the usb code which is located in musbstd.c at function musb_open(). There you will find a line libusb_claim_interface() which requests exclusive access to the usb subsystem. The code is there because I copied it from some standard example for the libusb library. You have to read the documentation for libusb (http://libusb.sourceforge.net/api-1.0/) and see if you can get rid of that. Probaby you have to claim/release the interface on each access, but I never tried that.

Stefan

Hermann-Josef Mathes wrote:

Hi,

we want to run two instances of our little DRS DAQ program but obviously the first instance started always claims all DRS boards for itself and the other one exits with an error. The 2 boards used in the example below have the serial number # 2413 and #2414 and are v5 boards.

The first one:

mathes@ikauger5:~/src/DRS4/Cpp> ./drsdaq -b 2413
DRSController: found board with serial number #2413
DRSController: found board with serial number #2414
DRSController: using board with serial number #2413
CalibratedFrequency= 1.00721
====================================
DRS type:            DRS4
Board type:          9
Serial number:       2413
Firmware revision:   21260

...
And the second one:

mathes@ikauger5:~/src/DRS4/Cpp> ./drsdaq -b 2414
musb_open: usb_set_configuration() error -6
musb_open: Found USB device 0x04b4:0x1175 instance 0, but cannot initialize it: please check permissions on "/proc/bus/usb/1/7" and "/dev/bus/usb/1/7"
USB successfully scanned, but no boards found
...


How can our goal be achieved?

Thanks

Hermann-Josef

 

 

Entry  Fri Feb 13 10:12:16 2015, Andrzej Grzeszczuk, drs4 and root 

Hello,

I compiled base file for drs system  (DRS.cpp) to root framework (root.cern.ch) as dynamic library DRS.so. It can be used for building many kind of applications under the root system. I applied it for older version of  root 5.28 and for latest version 6.02 too.

If anyone is interesting, I can help, please write to me andrzej.grzeszczuk@us.edu.pl

Regards

Andrzej

Entry  Fri Jan 16 13:29:05 2015, Rainer Hentges, Mac OSX Yosemite 10.10 
Hello,

I can compile version 5.0.3 of DRS4sc on Mac OSX 10.0 without errors but when I want to execute the program I get the following error:

[home]$ ./DRSOsc
DRSOsc(48068,0x7fff7ac5e300) malloc: *** error for object 0x7f88d9434a80: incorrect checksum for freed object - object was probably 
modified after being freed.
*** set a breakpoint in malloc_error_break to debug

Is this a known error? Will it be fixed in the next release?
    Reply  Fri Jan 16 14:12:19 2015, Stefan Ritt, Mac OSX Yosemite 10.10 
> Hello,
> 
> I can compile version 5.0.3 of DRS4sc on Mac OSX 10.0 without errors but when I want to execute the program I get the following error:
> 
> [home]$ ./DRSOsc
> DRSOsc(48068,0x7fff7ac5e300) malloc: *** error for object 0x7f88d9434a80: incorrect checksum for freed object - object was probably 
> modified after being freed.
> *** set a breakpoint in malloc_error_break to debug
> 
> Is this a known error? Will it be fixed in the next release?

When I compile on OSX 10.10.1 with XCode 6.1.1 I get no error. I'm using wxWidgets 3.0.0. Same when I compile with the command line 
tools (which you first have to install from Apple) via "make", "make app", "open ./DRSOsc.app". You cannot start a graphical program 
directly from the command line like under Linux, you have to make an app and the do "open <app>".

Best regards,
Stefan
Entry  Mon Nov 17 16:36:18 2014, Mickey Chiu, Raspberry Pi drsosc does not exit properly 

When running drsosc on a raspberry pi, it seems the exit doesn't seem to work at all.  This is true for the "exit" button on the window, or the file menu exit, or the "x" on the window.  I end up having to kill drsosc manually from the command line.  This wouldn't be such a bad thing except that it doesn't seem to store any settings when killed in this way.  I'm wondering if anyone else sees the same thing, or if there is a fix out there, before I go and delve into why.

    Reply  Tue Nov 25 14:06:34 2014, Stefan Ritt, Raspberry Pi drsosc does not exit properly 

Mickey Chiu wrote:

When running drsosc on a raspberry pi, it seems the exit doesn't seem to work at all.  This is true for the "exit" button on the window, or the file menu exit, or the "x" on the window.  I end up having to kill drsosc manually from the command line.  This wouldn't be such a bad thing except that it doesn't seem to store any settings when killed in this way.  I'm wondering if anyone else sees the same thing, or if there is a fix out there, before I go and delve into why.

Unfortunately I don't have a pi here right now, so I cannot reproduce your problem. I checked on a linux system and it worked fine with wxWidgets 3.0.1 and GTK2 2.20. The wxWidget library sends an wxID_EXIT event to DOFrame::OnExit, which then closes the window. The destructor of DOFrame then calls SaveConfig() to save the current settings. Maybe you can debug this.

/Stefan 

Entry  Sun Oct 19 14:36:54 2014, Chris Tully, coverting the xml file format into binary 

 Hi,

    Is there a straightforward way to convert the xml file format into the binary format?  I have some runs taken mistakenly with xml.

Best,

Chris

 

Entry  Wed Aug 13 20:17:19 2014, Roman Gredig, binary files time calibration header in drs-5.0.2 
Dear Stefan

I have a problem considering binary data files.
Usually binary files start with TIME... (the time calibration header). But I observed the following reproducible problem.
1. Start to save a binary file (e.g. 001.dat) with 1000000 events. 
2. Hit the close button before this limit has reached. (so far the binary files seems to be ok) 
3. Start to save again a file with the SAME filename (and agree to replace the already existing it)
If I do it like this, the file has no time information anymore and starts directly with EHDR.

could it be that the m_evSerial counter is not reset in this specific situation?

Cheers,
Roman
    Reply  Thu Oct 16 16:16:12 2014, Stefan Ritt, binary files time calibration header in drs-5.0.2 
> Dear Stefan
> 
> I have a problem considering binary data files.
> Usually binary files start with TIME... (the time calibration header). But I observed the following reproducible problem.
> 1. Start to save a binary file (e.g. 001.dat) with 1000000 events. 
> 2. Hit the close button before this limit has reached. (so far the binary files seems to be ok) 
> 3. Start to save again a file with the SAME filename (and agree to replace the already existing it)
> If I do it like this, the file has no time information anymore and starts directly with EHDR.
> 
> could it be that the m_evSerial counter is not reset in this specific situation?
> 
> Cheers,
> Roman

This problem has also been fixed in version 5.0.3

/Stefan
Entry  Tue Aug 26 14:16:26 2014, Roman Gredig, binary files with more than 4 drs board ver. 5.0.2 
Dear Stefan

after having some problems with writing binary files with more than 4 drs boards (in multiboard-mode) I might 
have found the solution.
In the file src/Osci.cpp at line 838 is: 
unsigned char buffer[100000];

If I understand the binary format right, this works only with up to four boards. With the maximum number of 
boards in your specification (16 boards) and all channels switched on on all boards this array needs to have 
about 400000 entries (for the first event, where the time information is written too).

Could you please cross-check that?

Thank you very much!
Cheers,
Roman
    Reply  Thu Oct 16 16:15:16 2014, Stefan Ritt, binary files with more than 4 drs board ver. 5.0.2 
> Dear Stefan
> 
> after having some problems with writing binary files with more than 4 drs boards (in multiboard-mode) I might 
> have found the solution.
> In the file src/Osci.cpp at line 838 is: 
> unsigned char buffer[100000];
> 
> If I understand the binary format right, this works only with up to four boards. With the maximum number of 
> boards in your specification (16 boards) and all channels switched on on all boards this array needs to have 
> about 400000 entries (for the first event, where the time information is written too).
> 
> Could you please cross-check that?
> 
> Thank you very much!
> Cheers,
> Roman

This problem has been fixed in software version 5.0.3

/Stefan
Entry  Tue Oct 7 14:09:02 2014, Stephane Debieux, USB Microcontroller firmware 

Hi,

I'm trying to recompile the USB microcontroller firmware starting from the drs_eval.c file but I'm not able to get a .iic file close to the one provided with the eval board. It seems to me that this drs_eval.iic file does not match the drs_eval.c and drs_eval.hex files or that I'm doing something wrong. Could you please help or give me an explanation.

Thank you.

Stephane

 

    Reply  Mon Oct 13 16:46:56 2014, Stefan Ritt, USB Microcontroller firmware 

Stephane Debieux wrote:

Hi,

I'm trying to recompile the USB microcontroller firmware starting from the drs_eval.c file but I'm not able to get a .iic file close to the one provided with the eval board. It seems to me that this drs_eval.iic file does not match the drs_eval.c and drs_eval.hex files or that I'm doing something wrong. Could you please help or give me an explanation.

Thank you.

Stephane

 

I did not touch the firmware since a couple of years, but I can confirm that the drs_eval.iic is the correct firmware file, since we use this one on all of our boards. To program it, you need the Cypress USB Console. You remove the jumper (to detach the EEPROM), then power the board (which then boots from the internal memory), connect to the board via the Cypress console, the put back the jumper while the board is running, then program the file into the EEPROM.

Best,
Stefan 

       Reply  Mon Oct 13 17:08:40 2014, Stephane Debieux, USB Microcontroller firmware 

Stefan Ritt wrote:

Stephane Debieux wrote:

Hi,

I'm trying to recompile the USB microcontroller firmware starting from the drs_eval.c file but I'm not able to get a .iic file close to the one provided with the eval board. It seems to me that this drs_eval.iic file does not match the drs_eval.c and drs_eval.hex files or that I'm doing something wrong. Could you please help or give me an explanation.

Thank you.

Stephane

 

I did not touch the firmware since a couple of years, but I can confirm that the drs_eval.iic is the correct firmware file, since we use this one on all of our boards. To program it, you need the Cypress USB Console. You remove the jumper (to detach the EEPROM), then power the board (which then boots from the internal memory), connect to the board via the Cypress console, the put back the jumper while the board is running, then program the file into the EEPROM.

Best,
Stefan 

 Thank you Stefan.

Would that be possible to get the corresponding drs_eval.c source file since I'm assuming the one provided with the eval board is not the right one?

Thank you.

Stephane

          Reply  Mon Oct 13 17:14:58 2014, Stefan Ritt, USB Microcontroller firmware 

Stephane Debieux wrote:

Stefan Ritt wrote:

Stephane Debieux wrote:

Hi,

I'm trying to recompile the USB microcontroller firmware starting from the drs_eval.c file but I'm not able to get a .iic file close to the one provided with the eval board. It seems to me that this drs_eval.iic file does not match the drs_eval.c and drs_eval.hex files or that I'm doing something wrong. Could you please help or give me an explanation.

Thank you.

Stephane

 

I did not touch the firmware since a couple of years, but I can confirm that the drs_eval.iic is the correct firmware file, since we use this one on all of our boards. To program it, you need the Cypress USB Console. You remove the jumper (to detach the EEPROM), then power the board (which then boots from the internal memory), connect to the board via the Cypress console, the put back the jumper while the board is running, then program the file into the EEPROM.

Best,
Stefan 

 Thank you Stefan.

Would that be possible to get the corresponding drs_eval.c source file since I'm assuming the one provided with the eval board is not the right one?

Thank you.

Stephane

There is only one drs_eval.c version around, and I confirm that it is the one in the distribution. If you use different compiler settings, like optimisations, you might get a different executable file (and thus a .iic file), but the files have the same functionality.

Stefan 

             Reply  Tue Oct 14 16:21:07 2014, Stephane Debieux, USB Microcontroller firmware 

Stefan Ritt wrote:

Stephane Debieux wrote:

Stefan Ritt wrote:

Stephane Debieux wrote:

Hi,

I'm trying to recompile the USB microcontroller firmware starting from the drs_eval.c file but I'm not able to get a .iic file close to the one provided with the eval board. It seems to me that this drs_eval.iic file does not match the drs_eval.c and drs_eval.hex files or that I'm doing something wrong. Could you please help or give me an explanation.

Thank you.

Stephane

 

I did not touch the firmware since a couple of years, but I can confirm that the drs_eval.iic is the correct firmware file, since we use this one on all of our boards. To program it, you need the Cypress USB Console. You remove the jumper (to detach the EEPROM), then power the board (which then boots from the internal memory), connect to the board via the Cypress console, the put back the jumper while the board is running, then program the file into the EEPROM.

Best,
Stefan 

 Thank you Stefan.

Would that be possible to get the corresponding drs_eval.c source file since I'm assuming the one provided with the eval board is not the right one?

Thank you.

Stephane

There is only one drs_eval.c version around, and I confirm that it is the one in the distribution. If you use different compiler settings, like optimisations, you might get a different executable file (and thus a .iic file), but the files have the same functionality.

Stefan 

I'm very sorry to insist but if I take the .hex of the distribution, convert it to .iic using the hex2bix utility, and reprogram the board, I can't read the board correctly (invalid magic number read with drscl for instance). Also, when using the uVision2 project file you provide and compiling the drs_eval.c, I get the same result  (i.e. no way to generate a functional .iic file starting from the sources). So, either I'm doing something wrong (and I don't know what) or the drs_eval.c is not the correct one.

                Reply  Tue Oct 14 16:29:12 2014, Stefan Ritt, USB Microcontroller firmware 

Stephane Debieux wrote:

Stefan Ritt wrote:

Stephane Debieux wrote:

Stefan Ritt wrote:

Stephane Debieux wrote:

Hi,

I'm trying to recompile the USB microcontroller firmware starting from the drs_eval.c file but I'm not able to get a .iic file close to the one provided with the eval board. It seems to me that this drs_eval.iic file does not match the drs_eval.c and drs_eval.hex files or that I'm doing something wrong. Could you please help or give me an explanation.

Thank you.

Stephane

 

I did not touch the firmware since a couple of years, but I can confirm that the drs_eval.iic is the correct firmware file, since we use this one on all of our boards. To program it, you need the Cypress USB Console. You remove the jumper (to detach the EEPROM), then power the board (which then boots from the internal memory), connect to the board via the Cypress console, the put back the jumper while the board is running, then program the file into the EEPROM.

Best,
Stefan 

 Thank you Stefan.

Would that be possible to get the corresponding drs_eval.c source file since I'm assuming the one provided with the eval board is not the right one?

Thank you.

Stephane

There is only one drs_eval.c version around, and I confirm that it is the one in the distribution. If you use different compiler settings, like optimisations, you might get a different executable file (and thus a .iic file), but the files have the same functionality.

Stefan 

I'm very sorry to insist but if I take the .hex of the distribution, convert it to .iic using the hex2bix utility, and reprogram the board, I can't read the board correctly (invalid magic number read with drscl for instance). Also, when using the uVision2 project file you provide and compiling the drs_eval.c, I get the same result  (i.e. no way to generate a functional .iic file starting from the sources). So, either I'm doing something wrong (and I don't know what) or the drs_eval.c is not the correct one.

And what happens if you program the .iic file from the distribution? 

                   Reply  Tue Oct 14 16:34:45 2014, Stephane Debieux, USB Microcontroller firmware 

Stefan Ritt wrote:

Stephane Debieux wrote:

Stefan Ritt wrote:

Stephane Debieux wrote:

Stefan Ritt wrote:

Stephane Debieux wrote:

Hi,

I'm trying to recompile the USB microcontroller firmware starting from the drs_eval.c file but I'm not able to get a .iic file close to the one provided with the eval board. It seems to me that this drs_eval.iic file does not match the drs_eval.c and drs_eval.hex files or that I'm doing something wrong. Could you please help or give me an explanation.

Thank you.

Stephane

 

I did not touch the firmware since a couple of years, but I can confirm that the drs_eval.iic is the correct firmware file, since we use this one on all of our boards. To program it, you need the Cypress USB Console. You remove the jumper (to detach the EEPROM), then power the board (which then boots from the internal memory), connect to the board via the Cypress console, the put back the jumper while the board is running, then program the file into the EEPROM.

Best,
Stefan 

 Thank you Stefan.

Would that be possible to get the corresponding drs_eval.c source file since I'm assuming the one provided with the eval board is not the right one?

Thank you.

Stephane

There is only one drs_eval.c version around, and I confirm that it is the one in the distribution. If you use different compiler settings, like optimisations, you might get a different executable file (and thus a .iic file), but the files have the same functionality.

Stefan 

I'm very sorry to insist but if I take the .hex of the distribution, convert it to .iic using the hex2bix utility, and reprogram the board, I can't read the board correctly (invalid magic number read with drscl for instance). Also, when using the uVision2 project file you provide and compiling the drs_eval.c, I get the same result  (i.e. no way to generate a functional .iic file starting from the sources). So, either I'm doing something wrong (and I don't know what) or the drs_eval.c is not the correct one.

And what happens if you program the .iic file from the distribution? 

It works as expected.

                      Reply  Tue Oct 14 16:38:14 2014, Stefan Ritt, USB Microcontroller firmware 

Stephane Debieux wrote:

Stefan Ritt wrote:

Stephane Debieux wrote:

Stefan Ritt wrote:

Stephane Debieux wrote:

Stefan Ritt wrote:

Stephane Debieux wrote:

Hi,

I'm trying to recompile the USB microcontroller firmware starting from the drs_eval.c file but I'm not able to get a .iic file close to the one provided with the eval board. It seems to me that this drs_eval.iic file does not match the drs_eval.c and drs_eval.hex files or that I'm doing something wrong. Could you please help or give me an explanation.

Thank you.

Stephane

 

I did not touch the firmware since a couple of years, but I can confirm that the drs_eval.iic is the correct firmware file, since we use this one on all of our boards. To program it, you need the Cypress USB Console. You remove the jumper (to detach the EEPROM), then power the board (which then boots from the internal memory), connect to the board via the Cypress console, the put back the jumper while the board is running, then program the file into the EEPROM.

Best,
Stefan 

 Thank you Stefan.

Would that be possible to get the corresponding drs_eval.c source file since I'm assuming the one provided with the eval board is not the right one?

Thank you.

Stephane

There is only one drs_eval.c version around, and I confirm that it is the one in the distribution. If you use different compiler settings, like optimisations, you might get a different executable file (and thus a .iic file), but the files have the same functionality.

Stefan 

I'm very sorry to insist but if I take the .hex of the distribution, convert it to .iic using the hex2bix utility, and reprogram the board, I can't read the board correctly (invalid magic number read with drscl for instance). Also, when using the uVision2 project file you provide and compiling the drs_eval.c, I get the same result  (i.e. no way to generate a functional .iic file starting from the sources). So, either I'm doing something wrong (and I don't know what) or the drs_eval.c is not the correct one.

And what happens if you program the .iic file from the distribution? 

It works as expected.

 Then why don't you use the .iic file and forget about the hex and c files? Honestly speaking, I don't remember what source file I compiled a couple of years ago, and it could be that an older file slipped into the repository, but that's all I have. I would have to investigate myself, try to compile and program the c file, do the debugging, and find out what the differences are. But unfortunately I don't have time for that right now. So just stick with the .iic file.

                         Reply  Tue Oct 14 16:51:37 2014, Stephane Debieux, USB Microcontroller firmware 

Stefan Ritt wrote:

Stephane Debieux wrote:

Stefan Ritt wrote:

Stephane Debieux wrote:

Stefan Ritt wrote:

Stephane Debieux wrote:

Stefan Ritt wrote:

Stephane Debieux wrote:

Hi,

I'm trying to recompile the USB microcontroller firmware starting from the drs_eval.c file but I'm not able to get a .iic file close to the one provided with the eval board. It seems to me that this drs_eval.iic file does not match the drs_eval.c and drs_eval.hex files or that I'm doing something wrong. Could you please help or give me an explanation.

Thank you.

Stephane

 

I did not touch the firmware since a couple of years, but I can confirm that the drs_eval.iic is the correct firmware file, since we use this one on all of our boards. To program it, you need the Cypress USB Console. You remove the jumper (to detach the EEPROM), then power the board (which then boots from the internal memory), connect to the board via the Cypress console, the put back the jumper while the board is running, then program the file into the EEPROM.

Best,
Stefan 

 Thank you Stefan.

Would that be possible to get the corresponding drs_eval.c source file since I'm assuming the one provided with the eval board is not the right one?

Thank you.

Stephane

There is only one drs_eval.c version around, and I confirm that it is the one in the distribution. If you use different compiler settings, like optimisations, you might get a different executable file (and thus a .iic file), but the files have the same functionality.

Stefan 

I'm very sorry to insist but if I take the .hex of the distribution, convert it to .iic using the hex2bix utility, and reprogram the board, I can't read the board correctly (invalid magic number read with drscl for instance). Also, when using the uVision2 project file you provide and compiling the drs_eval.c, I get the same result  (i.e. no way to generate a functional .iic file starting from the sources). So, either I'm doing something wrong (and I don't know what) or the drs_eval.c is not the correct one.

And what happens if you program the .iic file from the distribution? 

It works as expected.

 Then why don't you use the .iic file and forget about the hex and c files? Honestly speaking, I don't remember what source file I compiled a couple of years ago, and it could be that an older file slipped into the repository, but that's all I have. I would have to investigate myself, try to compile and program the c file, do the debugging, and find out what the differences are. But unfortunately I don't have time for that right now. So just stick with the .iic file.

Thanks for the help.

I'm not doing this for fun, checking that the source matches the .iic ! I know I could directly use the .iic and forget about the hex and c files.

I just wanted to use your source file as the starting point for my own board, as everybody is doing at the application level.

Entry  Mon Sep 15 16:24:41 2014, Hannes Wachter, Timing Calibration Fail 

Hi,

has anyone experienced a shutdown of the DRSosc.exe or DRScl.exe when executing a Timing Calibration? Also, when we add the command b->CalibrateTiming(NULL); to the drs_exam.cpp and run the exe, our program shuts down immediately and windows shows an error message (identical to DRSosc and DRScl).

Any help is appreciated.

 

    Reply  Mon Sep 22 15:04:37 2014, Stefan Ritt, Timing Calibration Fail 

Hannes Wachter wrote:

Hi,

has anyone experienced a shutdown of the DRSosc.exe or DRScl.exe when executing a Timing Calibration? Also, when we add the command b->CalibrateTiming(NULL); to the drs_exam.cpp and run the exe, our program shuts down immediately and windows shows an error message (identical to DRSosc and DRScl).

Any help is appreciated.

 

Actually there is no need to call b->CalibrateTiming() at all from drs_exam.cpp. The timing calibration, once executed, will remain valid over a wide temperature range and for very long time (years), so no need to redo it over and over again.

/Stefan 

Entry  Fri Sep 12 14:57:22 2014, Dmitry Hits, compilation error for v5.0.2 

 Hi,

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

src/DOFrame.cpp:617:14: error: invalid conversion from ‘char*’ to ‘wxChar {aka wchar_t}’ [-fpermissive]
 
I have wxWidgets v. 2.8.12 package on Fedora version 3.9.10-100.fc17.x86_64
 
Has anyone seen this before?
 
Thank you,
 
Dmitry 

 

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

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

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]
    Reply  Fri Sep 12 16:08:49 2014, Stefan Ritt, compilation error for v5.0.2 

Dmitry Hits wrote:

 Hi,

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

src/DOFrame.cpp:617:14: error: invalid conversion from ‘char*’ to ‘wxChar {aka wchar_t}’ [-fpermissive]
 
I have wxWidgets v. 2.8.12 package on Fedora version 3.9.10-100.fc17.x86_64
 
Has anyone seen this before?
 
Thank you,
 
Dmitry 

 

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

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

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]

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

 

       Reply  Fri Sep 12 16:38:24 2014, Dmitry Hits, compilation error for v5.0.2 

Stefan Ritt wrote:

Dmitry Hits wrote:

 Hi,

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

src/DOFrame.cpp:617:14: error: invalid conversion from ‘char*’ to ‘wxChar {aka wchar_t}’ [-fpermissive]
 
I have wxWidgets v. 2.8.12 package on Fedora version 3.9.10-100.fc17.x86_64
 
Has anyone seen this before?
 
Thank you,
 
Dmitry 

 

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

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

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]

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 

          Reply  Mon Sep 22 14:52:21 2014, Stefan Ritt, compilation error for v5.0.2 

Dmitry Hits wrote:

Stefan Ritt wrote:

Dmitry Hits wrote:

 Hi,

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

src/DOFrame.cpp:617:14: error: invalid conversion from ‘char*’ to ‘wxChar {aka wchar_t}’ [-fpermissive]
 
I have wxWidgets v. 2.8.12 package on Fedora version 3.9.10-100.fc17.x86_64
 
Has anyone seen this before?
 
Thank you,
 
Dmitry 

 

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

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

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]

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

Entry  Fri Sep 12 11:52:21 2014, Dmitry Hits, synchronizing two DRS4 evaluation boards readout with one computer 

 Hi everyone,

Has anyone tried to synchronize 2 (two) DRS4 evaluation boards readout by the same computer? I have read about some attempts on this board in the past, but I do not know if they have succeeded. If yes, could you share your experience and/or software.

Thank you very much,

Dmitry.

 

    Reply  Fri Sep 12 13:00:04 2014, Stefan Ritt, synchronizing two DRS4 evaluation boards readout with one computer 

Dmitry Hits wrote:

 Hi everyone,

Has anyone tried to synchronize 2 (two) DRS4 evaluation boards readout by the same computer? I have read about some attempts on this board in the past, but I do not know if they have succeeded. If yes, could you share your experience and/or software.

Thank you very much,

Dmitry.

 

Please read the manual http://www.psi.ch/drs/DocumentationEN/manual_rev50.pdf page 25 where this is described in detail.

/Stefan

       Reply  Fri Sep 12 13:37:42 2014, Dmitry Hits, synchronizing two DRS4 evaluation boards readout with one computer 

Stefan Ritt wrote:

Dmitry Hits wrote:

 Hi everyone,

Has anyone tried to synchronize 2 (two) DRS4 evaluation boards readout by the same computer? I have read about some attempts on this board in the past, but I do not know if they have succeeded. If yes, could you share your experience and/or software.

Thank you very much,

Dmitry.

 

Please read the manual http://www.psi.ch/drs/DocumentationEN/manual_rev50.pdf page 25 where this is described in detail.

/Stefan

 Hi Stefan,

 

Thank you for pointing me to the document. Does it apply only to version 5 of the board or can it be applied also to version 4 (which is the one I have)?

Dmitry

          Reply  Fri Sep 12 13:41:43 2014, Stefan Ritt, synchronizing two DRS4 evaluation boards readout with one computer 

Dmitry Hits wrote:

Stefan Ritt wrote:

Dmitry Hits wrote:

 Hi everyone,

Has anyone tried to synchronize 2 (two) DRS4 evaluation boards readout by the same computer? I have read about some attempts on this board in the past, but I do not know if they have succeeded. If yes, could you share your experience and/or software.

Thank you very much,

Dmitry.

 

Please read the manual http://www.psi.ch/drs/DocumentationEN/manual_rev50.pdf page 25 where this is described in detail.

/Stefan

 Hi Stefan,

 

Thank you for pointing me to the document. Does it apply only to version 5 of the board or can it be applied also to version 4 (which is the one I have)?

Dmitry

In principle it should also work with version 4, but I'm not sure how well the V4 software supports this. You might try the V5 software with your V4 boards.

/Stefan 

Entry  Thu Aug 21 11:03:36 2014, Martin Petriska, 10GSps on DRS4 Evm with delay cables 

 Hi, I read its possible to use channels 2,4,6 to extend 200ns to 400ns (1024bins to 2048).

Is it possible to use same channels to double sampling rate with paralel feeding, one channel delayed by Ts/2, for 5,12GS/s is it cca 3cm delay cable?

 

Martin

    Reply  Tue Aug 26 12:32:21 2014, Stefan Ritt, 10GSps on DRS4 Evm with delay cables 

Martin Petriska wrote:

 Hi, I read its possible to use channels 2,4,6 to extend 200ns to 400ns (1024bins to 2048).

Is it possible to use same channels to double sampling rate with paralel feeding, one channel delayed by Ts/2, for 5,12GS/s is it cca 3cm delay cable?

 

Martin

In principle yes (you could split your signal externally and add some cable delay to one side), but it is not supported by the software. You would have to combine the data from the two channels yourself. But it won't help much. The analog bandwidth of the evaluation board is about 700 MHz. So sampling at 10 GSPS vs. 5 GSPS won't give you any additional information, since the highest frequencies in your signal will be only 700 MHz. You could as well take your 5 GSPS measurement and interpolate it with some sinc function to get exactly the same result. See here for details: http://en.wikipedia.org/wiki/Whittaker%E2%80%93Shannon_interpolation_formula 

ELOG V3.1.5-3fb85fa6