Debugging the electron detector

[SteveF161]

Another noob question: Is there a guide [...idiot level, of course...] to debugging construction problems? I have a board that's built and where every joint and connection appears to be correct, and where all have been continuity tested with a multi-meter to different parts of the PCB (i.e. not just checking across the component but from wherever the component connects to next). The detector shows a nice pulse when switched on and off in the web oscilloscope, but gets no pulses from ~ 10g of KCl. Is there a recommended set of steps for tracking down problems? Does the web oscilloscope software need any specific adjustment?

Steve

[ozel]

Hi Steve,

there is a troubleshooting list in the wiki: https://github.com/ozel/DIY_particle_detector/wiki/Assembly-Instructions#troubleshooting

Seeing a signal when switching the battery is already very good!

If it is really just 10 grams, it should be right on top of the diodes inside a small plastic bag. If you have more, like a full 100g salt dispenser wrapped in its original paper/carton you could put it as well outside, on top of the detector case (unless the diodes are then very far away inside the case, like further than one or two centimeters from the outside). 10 grams of KCl will result only in about 1.3 pulses per minute per covered diode. You've built the electron detector with four diodes, right? In this case, you should observe about 5 pulses per minute maximum, it may still require some patients to wait for them. :-)

With my web oscilloscope (https://ozel.github.io/DIY_particle_detector/data_recording_software/webGui/) one usually has to adjust the red line trigger level and put it much closer to or further away from the noise level in order to capture pulses (signal range depends a lot on the smartphone/laptop hardware). Use the two up/down arrow buttons to adjust the red line threshold level. You could also have inverted signals (i.e. detector pulses going up than downwards) in this case you have to move the red trigger line above the noise levels. You can fix that by swapping the ground and signal connection on the 3-pin or 4-pin jack connector. Btw, double-check that you have soldered those connections correctly as explained here: https://github.com/ozel/DIY_particle_detector/wiki/Cables#connection-with-a-headset-socket

If you still see no pulses, it could be too much light reaching inside the case and onto the diodes. Throw a black pullover/shirt on top of the detector case and try using it in a dimmer room. If this helps, you just have to find and patch some tiny slits and holes of the case with black tape. The last resort would be to measure your output signals with a real oscilloscope and compare the noise voltage levels with the screenshots of mine (in the main readme). But usually, problems can be identified without that.

Don't hesitate to post pictures of both board sides and your headset connector wiring. The latter is always a kind of paint point to get right.

[SteveF161]

A brief update before I spend a few days off-line: I upped the amount of KCl to about 25g and put it on top of a stand to raise it closer to the detector diodes. However, I stopped seeing the on/off pulses when the detector was switched on and off. I checked and rechecked everything but couldn't find an obvious fault. Today, I was tinkering with Windows 10 microphone settings and took the blindingly obvious [...to other people...] step of monitoring the microphone socket of the detector via the headphones. Now, suddenly, I'm hearing white noise and soft clicks every 10-15 seconds when the detector is switched on! The web oscilloscope (DIY pulse detector) started showing the white noise but very few clicks. (These seem to be only a little above the noise level, and the pulse detector only seems to detect even the white noise about 10% of the time.) My thoughts now are that this is partly a software problem, which I might tackle by rebuilding an old laptop under Ubuntu, or that there's stray light causing excess noise and I can fix that with some black tape upon my return.

[ozel]

Check that the battery has still enough power! If the voltage drops below 8V (measured across the disconnected battery), it is rather empty. It might deliver enough current for a few seconds if you give it some rest, but it will turn into an unreliable power source if it is drained too much. If the detector was on for about 2 days, it's probably drained. I recommend buying cheap 9V accumulators & chargers: https://github.com/ozel/DIY_particle_detector/wiki/Batteries

The many microphone input settings of headset sockets can be a tricky problem to get right. On Mac/iPhone/iPad the headset connector switches only to "external microphone" mode if the detector is already powered before plugging it! And there is no way to do the switch manually, it is detected only automatically on Apple hardware. It also works with the lightning-to-headset adapter, by the way (if the detector is powered before plugging it in).

There could be some similar automatic detection going on with certain Windows machines, depending on the hardware. Another problem is that some PC headset inputs are really flexible and can also function as a regular stereo or mono microphone input. A 3-pin connector and different wiring would be needed, if the socket is in that microphone mode, see: https://github.com/ozel/DIY_particle_detector/wiki/Cables#audio-jack-connector-overview-35-mm-trstrrs)

If you want to be 100% sure that the correct headset mode is recognized and selected within the web oscilloscope, please plug a regular headset and whistle/hum into the microphone. You can also experiment with the red trigger level line ob the web scope app that way and see how the triggering work works (frozen image everytime the signal goes below the line). You did not mention if you adjusted the trigger level in the web oscilloscope app. The red line needs to move as you push the up/down on-screen buttons. It should be as close as possible below the noise levels, but not too close to them. Unless your pulses got upwards because of twisted signal and ground wiring. In that case, the trigger line would need to be close above the noise levels. The microphone input level in the Windows audio mixer settings should be usually set as high as possible. There may be a switch for some extra gain, sometimes that is helpful, sometimes it adds too much noise in relation to the signal.

In principle, it is possible to hear the pulses as very short glitches, depending on audio settings. But I would not check for them that way before you have seen them on an oscilloscope plot. As described in the troubleshooting list, try snipping your detector case hard & briefly with a finger. If you can't excite short sine-like waves that way, something is still wrong on the soldering side. My main guess right now is that your trouble is related to setting the trigger level correctly (in the app, not inside windows).

Also consider testing it on a smartphone or tablet with Firefox or Chrome (Safari on iOS). If the OS is recent enough, it should be able to access the headset socket's microphone input. Remember to always power the detector on before plugging it in. If you switch it off to check for that power-off pulse, please unplug and re-power before plugging it in again. A browser reload would be also good after replugging it.

If all of this doesn't get you anywhere, consider trying another microphone/audio input. Like the cheap CM108 USB soundcards. They are 1-2$ on Aliexpress, and a bit more on Ebay: https://github.com/ozel/DIY_particle_detector/wiki/Soundcards You'll just need to make another 3-pin TRS jack cable for those instead of the 4-pin TRRS one for headset sockets.

[SteveF161]

After spending a day or two visiting family, I rebuilt an old laptop (Asus Eeepc 901, vintage 2010, Intel Atom processor, 2GB RAM, 32GB SSD) to run Lubuntu and connected the detector to its mic input, As expected, there is a lot of electronic noise but I do see the up/down pulses from the detector and you can fairly easily distinguish them from the false pulses caused by noise peaks. Conclusion: it's working! Thanks for help and suggestions. My son and I will probably blog this later, complete with construction photos and screenshots.

[ozel]

awesome! please post the blog link once done :-) The noise is expected as the circuit got only a few thousands of charges to work with for each particle. An external USB soundcard might improve it, but usually not by much. It can be worth trying different gain settings, I've had the best results at maximum gain but anything that looks like noise-canceling disabled (see the wiki page on Soundcards).

