|
--- In "charliem_1216" <> wrote: > > > * What sampling frequency? > > > > The A2D runs at 4us / sample. We programmer the A2D to trigger at a 5us > > rate, and it puts values in a FIFO. We discard the first 200 samples in > > the FIFO, and then sum the next 3334 (that equates to 1/60 of a second) > > samples to generate a sample to use. The summing is done in floating > > point. > > OK, so you take many of these 'samples to use', and this is where you find the variance? Do you find any variance within the 3334 data points? Almost always, but I'm not sure how much. I'll suggest adding an stddev check, but all that floating point math will slow down the scanning. > > > * How is data taken / transferred from your A/D card? Userland or > > kernel driver? > > > > Userland, I suppose, since t he test program is doing direct I/O to the > > A2D card. > > Well, I'm confused then. How do you know when to empty the FIFO from userspace, without an interrupt? We sleep for a millisecond then process all of the values currently in the FIFO. The A2D does not fill the FIFO within 2ms, so we get all of the samples. Any extras in the FIFO when we're done are discarded (as were the first 200 readings). > A well-known problem is the granularity of sleep intervals. Your 1 mS sleep will be OK on i386 as it uses high resolution timers by default, and you were using RTAI. But on the TS-7800, I believe you have to rebuild your kernel to get HRT. Yes, as some useful (and a bit of incorrect) information from Technologic, we got their kernel rebuilt with a 1ms timer rate. > Your 1 mS sleep will actually be 10 or 20 mS, which probably partly accounts for your code running slower. And that will certainly overflow y our 512 (or 1024) sample FIFO. Depending on when you reset the FIFO, you could be reading older samples (or even samples from the other channel?). Our 1ms sleep is between 1 & 2ms. > In the spirit of debugging, I would see if you can: I'll forward those suggestions to the guy working on the program, but he told me today that lowering the sampling rate does seem to improve the values somewhat. > * use a busy loop taking single samples a fast as possible. (Yes, I know it's not a good practice, but we're debugging here ...) > * Take samples into an array of 16bit integers, rather than using a floating point accumulator. You can then look at the individual samples for variance or noise patterns, or for problems in your > * Turn down your sampling rate. Even 333 samples at 20 000 samples/S would be quite a lot to average. If you are averaging to 1/60, I'm not sure why you need to sample at 200000/S. > * If do a lot of f loating point, even outside of your A/D, try building an EABI kernel & rootfs. While you are at it, turn on HRT. We do one floating point add per sample from the FIFO, then one divide to get the average when we're done. Not much more than that. We need to learn about EABI (I only recently found out about it), how to enable it, use it, program with it, etc. > I expect you are seeing a difference because you are using userland methods to acquire data. While they happen to work on x86 due to the higher clock (I guess?), RTAI, and HRT, the same methods don't do what you expect on ARM. To fix it, you need to either use a kernel driver that can empty the FIFO on an interrupt, or dig deeper into your acquisition routine specifics (with the A/D hardware manual in hand ...). The hardware manual does appear to be quite good ... <smiling> Except for instructions on how to program and use the auto- and auto-auto-calibration functions.&nbs p; I hear that information is most arcane. > Your hardware vendor has a linux driver (rather like VMWare: a kernel mode stub you compile for your kernel, and a closed source library you can link to). Have you asked about an ARM version? They weren't interested in building one for us and they wouldn't provide the driver source for us to create one for ourselves. I think they offered to license a copy of the driver source for more money than the project is worth to us, but I could be wrong about that. > Finally (sorry for the rambling ...) your vendor also has a bunch of example C programs that exercise the A/D without the kernel driver or closed library. You could run some of those, under both x86 and ARM, to verify that the board is OK with the TS-7800. We have. It isn't, that's why I'm asking this question. We've encountered some issues with Technologic's PC-104 implementation before (I believe they were an item about an optional voltage on one pin and something about compatibility with older PC-104 hardware), so it seemed to me that the TS-7800 could be somehow affecting the values coming from the board. Actually, I was hoping to be proved wrong, but between the ARM, the 7800, and the operating environment as a whole, things are not looking good. Thanks for taking the time to think about this and respond! __._,_.___
Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required) Change settings via email: =Email Delivery: Digest | m("yahoogroups.com?subject","ts-7000-fullfeatured");=Change Delivery Format: Fully Featured">Switch to Fully Featured Visit Your Group | Yahoo! Groups Terms of Use | =Unsubscribe __,_._,___ |