by Doug Coulter » Sun Oct 19, 2014 2:03 pm
You're both really sharp-eyed, and FWIW, there's a mistake on the schematic (but not on the board layout) which I might get around to etching today, we'll see. Finished it last night. I'm going to make that whole board into a library component and tile them so I get a few out of a sheet of laser printer transparency - that stuff isn't cheap, nor is it perfect edge to edge. And in a couple cases (not yet shown here) I pushed the design rules really hard and not all the prints might come out without an accidental short. Usually, the easiest place to fix that is after exposing and developing the board, but before etching, with a razor blade and a stereo microscope, which is plan-a - I usually do that inspection anyway. I found the one (only?) good use of ferric chloride in doing this. Wipe it on the developed board, and all the actually-exposed copper turns really dark. Places where a tiny amount of resist clung on (too thin to see otherwise), don't. Makes it easy to see exposure-development mistakes and fix them - and repeat as necessary with a new wipe test. I usually do this at 30x or so magnification and no caffeine but perhaps one beer and a couple hand steadying tricks.
Having done this before, I'm well aware that there will likely be some changes required before I have one I could sell or send off in good conscience. That's just how this usually works out. Hardware often needs "editing" just like software. It's just hard.
The fet gates (they are enhancement mode n type IG mosfets, not jfets) aren't supposed to be tied together - the right hand one gets it's own pin on the UNO32 and separate control. There's a good reason for that, which I'll get into. We want to turn that one off before we let the other one turn off, so we can't get into a high-current fight with the NPN transistor.
The PNP transistor gives me 1 Vbe more or less off ground when the opamp is putting out zero volts (it's a rail to rail fast opamp). It will be on the high side due to the low value emitter resistor (lots of current, Vbe is the log of current), and worst at near-ground when the emitter current is highest - a fast constant current source seemed like a futile adding of complexity there. The Vbe of the NPN will also vary, but mostly be at the low end once Ch is charged up, since no current will be flowing at that point, but the intent is to cancel out and make tiny pulses near ground possible to digitize at all. Since these are all SMD over groundplane, they should track temperature pretty well at least.
The result of that pair will be a bit of non-linearity in the results, as the larger pulses won't be perfectly as much larger as a small pulse would be, due to the current variance through the PNP. I can live with that - and NaI has it's own nonlinearities, so for a pro-grade thing, we'd have to do some heavy math lifting in the PC (preferably) to make it all come out accurate in keV. For what I want, and since I own a plethora of calibration sources, I probably won't bother unless it's really bad.
It should be deterministic, as I've prioritized the interrupt I'm using so the usual arduino-type opsys stuff they hide from you can't mess with my timing as much (it takes timer interrupts among other things).
I think the flip flop got mis transcribed as to the number. It's a TI part and some of the numbers are letters (5 and S are hard to tell apart in my sloppy handwriting, as are 1 and l). It only has a /reset, there is no /Q output (hence the change in the drawing and I'll have to change the software too). The digikey part number is 296-17617-1-ND, It's just a d type flop with a couple pins missing from a 7474 and only a "single" at that, in an sot23-6 package. Teeny stuff. Hate to admit it, I kinda miss the days when you could proto this stuff on perfboard...but most of these parts aren't even available in through-hole versions.
What is supposed to happen here:
Assume we are initially "at rest" and the signal is under the threshold set by the pot on one of the comparators. A pulse comes in, and shows up as a positive pulse at the opamp output (and yes, I know the gain control will interact a bit with the shaping - simple and perfect rarely occur together). Once we go "over the top", and the PDI (pulse detector input) signal drops below the PDO signal - we set the flop - but only if PDI is still above threshold, since that comparator feeds the D input. There might be some error on really tiny pulses - we'd miss them. That's life, I personally am not interested in the extreme low end of energy, and were I to be, well, that's what the gain control is for (losing high energies to clipping at the other end if you crank it up).
In real life, you use a different NaI for each end of the range anyway. My "Gallon jug" NaI's are horrible at the low energy end, but great in the megavolt range. I also have one with about a 2mm thick NaI head that is fantastic at the 10's of kev range, but of course, can't handle the big stuff well at all - it mostly scatters out. I have them all wired to take a negative power supply input, with the phototube anode floating, so they can be connected to this directly, no coupling capacitor required, they are an almost perfect current source. You can't pull this off with just any detector - some have noisy leakage from the photo cathode to the world..but with these, you can. For your basic 2 wire bicron, you have to use positive HV, a series resistor load (I use from 10k to 50k there, on the high side, but I like loud signals), and a coupling cap - a few hundred to 1000 pf, to this board. In either case, power supply regulation is pretty important, as most phototubes when run around their specs, are super sensitive to it - gain goes all over the place. I sometimes defeat that issue by simply running them on the hot side, voltage wise, where this effect is less pronounced. I've never figured out why everyone seems to get on the steep part of the error curve on purpose. I could be missing something, but these tricks are what made the really pretty spectra on that thread with the URSA II pro MCA we borrowed. And those showed us that no matter what - there's not much point in having more than 1k bins on an NaI - the lines are all a few bins wide. We wound up using a lot of inter-bin smoothing in the URSA software to get good looking plots - which wound up with around 500-100 effective bins, just prettier/smoother looking. I'll probably just blow this spectrum straight out to gnuplot. It should be good enough for what I need right now. I'll probably use perl as the duct-tape to make that go. You can open a USB serial device "by-id" with the serial port module in perl, so it doesn't get confused with other serial dongles. And in general, doesn't care about what baud rate you specify at either end. In our case, we'll be sending single characters to the unit to control it, and once in awhile getting a flood of 32 bit numbers back as ascii.
Very similar to the way Phillipp did his, but I might use some different characters for commands (since I do have some already established protocols for my other uP data aq here), and probably fewer, since I just want spectra - I don't need to look at single bins (which you can still do anyway once you have all 1k of them).
OK, setting the flop creates an interrupt to the uP. The uP responds by flipping the s/h internal to hold and starting the a/d acquisition. I rewrote their init code to leave the a/d always in sample mode on channel 0 so this could work. Setting the flop already pulled down the base of the NPN - a nice safe place to turn off the input vs shorting out the opamp and so on (the reverse emitter base diode of the PNP just barely can hold off the 5v, but barely counts here). Once the a/d conversion is begun, the uP will turn on the other half of the fet and discharge the main Ch - these are relatively large fets (ampere ratings) and have fairly high capacity already - we may not even need an explicit Ch here. Since all this happens either before or after the internal uP sample/hold is closed - we don't worry about charge injection issues, or glitches - all the noisy junk happens when we are not watching. That's on purpose.
Now that we have our number, and have incremented the appropriate bin in our spectrum, we turn off the Ch fet (the cap is presumably discharged by now, if we find otherwise we can add some delay in the code), and apply the reset enable signal (low true). The comparator and or gate ensures that the peak detector will not actually open again (allow the flip flop to reset) until the signal in question has fallen below the threshold (0-120mv with the values shown here, roughly). Everything returns to step one, waiting for another pulse at that point. The uP is responsible for holding that reset enable signal until it sees the flip flop reset - it can read that pin as well as use it for an interrupt, and it must do this or we might get "stuck" in a state we can't recover from.
The top half of all this runs off 5v, so we can always be sure of reaching 3.3v output. The bottom half runs on 3.3v, since that's what the uP wants - I used 2.7k resistors on signals driven from the 5v side to the 3.3v side to limit current. The UNO32 also has input protection stuff, but some of that you'd rather not put to work as it can actually pull up the 3.3v supply if you hit it hard enough. This should still work at all for pulses larger than 3.3v out of the opamp, but all those should stack up in the very last bin as they often do in a "real" MCA - for one thing, cosmic rays - you always have with you. We won't get an accurate value for that kind of thing, but we'll know it happened. For really low intensity sources, we'll probably have to add an option to not plot the last couple of bins so auto-scaling doesn't hide our desired signal. Of course, I will have a choice of log or linear plotting, since it's so easy in this system.
This will, of course, have some dead time. For most signals, that's a pretty large problem - you get funny results sampling, say, an IF strip looking for the PDF of it, unless (under)sampling is "truly random" - beats, aliases and so on (we had to do this to make an automated signal to noise measuring device for radios in the...outfit I can't talk about). Here, it's not such an issue assuming we get our randomness via the source radiation itself - if that turns out to be somewhat coherent, we'd have a problem. Since I have 32 bit everything here - we could likely just wait longer and average all that out, though. It's going to take a long time to overflow.
I strongly considered trying to pull this off with a garden variety arduino UNO. The specs just aren't there for this, the a/d is too slow, and so is the rest. The chipkit UNO32 does cost more...but it's orders of magnitude better in all ways. And I like PICs better than Atmel...even if this one does have a MIPS core - it still has their really good IO behavior, which is most of the reason I started with PICs before they even discovered that having interrupts would be nice. So for a couple times the price, we get orders of magnitude in a/d speed - mhz vs khz - and core speed (80 mhz vs 16), which we can put to good use here. Given that two consecutive lines of digitalWrite on the regular arduino can make at minimum a 5 uS pulse...something is a bit off there anyway - it should be tons faster than that at 16 real mhz. Maybe the atmel is more than one clock per instruction? More likely, the simplistic arduino IDE with tons of hidden library code full of #defines (to support every board under the sun), is the real problem there. And it's hard to find that stuff - long searches using grep in directories not mentioned in the dox...and so on. (Glad I'm on linux here, or even that would have been hard).
We'll see - I should have this in testing in at most a week, probably much sooner. I've got another project going on in parallel just now - fiber optics comm for a servo I want to have floating up at 50kv or so and tune a capacitor from down here at ground levels. It's taking me a little effort to test with this unfamiliar stuff. I thought of using WiFi for that (I have WF32 boards) but it's in a very noisy place, and near 100's watts RF as is...probably won't work with WiFi.
Posting as just me, not as the forum owner. Everything I say is "in my opinion" and YMMV -- which should go for everyone without saying.