It's been important to take decently real-time and reasonably accurate data from the fusor here, for later analysis - it's yielded a lot of great insights. We've used a couple of systems, one based on our standard counter board, and now one based on an arduino - so even the hardware is open source!
Well, there are a few little things you should add to a stock arduino for this to work best, like a box, some BNC connectors, a 2.2k resistor and diodes to the rails for the counter inputs to protect them, and a lowpass filter consisting of a 47k series R and a .1 or so uf ceramic cap inside the box for the A/D inputs.
This outputs data from all 6 A/D channels and the two counters at 10 hz, along with the Arduino's idea of time since start in milliseconds. The perl script knows how to talk to the Arduino, and plot and log the results (in real time, and with a sliding window so a relatively weak PC or even raspberry pi can keep up, though for the pi the window has to be much shorter - 3-5 seconds), with A/D normalized to volts and counts normalized to CPM. The log file will show up named "$date-time".log wherever adaq (the perl program) was run from, more or less guaranteeing unique log file names and saving you some work. The plots aren't further normalized as we do that in another plot program. This is just so you can see if you're getting good data in real time during a run, and so all the traces fit on the same plot - if we had scaled to kilovolts and milliamps...you'd have to have a bit excessive resolution in your monitor to see both on-screen, eh?
For the perl script to run, you'll have to ensure it's executable, and add a few perl modules (I use CPAN as the source of them). You'll also have to install Gnuplot.
For linux machines, this is all relatively easy to do, for windows you have to add the GTK runtime and a few other things as well. I reccomend just running adaq from a terminal - it will give errors till you have all the modules you need, and tell you which one it was missing when it aborted interpretation/compilation into perl's intermediate code. As often as not, pasting that name into some "software center" in linux will get you a list of similar things - get the perl module and all is well.
What we are actually doing internally:
The A/D is actually sampling all 6 channels every 6 ms or so, but simply adding all the results, so you get a 14 bit number from a 10 bit a/d. Experience has shown it's pretty close to really being that good, but maybe 12-13 bits depending somewhat on the signal. These grabs are time-spaced out in the 100 ms recording interval.
C0 is a hardware counter, it's fast, no issues. C1 is an interrupt driven software counter so don't try to put mhz signals into that one - it eats up the arduino's CPU.
Both overflow at 2^32 counts, and are never reset unless an explicit reset command is sent. This way we never can lose a count while reading the counter...and 4 billion counts roughly "ought to be enough for anyone". Anyone who lives through 4 billion geiger/neutron counts at their location in a single run, I'd like to meet.
The arduino communicates over USB and pretends to be a 115200 baud serial port. A serial port emulator works fine as 8n1-115200 with this. Sending the arduino a '!' (without the quotes) resets it. Sending it an 'i' tells it to ID itself.
We're using any line with a # starting it as a non-data line. The PC might want to add data, filenames, constant etc and can do so in the log file by using the # at the first column as a "comment" indicator, and you can later parse that kind of thing anyway you like. My other plotting software does that already. Other than that, the format is pretty simple - time in milliseconds since boot, A0-A5, C0-C1 and a linefeed (this IS linux, you windows guys can make that \r\n in the perl, but won't have to - perl is smart enough to do that). On the other hand, the arduino isn't, so if you want windows, you have to add the ridiculous extra character in the output print.
And they have to be in the right order for windows. Funny, linux works either way, but Microsoft claims they want to be compatable with everyone. Apple used to, but they use just the /r for a line ending just so no one is compatable with anyone.
I'll assume for now you know how to read code some in the arduino IDE, or use some nice syntax highlighting editor for the perl part (I use either gedit or Padre depending on my mood there). If there are questions, fire away. I built mine off a cheap Seeduino copy ($8 shipped from China) and put it in a die-cast box, cutting out some holes and slots on my mill. Remember, around a fusor there can be plenty of noise, and it can get well past the point of a/d errors - it can fry things. A good box is paramount for this work. A big arc can fry a PC from 10 feet away, not even connected up - the mouse or keyboard cables can be a good enough antenna to let the smoke out of the mobo. I'm on #3 for PC's next to the fusor, about 1 a year, from that, and I route cables carefully and use ferrite common mode noise chokes on them. Once I learned to shield 100% of the HV wiring, I didn't fry PC's anymore, but you can't ever manage that perfectly if there's say, a window to look at the fusion, probes etc, and various leakage right through copper screen.
Note the perl script finds *any* arduino connected to the box. You can make that more specific if you like, I'm just looking (linux) in /dev/serial/by-id/ for anything that has "arduino" in the name for that.
Here are some pix. As usual, click the pic for a large version.
Here's a screenshot with me fooling around with the inputs. I connect the counters (sloppy at first with a wire off a clip lead) to a signal that counts once per two passes of arduino's "loop()" function - note that C1 doesn't count quite as fast - it steals interrupt cycles when a count happens. I later connected a channel to a 1.588v (fairly fresh) AA cell to calibrate things...I tested that voltage with a really good couple of voltmeters. Turns out my particular Arduino's 5v is more like 5.0x volts. That's running off a wall wart. If you run off the PC 5v from USB, you'll have tons of errors as the PC 5v isn't that great as an A/D reference...