Miniature GM detector, part I

First thing first. I tested the GM tubes from yesterday, and the results are more or less as expected. The huge tube, SI-22G, is really sensitive to the background, and it was nice to have it sitting on my desk and clicking. The STS-5, that one in the middle, was more or less on par with the SBM-20 I am using for my detector. The tiny one, SBM-21 does not seem to care about background much. I did not have any active source at hand, but I believe the results will be different when actually measuring something hot. The tiny tube is simply too small, compared to the monstrous SI-22G, and the chances that a particle will hit such a small target are simply... small.

I started to work on the miniature version of the GM detector, and I cloned the HV supply from my very first design, using the same parts, and duplicating the capacitors to achieve similar 

capacity as the original design (original caps are 18nF, these small blue ones are 10nF only). The results are positive - without load, the HV supply draws less than 0.5mA from 9V battery, and 0.25mA from 4.2LiPol 18650 accumulator. I am not sure what was the trick, though. The basic schematic comes from the Geiger Counter Circuits, the second circuit. Picture above is the component side, the picture on the left is the bottom side. I used SMD parts for pretty much all I could. Transistors are SMBT3904, 3906 and SMBTA42. I believe the transistor selection is vital, the SMBT39xx have relatively high hfe. Inductor uses cca 100-200 turns on ferrite core (hand wound). I don't remember what is exact inductivity, but it was pretty high when I measured it before, around or over 50mH. My impression is that bigger is better here. The ferrite core bears marks "SEM TM12". It's either coming from Pollin (part of the mixed inductor sale), or from local shop. Pollin is more likely.

The power supply seems to be relatively 'hard' - measuring the voltage with common 10MOhm multimeter shows 270V, while my previous constructions usually did not get over 150V. I still did not add the GM tube and clicker, that's left for tomorrow, or more likely after my vacation.

GitHub! (and fixing yet another old LCD)

Let me start with a picture today again. I swear I am not making it up!
This morning, my wife attempted to start her PC, and after a while, she said "Well, I don't want to sound stupid - but my monitor died." Let me remember that few days ago, I fixed two old FSC P19-2 LCD monitors. My wife uses the third one - and obviously, its time has come. I quickly swapped my wife's monitor for the one I fixed already, and went to work.
After arriving hope, I opened the monitor and discovered another failed Capxon, this time 100uF/25V. The top was bulged slightly, but as you can see on the picture, it was pretty much done. Luckily, I found some Samxon KM capacitors that seem to do the trick for the moment, and I already ordered some Rubycon and Panasonic ones.

The second picture shows the GM tubes that arrived from Bulgary recently. The middle one is STS-5, an equivalent of SBM-20. That lovely little tube is SBM-21 I want to use for pocket GM I could carry with me on vacation to Krkonose. The big one is SI-22G to be used for background measurement.
Last thing, the one that took me most of my evening and annoyed and frustrated me almost to death. As you might know, Google will shut down Google Code and suggests to migrate to GitHub. I am not going to rant here about Git - I just don't like it, I find it confusing and overly complicated for my purposes, and I am worried I'll hit the wall using it. But... well, that's the way it is. I had to manually import my Google Code repositories, as the default import didn't work the way I needed, and I already managed to mess the repository by a single click to such a degree I almost needed to import it from Google code again... I'll give it a try and see if I shall stay with it, or find another SVN service. Anyway, a hint for all who need to use Git - don't waste your time, and go and get TortoiseGit. It makes the whole process of using Git a bit less painful.

Fixing old LCD monitors - Fujitsu Siemens P19-2

