To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.robotics.rcx.legosOpen lugnet.robotics.rcx.legos in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Robotics / RCX / legOS / 3686
3685  |  3687
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
    

Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR