Fusor Forums

Here is an interesting link on hearing radiation: http://youtu.be/Eas4p8Sob9E You might want to skip out to 9 or 10 minutes to cut to the chase.

More accurately, it is converting a pulse height over to an audible frequency. After that they round the frequency of the note up or down to so that it is a discrete note.

Interesting sounds that accompany various radioactive materials. I think the technique could be refined better to give a good way to listen to various sources of radiation. A pure source should give a single tone for each of its peak energies. Neutrons would scream out of the audio with their high energies. It would certainly give a researcher far more information than just hearing audio clicks and rate.

Frank Sanns

That's very cute, in part because it sounds surprisingly good.

I'd love to take this idea to the Explora Museum here in Albuquerque where I run some little hands-on activities relating to physics on occasion.

I think I can modify my LabVIEW MCA program to do this almost trivially, but the question really comes down to making it sound good--tone persistence, timbre, and temperament, and how pulse height is converted to an audible frequency (linear, logarithmic, etc.) Thanks for posting this very endearing idea.

-Carl

Frank,

Very cool, thanks for posting, that brings a new meaning to sound card spectrometry.

Steven

Good effort, worth evolving from there, I think: I'd throw my own suggestions at this. I'd point out that, frankly, one sound sounds much as another. OK, sure there are a few more high notes in response to one source than the other, but similar.

So what could be done is instead of fixing the note frequencies according to a given key, the computer could do a 'best fit' of the incoming signals that most closely match a musical key. Then, the key would, I suspect, likely change with different sources and that would really bring out some 'colour' between different sources.

The next thing would then be for the computer to be 'told' (programming-wise) to recognise maybe 3 or 4 different 'keys' within the signals, and then to give a proportionate amount of time to each, effectively filtering different 'harmonic sets' in the signal energies. So, for a given time ('bars') it'd play those that come within some correlation to one key, then change to another. That would then give a change of tempo too, as the computer selected between different harmonic sets within the data because the populations of signals matching each key will no doubt be different. Bringing different isotopes together (that stimulate different keys) would then have the audible effect of changing key and tempo every so often as the computer plays the different combinations.

Also, as well as discretising the frequency space into different notes of a key, the computer could also provide some temporal discretisation and match the note outputs to particular timing positions. This would then increase the probability of chords being struck. Another way would be to 'compile' a certain number of notes, randomly between 1 and 10 in number (according to a randomising algorithm), then play those notes altogether once the due number of notes have been received. This will give a mix of single notes and simple, or more complex, chords per music normally played.

Rather than single notes to single signals, there could also be a time-delay so that when the same note is struck repeatedly within a time-frame it is played as a continuous note.

I like the 'bumbling' bass effect of the low energy background that adds a colour and atmosphere to the lower end of the register. Maybe it doesn't need to be temporally discretised below some frequency.

