Page 4 of 4

Re: Spectrum Recorder PCI-E Card?

Posted: Sun Feb 03, 2019 12:45 pm
by Harald_Consul
You're absolutely right John, if I wanted to count in real time.

But that's not the case! Instead I want to record a longer period to a fast PC hard disk (a SSD) and to analyze the recorded data much more sophisticated by a statistical software for hours, days and weeks to solve the piled up amplitudes problem fully (thus to count 100% correctly).

John, why should I invest 800 USD for a multichannel analyzer or even much more USD for a more universal spectrum analyzer now, that count piled up amplitudes wrong,

when the HackRF software defined radio costs about 200 USD and most possibly its next generation will be 1GSample/s and I can record terrabytes of amplitude data with it and I could do nearly any known analysis with it using a statistics software like R?

Re: Spectrum Recorder PCI-E Card?

Posted: Sun Feb 03, 2019 5:13 pm
by Chris Mullins

Focusing on just a couple small issues in this response - I think there are still some large terminology gaps causing some misunderstanding. In the US, a "spectrum analyzer" is a specific tool used mostly for RF work in the frequency domain. None of the hits in your ebay search for "spectrum analyzer" would be well suited for what you're trying to accomplish, or will be counting any pulses at all. Rich hit on this in his first reply in this thread - your use of the word "spectrum" here is a bit confusing, and when he asked about "radiation energy spectrum", that use of the word "spectrum" is completely different than how it's used in the phrase "spectrum analyzer" in the US.

Rich also tried to guide you to realize why that HackRF software-defined radio isn't going to be useful for your use. SDRs use special sampling techniques optimized for their purpose - take Rich's advice to learn about undersampling, and RF down-conversion to understand why that makes them unsuitable for baseband pulse sampling.

If you're trying to develop novel pulse analysis algorithms on a small budget, your best approach with real hardware is to get a cheap scope with a PC interface, and dump triggered waveforms to get some raw data. Looks like you can get a 500MHz, 1-2Gs/s scope used on ebay starting around $500 (in the US). If you don't already have a scope with those specs, you're going to need one anyway to get your hardware working. If you dump captured waveforms to a PC at the maximum rate of the scope, those won't be a continuous 2Gs/s trace, but still gives you data to work with. Statistically, does it matter if you only have a small percentage of the entire dataset, if the waveforms you do have are captured in an unbiased manner?

There is a lot of good advice from everyone in this thread that I don't think you're fully digesting.

Re: Spectrum Recorder PCI-E Card?

Posted: Mon Feb 04, 2019 5:32 pm
by Harald_Consul
Just for info: I've got a 250 MHZ 1GSample/s digital oscilloscope with data export functionality. However the maximum #samples is very limited. 48k samples or so.

Ok, lets do some digestion of your advices now:
  1. You say, to sense a periodic signal (e.g. sinus signal) a sample rate of 2,5 times the frequency would be fine (2 times rate = nyquist rate = absolute minimum)
  2. However, scintillation tube amplitudes are not periodic. If the signal risetime were on the order of 2 ns, you consider the signal a 200 MHz signal and suggest "high fidelity sampling" at 500 Msps for it.
  3. The optimal sample rate might be even a little higher considering the antialising problem. "In practice, designers need some room for the anti-alising filter to roll off between 100% passing with constant delay (in frequency range of interest) to 100% stopping (at and above half the sampling rate)." Here I do not understand how much more sampling rate is effectively required for antialising.
  4. You do not refer to mathematical decomposition method of piled up amplitude. I say, a mathematical decomposition method for of piled up amplitude should be the basis to determine the necessary sampling rate.
  5. You say, piled up amplitudes do not occur this often, that this would justify analyzing them sophistacally. I say, I buy a measurement instrument, that I will most possibly used for many purposes in the future. Therefore it is better to have the option to decompose piled up amplitudes than not to have. Further, a lot of physics discoveries have been caused by new more sophisticated detectors. Maybe I've got the chance to make such discovery with a sophisticated measurement instrument.
  6. You say, the waveform/ curvature of an scintillation amplitude is highly system specific (starting with PMT and ending with last analog signal processing in front of the A/D converter) and will tremendously depend on the rise- and fall times of the whole analog electronic pathway. Thus, trying to decompose a highly individual signal is not possible, as some kind of signal map/ signal directory cannot exist. I say, the deformation of the signal does not matter for decomposing it statistically, as far the signal deformation from the system electronic is always the same (especially in the means of skewness and kurtosis).
  7. You say, a shaping amplifier to slow down the pulse is another valid alternative. You say yourself, that this is only possible when the scintillation analysis is in "single particle detection" condition. Otherwise two following amplitudes will pile up. As I do not know about my future measurement conditions, I am not too interested in this approach this time (which might change in future).