I realized I'll need a secondary LCD monitor for my vacation. I had two FSC P19-2 LCD monitors in my basement, as I was planning on fixing them one day, and the day arrived :) Those monitors were really a high end ones when I bought them (okay, high end consumer ones), sporting PVA panel and pretty good speed and size. They're 1280x1024, 19 inches.
The first one did not start properly, and if it did start, it switched off itself soon again. It dies last year, so I still remembered what was wrong with it. The second one was sitting in the basement for a bit longer, and I just barely recall the backlight died, although I am not completely sure. Anyway, after watching Dave Jones' video on fixing the LCD monitors, I felt confident I'll be able to fix at least one.
Opening it isn't that difficult. A nice guide is on Diit, however after figuring out that the two important screws are hidden under the white rubber plugs, it did not take more than a few minutes. Just demount the monitor stand first (four screws), then the two under the white rubber plugs, and then gently pry the back cover apart. The electronic is hidden under the metal sheet held by three screws around, two screws near the power socket, and the four hexagonal nuts (or how they are called?) of the DVI and VGA connector. Then slide the metal cover off the holders, and that's it.
The source of the problem can be easily spotted - see that green capacitor on the left side of the picture above, close to the heatsink? It's bulged - not much, but it is. More detailed picture on the left. All I needed to do is replacing it with similar, but working capacitor. I didn't have any new one at hand, thus I used an older capacitor I recovered from an old Pentium mainboard - and, well, that was all. After putting the LCD together again, it works, at least for now. The original bulged cap showed no capacity at all!
By the way - I used the same method for fixing our late satellite Topfield receiver. Again, replacing the bulged cap with an old one recovered from old mainboard was sufficient. If you happen to have some old mainboard from the era before those capacitor problems, don't throw them away, keep the caps! And the coils, and maybe some other stuff - heatsinks, PS/2 connectors, resettable fuses...
The second LCD (again, P19-2) was a mystery. It worked when I tried it today, although I am sure it didn't work before. The cap in the power supply that I expected to be bulged was okay. I replaced it just to be sure, and also replaced another, smaller cap nearby that looked bulged, but I did not have adequate low ESR replacement, so I'll order some and will fix it once for all.
That's pretty much for today - oh wait, three small things:
 - the pre-WW2 vase with uranium-oxide paint arrived today. It looks nice, and is not as hot as I expected, showing something around 2000CPM (1mR/h). However, because of bigger active areas, there's a measurably increased radioactivity even some 20cm far from the vase.
 - we had partial Sun eclipse here. I watched it for a while, and although it doesn't compare to the total eclipse I saw in 1999, it was still nice.
 - the meteo node powered by a solar cell and 1F goldcap is still up and kicking. I am using RasPi to monitor it, and despite the fact the node isn't power optimized yet, and reports every 8 seconds, it's still at 3.47V (almost midnight here). The voltage drops by 10mV every 3-4 minutes and I expect it to die at around 3-4AM. With some optimizations, I am pretty sure it can make it through the night! (an afterthought - in emergency situations like when the voltage drops to dangerous levels, what about sending the meteo packet less often?)
Last but not least - I'll rework the sensor packet definition to give bigger range of voltages. Maybe one bit flag, specifying either 10mV precision as being used by now, or something like 50mV usable for higher voltages. Actually, that would be backward compatible!

Barbie bed

I felt like doing something else today, I definitely need a break and think about further updates of the central node. I was asked to build a bed for Barbie and her friend, so here it is. The frame is made of plywood, my wife provided the fabric, and the mattress from soft foam material I found somewhere, it was originally part of keyboard packing or something like that.

I used my old good Proxxon table saw. The saw is fastened to a little plank of wood by four screws, and then the plank is fastened to the table with two clamps. To cut big pieces of plywood more or less rectangular, I made a bigger working are of plywood and some squared timber. It's not perfectly rectangular, and has other problems, but with a bit of effort, the results are at least satisfying.

The frame slides along the saw table, and helps me to make long and straight cuts. Unfortunately, this whole arrangement only allows me to cut plywood not thicker than 5-6mm, but it's still a major help.





I also made another attempt on the high voltage power supply for GM counter. The results are even worse than the previous attempt, and I am wondering why. I ordered some 9.1MOhm SMD resistors, and next attemp will use SMD transistors, the same I used for the very first supply.
Some minor changes were done to the central node code as well, but nothing major. I started to look into the available libraries for RFM12B that could be used with Due. I found one, using SPI port, but I am a bit skeptical about it - plus, of course, I have no free SPI CS pins. However, I am considering getting rid of the display, and if nothing else, I can just convert an existing library to use SW SPI.
Why removing the display? First, I am not sure how useful it will be in final product. It is pretty useful now, but the nRF24L01 modules have quite short range, and even with 250kbps, the signal doesn't make it through walls to the bathroom. To overcome this, I am considering putting the central node to more central location in the appartment, but then the display will be useless. Second, as clearing the screen takes over 100ms, it would greatly impact the response time of the RF24Network, eventually losing packets randomly, and I don't like that idea.

ENC28J60 library, GM counter - part III

Lazy evening today, but what would you expect on Monday. I spent most of the time getting the ENC28J60 library to work on Arduino Due, and I succeeded in the end. One of the problems I met was the fact that Due fed from USB cable wasnt' able to provide enough power to the network chip. That was really strange, as the USB cable was connected to a powered hub, but whatever... after using a barrel jack with 12V, the network started to work. I had to do a few minor changes in the library itself, mostly sorting out of the small incompatibilities, like replacing "sei" with "interrupts" etc. The library is available from SVN, revision 154.
I changed the code for GM counter slightly to update the CPM more frequently, basically guessing the CPM based on 5 second measurement with a running average over 30 seconds, and I changed the display from mR/h to uR/h. The natural background shown is between 5-15 uR/h, which is more or less of what I'd expect. According to web, the natural background in Munich is around 0.8mSv/a, that's 80mR/a. Year has 8766 hour, thus we should expect to measure roughly 10uR/h.

ENC28J60 library, GM counter - part II