... just a few thoughts for development, if anyone has the programming skills (that I don't!!) ....

Might get some tips on sounding good and sounding bad from here:

"Why Dissonant Music Sounds 'Wrong'"
http://entertainment.slashdot.org/story ... unds-wrong

Very nice.

The OP reminded me of a different photon-to-acoustic spectral converter, seen via the Internet a year or two ago. But more than an hour of obsessive searching failed to turn it up last night.

It made audible tones out of chemical elements's -optical- spectra, from their -electron- energy transitions. Maybe someone else here has seen it, or one like it.

For each user-selected element, we got a nicely rendered picture showing the discrete energy levels. Then after simulated excitation events (random or user-directed, I don't recall), we would hear beeps or bell tones as electrons dropped back to lower energy states. The acoustic frequency went up with the energy step size, as would the optical frequency in real life.

I guess one could bend the pitches to fit a musical key (whose well-tempered scale closely approximates true harmony). Or let the Lyman and Balmer series, etc., form their own key!
Isaac Newton, after discovering that white light is a "mixture of rays with different refrangibility", deliberately chose as many color names as there are musical pitches in an octave.

Again: does anyone here know where to find a tool to "audible-ize" atomic emission spectra?
Thanks
Rich

I would imagine that a lookup table would be the easiest solution. When a pulse height is between a given range, a particular tone is called out of an array and that tone sent to the sound card for a predetermined duration. Don't know if you are programing in Visual Basic or C+++ but back in the day I did this for inputs from a solar cell and from random sources quite trivially using the above method. Actual notes are the best and it does not take many to get the effect. Ideally, I could imagine something like Audacity being used to slew tones to what you want or to even put different sounds to different energies like a gong sound when the energy is above the top thresholds. An alternative to this is to make up short mp3 files of very short duration and of the tone that you would like then call them up out of an array. There are short sound clips for free of just about anything you want or use one of the free music programs to make them like Garage Band even. A bit of work up front but I can imagine the final product being much better than the chaps in the video that I posted. Let me know if I can help in any way.

Frank Sanns

Wow that's cool, well spotted frank.

I was musing the other day how an electric or acoustic guitar would sound played by Alpha particles if it was set up as a spark detector after looking at some of Carl's work.

http://www.youtube.com/watch?v=HO8VDf_rCXo

Not as complicated but Jeff from Mighty Ohm setup something like this for the Maker Faire with his geiger detector kit.
http://mightyohm.com/blog/2012/05/pics- ... ker-faire/

I wrote a little LabVIEW VI that emulates this demonstration with a 2x2" NaI detector.

I'm not a very good programmer, even for labVIEW; It was more of a challenge than I thought, and it still needs a LOT of work if it's going to be any good, but I will share a little video later today. I'll also send the VI to anyone who wants it, but it is specific to the Canberra 556 MCA and requires EPICS running under Cygwin or Linux.

My program's basic philosophy is outlined under the dashed line below. I fiddled with several approaches, and this one is the winner so far, running on my little Windows 98 netbook. At first, I thought I could collect spectra with a single count in them and search the spectrum array for the first instance of a 1 to get channel number and directly turn that into audio output, but even in a shielded 2x2" the background counts come in too fast to make that practical. So I collect short spectra and then pick out the channel with maximum counts to derive an audio signal. Cs-137 sources give a nice monotonous train of beeps, most at the same pitch, and Co-60 gives a warbling, lively high-pitched sound. The big problem seems to be audio buffer underflow that causes some outputs to echo and click at times, and the irony is that it is occasioned by the long time it takes to write to the buffer in LabVIEW's function for that purpose. The time needed to complete the main loop in the program is dominated not by spectrum acquisition, communication with the MCA, or math operations, but by the sound output write operation. I'm trying to better understand that and fix it.

Some future directions:
-Playing sound samples rather than waveform synthesis may be much faster and open the door to more complicated tonalities
-Gathering timed spectra rather than total-counts-based spectra would allow V(0) in step 9 below to be scaled by the sum of the spectrum ROI, so that high count rates would correspond to louder tones.
-Adjustment of timbre with pitch to accentuate high-energy events and help distinguish them from Compton continua. Above certain pitches, second, third, fourth and fifth harmonics can be mixed to brighten the tone and make a reedier, more penetrating sound.
-It would be nice to re-bin the spectra such that the FWHM resolution of the detector as a function of energy would correspond to about one or two semitones regardless of energy. Of course, to make it sound good, the frequency difference between semitones may have to be adjusted away from 12-tone equal temperament.

Any other ideas?

-Carl

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

(1) Configure MCA to accumulate X counts in the ROI between channels L and H, then stop. (A good value of X for a 2x2" NaI crystal and 512 channels of memory / 3 MeV seems to be about 15 counts; L = 20, H = 511).

(2) Configure and start a continuous audio task and pre-fill the sound output buffer with an all-zero array.

(3) Start MCA acquiring.

(4) Poll MCA for status. If done acquiring, go to (5). Otherwise, repeat.

(5) Get MCA spectrum.

(6) Search spectrum array for max value and return the index (channel number).

(7) Convert index to a musical note relative to a reference note. E.g., semitone number S corresponds to index N by S = round[(R/A)*N], where A is the channel number selected to play at reference semitone R. On a 512-channel / 3 MeV spectrum, A = 150 and R = 49 (key A4) sounds decent. I have not played with a non-linear relationship between note and channel number.

(8) Convert note to frequency on a 12-tone equal-tempered scale, i.e. f = F*2^((S-R)/12) where F is the reference pitch for key R. Concert pitch F = 440 Hz @ R = 49.

(9) Calculate an audio waveform with a damped envelope. V(t) = V(0)*exp(-q*t)*sin(2*pi*f*t).

(10) Sample V(t) and write sample array to the sound output buffer to be played.

(11) Return to (3).

Looks good Carl but you are going way farther into it than I think necessary for the first step. I was just imagining taking the mv signal alone and translating it to a tone. Same idea that you are using but without the MCA step. More mv of signal giving higher tone while below the noise threshold giving no tone.

While calculations on the fly are good, doing them beforehand and storing the result in arrays makes for a quicker program. Populating an array with the results of the calculation before the start of the loop program takes care of that.

I will think on it some more.

Frank Sanns

Nice one Carl. Well done.

On further ideas.

I would be looking at decoupling the Radiation and Sound making. Sounds like you are falling over the fact it is perhaps monophonic and perhaps need polyphony. But without seeing details could'nt be sure.

An alternative is to capture pulses rather than spectra and re process their essential information into a MIDI stream.

The MIDI can be saved to a file or piped to MIDI software, ie a midi player.

MIDI players will give you a range of instruments (Voices) notes etc. You can run up a full band or orchestra if you like real easy. Hell you could even play along if you had a MIDI instrument (Keyboard).

The key to it is your midi stream, which comprises channels (one per voice) and information about notes ie pitch duration etc etc.

Using this method you can use mutiple sources and or divide up energy ranges into multiple voices to map across to your chosen instrument ensemble.

The clever bit in this is mapping Pulses and Sources to MIDI channels and information, it sounds (Pun intended) like you are already well along that road. With MIDI the sound part is already done for you and gives pretty good polyphony. In the MIDI software you choose which instruments are played by which channels (Even a full drum kit, geiger that)

Plus your Rad to MIDI software will not be waiting on the sound production.

Thoughts for what they are worth.

BTW once upon a time when sound cards were optional add in's many came with freebie MIDI software.

Video will be here, once it is done uploading (another two hours, assuming no technical glitches): http://youtu.be/j4lGMW1hk4U

Andy, I think you have a good suggestion about decoupling the acquisition / spectrum processing loop and the audio signal generation and playback loop. Ideally, the nuclear module would write a simple file with timestamp and note value, and the audio generator would read this at its own pace.

I should point out that I have no good, obvious way with my MCA hardware and the EPICS software to get single-count data on the fly. I can indeed command the MCA to acquire until it has one pulse in the ROI, but in practice, it always picks up more than one at high count rates.

Frank, the sound card in-and-out approach you suggest would look at single pulses as they arrive. Unfortunately, I don't know the tricks that are behind software like PRA and Theremino, and while the techniques for signal processing used there could probably be figured out or perhaps even pillaged wholesale if the source code is available, I think that's beyond my league (and the time I have to give this idea). I may play around some more in LabVIEW and see what I can accomplish in the way of pulse-height analysis from the soundcard there (but my hopes are not high).

Again, this is a very cool concept with some real neat applications in entertainment, pedagogy, and maybe the "real world" of radiation detection.

-Carl

Carl,

You may recall we also have a blind member of this forum, and I know he was experimenting with spectrometry, I imagine a gamma spectrum could be represented audibly as a scale of notes with varying volume representing the peak heights.

Steven

Hello All and thanks for remembering Steven.
I have gotten rather sidetracked the past couple of months. I joined the local ham club to get help with soldering and building rad science related circuits. Well, the urged me to get my license last April, then set me up with a Kenwood TS-450s tranceiver and inverted V dipole on 20 metres. That was seven weeks ... or was it eight weeks? ago. I'm still trying to find a balance and get back to rad science. I purchased two RAP-47 probes from George Dowell. Still haven't attempted hooking one up to power and my computer. Joe Jarski, Doug Coulter's partner, built me a filtered variable HV supply so I've no excuse in that department.

I'm a bit hesitant when you talk about anything musical. Haven't a tin ear, but don't do to well with audio adaptations designed for the blind by well-meaning folks.

Mostly, what I hope for is a way of sorting text numeric data in a program like Excel, which I can use, so that I can find energy peaks. One of the GCE forum members wrote me a very nice "tactile" description of gamma spectrometry using marbles as photons, accumulating in vertical grooves cut into a board, energy from left to right along the base (x-axis). But I am still somewhat in the dark as to how the computer, using say PRA, can sort out the different energy pulses, and of course, most of this stuff is displayed as a graph. Some posts have gamma spectra as a list of numbers, for which I also need interpretation. The whole matter is somewhat intimidating.

Though this is only indirectly related to neutron production in a fusor, and even if I can't do much, I'm interested in getting a scintillation probe working as I've learned they make very sensitive general purpose detectors. Since reading Carl's post/article about making a long PMT probe with 8 cube crystals (BFI? forget the crystal type, just not NaI or plastic)for hunting uranium, I've wanted one something like that for rockhounding.

Still waiting on my physicist friend in Vancouver to drop over for a visit with a vacuum system he promised me back this spring. Who knows, he may have gotten sidetracked building his own fusor.
Regards, Brian
.

is

Hello Fran and Carl,
This business of hearing converted gamma radiation energies is facinating. I would hope some genius might eventually create a module that I could plug in one of my CsI probes, with a power supply and hook it to a computer, run software and hear what the Swedes and Carl have produced. Very useful for blind amateurs, and just plain fun physics.
Great preliminary work Carl. Can it be simplified?
Best.

Hi Again Frank,
I like the thought you expressed. It appeals to me from a 'hearing only' perspective. What kind of circuitry would be required? Who could design and build it? And, then there's the software problem... Carl's assembly uses some of the nuclear physics modules he already has in house. I've only got a CsI(Tl) probe, the RAP-47, a filtered variable HV supply and computer running Windows XP, or a lap-top running Vista.
I've listened to the Swedish "radiation music" video, and to Carl's video, and both have me real interested. I'd love to have a system that allowed me to listen to gamma spectra this way. Course, I eventually want to be able to pull gamma spectra numbers into Excel in Windows XP, and know what I'm listening to, and be able to identify isotopes.
.
Regards, Brian, VA7BDG
(Also a Geiger Counter Enthusiasts member)

Hi Brian,

I'd like to simplify this concept, sure. My skills are poorly matched to the job of making a lean and efficient program that can use a computer sound system in the way it needs to be used in this application, but maybe someone like Marek Dolleiser can roll a similar functionality into his C++ code for PRA.

-Carl

I am feeling my age right now as I could to this with not much effort in Fortran or Basic but those are dinosaurs today. Have not done anything in C++ but maybe I will try to get some proficiency in it. It is all about syntax. What is one more language, computer or spoken.

Frank Sanns

I may not know radiation measurement but I DO know C++ - it's my day job. I'm happy to lend a hand if you need it. Even if it's just looking at one of those silly edge-case bugs that causes you pull your hair out.

Hey Pascal,

Last night I gave myself a crash course in C++. I think I have it figured out how to sense when a signal is coming in then finding its maximum amplitude and integrating the area under the curve for a fixed (or user input) period of time based on the detector. What I am not sure about is how to get the data in. I see some pre written programs to scan for USB ports but this is all new to me and I am not sure if it is better to get the data from a DAQ or from input from a soundcard as Steven's Gamma Spec unit does. Any thoughts on the front end of this? Thanks.

Frank Sanns

Pascal Dennerly wrote:
> I may not know radiation measurement but I DO know C++ - it's my day job. I'm happy to lend a hand if you need it. Even if it's just looking at one of those silly edge-case bugs that causes you pull your hair out.

> What I am not sure about is how to get the data in. I see some pre written programs to scan for USB ports but this is all new to me and I am not sure if it is better to get the data from a DAQ or from input from a soundcard as Steven's Gamma Spec unit does. Any thoughts on the front end of this?
DAQ will go down to DC, few unmodified sound cards will.

I'd have to look up the input impedance of a sound card input.
For the DAQ it depends on the model. Some of the older ones were quite low in the 50k range.
Some of the low cost current ones are in the 2M range, with the higher end ones approaching 10M getting on par with your typical volt meter.

So it comes down to what is your source impedance and your source frequency range as to picking one.

As to USB scanning is usually unnecessary, and sometimes a bad idea, as you can locate the device by the USB ID in the registry. The exact method varies a bit with the USB device type. This program is helpful for figuring out such things: http://www.nirsoft.net/utils/usb_devices_view.html

If I knew exactly what hardware you had and what software you are using for development I might be able to give better advice. I do this stuff for the Day Job.

I'll be down in your area Mid-December, maybe we can get together then?

Hi Bob,

Thanks. If the program were just for me, I would not need to scan to find the USB ID and I could get it on my own but I am trying to make a generic program that could be run by others. That is also the reason I was looking at either sound card input or a DAQ type device. Guess either way a preamp or a DAQ would need to be purchased.

Let me know when you will be down this way and we can talk and I can run a fusor experiment when you are down. I do have one trip coming up but it is short and hopefully will not interfere.

Frank Sanns

> Thanks. If the program were just for me, I would not need to scan to find the USB ID and I could get it on my own but I am trying to make a generic program that could be run by others. That is also the reason I was looking at either sound card input or a DAQ type device. Guess either way a preamp or a DAQ would need to be purchased.
Okay. If anyone has an interest in external USB based sound card the SignalLink,
is popular with the Hams. Both the input and output are transformer isolated to avoid ground loops.

http://nuwen.net/mingw.html is a good development library for Windows, and the code can be made cross platform. Take a look at the SDL library http://wiki.libsdl.org/moin.cgi/CategoryAudio and the Audacity Source Code http://audacity.sourceforge.net/download/source for items that should help you out with the audio related items.

> Let me know when you will be down this way and we can talk

I'll send you an email with the details.

Frank,

I response to the Swedish team, marek Dolleiser has released PRA version 7, with sound output feature.

Pretty cool for the first 30 seconds, fortunately you can just hit the space bar to turn it off.

http://www.physics.usyd.edu.au/~marek/pra/index.html

Steven