Subject:
|
Re: Spurious bad readings from sensors
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Wed, 25 Feb 2004 22:00:28 GMT
|
Viewed:
|
4546 times
|
| |
| |
Hi Mark,
Thanks for the help. In Steve's legway code he reads from LIGHT_1 and LIGHT_3
(even if there is no sensor hooked to LIGHT_3). When I was running his code
with instrumentation for both sensors, I had nothing hooked to SENSOR_3, and I
still got the suprious readings from SENSOR_3.
It would seem the issue is not related to powering the sensor.
Kevin
In lugnet.robotics.rcx.legos, Mark Riley wrote:
> In lugnet.robotics.rcx.legos, Kevin L. Clague wrote:
>
> > I instrumented Steve Hassenplug's legway code so that after it falls over it
> > can dump sensor data and motor control valiables out to a PC.
> >
> > One of the things I noticed in this process is that aperiodically, the sensor
> > inputs give a sensor reading that is way off from the preceding or following
> > readings. The values of these readings are typically 127 or 128 (when reading
> > LIGHT_1 for example). I've using only one EOPD sensor and two other sensors
> > that are read as LIGHT_2, and LIGHT_3. These two sensor inputs also give the
> > spurious sensor readings.
> >
> > The spurious readings do not happen at regular intervals.
> >
> > Is this a known issue with brickOS?
>
> Because of the way BrickOS uses interrupts to handle active sensors, it's
> possible for sensors to be deprived of power for 300us or more, though typically
> the interval is only 30us or so. This is due to long interrupt latencies in
> BrickOS that prevent the A/D conversion ISR from restoring power to the sensor
> in a timely manner.
>
> In a previous post, I outlined the steps taken by the A/D ISR (see the very top
> of message):
>
> http://news.lugnet.com/robotics/rcx/legos/?n=3078
>
> In my firmware, I avoid using the A/D completion interrupt with active sensors.
> Instead, I perform the conversion synchronously:
>
> 1. Cut power to sensor
> 2. Delay for a suitable settling period (usually 10-20us depending on the
> situation)
> 3. Start A/D conversion
> 4. Poll for completion
> 5. Restore power to sensor
>
> This is all done while interrupts are disabled so there's no possibility of
> starving the sensor for power.
>
> Anyway, this is just a theory as to what may be happening. Also, I don't know
> if your EOPD (or the other sensors you mention) are more sensitive to power
> starvation than Lego's standard light sensor.
>
> Mark
|
|
Message has 1 Reply: | | Re: Spurious bad readings from sensors
|
| (...) Could it be noise getting into the analog power supply? If you're switching between brake and full power with the motor ports, it seems possible that some spikes could get through to the A/D converter. You might be able to test this by (...) (21 years ago, 25-Feb-04, to lugnet.robotics.rcx.legos)
|
Message is in Reply To:
| | Re: Spurious bad readings from sensors
|
| (...) Because of the way BrickOS uses interrupts to handle active sensors, it's possible for sensors to be deprived of power for 300us or more, though typically the interval is only 30us or so. This is due to long interrupt latencies in BrickOS that (...) (21 years ago, 25-Feb-04, to lugnet.robotics.rcx.legos)
|
4 Messages in This Thread:
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|