Page 1 of 1

Re: Parametric sweep of fusor parameters plotted in 4 dimensions

Posted: Tue Aug 07, 2012 5:03 pm
by Chris Bradley
Doug Coulter wrote:
> The process isn't automated other than the data taking, once begun. I'm lucky to have this killer-good Spellman supply, so for each run I simply set the voltage and current limits, then fiddled with the gas, or let the system drift - which it does with temperature and "phase of the moon" seemingly sometimes.

Hi Doug, the data aq is absolutely fantastic. Just wondering if it may be better to use some standardised way to roam through the parameter space to collect the data, rather than trusting in the 'phases of the moon'.

If you make changes next time to the way you approached certain parameters in this run [for example if you approached a parameter point from high pressure to low rather than vice versa (or whatever) and get a significantly different answer] would you be likely to forget the different scenarios that lead to that differing result, which might mean you'd be prone to conclude it was something else you'd done differently? One second for the readings to stabilise seems quite a short time. I'd imagine that what happened in the preceding second might contribute significantly to the readings in the next second.

Re: Parametric sweep of fusor parameters plotted in 4 dimensions

Posted: Tue Aug 07, 2012 6:26 pm
by Doug Coulter
The data aq is kind of a compromise. The one second period is because shorter, and I might not get very reliable counter data (unless I demand high count rate counters - but my fusor swamps my 3He tube for example, and it counts wrong due to deadtime issues), and longer and the other channels (they are all produced in a batch, and timestamped together) smears out the other parameters too much.

There's no problem with approaching from either direction, in fact, this dataset did that multiple times per run going both ways, and the results at a particular set of parameters don't have all that much smear, though there is a little, mostly due to that slow second (from the a/d point of view). There's a little bleed in the a/d data from the previous second or two due to the anti-aliasing filter. There is also some scatter in the counters due to the short (for them) time interval used. Compromise is kind of like that...

However, don't forget that what is saved here is the raw timestamped data (something PCs are bad at, which is why we do it in an embedded uP - we can guarantee *all* the data for that second started and stopped right on the seconds boundary within a fraction of a microsecond), we can look at it any way we want, and one of the demos I put up on youtube indeed shows it vs time (actually, a few of them do), so you can see if there was a significant precursor situation to whatever feature you're examining.

I am still exploring what gnuplot can do for us, and what's worth doing. One thing I can do even on this multidimensional plot is to draw arrows between the points, according to their time order, for example, however - on this much data, it obfuscates rather than informs.

These parameters are NOT independent in a fusor. At X gas pressure, you cannot have arbitrary volts and current - they all interact. In fact, you can have a situation where the thing won't light off at a given set of pressure, volts - but once lit, will stay lit just fine (and it will stay lit for a lower pressure once lit) - there is a divergent feedback once there are a bunch of ions present that drives things to a limit (what we normally call stable operation).

I am of course, looking at automating my gas control stuff. (to do that well, I need finer control per pulse of the inlet and outlet solenoids than I now have) But then you'd have to track that too if you were interested in say, how fresh this batch of fuel was - obviously contamination builds up during a run due to things getting pounded off the walls, sputtering off the grid and so on...and as mentioned, temperature has an effect - which means, as you say, the the immediately previous conditions are somewhat important since it takes awhile to heat and cool.

This again, is why we do our science "right" and always, ALWAYS, keep all the raw data just as we collect it - that way, if a new idea comes up, we can tailor our display method of it to see if that new idea has merit or not. You can't do new ideas in data-mining if you don't keep the pure raw data around! The format does allow for comments in the log files, and I do put them in there. We just don't plot the comments...

There are of course some practical limits on what's worth logging. I'd like to have chamber temperature too for example. At some point though, the data rate gets out of control for the systems involved (The PC is generally the limit on bursts of data, it's not really a good real time thing), and the cost gets very high for all those channels. There will always be more we wish we could do, I suppose.
Here I'm trying to keep the line length per burst under 80 chars and still keep it human readable, since there's a lot of useful software out there that barfs on longer lines.

For high time resolution, I've been adding a GW Instek scope to this and grabbing screens from it's 4 channel, 2.5ghz sample rate data set - you can't get it all, but it lets you put a time-microscope on individual events. This can all be put into say, a MySQL database for later mining, though once you have two separate interfaces into a PC (and didn't get to write the opsys yourself), keeping them accurately time-aligned is more or less impossible. Two simultaneous inputs into a PC can be recognized in either order even down at the driver/interrupt level. If you have two programs stuffing things into a database, vagaries of the opsys time-slicing add to the uncertainty for both programs, and the database program *itself* may not put things in in the order recieved. We discovered this on a more ambitious prototype of this, where we had the scope and a 10 channel pro audio card all going at once along with this. At the speed transient events happen in a fusor, you really can't depend on sorting out which was cause, and which was effect unless for example, they are both on the same input (for example, the soundcard or the scope). If the signals come in on different interfaces - all bets are off.

So, doing that gets you into government-money-level custom built stuff, the sort of stuff I used to do for NSA intercept systems. I thought this was rather a decent compromise since I can take a family to dinner (admittedly at a good restaurant) for less than this will likely retail for.

No need to colonize mars yet - I'm just getting to earth orbit - while most people can't even fly, for now.

I'm putting all the demo movies up at: http://www.youtube.com/user/DCFusor?feature=mhee
And embedding them on my site, with discussion: http://www.coultersmithing.com/forums/v ... 34&start=0
which includes plots vs time on all this if that would answer any of your "what came first and from which direction" kinds of questions. You can see for example, the pressure varying (either due to my actions or randomly) and what happens before and after quite clearly on those, but not some other interesting facets we can see in the 4d plots better - depends on what you want to look for in the data mine.

Re: Parametric sweep of fusor parameters plotted in 4 dimensions

Posted: Wed Aug 08, 2012 2:10 pm
by Richard Hull
The natural hysteresis in glow modes on and off points is maddening in fusor data collection, but allowed for many novel uses of the ubiquitous NE-2 and sabilized NE-77 three element lamps in the 50's and early 60's when used as Flip-flops, astables, saw tooth gens, etc. GE put out a large engineers desk volume on its line of neon lamps with many apps and circuits featured in the late 50's.

As we work near a ragged edge of glow and higher vacuums with 40kv drops across our glow instead of the normal 55-70 volts of an NE-2, the going gets really rough and often maddening.

Richard Hull

Re: Parametric sweep of fusor parameters plotted in 4 dimensions

Posted: Sat Aug 11, 2012 4:29 pm
by Donald McKinley
Doug,
8-11-2012

I like your idea of taking account of the spin properties of reactants. I have been thinking about this for quite some time. I have an experiment to suggest roughly along those lines. I will mention it in a separate post so as not to muddy up the waters here. It involves calculated de Broglie frequencies.

regards,
Don