Link to lab: https://itp.nyu.edu/physcomp/labs/labs-arduino-digital-and-analog/lab-sensor-change-detection/
For the analog sensor threshold detection, with the code from the lab, pressing hard on the sensor causes it to register more than one passing of the threshold:
Serial port output for the program example in the “Program the Microcontroller to Read a Sensor Threshold Crossing” section of the lab (linked above).
I decided to stick with the CLI, but because I’ll be using the commands a lot, I added some function shortcuts for this board’s setup to my shell’s configuration file to save me some typing:
export IOT_PORT=/dev/cu.usbmodem14401
export IOT_FQBN=arduino:samd:nano_33_iot
function arduino-iot-compile() {
arduino-cli compile --fqbn $IOT_FQBN $1
}
function arduino-iot-upload() {
killall screen
arduino-cli upload -p $IOT_PORT --fqbn $IOT_FQBN $1
}
function open-iot-port() {
screen $IOT_PORT
}
For reading the pushbutton, at first I made a mistake and connected it to digital pin 3 instead of digital pin 2, which the program was reading (shout-out to Apoorva for trying to help me debug this, even though I didn’t figure it out until I looked again later). Something interesting happened — the signal from input 2 still read as HIGH when the button was first pushed down, sometimes oscillated between HIGH and LOW briefly, and then went back to LOW. This meant that the first couple examples actually worked, since they only check for when the state changes to HIGH. In this case I would expect the read input to stay at LOW, since there is nothing connected to pin 2; why would does still read a change when the button isn’t connected to it? This didn’t happen when I tried instead connecting the button to digital pin 4, so does it have something to do with the proximity between pins 2 and 3?
Setup where button is connected to digital pin 3 instead of digital pin 2
In the section on dealing with noise when reading a peak value, the lab shows this diagram to explain how noise might interfere with the sensor reading:
Wouldn’t the first peak value code already deal with this situation, since it doesn’t record/print the peak value until after the sensor value falls back below the threshold? It seems to me like the modification suggested helps not with handling local peaks in general (which the original code already does), but specifically with handling small local peaks that cross the threshold, like this: