I think what you're getting translated as "pressure" really means voltage (or electromotive FORCE), which is pressure in the electronics<>plumbing analogy, and makes sense with what I am seeing here in testing. I find that analogy useful for teaching beginners -- current is flow, resistance is an orifice, a valve is a valve, a capacitor is a tank, and so on. Easy to model once you realize that for electricity the world is some sort of solid substance that needs holes (pipes<>wires) through it for it to flow.
A normal tube will usually act as a proportional tube up to a certain voltage, with varying pulse heights depending on the energy deposited in it, then go to a plateau mode where all the pulses are the same height, that height being more or less the difference between the voltage at the beginning of the plateau and where you are operating the thing. For example, a more "normal" tube might have the beginning of the plateau at 600v, and if you run at 700, you get 100v pulses. After the plateau region, running the voltage up further results in at first, false counts, then simple glow discharge (which wrecks the tube in short order under most conditions). Could be I didn't set the scope up sensitive enough to see the stuff in the proportional region. What was kind of a surprise is that above that threshold voltage, I got 100v pulses -- even at only two or three volts above the threshold. 320 volts seems comfortably above that threshold, but I'll check the other 8 tubes to get a good design center for that.
These tubes either don't do that, or I need to look more closely. Right around 260v, nothing comes out I can see. Just above that, you get 100 to 150v or so output pulses, all about the same height unless two are close in time, during the "dead time" when the ions from the last pulse haven't drifted off and been collected yet (possibly the function of that extra terminal is to accelerate that process) -- the geiger version of pileup. I'll put up a movie on this at some point, because it's worth knowing about, and it's enlightening to see how often it happens even with a nominal 300 or so cps rate (off a 1b22 spark gap tube that has radium in it).
Obviously, this isn't counting alphas from the Ra, but gammas, betas, etc from all the daughters of this WW II era radar spark gap tube.
So, even with a "safe" source -- this tube is already almost too sensitive! It's a little less so than the super good, expensive, really 2" ones we got from Geo, but since it's less than 1/4 the price, not bad at all. Torbermite ore need not apply at close range for this guy, nor a smoke detector source! Either will flat out saturate this (or most phototube/scintillator arrangements).
At any rate, fairly wide voltage variations don't affect much but the output pulse size, and that only a little bit, which is what makes this so nice for this job. It either counts, or it doesn't, the threshold is determined by physical construction, so there's no way to mess it up. It's obviously quite easy to get a cmos input to count with that kind of pulse size as well(!). As I said above, more a question of not frying one or the other due to CMOS clipping at the supply rails. And we get a cubic crap-ton of noise resistance, unlike millivolts out of a phototube.
////////////////////
So, what I'm working on here as a first go, is a pic based counter, with the pic used to monitor/control the power supply (takes less parts to use the stuff built into the pic, and it's more accurate anyway), one of the pic hardware counters to do the counting, and I/O initially through rs232 only. That will be the cheapest/easiest possible thing to make. If I have enough pins left over, I could add *either* a LCD display and some moderately expensive boost power supply parts, and a rotary encoder for UI on the box -- that will add maybe 50-70 bucks to the price, though, as it will also require a bigger box, bigger batteries, and so on. If I don't use up all of port B for that (and a couple other pins for the encoder) then I can use two port B pins as interrupts for things like anti-coincidence or other counters, or some A/D inputs for logging. The idea is to spit out RS-232 on the second, with accurate time-stamping, for use in a PC, in human readable (read, easy to parse for software too) form. Having already built and used our much fancier multi-geiger, this seems like a good way to go, and if all you have is a laptop or something, there are USB dongles for serial around pretty cheap. Since everyone here, by definition has a computer, and most of us don't have a ton of spare change, that seems reasonable.
I will use the PIC 18lf2325 chip (they're cheap) as a 28 p through hole, a MAX-232 for rs-232, a watch crystal for accurate timing, a few bypass caps, and very little else but a box and power switch. Plan A is to use 3 alkaline AA cells to power this, as it's just a little more power needed than we can suck out of the RS-232 control signals from a PC (which of course also takes software on the PC to make sure they're on and in the right state). I will use my standard 9 pin female connector for a straight (not null modem) cable or direct plug to the back of the PC, with my usual wiring of things like data set ready<>data terminal ready and CTS<>RTS so no matter the PC software, it will just work -- we are ready if you are.
The point is, doing it this way means anyone can simply buy the parts and kludge one up, wirewrap if they want to -- no need to buy it from me, and then program the software into the pic, which I'll post up here free as source and binary. I'll probably skip the fancy RJ-11-6 onboard programming connector, and go with stakes (far cheaper) for that, or nothing and just use a board with that connector here to program them.
I am trying to keep the total cost under $200 here and still have something that does this one job quite well -- EG, our cheaper TCO version of a BTI detector (these should last a good bit longer than BTI's do). Other designs can be made off this basic thing (and have already, and the software for one is already posted on this board for a fancy model), but that's too expensive for what I have in mind here - a more or less universal way to compare results from fusion runs -- even share moment by moment data as simply as having hyperterminal (windows) or GTKterm (linux) or ??? (apple) save a file to upload so we can all see it and make any interpolation or extrapolation ourselves. In the case of silver, it's crucial to time the interval between fusor-off and sample measure start, for example, and this gives you that since just about any fusion device will make this count pretty fast during the run. I have to put my current tube behind a 2" thick lead block, some lead sheet, lead glass, and the lead on the tank walls with the actual grid about 2 feet away to get the count rate down to about triple background for example. Without that stuff, it will saturate hard -- just removing the 2" lead brick pushes this up to the thousands counts per minute, to the point where it is losing some counts due to pileups.
Maybe most people have very little engineering experience, but consider that the setup charge for a PCB build is more than the cost of two tubes, and a quality box costs nearly what the contents does...for a small quantity run, the detector doesn't dominate the total cost - it's almost in the noise.
I will probably have this put out a line per second of text that will look something like:
Runtime:00:00:23 Count1:10 Count10:112 CountPM:672 AD:1234 <cr><lf>
With Time being pic runtime (accurate, from a watch xtal and not subject to idiotic PC opsys latencies/errors), counts for the last 1 and 10 second intervals, and a CPM based on the previous 10 seconds worth of counts (updated every second by dropping the oldest and adding in the newest 1 second counts). That seems like it will do it. We have a lot of options on the MultiGeiger stuff, but we never use them. Background subtraction is pointless since it varies so much and would produce negative numbers often as not. Other time intervals are too short or too long to be practical counting silver -- and you can always add data up from this format if you want long periods anyway. I'm a big fan of providing unsmoothed raw data so you keep the option for any kind of analysis later on (this is pretty basic science-religion, actually, though often violated these days in papers). Internally, the PIC will extend the 16 bit counter in software via interrupts when the hardware counter rolls over, to a 32 bit number -- plenty! It will derive the output numbers via 32 bit subtractions and of course multiplications by 6 for CPM derived from the 10 sec interval. I'll use the pic opsys I've already posted up here -- it works fine.
Possibly desirable would be to keep track of total counts out of the tube over all time -- these do have a lifetime, and it's not crazy big - I would not let one sit and count torbermite for a week. We could put out that number on every bootup -- the pic has some eeprom to store things like that, and that would let you know when to stop trusting the thing, though there will be other ways to test it. We use a thoriated mantel from a gas lamp for a calibration source here, as it gives on the order of 10k cpm on our Geo tube, nice round number -- and we have tons and can mail those around with the units.
This format allows for changes and upgrades in the future, as any parsing software can simply look for the defined labels, then pick out the next number. If we add things, all we have to do is make sure to use unique new labels for it. Most scripting languages do this easy (they were really meant for things like this).
If desired, I suppose one might have a mode for CSV here, with just one header at the top to make it easier to import to spread sheets, but frankly, it would be less hassle to write a 2-3 line perl file format converter for that.
Down the road I can add things like commands from the PC to put the thing in some other mode if we can think of a reason to do that. For now, the KISS methodology rules. The hardware will be ready at any rate, no point not hooking it up.
I already have most of a PCB layout, I'd done one for a 28 pin pic with rs232 a long time ago, and making the new one will mostly involve removing things from that which aren't needed here.
Somewhere along the way, the RJ-11-6 connector I used then became completely unavailable, and all the new ones reverse the pin footprint, which is a shame as that board was almost single sided (would be with two jumpers). Turning all the pins around would make quite a mess, though. The plan is probably to make at least the first one here to check it, before sending it off to AP Circuits in Canada for the real ones. Converting my output to gerber files for them will be most of the total work! It can be a nightmare to get the aperature and drill files all correct and lining up, and the reason they only charge what they do for setup is they don't check -- you get what you sent them, else setup would be $300-$600 instead of whatever it is right now, usually under $100 for proto-1 service which is plenty high quality. Of course, if there's only going to be 3-5 ever built, I'll make the boards here and put in any jumpers needed. I can kind of do double sided, but not plated through holes, and for something this simple, there's no point in that.