View Single Post
  #4   Spotlight this post!  
Unread 22-02-2009, 02:24
eugenebrooks eugenebrooks is offline
Team Role: Engineer
AKA: Dr. Brooks
no team (WRRF)
 
Join Date: Jan 2004
Rookie Year: 2001
Location: Livermore, CA
Posts: 601
eugenebrooks has a reputation beyond reputeeugenebrooks has a reputation beyond reputeeugenebrooks has a reputation beyond reputeeugenebrooks has a reputation beyond reputeeugenebrooks has a reputation beyond reputeeugenebrooks has a reputation beyond reputeeugenebrooks has a reputation beyond reputeeugenebrooks has a reputation beyond reputeeugenebrooks has a reputation beyond reputeeugenebrooks has a reputation beyond reputeeugenebrooks has a reputation beyond repute
Re: AnalogModule->GetAverageValue() gives wrong results if polled too fast

I'm at my son's place for the evening now,
and will be driving back home in the morning.
I won't be able to check this thread again until tomorrow
evening.

We had seen the spurious value I had reported on the
previous thread when using the analog input on the same
module as the one measuring the battery voltage. Your
observation does seem to indicate that it was the battery
voltage that was being reported when the spurious value
came through. We also saw spurious values near zero
in other testing, for instance we tried other channels and also
swapping the interface card, and in this case the jumper
for the battery voltage, was likely not hooked up.
This explains the behavior. We never saw a zero spurious
value when the ones associated with the battery voltage were
coming through, so it appears to be confusion with regard to
the analog input used for the battery voltage.

We got no help, so we tossed in the towel on using
the analog input for anything in a feedback loop.

We were detecting spurious values by recording and reporting
a high and low limit for an input that was set up to read
a fixed voltage with a pot. One would pop through every
few seconds or so.

This behavior went away when we upgraded, but it appears that
the problem is still lurking. We ran a system that showed
the glitch every few seconds or so for about 10 minutes and did
not see the problem occur after our upgrade specified in
team update 12. Our cRIO is now in the crate with
the robot, so we can't do any follow-up testing until we get to
the San Jose regional. We had tried both side cars, both bumper
cards, both plugins, and both slots.

We decided not to do anything with analog inputs when we saw
the problem during the build, but have since spent some time developing
a feedback circuit for the SanJose regional as we thought that the
problem was gone. it is not good that the problem is still lurking.

I believe that the spurious values come through one at a time,
with good values on either side, but we will have to check that
carefully in SanJose. One strategy to deal with the
problem for suitably filtered analog inputs would be to lag the
value used by one cycle and look for unreasonable jumps and when
these occur interpolate. Another strategy is to design your analog
system to avoid the value produced by the battery voltage, so you
know when a glitch has put it out of the normal range.
We will have to try this in SanJose if we
see the problem happening with our planned feedback loop.

If you see any more clues or a way to resolve
the problem please post the data.

Eugene

Last edited by eugenebrooks : 22-02-2009 at 02:31.
Reply With Quote