--- In "Anouk Ahamitet" <> wrote:
>
>
> --- In "charliem_1216" <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 the 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
> your 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 floating 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. I hear that information is most
> arcane.
Well that part does look a little obfuscated, but you weren't using it on x86
either, so it shouldn't matter. Slightly bad calibration would cause some
linearity problems, but wouldn't cause variances on a steady sample.
>
> > 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!
>
So you can reproduce the variance even when acquiring single samples in a tight
loop?
Sorry, I'm out of suggestions. Good luck with your project; it seems you
mostly have your mind made up that there is a hardware problem.
If you find anything more digging deeper, please post your results.
regards, ....... Charlie
------------------------------------
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/ts-7000/join
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|