I will address your advices to the HackRf software defined radio in another digestion like this one.

Re: Spectrum Recorder PCI-E Card?

Posted: Tue Feb 05, 2019 5:45 am
by John Myers
  1. To avoid aliasing sampling needs to be greater then 2 times the signal frequency.
  2. ...
  3. Sampling too fast can also cause aliasing issues, so faster isn't necessarily better. The roll off rate of a filter isn't about the sample rate it has to do with how fast a frequency can be cutoff completely.
  4. Deconvolution is a mathematical method for separation(decomposition) of piled-up signals
  5. ...
  6. But it is possible to separate the pulses, it's just system specific because you need to know what each separate pulse looks like first before you try to 'decompose' a piled-up signal.
The HackRf is way too slow for the performance level you are looking for.

Re: Spectrum Recorder PCI-E Card?

Posted: Tue Feb 05, 2019 11:51 am
by Harald_Consul
  1. The following picture from wikipedia aliasing article shows a sine funtion, that is undersampled:
    So, if I sampled a periodic sine function with 2 or 2.5 times its frequency (to avoid aliazing), would that also invoke, that there are enough samples (data points) to reconstruct any sine function by e.g. fourier transformation, as far the assumption of periodicity is met?
  2. If no. 1 is true, how is this reconstruction possibility then extended to non-periodic signals like scintillation amplitudes? By section-wise approximation by a sine function? If so, what mathematical method is used to this approximation? Afaik fourier transformation can only handle strictly periodic signals.
As I want to analyse the raw data in software, I have to explicitly rebuild the approximation/ interpolation logic, that may be applied by a digital scope implicitly on automatic.

Re: Spectrum Recorder PCI-E Card?

Posted: Tue Feb 05, 2019 1:19 pm
by Chris Mullins

The sampled signal doesn't have to be periodic, just bandlimited. E.g. see here: ... vp/id/3628. The reconstruction is the same, using the sinc function like Rich already mentioned. Try searching on "reconstruction filter" to learn more about that. In practice though, reconstruction isn't usually done if there is further signal processing or detection to be done. Since it doesn't add any signal information (in an information theory sense), it's often the case that an algorithm optimal in some sense gives the same result either way.

