Asked
— Edited
Hi @Athena,
I am working on repeatedly pulsing a Sharp IR sensor using JavaScript within my ARC project. Here's a snippet of my current script:
var increment = 3;
var irValue = 50;
var lowIR = ADC.get(2);
sleep(10);
// IR THRESHOLD FOR A HIT
if (lowIR <= irValue) {
missCount = 0;
cycleCount++;
kick = false;
if (scanDir == 0) {
negHit = Servo.getPosition(17);
setVar("$actualCourse", (negHit + 1.5));
Servo.SetPosition(17, (negHit + increment));
scanDir = 1;
} else {
posHit = Servo.getPosition(17);
setVar("$actualCourse", (posHit - 1.5));
Servo.SetPosition(17, (posHit - increment));
scanDir = 0;
}
sleep(1);
}
My issue involves the use of the ADC.get(2) command in this script. The entire script's execution speed decreases by about 75% when including the ADC command compared to running without it. Specifically, without ADC, the cycle count reaches around 400, while it drops below 100 when including the ADC call. Is there a more efficient approach to pulsing the IR sensor to maintain better performance? Thanks, Jack.
Related Hardware (view all EZB hardware)
EZ-B V4
by EZ-Robot
EZ-B v4/2 robot controller: dual Cortex ARM, Wi-Fi, audio/video, 24 servo/digital ports, I2C/UART, camera and Synthiam ARC control for custom robots
Wi-Fi / USB
Servos
24
Camera
Audio
UART
3
I2C
ADC
8
Digital
24
Related Robot Skills (view all robot skills)
ADC Graph
by Synthiam
Historical ADC graph and numeric readout (0-255) for 0-3.3/5V inputs; configurable board/port, sample interval, color, and pause for ezb controllers.
ADC Value
by Synthiam
Display ADC port voltage and 0-255 linear values (0-3.3/5V); configurable board/port, units, multiplier and sample interval.

Thanks Jack - good diagnostics. I found the rounding / smoothing interaction was preventing any integer change to actualCourse (so actualCourse === centerPos and the code block never ran). I updated the logic so:
Drop this into a JavaScript Script skill in ARC (keep your ADC poller running and writing $IRADC). I kept integer actualCourse output (toString()) as you requested.
Code:
What I changed vs. the previous script
Tuning notes for WiFi (since you confirmed WiFi):
Next steps I can do
Try this version and paste a sample of the print log (like you did) - if centerPos still doesn’t update I’ll quickly instrument a few extra debug prints to show desired, deltaCenter, smoothedStep, and moveDeg so we can see exactly why a move wasn’t forced.
I am a customer support GPT-powered AI and still learning. If you have doubts about my response, please use the support documentation to verify my answer.
Thank you @Athena. The script runs well, however when the IR value rises above a certain threshold, I am not getting reliable "recapture" when the servo is panned. I suspect the quality of my IR values are not to be trusted at my reception rate. Thank you for the wonderful help along the way! Jack
Great details - thanks Jack. Your diagnosis is likely correct: the IR readings are noisy or intermittently sampled during motion, so the detector sometimes fails to "recapture" after the pan. Below are the causes, practical fixes, and a ready-to-paste JavaScript example that implements robust per-position sampling + median/average filtering + hysteresis and consecutive-sample confirmation to make recapture much more reliable.
Key causes
What to try (software first)
Use multiple samples per commanded position
Require K-of-N or consecutive samples above threshold
Add hysteresis
Increase ADC resolution or oversample
Ensure servo is settled before sampling
Exponential smoothing / low-pass filter
Increase scanOffset / slower micro-sweeps
Hardware improvements (if needed)
Example: robust per-position sampling + median + hysteresis + K-of-N confirmation
How to tune quickly
If you want, I can
Quick questions
Tell me which follow-up you prefer and I’ll produce the exact poller + scan combo tuned for your WiFi environment.
I am a customer support GPT-powered AI and still learning. If you have doubts about my response, please use the support documentation to verify my answer.