I continued with what I was working on yesterday. First task today was to get the SW SPI library working with ENC28J60. I used the old goold Ethercard library by Jeelabs, and the porting went pretty well. I did not care to port it properly, with defines and stuff, I just wanted to verify if it works. It does, despite the fact I am using digitalWrite, and the demo properly displays the web page. I'll polish the library in upcoming days, test it on Due (I used Uno for tests today), and will put it into SVN repository.
I also finished the hardware of the GM counter. Nothing big, just small change of the hardware, and adding Arduino Pro Mini and Nokia display, plus some small changes of the HV power supply. I tried to replicate the other power supply, hoping to get the power consumption under 1mA, but no matter how I tried, it stays around 2.5mA unloaded. I don't get it, the power supply is the same, just the transistors are different, and the capacitors are actually smaller - 6.8nF instead of 18nF. Anyway, the whole thing is not supposed to be switched on for extended period of time, and Arduino and display also consume some power, so there's no need to keep it low... but still. I am really curious what causes this. I found some reasonably prices disc ceramic capacitors on eBay, and those should be smaller than the ones I am using (size-wise), which, combined with a small tube like SBM-21 could make a nice pocket geiger.
I put a very simple software into the Arduino, basically just to find out how it performs, and added basic CPM -> dose calculation based on the SBM-20 datasheet for Ra226. The hottest ore sample I have shows 4 mR/h (on the picture). I bought it as uranocircite, although I guess that there's some torbernite in the sample that's much more active, because the most active part of the sample does not fluoresce, so that's most likely not uranocircite. The reading depends on which value of the CPM -> dose I choose, there are some similar values for Cs137 and Co60, but the final number will be around those 4-5 mR/h.
I have a few ideas for the software, based on these kits. That's definitely something I want to finish next week!

ENC28J60 library, GM counter

As promised and planned, I took better look at the SW SPI modification of the ENC28J60 library. I am not sure I mentioned what library I am using, so here's the link.
Unfortunately, there are two problems:

• the library I originally got was version for regular Arduinos. It took me some time and research to find out there is a branch numbered 1.5.x that is compatible with Arduino Due and Arduino 1.5.x. In fact, I figured this just as I am writing this text. I originally only got a ZIP file what was linked from forum, and just now I realized it's a branch of the library. Anyway, I had problems to compile the thing, and in the end something went wrong and the library stopped work at all. I suspect Arduino, I was changing the versions of the library, and at one moment I had Arduino actually using a library I already deleted!
• the library seems to have a known bug that the communication hangs after a short while. This was supposedly fixed in the branch I didn't have this morning, so I had no chance to test it, and then I moved to another project.

However, my SW SPI modifications actually worked.  The problem I was facing yesterday was just a minor bug in SPI read. The SPI clock goes high, then the data from slave can be read, and then the SPI clock goes low again. After fixing this, Due communicated with network... until the library bug caused it to hang.

I was fed up with that, and moved to the GM counter project. I used slightly different HV power supply for this variant, and it wasn't a good idea. The power supply is safer, sort of, because the output voltage bleeds to zero quickly when I remove the battery. The previous power supply kept the output capacitor charged, and despite it's just something like 10nF, those 450V made a nice spark when I shorted it with a screwdriver! The new power supply drops the voltage to zero within a second or so. Another problem with this new one is the power consumption - unloaded, it draws around 5mA from 5V power supply. The old one, with some tweaking, draws less than 500uA. I am considering to change the new power supply to the old one. See this page. The very first one is the "new" one, second is the "old" one. The second is simpler and better, and given the fact I power it from 4.2 LiIon, there's no need to stick with the new design.
I also found out that when it comes to inductance, bigger is better. The guy recommends 10mH, but I am getting the best performance with an inductance so big I even cannot measure it. The second best is my home wound pot core inductor with something like 80mH. Less inductance means bigger power consumption.

I also received some small toroid cores and I tried to wind my own inductor in an attempt to make the 10mH reference one as being used by the "old" HV power supply. I found nice video about winding toroids, and tried it myself. It's a good idea, unfortunately my wire was thinner, and curled all the time. It took me a lot of time to straighten the curls every turn, and in the end some curls bent, and the wire broke after some 30-40 turns out of 100 planned turns. The enamel on the wire was pretty worn out at some spots, and I wouldn't really want to use the resulting coil in a mission critical application. However, with thicker wire, more patience and after finding a way to straighten the wire so it stays so, I can make my own inductors!

The fastest way to high inductances turned out to be a combination of pot core with plastic holder, and an electric drill. In no time, I had a pot core with few hundreds of turns.

GM counter tube test

The GM tubes from Bulgary arrived today, to my big surprise - I didn't expect them this month :) It becomes more and more obvious that the major cause of all the shipment delays is the German import duty office.
I hooked the tubes to my sparrow nest HV supply and tested them immediatelly. Both work fine, the sensitivity is much, much higher than the SI-3BG. While my hottest uranium ore barely made the SI-BG3 tick, the new tubes go crazy. The tubes are SBM-20 and SBM-20U. After I ordered them, I found out those are basically the same spec tubes, just the U variant is specified for more humid environment (or something alike).
Anyway, the analog part of the GM counter works fine. I'll replicate it in more good-looking fashion and add the digital part to it. I am still waiting for some small inductors from China, the one I am using right now is rather bulky. But so are the capacitors (the circuit uses voltage doubler, which increases the amount of capacitors to three), so maybe I will just use what I have. The whole counter draws something like 0.5mA from 5V power supply - not bad!