Deconvolution is one technique to undo the low pass filtering/pulse stretching of the PMT amp. In communications theory terms, the frequency response of the pre-amp/amp is the "channel", the original narrow pulse (that you can't measure directly) is the signal. You create an "inverse filter" to undo the frequency response of the "channel", thus restoring the original narrow pulse. This would turn the stacked pulse into non-overlapping very narrow pulses. There's a whole body of signal processing around this technique, including tracking a time-varying channel. Try searching on "inverse filter" or "channel estimation" to learn more.

There are also techniques for when you don't know the channel - try searching on "blind deconvolution" or "deblurring" (although these are often 2D algorithms, they can also be done with 1D signals). In your case, the "channel" doesn't change with time (it's "stationary"), and should be easy to characterize, since it's mostly the effects of the amp itself. In fact, if the original pulse is narrow enough, the PMT amp output is the "impulse response" of the channel, and the opposite of that is the inverse filter.

If your scope can sample at 1Gs/s with a 48K depth, that could be enough to get started. If it can capture and transfer say 200 of those per second to the PC, that's about 1% of realtime. Since the pulses are mostly independent, just wait longer to capture more data, and splice the captures together.

Re: Spectrum Recorder PCI-E Card?

Posted: Wed Feb 06, 2019 6:46 pm
by Harald_Consul
Thanks for your insights into physics topics. I do not doubt, I am maybe sometimes like a little child in these physics things, as I am a statistician (not a physcists).

However, on the other side it may also be interesting for you physicists how a statistician is planning to deal with the piled up amplitude problem by software programming in R. As most of you do not understand R code, I will write pseudocode, instead.

Code: Select all

# Assuming the voltage data from a data acqusistion card would a csv data file, which has a voltage figure on every line.
import.csv("mdata_00.csv" as mdata_00)
columns(mdata_00)= c("ln", "volt")

# (Non-noise) signal is greater than 0.1 V
mdata_01= data.frame(mdata_00, signal= (mdata_00$volt>= 0.1))
mdata_01= data.frame(mdata_01, voltmax= roll.max(madata_01$volt, 30))
mdata_01= data.frame(mdata_01, ampbegin= rep(NA, nrow(mdata_01), ampend= rep(NA, nrow(mdata_01))
mdata_01$ampbegin= (madata_01$signal== TRUE & mdata_01$signal.predecessor== FALSE)
mdata_01$ampend= (madata_01$signal== TRUE & mdata_01$signal.succesor== FALSE)

mdata02= select(mdata_01 where mdata_0$sinal==TRUE)
mdata02$ampno=rep(NA, nrow(mdata_02)) 
j= 1
for i in (nrow(mdata02) {
	mdata02$ampno(i)= j 	 
	If mdata_01$ampbegin(i)== T {
		j += 1

# Transposing the amplitudes into rows
ampdata_01= transpose(mdata02, by= ampno)
ampdata_01$rowlength = ...

# Assuming a gaussian bell curve for singular amplitudes and testing it for gaussian distribution
ntest_results= apply(test.gaussian(ampdata_01, distrution="normal", alpha= 0.05), by=row)
ntest_results$ampno= ...

# "SQL"-Joining the results back
ampdata_02= merge(ampdata_01, ntest_results, by.x= "ampno", by.y= "ampno")

# Calculating the numerical volt integral of the amplitudes

# Creating classes of volt integral
ampdata_02$voltintclass= class(ampdata_02$voltint, step= 0.1)

# Aggregating the sum of volt integral by ntestresult
intvoltdata_01= aggregate(ampdata_02$voltint, by= c("ntestresult", voltintclass")

# Assuming that piled amplitudes contain singular amplitudes in the same proportion as singular amplitudes occur 
# Multiplying the singular amplitudes counts so that the integral voltage of multiple amplitudes gets compensated 

As you (hopefully) can imagine now, counting piled up amplitudes correctly by using the statistics software R neither requires a genius nor requires self developing a new mathematical method. Instead simply one of the thousands of R packages is used to apply a widely universal statistical method on the data.

And I thought, as most small particles in physics are best described by a distribution, physics would also always do the same numerical programming (or similar in Matlab, SAS, Pyhton, ...).

But, concluding from your answers, this does not seem to be the case.

[/Your insight to statistical working]

Re: Spectrum Recorder PCI-E Card?

Posted: Thu Feb 07, 2019 3:48 am
by Chris Mullins

To be clear, my suggestions (and background) are centered around the digital signal processing and sampling ideas, not the underlying radiation/detector physics, or real-world PMT counter applications - I don't have much experience in that. Others have given good advice there.

Re: Spectrum Recorder PCI-E Card?

Posted: Fri Feb 08, 2019 4:05 pm
by Harald_Consul
After in depth study of Chris answers there is only one thing left:

Saying thank you to Chris for his imho high quality answer and to all the others, who mentioned a lot of major ideas before.

Re: Spectrum Recorder PCI-E Card?

Posted: Sat Feb 09, 2019 10:29 am
by Harald_Consul
Just one final remark from my side. I've figured out, that my Hantek digi-scope effectively is a Linux computer. Thus, may be it is - on a maker basis - possible to construct an inexpensive "very high frequency recorder" by porting the Hantek Linux scope solution to a more potent mainboard with a PCIe or M2 slot, so that the data record stream will be stored directly on a NVMe SSD (with currently about 8 GByte/s transfer performance). By that, the original e.g. 48K sample storage depth of a digi scope would be extended to the gigasample range.

However, the necessary amount of work is pretty much out of my scope.