Can Analog Pre-Filter (Averaging) be Disabled in EXP?

VEX V5 General Discussion Technical Discussion
1

Hello,

I have an EXP with an analog light sensor. According to the Knowledge Base, all analog ports are pre-filtered for a few milliseconds. I’ve tested this on the EXP and the pre-filter was about 200 msec (analog value 0 before 200 msec, valid output after 200 msec). I’m assuming pre-filter is a moving averaging over those 200 msec.
Is there a way to disable the analog pre-filter and get the instantaneous analog value? I am using VEXcode TEXT for the EXP.

Thank you.

2

The averaging is only over a much shorter period of time, perhaps 1mS (it’s been years since anyone was in that code so I forget exactly). There will be a delay after user code is running before any data is available, and the update rate for sending data from the 3wire ports to the main EXP cpu is every 10mS. But i’ll check if there’s anything unusual going on with the light sensor and EXP sometime in the next few days.

5 Likes
3

I had a quick look at this today. Light sensor plugged in EXP 3wire port A running this code.

//instance of light sensor
vex::light       lg1(Brain.ThreeWirePort.A);

int main() {
    vex::timer t;

    while(1) {
        printf("%6ld %4ld\n", t.time(), lg1.value(analogUnits::range12bit));
        // Allow other tasks to run
        this_thread::sleep_for(10);
    }
}

I was using a LED flashlight that can “flash” at approximately 10Hz, so 50mS on and 50mS off (more or less). The results were as follows, first column is time in mS, second column is raw 12 bit analog value from the sensor.

terminal output 
   0    0
  10    0
  20    0
  30    0
  40    0
  50    0
  60    0
  70    0
  80    0
  90    0
 100    0
 110    0
 120  544
 130  544
 140   26
 150   26
 160   26
 170   26
 180  124
 190  283
 200  420
 210  514
 220  514
 230   26
 240   26
 250   26
 260   26
 270   26
 280   80
 290  239
 300  488
 310  488
 320   26
 330   26
 340   26
 350   26
 360   26
 370   35
 380  194
 390  469
 400  549
 410  549
 420   26
 430   26
 440   26
 450   26
 460  149
 470  306
 480  306
 490  439
 500   26
 510   26
 520   26
 530   26
 540   26
 550   26
 560  105
 570  264
 580  512
 590  512
 600   64
 610   26
 620   26
 630   26
 640   46
 650   46
 660  370
 670  485
 680  567
 690  567
 700   26
 710   26
 720   26
 730   26
 740  159
 750  330
 760  330
 770  457
 780   27
 790   26
 800   26
 810   26
 820   26
 830   26
 840  130
 850  273
 860  425
 870  525
 880   26
 890   26
 900   26
 910   26
 920   86
 930  230
 940  230
 950  391
 960  501
 970   26
 980   27
 990   26
1000   27
1010   27
1020   41

so first 120mS there is no valid data. This is because the 3wire ports are still being configured, they have to be setup to understand that port A is analog input for the light sensor.
but after that the raw analog value is following the light sensor. It’s interesting that the light sensor is slower to respond to light being removed than it is to light present, this seems to be just related to the sensor itself and is nothing to do with any digital filtering in the 3wire firmware.

10 Likes
4

Hi,

This is incredible. Thank you so much for taking time to looking into this. I can confirm that around ~111mS was around when I got valid data following your granular steps. I’m using 200 mS just to be safe.
Does this mean any project that uses 3-wire sensors need at least a ~120mS wait at the top of main() to allow time for the ports to configure?

Best regards

5

With the current version. Generally this isn’t an issue as other things (inertial sensor etc,) need to finish calibration or would be returning 0 anyway. Much of the code for the 3wire sensor came from V5 and, due to dual cpu architecture, initialization was a little complicated. We will take another look at this for EXP and should be able to remove most of that delay for the 1.0.2 release, however, some will always remain.

3 Likes