I'm using picoprobe/scope for simple X-ray spectroscopy and I'm automatically saving amplifier traces for trigged events using the alarm feature and dumping the buffer. I save thousands of such events; then I convert the .psdata to cvs (works nice but a bit slowly); then, using some bash scripts, I collect one sample from each file (the sample with the highest amplitude). Clumsy procedure, but useful for me right now.
Now I want to use those thousands of picked peak-samples (each representing the wavelength/energy of an X-ray) and plot them in a histogram to create the X-ray spectrum. However, making those kind of spectroscopy-histograms requires precise binning of the data, and here lies my problem:
I cannot convert back the Picoscope represented mV values to exact ADC counts. I.e. I do not get integer numbers if I divide the mV value by (scope-range)/ 32768. It may be caused by truncation of the mV value, but each step of the actual 8 bit mV values is also not linear. The (8 bit) steps actually varies between 140 and 150 times the (16 bit) LSB value, i.e. quite strange values (8 bit steps should be 256 16 bit steps).
Would you have some additional information for me that could help me getting my (back-projected ADC count) binning right ?
where max_ADC_count is the maximum ADC count for your device (not 32768). If you can indicate the device you are using, I can let you know the max_ADC_count value to use.
Thanks very much for your answer. Your formula will yield homogeneous LSB steps as it should be when the voltages are representing a binary 'staircase'. But the problem is that the resulting voltage scale output is not yielding a homogeneous 'starcase'. The column of data below are all the, unique, voltage values that I get as output after having collected about 6000 data points. I get data in most ADC bins after that amount of statistics, in this case except 3-5 bins. If you plot these data as Y-values against a linear (e.g. integer value) X-axis, you will see what I mean. It is virtually impossible to revert these voltage values back to homogeneous binary bins.
I wish that the Picoscope 6 program could have had the very simple feature of dumping binary values rather than only values converted to voltage. I realize that I can get the ADC values if I read-out using my own program, but it is also useless for me because there seems to be no trigger-listening feature in the API that I could use as alternative to the 'Alarm' feature in the Picoscope 6 (or is there ?). That would be necessary for my kind of (asynchronous) spectroscopy needs.
I'm sorry that I've gotten stuck with this, I have a higher-spec bench-top oscilloscope in my lab and I bough the Picoscope as it seemed to offer me more of a general purpose "data-acquisition" system, but I'm about to conclude now that no one in the gamma-/X-ray spectroscopy community currently can get the maximum out of your system. The only thing that you need to do to change that is to offer the optional binary ADC values output.
Best regards, Einar
Below are the voltage 'staircase' values that I get from your system:
The data is taken at the +-1V oscilloscope range and the values are scaled by 10e8 just to get integer values (thus the first value, e.g, was originally 0.08865627)
Would it be possible to send the corresponding PicoScope data file so that I can see the values collected?
With regards to the trigger, what sort of condition are you looking to trigger on? The API functions from the driver allow a greater range of trigger options relative to the PicoScope software.
Thanks again for fast reply. The acquired voltage values I sent you was generated from traces in 6000 psfiles converted to csv (using the DOS command Picoscope /c *.psdata /f csv /b all). In a Linux bash script I then selected the maximum value of each file. This gave me 6000 values that included multiple instances of nearly all possible voltage levels. Than I ran the bash commands "sort" before "uniq" that gave me the single instances of nearly all possible voltage levels, i.e. the range of data that I sent to you. None of the above Linux operations altered any of the values, but I did multiply them by 1e8 before I sent them to you.
I also have tried to use the measurement "Maximum" feature, and upon each trigger Alarm, run the script Picoscope.com /a Measurements.CSV? >> mydata.csv. This is more effective and would be my preferred method, but in that case the voltage homogeneity between ADC levels is even worse. A set of these data (~34000 acquisitions) I have attached 1: rawdata directly after the Picoscope script, appended values, 2: only the max values (with removal of other columns, removal of the "mV" string and deletion of all header lines), and 3: only single instances of the max values. The last one is similar to what I sent you before and if you plot these values against a linear X, you will again see the inhomogeneity between the steps.
Regarding API & trigger. This is not so much about type of trigger, it is about recognizing the trigger remotely so that buffers can be read only upon each new trigger. You may imagine that if triggered events are rare, as in my case now, I don't want to read the same buffer over and over again. I want to wait until I get a new trigger and then read. Maybe this is possible (?), but it is more preferred anyway for me to just get correctly binned data directly generated from Picoscope 6 (programming is time consuming).