It seems fusor development is all about measuring/metrology. Results from sweeps of the various parameters, properly analyzed, lead to further improvements on an ongoing basis. By sweeping various parameters, an N dimensional plot of Q, neutron output, or other metric of interest can be produced to find out what really works best, rather than guessing accompanied by arm-waving.
Keeping good notes is a virtue, but tedious and not always possible due to fleeting modes of operation as parameters change, bursts and so on. Many narrow or (initially) hard to get setups simply don't last long enough for a human to read several gages and write down what they were saying when the good thing happened, which can be frustrating. While humans may be the best final analysts, they are kind of lousy at recording fleeting events accurately. We notice that they occur, but have trouble quantifying just what happened without some help.
A computer may stink at some aspects of discovery, but basically cannot be beat for writing down the raw data for later analysis by a human, using both the human and computer for what they do best in the human/computer system. Thus, for quite awhile here we have been putting most of our time, money, and effort into creating a system to aid our development, particularly since we have been getting plenty of indications that pulsing and bursting modes often give the highest Q we ever see in a fusor setup, an in our case, Q is what we are trying to improve in the quest for more-practical fusion as a possible energy source. We feel that total output power is something to worry about after, not before, getting to gain. Once we know a way or ways to get to gain, we'll have a clue how to scale it up, and until then we really don't know what it is that we need to scale up!
So, based on a long career of doing things that have involved data acquisition and analysis, we are building a system customized for the fusor development application. This will combine COTS and homebrew pieces, and custom software, adapting as needed as we discover new things. Being frustrated with the limitations (and poor adaptability to new needs), not to mention costs of pure off the shelf systems, we decided to design our own, probably somewhat influenced by the idea that we know a little bit more about what we want to measure and record than the "mass market" about this game. We are just now deploying the first parts of this here, and expect usage experience to guide further development, which is only possible/practical if we are the developers. This has involved a fair amount of up-front work that might have been just as well done with off the shelf stuff -- but that would not be as adaptable or extensible as what we have already.
It seemed obvious to me that the best repository for our data would be a computer database, designed with an eye to being fast on acquisition, and flexible for later data mining. Further, though (kind of sadly) a Windows expert, including ring 0 internals, I am now a Linux dude, so cross platform operation seemed best -- making it easier to share relevant parts of this system with others working in the field. Thus, while all this development is currently on Linux, we are definitely making sure we use or write no code that isn't cross platform where that matters, and in fact we have significant data Aq hardware that is windows-only, so this system as applied here will be cross platform all the time, at least in parts, with some of the data aq done in windows (running in Virtual box on a linux host, natch).
Where we build hardware, it will use various universal communication standards so it won't matter which opsys is the final resting place for the data. This is a requirement since it is prohibitively expensive now to create windows drivers (which now have to be signed by MS at high cost and time delay to run), and a hassle to write Linux ones. So, RS-232, ethernet, USB (often just as a fancier faster serial port) are what is on the table as interfaces. Further, the philosophy here, to avoid re-inventing the wheel, is to use existing code insofar as possible with a requirement that it be cross platform already. This leads to a fairly short list of possible tools. Perl runs everywhere. MySQL runs everywhere. Sox runs everywhere. Ardour runs everywhere. Custom C or C++ doesn't without a lot of extra work. Bash scripts only run on Linux (or windows after a painful install and tweaking of POSIX adapter code). I guess we are leaving Macs out of this for the moment, as they have such a tiny share, are expensive for what they are, and we don't have any here. but since Macs are BSD Linux, there's a good chance that this will run there too if you can get inside the "walled garden" they have created.
Our current deployment just getting going looks like this:
We built a PIC based piece of hardware that counts up to 5 counter type sources accurately, and has 4 slow a/d inputs for things like power supply and gas gage parameters. In addition it has a very accurate internal clock for timestamping, unhindered by the problems that complex PC opsys all have, so it can be our master timekeeper with fairly fine resolution (32768 khz). To that, we add a PC soundcard, and are adding to that a pro digital audio workstation with 24 bit resolution, 96 khz sample rate, and 8 channels of full duplex in real time. While these latter are all AC coupled, it is possible to digitize DC inputs via use of a chopper to turn DC inputs into AC square waves that can be trivially rectified once we acquire the raw data. This is attractive as the cost of digital audio workstation hardware is a small fraction of hardware with equivalent specs made for "fiscally clueless physicists"
Data from all these is gathered by a Perl/Tk script and gui, and pushed into a MySQL database, with the database schema and design such that it is fast to write into, and very extensible for accepting more inputs later, all in time sync, from any new AQ hardware we may obtain or build. Once data is in a SQL database, there are a lot of options for mining and displaying it. Most word processors (Open Office) and spreadsheets (Excel and again, open office) can pull data from a DB and make pretty plots, though for what we are looking at they are on the limited side, so we will be also using Perl + various modules for making N-dimensional plots and projecting the N space onto a number of dimensions one can use the human analytic capability to interpret as the hyperspace is rotated so you can see how the projection changes. By simply allowing the various parameters to drift (in say, the case of gas pressure, which tends to drift anyway) or driving some of them actively, we can quickly build up a database of performance vs all the possible parameters, and not miss fleeting but also narrow "sweet spots" in operation that most miss when only a human observer is involved. For just one silly example, we have noticed (manually) at least one very high Q mode that is fleeting on startup, when both power in and output are quite low -- so low as to be difficult to measure. This slipped right by all other workers in the field, as what they seem to be interested in is simply "more" output, not efficiency and since all the counters weren't going wild, to the extent it was noticed at all, was considered a possibly interesting, but not very worth pursuing operational mode. We feel that that is a BIG mistake, frankly. We think "at all" is much more important than "more output regardless of waste" is, and that "more" will be there once we know what it is we want more of!
So far, we have our "Multi geiger" PIC based front end and the normal computer sound card integrated and deployed to the computer proximate to the fusor setup, and it's first real run will be the next time we run the fusor, so obviously, that will shake some things out and somewhat define where we will take this going forward. We have not integrated any of the windows-only things yet, which include a mass spectrometer, an arbitrary waveform generator, and the digital oscilloscopes, but plan to of course. Since the GW Instek communication standard is "open" we will at some point make that a Linux thing instead of relaying that from an instance of windows, but there is little hope for the other pieces. Luckily, TCP or UDP communication from a windows instance running in virtual box is quite fast to the linux host it's running on, and of course, there are shared folders as we set them up as well. The idea is to not be limited by the tools we will employ, after all.
At this stage we have not yet done much on data mining and analysis -- this is a staged project, and getting the data in the first place has to come before that, partly so we don't lose full data from any more runs due to human limitations in taking it, but obviously that's going to be the really impressive part (at least to those who don't understand how tough it is to acquire accurately time-aligned data from multiple disparate sources with flexibility to add more later). As this is an ongoing effort, by design, this post can't describe it all, or as yet even get into fine details of the implementation, but this again where most of the time and money are going here, as we have the basics of fusor design and construction well in hand at this point. Now that we can "do anything" with the fusor hardware, we want to find out what it is we should be doing!
So if I seem a little concentrated on metrology issues, that's why -- it is what I'm doing morning noon and night, even paying for some help on the coding since there is just so much of it to be done, and the calendar keeps on moving.