[SteveF161]

I've blogged it here: https://clanhouse.com/cern-at-home-building-a-particle-detector

[ozel]

Since you're using the website scope that shows the signals rather zoomed out (optimized for alpha pulses): you may have a better experience with the WaveWatch processing sketch, as it allows zooming into the pulses. Copied from the main readme (as I need to put this more prominently): To run this program written in Processing, download Version 3 from www.processing.org and install the missing ‘Minim’ library via the ‘Sketch’ menu / ‘Import Library...’ / ‘Add Library...’. Download my version of the WaveWatch Processing sketch from https://github.com/ozel/WaveWatch/archive/master.zip, unzip and open the file WaveWatch-master/WaveWatch/WaveWatch.pde in Processing.

If you want to explore some "learning to program" aspects with your son (for which Processing is perfect...), I've uploaded a very simplified oscilloscope sketch here: simple_audio_scope_for_Processing.zip

It allows setting a trigger level and count particles. Some summer students developed this with me a while back. It could be relatively easily extended to calculate a count rate per minute or per 10 minutes etc. The WaveWatch sketch got better trigger and zooming functionality, of course. But it's more complicated to understand and work with its code directly for making extensions. Processing is multi-platform, by the way. Should work well on Lubuntu. Only the selection of the sound device can be annoying. :-)