Things are coming along at the homestead - various "oh, things only fail in bad weather, but are now fixed" stuff - boring, and exciting (to me, anyway) - I've been doing some interesting (to me) work on a new data acq system with a lot more capabilities for fusor2. It's kind of kept my head down and nose against the abrasives. Which is fine, since some good things are happening.
I found a way to get nearly hard (low jitter) timing out of a raspberry pi, at least for this application. The original demand was to allow serious synchronization of some slave nano clones, so as to get more channels of input, and have them all in absolute sync with one another - even if there was a little jitter in the timing, at least I'd preserve the info about cause and effect, and not have one drift a lot in relation to the other one. That would happen even with crystal oscillators, but with the built in RC ones in these LG8T clones - it's bad.
FWIW, along the way I found out that there is hardware on the pi, badly and rarely documented, to create real serious low jitter timing if you can figure out how to work it. But it's intended to be used as clock generators for other uPs, I2S audio and the like - it won't go slow enough for this, and I didn't want to add a bunch of ttl dividers....
Well, I found a way that seems to give pretty reasonable results in pushing a pulse out of the pi on an IO pin that's within a few microseconds of perfect, at 100 millisecond intervals - just how perfect is probably going to be somewhat a function of other loads on the pi, but being able to get it that good on a preemptive opsys frankly amazes me. At least it seems to be that just about all the pre-emption that occurs happens *after* the front edge of the produced timing pulse, so it's don't-care. Whew. A version of that code went up on my github here:
https://github.com/dcfusor/Timing_generator
Once I had hardware IO and this kind of figured out...I thought it might be good to have a few a/d channels right on the pi, using I2C and ADS1115 converters. Ok, I tried wiring pi - it works, but Gordon is taking it down, being frustrated by various life factors, and it doesn't support some of the things I want. Not really wanting to get totally into that ecosystem (it IS good for what it's good for), I decided to get down on the metal - to memory mapping and the somewhat luxury of some linux drivers - and go from there, which is where this is right now. I will publish this code, which is pretty cool, as soon as I've rubbed off some of the inevitable burrs. Since I've rewritten from scratch a few times to get the basic paradigm right, might as well make it purty and "production grade" before turning it loos on the world.
So the net thing will have 2 nano slaves, with 4 a/d channels (with some DSP tricks to get a couple more bits resolution) and 2 counters each. One counter on each one has been tested up to 12 mhz, and the tests I want to do on the new rig are going to involve some RF and more automated control than on the big one downstairs, so...need to write it all down so once the parameter search turns up some goodness, I'll have the data to analyze, plot and share. Whew, there's a lot of handle turning to get there, but there IS progress.
This will also have 8 channels of 15 bit a/d directly on the pi, and a couple 12bit d/a converters to enable some automated tuning and testing. Anticipated is some stuff that can measure phase angles and time delays and get that into the system as well. I think this is way worth doing, and after all this work to get it really kind of right - and very general purpose, the resulting design and code will be something I think others will want to copy -
That's one heck of a data aq system, dirt cheap, with a lot of downstream analysis capabilities and data mining - all this is going into an onboard SQL database, with tables for each bit of hardware, and other tables that can allow code to know how to interpret the resulting numbers, analyze, label, plot and so on, and make it easy to specify new schemes for any changes in the hardware lashup.
After it's time to build a railroad, it might be time to build a
beautiful one. This would be an attempt at the latter.
Hopefully I'll be able to pull out for air and post a bunch of this on the github and here - I'll have a much better blow by blow description when it's not changing so fast, and the needed documentation for anyone wanting to duplicate this. I'm doing this one on a raspberry pi 4, but to be honest, the system loads I'm seeng so far for data only are in the few percent range, so it'd probably work fine on an older one. I'll test that sort of thing a little down the road...it'd be nice to have it completely self contained, though for safety here I'm usually using a separate server to do the SQL database -that way if the fusor-proximate one gets fried, I don't lose data up to that point. There doesn't appear to be any other reason, though - this thing seems to be loafing with this load.