Data aquisition from USB PIC

For stand-alone microprocessors

Data aquisition from USB PIC

Postby Doug Coulter » Wed Feb 08, 2012 11:56 am

Here's a mod to the original standard counter software that does some more things. Now, in addition to counting two hardware counter inputs, it also digitizes the first four a/d channels. I did change the output format to keep the lines shorter, so it won't work with the same PC software (unless you change one or the other), but it's not a real big deal. It still outputs a line once per second with a timestamp at the front, then counts from the two counters, then the a/d channel values. As before, the format is all human readable text, and is:

Linefeed Time text-label number text-label number text-label number....and so on till the next linefeed.

Some might think that 1/second moderate resolution a/d is not worth much, but compared to not having it - and with that timestamp so you know when all things occurred, I think otherwise. I did an interesting trick on the a/d. The PIC has a built in 10 bit a/d, and it's actually pretty fast. Since I had to either report 8 or 16 bit numbers, I went with the latter, which would normally leave 6 bits unused. That's no good! So instead of just taking one sample, the code takes 64 samples for each channel and sums them all up into an unsigned 16 bit value. This doesn't really have 16 bits worth of accuracy or resolution of course, but it does have roughly 12 bits of "goodness", due to the fact that first of all, the PIC a/d has pretty accurate bit thresholds, and secondly, the inevitable noise acts as a source of what signal processing guys call "dithering". So you wind up with a fairly good average of what was really there. The scheme is to sample channel 0,1,2,3, over and over till 64 frames have been taken. This takes a lot less than a second of course, so the code needs no ready/done flags at all - the best designs know what can be omitted. I may slow it down a little - the PIC has a sample/hold delay timer in it which is already set to slow things down below what's needed, but a little slower would spread the samples across the second better than it does now. You can of course also add analog filtering to the inputs as desired.

It just seemed dumb to not use more of the free hardware in the PIC when there it is - and the thing still has plenty of unused hardware available, as well as about 70% of memory and most of the cpu cycles.

The envisioned use is for my fusor. I will hook voltage, milliamp, and pressure signals to 3 of the a/d inputs, along with various radiation detectors to the counters, and get frames all in time-sync for plotting and general data mining. You could imagine a 3-d plot (actually more is possible if you use colors and shapes along with normal projection 3d) of say, neutron output against two other parameters, so you could do a scatter plot while sweeping all the run parameters and see the shape of the output or Q curve vs whatever you were varying, and get a lot more done in a single run to map out the "sweet spots" for your fusor.
Just one example - a lot more is possible when the PC software comes along further. But this is the necessary prerequisite, to just get the doggone data in a way that unloads the PC of all real-time requirements so you can run a modern very-much-not-hard-real-time operating system to get the use of the features that provides, and still have robust on-time data collection.

For this one, I left in the code that polls for USB connectivity in case you want to power the board off something else. You could want to do that to get more precise 5v, which happens to be what the a/d uses for a full scale reference voltage. I have to say though, that in tests here - all my machines put out 5.0v to USB to a tiny fraction of a percent - unexpected but I'll take it. Since the a/d numbers are raw counts anyway, if you've got a stable reference, you would simply compute the appropriate scale factor for use on the PC side anyway and not care about absolute values - just drifts.

And, tada - here's the code. Please consider my stuff (most all is in opsysutils.h) GPL V2 - if you make it better, share it back. The CCS stuff is, well, their stuff. I'm really liking their compiler for the pic 18 series, having tested all the others at my own expense and reccomend it highly. While there are some other ones that make multiple compilation and mixed assembly language work better or easier - the CCS basic stuff like the interrupt dispatcher - are actually really darned good and I've not felt the need in any recent projects to "improve" or "workaround" any of it. I did have to do a little fakey trick to get the automatic sample/hold delay set up, but that sort of thing is typically needed anyway. I suspect this will require their compiler to build - so be it. It's not a bad deal for the money, and their support is decent - they earn it on both sides of a purchase. Their programming dongle is also a bit better than microchip's, as is their code debugging support (though I don't use either vendor's debugging, I roll my own).

StdDaq.zip
Source for the data aq application. Uses same uP board as standard counter.
(325.68 KiB) Downloaded 402 times



Now that we have USB up and running, we can do things we couldn't do before. Most PCs, especially windows ones, cannot even hack over 19.2 kbaud of continuous flow from an external device over rs-232 - you'll have uart buffer overflows as the opsys just can't seem to get a decent interrupt response time. But the USB hardware and drivers were meant for things a lot faster than this, and have more buffer to handle some real fat flows, so we could in fact go very much faster for things that will want that later.

More to come! I designed this board to be very versatile - it's just the PIC and the necessary stuff to get going, and we ran all the extra pins off board so you can pretty much do anything with it you can do with the 18f4550 chip on any board. Joe did a nice layout job to get all this onto a standard dual row of pins so standard IDE type connectors can be used to plug this down onto the motherboard of your choice, or you can stick wire wrap pins into the holes and have your way with the thing, with all the "hard parts" that involve very fast signals already taken care of. Just add 5v and code!
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.
User avatar
Doug Coulter
 
Posts: 3515
Joined: Wed Jul 14, 2010 7:05 pm
Location: Floyd county, VA, USA

Re: Data aquisition from USB PIC

Postby Doug Coulter » Tue Feb 28, 2012 10:05 am

Just a note to check the PC side of our software forums. I've just completed some software to drive the standard data aq pic software from the pc, complete with scaled plots and so forth. I'll be posting it as soon as I boot the dev machine to get it here and feed the cat. When we figure out what these cost us and can sell for, the package will show up on DJ's here, but since this is all completely open - if you have a pic programmer you don't have to wait or even buy it from us. Enjoy!
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.
User avatar
Doug Coulter
 
Posts: 3515
Joined: Wed Jul 14, 2010 7:05 pm
Location: Floyd county, VA, USA

Re: Data aquisition from USB PIC - update

Postby Doug Coulter » Sat Jul 21, 2012 2:33 pm

Here's the latest code for the data aq (I usually call it sdaq) device:

StdDaq.zip
Latest PIC C code
(327.74 KiB) Downloaded 405 times


Minor changes only - a few tweaks to the a/d timing for better results. This code takes 64 samples per channel to produce a 16 bit result from a 10 bit a/d. As luck would have it, the a/d accuracy and noise is such that about 12-13 bits are out of the noise, and the system noise dithers the input just right to get that - so we get a couple more bits than the hardware provides. A passive RC filter on each a/d input provides some anti-aliasing and smoothing, in the hardware. Currently that is set for about half a hertz 3 db point, this is so far meant for things that don't change all that quickly, like power supply and vacuum system data.
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.
User avatar
Doug Coulter
 
Posts: 3515
Joined: Wed Jul 14, 2010 7:05 pm
Location: Floyd county, VA, USA


Return to Embedded software

Who is online

Users browsing this forum: No registered users and 1 guest

cron