Making an Ultrasonic Anemometer Using Just 2 Ultrassonic Sensors (HC-SR04)

What small discrepancy?

Each separate trigger only arms the sensor attached to the trigger.

If there is a triggering time discrepancy between the two sensors, it would be systemic, and independent of windspeed: One sensor might deliver a biased low distance, while another might be biased high.

I can see the distances could easily be different in a real device, since each sensor has a separate sender and receiver. With a 0.03m (3cm) separation spacing between a sensor's sender and receiver, just a 1° alignment error could make a 0.03m*sin(1°)=0.0005m difference in lengths of the two paths between the two sensors. Or a 0.03m*sin(1°)/343m/s=1.5us difference in paths.

But if you are using different triggers, each sensor has one upwind slow leg, and one downwind fast leg. If the (effective) differences in distance are negligible, the only thing that is different between the two sensors is whether the upwind slow leg comes before the downwind fast leg or vice versa--the time from ping to echo is the same.

2 Likes

If the two are aligned with the wind... what cross wind?

As was mentioned, put them on a wind vane, get direction from that.

1 Like

In theory, even with different triggers (pulses), as long as the distance differences are negligible (*), what matters is the distance and the time it takes for the sound to travel from one sensor to the other (the oposing sensor's echo).


(*) For example, in the original project where I used different triggers, the measurements for S1_2 (sound from sensor 1 to sensor 2) and S2_1 (sound from sensor 2 to sensor 1) were, 98% of the time, nearly identical, with only a 4-microsecond difference when no wind was present. When wind was introduced at an angle (e.g., 45Âș), the distances would change slightly.

For instance, one distance would decrease while the other would increase. Originally, the distances averaged around 29.70 cm, but with wind, they could change to values like 29.10 cm (downwind) and 30.40 cm (upwind).

Therefore, I believe that as long as there is a delay between both measurements, the ultrasound from the opposing sensor will not interfere with the ultrasound of the sender, even if they do not trigger at exactly the same time, which i concluded by the reactions the project had when put to the test against some turbulence.


The small discrepancy comes from using two different triggers for the sensors, which introduces a slight timing offset between their measurements. While this may cause a small error, it’s important to note that the wind’s effect on sound propagation is much larger than this timing difference.
The sensors don’t fire at the same time — one fires slightly before the other, which introduces a very small timing gap. This is what leads to the discrepancy in the calculation (IMO, I might be totally wrong and "lost in the sauce" already :sweat_smile:).




PS: Sorry if the text is way too much cramped, I wasn't sure how to better organize it.

We seem to agree.

As mentioned a number of times, the code, theory and data analysis in the PDF file posted earlier (e.g. post #88) is basically correct, was tested in a wind tunnel, and shown to work reasonably well.

1 Like

Sure looks that way to me.

50ms is a huge offset. Distance-wise, that 343m/s*0.050=17.15m or more than 50 times the 0.3m distance between the two sensors:

If you are triggering two different sensors 50ms apart, and reading their echo pins, you are getting the 30+30cm ping+echo reflection timing, and the wind signal is lost because the sped-up and the slowed-down propagation (mostly) cancel out.

If you do the simultaneous triggering, both sensors send a ping, but the only pulseIn being read detects the ping emitted from the opposite sensor after one 30cm trip. That ping is sped-up (OR slowed down) by the component of the wind aligned with its path. If you then simultaneous-trigger both pings, and do the pulsein on the opposite sensor, you get the opposite reading, and can extract the wind signal from the time difference of the furst pulseIn vs the second.

The 50ms-different-pin-triggering scheme makes no sense for "an ultrassound anemometer using 2 HC-SR04 sensors".

1 Like

Stuck with ping modules... from the same batch they should send identical peeps. But note that with the wind the peep freq would stretch and against the wind, compress, normally the peep and echo would cancel.
Do ping sensors measure frequency?

If both were triggered by phototransistors aimed to see a led flash halfway between, they would be in synch.

With an electret mic and a piezo buzzer....

Triggering is easy -- you hook them both to the same Arduino pin. (See #93, #88, #29, #36, #35, but not #1 or #96) It's the sensing that's more difficult. You'd have to upgrade from the blocking pulseIn() scheme to detect the opposite tranducer's pings simultaneously-ish.

2 Likes

That’s the thing —I tested the exact same setup. I used his code, pins, and my structure closely resembles his design and distance. Yet, no matter what I tried, I couldn’t achieve anything even remotely close to the results he reported. The values fluctuated far too radically, and regardless of the tests (with or without wind), there was never anything conclusive or consistent—let alone anything resembling the graphs he provided.

Your calculations make sense, but i dont thing the delay is the problem.
I have re-ran the original code (where i use 2 different triggers) and i got the following results in a no wind setting, using the 50ms delay:

Edit: I forgot to remove cloud connection text (that i'm not doing) from the output. This edit was to do remove that.

Sensor 1 time: (t1_2s): 0.001754 s
Sensor 2 time: (t2_1s): 0.001752 s
Sensor 1 distance: 29.818 cm
Sensor 2 distance: 29.784 cm
Time difference: 2 microseconds
---------------------------
Sensor 1 time: (t1_2s): 0.001750 s
Sensor 2 time: (t2_1s): 0.001747 s
Sensor 1 distance: 29.750 cm
Sensor 2 distance: 29.699 cm
Time difference: 3 microseconds
---------------------------
Sensor 1 time: (t1_2s): 0.001754 s
Sensor 2 time: (t2_1s): 0.001752 s
Sensor 1 distance: 29.818 cm
Sensor 2 distance: 29.784 cm
Time difference: 2 microseconds
---------------------------
Sensor 1 time: (t1_2s): 0.001754 s
Sensor 2 time: (t2_1s): 0.001752 s
Sensor 1 distance: 29.818 cm
Sensor 2 distance: 29.784 cm
Time difference: 2 microseconds
---------------------------
Sensor 1 time: (t1_2s): 0.001750 s
Sensor 2 time: (t2_1s): 0.001747 s
Sensor 1 distance: 29.750 cm
Sensor 2 distance: 29.699 cm
Time difference: 3 microseconds
---------------------------
Sensor 1 time: (t1_2s): 0.001754 s
Sensor 2 time: (t2_1s): 0.001752 s
Sensor 1 distance: 29.818 cm
Sensor 2 distance: 29.784 cm
Time difference: 2 microseconds
---------------------------
Sensor 1 time: (t1_2s): 0.001754 s
Sensor 2 time: (t2_1s): 0.001747 s
Sensor 1 distance: 29.818 cm
Sensor 2 distance: 29.699 cm
Time difference: 7 microseconds
---------------------------
Sensor 1 time: (t1_2s): 0.001754 s
Sensor 2 time: (t2_1s): 0.001747 s
Sensor 1 distance: 29.818 cm
Sensor 2 distance: 29.699 cm
Time difference: 7 microseconds
---------------------------

And here with a delay of 10ms in between the reading of the sensors:

Sensor 1 time: (t1_2s): 0.001721 s
Sensor 2 time: (t2_1s): 0.001748 s
Sensor 1 distance: 29.257 cm
Sensor 2 distance: 29.716 cm
Time difference: -27 microseconds
---------------------------
Sensor 1 time: (t1_2s): 0.001755 s
Sensor 2 time: (t2_1s): 0.001747 s
Sensor 1 distance: 29.835 cm
Sensor 2 distance: 29.699 cm
Time difference: 8 microseconds
---------------------------
Sensor 1 time: (t1_2s): 0.001753 s
Sensor 2 time: (t2_1s): 0.001748 s
Sensor 1 distance: 29.801 cm
Sensor 2 distance: 29.716 cm
Time difference: 5 microseconds
---------------------------
Sensor 1 time: (t1_2s): 0.001752 s
Sensor 2 time: (t2_1s): 0.001752 s
Sensor 1 distance: 29.784 cm
Sensor 2 distance: 29.784 cm
Time difference: 0 microseconds
---------------------------
Sensor 1 time: (t1_2s): 0.001752 s
Sensor 2 time: (t2_1s): 0.001752 s
Sensor 1 distance: 29.784 cm
Sensor 2 distance: 29.784 cm
Time difference: 0 microseconds
---------------------------
Sensor 1 time: (t1_2s): 0.001750 s
Sensor 2 time: (t2_1s): 0.001748 s
Sensor 1 distance: 29.750 cm
Sensor 2 distance: 29.716 cm
Time difference: 2 microseconds
---------------------------
Sensor 1 time: (t1_2s): 0.001750 s
Sensor 2 time: (t2_1s): 0.001751 s
Sensor 1 distance: 29.750 cm
Sensor 2 distance: 29.767 cm
Time difference: -1 microseconds
---------------------------

With this results, the delay in between basically has a miniscule influence in the distance that both sensors return (accounting that this was with the 2 different triggers that should not give accurate results.

But by doing this at the same time, shouldn't both ultrassounds interfere a bit with eachother before reaching the desired receiver?

That’s what I did while recreating the project based on the original great PDF sent by jremington, as it makes more sense to send both triggers at the same time. However, as I mentioned, I could never get consistent results. The distances between the sensors (around a +1cm difference (with the original 30cm distance) when they are both in the 13cm output range) and the arrival times just didn’t align well for a windless setting.

Is this the approach you recommended (assuming those zero wind distances)?

// Calibrated zero-wind distances for each sensor (in meters)
const float CalibratedDist1 = 0.2781275;
const float CalibratedDist2 = 0.265827;

// Function to calculate wind speed using the calibrated distances
float calculateWindSpeed(float d1, float d2, long t1, long t2) {
  // Wind speed formula:
  // (d1*1e6/t1 - d2*1e6/t2) / 2
  return (d1 * 1e6 / t1 - d2 * 1e6 / t2) / 2;
}

void loop() {
  // Measure the time for the pulse from sensor 1 to sensor 2
  digitalWrite(TriggerPin, LOW);
  delayMicroseconds(2);
  digitalWrite(TriggerPin, HIGH);
  delayMicroseconds(10);
  digitalWrite(TriggerPin, LOW);
  Duration1 = pulseIn(EchoPin2, HIGH); // Capture time on sensor 2

  // Wait before reactivating
  delay(50);

  // Measure the time for the pulse from sensor 2 to sensor 1 AFTER the first measurement
  digitalWrite(TriggerPin, LOW);
  delayMicroseconds(2);
  digitalWrite(TriggerPin, HIGH);
  delayMicroseconds(10);
  digitalWrite(TriggerPin, LOW);
  Duration2 = pulseIn(EchoPin1, HIGH); // Capture time on sensor 1

  // Calculate wind speed using the calibrated distances
  float windSpeed = calculateWindSpeed(CalibratedDist1, CalibratedDist2, Duration1, Duration2);

}

Gives the following average outputs:

Sensor 1 Distance = 14.195 cm
Sensor 2 Distance = 13.209 cm
Time Difference = 58 microseconds
---------------------------
Sensor 1 Distance = 14.280 cm
Sensor 2 Distance = 13.226 cm
Time Difference = 62 microseconds
---------------------------
Sensor 1 Distance = 14.212 cm
Sensor 2 Distance = 13.209 cm
Time Difference = 59 microseconds
---------------------------
Sensor 1 Distance = 14.212 cm
Sensor 2 Distance = 13.226 cm
Time Difference = 58 microseconds
---------------------------

Which gives values a bit better than the previous ones i had with the same triggers, but still not the ones I'm aiming (not sure why, since i think that line of thought is definitely correct, i might have messed up somewhere). The altered code to get this is as follows:

#include <ArduinoIoTCloud.h>
#include <Arduino_ConnectionHandler.h>
#include <WiFi.h>
#include <Wire.h>
#include <Adafruit_Sensor.h>
#include <Adafruit_BME280.h>

// Wi-Fi credentials
const char WIFI_SSID[] = "TESTE";       // Wi-Fi name
const char WIFI_PASSWORD[] = "TESTE";     // Wi-Fi password

// Variables synchronized with the Arduino IoT Cloud
float temperature;
float humidity;
float pressure;
float windSpeed;
float windDirection;
String beaufortCategory;

// Configuration of ultrasonic sensor pins
const int TriggerPin = 9; // Single trigger pin for both sensors
const int EchoPin1 = 10;
const int EchoPin2 = 12;

// Variables to store the time measured by the ultrasonic sensors
long Duration1 = 0;
long Duration2 = 0;

// Distance between sensors (in meters)
const float DistanceBetweenSensors = 0.3; // 30 cm

// Calibrated distances (zero-wind) for each sensor (in meters)
// Calculated from the speed of sound (341.68 m/s) and measured times
// DistTo1 = 341.68 m/s * 0.000814 s = 0.2781275 m
// DistTo2 = 341.68 m/s * 0.000778 s = 0.265827 m
const float CalibratedDist1 = 0.2781275;
const float CalibratedDist2 = 0.265827;

// I2C address for the BME280 sensor
#define BME280_ADDRESS 0x76

// Create an object for the BME280 sensor
Adafruit_BME280 bme;

// Function to calculate the speed of sound using the thermodynamic formula
float calculateThermodynamicSoundSpeed(float temperature) {
  const float gamma = 1.4;     // Ratio of specific heats for dry air
  const float R = 8.314;       // Universal gas constant [J/(mol·K)]
  const float M = 0.0289644;   // Molar mass of dry air [kg/mol]

  // Convert temperature from Celsius to Kelvin
  float temperatureK = temperature + 273.15;

  // Apply the thermodynamic formula
  return sqrt((gamma * R * temperatureK) / M);
}

// Function to calculate the wind speed using the calibrated distances
float calculateWindSpeed(float d1, float d2, long t1, long t2) {
  // Wind speed formula:
  // (d1*1e6/t1 - d2*1e6/t2) / 2
  return (d1 * 1e6 / t1 - d2 * 1e6 / t2) / 2;
}

// Function to classify wind speed based on the Beaufort scale
String beaufortScale(float windSpeed) {
  // Treat negative and positive values equally (abs)
  if (abs(windSpeed) < 0.3) return "Calm";
  if (abs(windSpeed) < 1.6) return "Very Light Breeze";
  if (abs(windSpeed) < 3.4) return "Light Breeze";
  if (abs(windSpeed) < 5.5) return "Gentle Breeze";
  if (abs(windSpeed) < 7.9) return "Moderate Breeze";
  if (abs(windSpeed) < 10.7) return "Strong Breeze";
  if (abs(windSpeed) < 13.8) return "Fresh Wind";
  if (abs(windSpeed) < 17.1) return "Gale";
  if (abs(windSpeed) < 20.7) return "Strong Gale";
  if (abs(windSpeed) < 24.4) return "Storm";
  if (abs(windSpeed) < 28.4) return "Violent Storm";
  return "Hurricane";
}

// Initialize variables in the IoT Cloud
void initProperties() {
  ArduinoCloud.addProperty(temperature, READ, 1 * SECONDS, NULL);
  ArduinoCloud.addProperty(humidity, READ, 1 * SECONDS, NULL);
  ArduinoCloud.addProperty(pressure, READ, 1 * SECONDS, NULL);
  ArduinoCloud.addProperty(windSpeed, READ, 1 * SECONDS, NULL);
  ArduinoCloud.addProperty(beaufortCategory, READ, 1 * SECONDS, NULL);
}

// Configure the connection handler
WiFiConnectionHandler ArduinoIoTPreferredConnection(WIFI_SSID, WIFI_PASSWORD);

void setup() {
  // Initialize serial communication
  Serial.begin(9600);
  while (!Serial);

  // Configure ultrasonic sensor pins
  pinMode(TriggerPin, OUTPUT);
  pinMode(EchoPin1, INPUT);
  pinMode(EchoPin2, INPUT);

  // Initialize the BME280 sensor
  if (!bme.begin(BME280_ADDRESS)) {
    Serial.println("Failed to initialize the BME280 sensor. Check the connections.");
    while (1); // Error case
  }

  // Initialize the IoT Cloud
  initProperties();
  ArduinoCloud.begin(ArduinoIoTPreferredConnection);

  Serial.println("Setup complete!");
}

void loop() {
  // Update the IoT Cloud
  ArduinoCloud.update();

  // First activation: measure the time to travel from sensor 1 to sensor 2
  digitalWrite(TriggerPin, LOW);
  delayMicroseconds(2);
  digitalWrite(TriggerPin, HIGH);
  delayMicroseconds(10);
  digitalWrite(TriggerPin, LOW);
  Duration1 = pulseIn(EchoPin2, HIGH); // Capture time at sensor 2

  // Wait before reactivating
  delay(50);

  // Second activation: measure the time to travel from sensor 2 to sensor 1
  digitalWrite(TriggerPin, LOW);
  delayMicroseconds(2);
  digitalWrite(TriggerPin, HIGH);
  delayMicroseconds(10);
  digitalWrite(TriggerPin, LOW);
  Duration2 = pulseIn(EchoPin1, HIGH); // Capture time at sensor 1

  // Use fixed distance between sensors (0.3 meters / 30 cm)
  float Distance1_cm = DistanceBetweenSensors * 100.0; // 0.3 meters to cm
  float Distance2_cm = DistanceBetweenSensors * 100.0; // 0.3 meters to cm

  // Readings from the BME280 sensor
  temperature = bme.readTemperature();
  humidity = bme.readHumidity();
  pressure = bme.readPressure() / 100.0F;

  // Calculate the speed of sound using the thermodynamic formula
  float soundSpeedThermodynamic = calculateThermodynamicSoundSpeed(temperature);

  // Calculate the wind speed using the calibrated distances
  windSpeed = calculateWindSpeed(CalibratedDist1, CalibratedDist2, Duration1, Duration2);

  // Adjust to ignore sensor fluctuations
  if (windSpeed > -0.196 && windSpeed < 1.297) {
      windSpeed = 0; // Natural fluctuation, treat as 0
  } else if (windSpeed <= -0.196) {
      windSpeed += 0.196; // Compensate for the lower limit
  } else if (windSpeed >= 1.297) {
      windSpeed -= 1.297; // Compensate for the upper limit
  }

  // Classify the wind speed on the Beaufort scale
  beaufortCategory = beaufortScale(windSpeed);

  // Display the results as in the original code
  Serial.print("Sensor 1 Distance = ");
  Serial.print(Distance1_cm, 3);
  Serial.println(" cm");

  Serial.print("Sensor 2 Distance = ");
  Serial.print(Distance2_cm, 3);
  Serial.println(" cm");

  // Calculate and display the time difference between the sensors
  long TimeDifference = Duration1 - Duration2;
  Serial.print("Time Difference = ");
  Serial.print(TimeDifference);
  Serial.println(" microseconds");

  // Display BME280 sensor readings
  Serial.print("Temp: ");
  Serial.print(temperature);
  Serial.print(" °C | Hum: ");
  Serial.print(humidity);
  Serial.print(" % | Press: ");
  Serial.print(pressure);
  Serial.println(" hPa");

  // Display sound speed
  Serial.print("Sound Speed (Thermodynamic): ");
  Serial.print(soundSpeedThermodynamic);
  Serial.println(" m/s");

  // Display wind speed
  Serial.print("Wind Speed: ");
  Serial.print(windSpeed);
  Serial.print(" m/s (");
  Serial.print(beaufortCategory);
  Serial.println(")");

  Serial.println("---------------------------");

  delay(3000);
}

No. 50ms or 10ms delay between making a 1.753ms long ping (29.784cm one way and 29.784cm echoing back) shouldn't make any difference. All these show you is that if you measure from A to B, you get about the same answer as measuring from B to A. And that if you measure the distance between two posts, it doesn't change much in 10ms or 50ms. That is true with either a echosounding ultrasonic sensor, or a measuring stick. That result is exactly what one would expect, and is boring and completely useless for measuring wind speed.

No, because superposition. They are travelling different directions and will pass through each other.

And the best one:

If your calculations say the posts were at a distance of 13 cm apart when they were actually 30cm apart, there was something wrong with your physics/calculation.

2 Likes

How? That code doesn't print anything. And it doesn't do any distance calculations.

And the output doesn't match this code either:

2 Likes

Makes total sense, but my question arises when i put both sensors on the same trigger pin, since both of them vary way too much in the measurements from 1 to 2 / 2 to 1, that's why i went and tried with the different pins again (since i remembered the distances matched).

Thanks alot, cleared a lot of questions I had in the beginning about ultrasounds (had i known that i would have not lost a long time planning the first structure where the sensors wouldn't be aiming at eachother).

Edit for clarity: The distances measured by the sensors for the trip from one sensor to the other were consistently around 13 cm, while the expected distance in the code and calculations was set to 30 cm (when using the same trigger).



I have been manually removing the other "useless" information about a certain post from the output everytime, since the output i get on the IDE here is way bigger than what i showed. I remove those infos just for the sake of clarity, it was my mistake to remove the calculations and other important values.
Here was the original output i believe:

Sensor 1 Distance = 14.195 cm
Sensor 2 Distance = 13.209 cm
Time Difference = 58 microseconds
Temp: 16.81 °C | Hum: 71.54 % | Press: 983.10 hPa
Sound Speed (Thermodynamic): 341.35 m/s
Wind Speed: -4.32 m/s (Light Breeze)
---------------------------
Sensor 1 Distance = 14.280 cm
Sensor 2 Distance = 13.226 cm
Time Difference = 62 microseconds
Temp: 16.80 °C | Hum: 71.50 % | Press: 983.08 hPa
Sound Speed (Thermodynamic): 341.35 m/s
Wind Speed: -5.09 m/s (Light Breeze)
---------------------------
Sensor 1 Distance = 14.212 cm
Sensor 2 Distance = 13.209 cm
Time Difference = 59 microseconds
Temp: 16.80 °C | Hum: 71.49 % | Press: 983.08 hPa
Sound Speed (Thermodynamic): 341.35 m/s
Wind Speed: -4.52 m/s (Light Breeze)
---------------------------

I am coding in my main language so are my piers, I am not coding in english. Every output and code is in my main language, so before i send out my outputs and codes, I send them either to google translator for small stuff or into a chatbot for translation.
Sometimes the chatbot doesn't return all that I sent out, even tho I always give a small look to see if its correct (but checking 200 lines everytime i send code makes me slip up sometimes.

???

I cleared out the text a bit more, sorry for the confusion

If the distance between the posts is about 30cm, then the time it takes for an ultrasonic post to travel from one post to the other is about 0.3m/343m/s=874us If there is a 10m/sec wind carrying the pulse, then it would take 0.3m/(343m/s+10m/s)=0.849us, or 25us less time. If the times are about two times as long, 2*874us=1750us, then the sound traveled twice as far, from one post to the other and back.

The trick for an ultrasonic anemometer is to measure the time it takes for a ping to travel from one post to the other and calculate the speed: 0.3m/0.000849s=353m/sec, which is 10m/s faster than the 343m/s speed of sound in still air.

The extra trick in this project, is that if you mis-use the HC-SR04 devices in this project by triggering them both at the same time and ignoring one of them, you can measure the one-way travel time, instead of the designed two-way ping+echo travel time that the HC-SR04s. Most of the code you see (and AIs are trained on) is written for HC-SR04 device used in the as-designed manner, with the two-way travel time.

Another trick that the project uses is that if you measure the speed both ways, you can measure the downwind travel time (and speed) and the upwind travel time (and speed), and use the two equations and two unknowns to calculate both the speed of sound (and the speed of the wind): Half the difference between the two speeds is the speed of the wind, and the average of the two speeds is the speed of sound.

One problem with using these devices in the real world, is that they are not perfect, are not designed to listen for other device's echos, and are not perfectly positioned. I think these issues might be sufficient to cause differences in the effective distance between the emitters and receivers on the opposite sensor devices, which changes the times and calculated speeds over the paths. Which, in turn, can cause some of the systemic errors you've shown.

Ideally, one would build an ultrasonic anemometer with transceivers that would operate as both emitters and receivers and can send and measure the pulse from one end to the other or in the reverse. This could eliminate some of the matching and alignment problems. But that would take more signal processing and be a more expensive/complicated device than the HC-SR05.

With the data you collected earlier in the no-wind situation, I calculated separate distances to make the result of the calculation come out to zero wind. If you assume the speed of sound is constant throughout the zero-wind measurement, then if there's a difference in times, the dist=speed*time equation means there must be a difference in the distances. If it was my project, rather than calculating and hard-coding the separate distances, I'd probably add a potentiometer to adjust the ratio between the two distances so that in zero wind, I could zero the reported wind speed.

From my end of this conversation, reported distances near 15cm on a 30cm baseline appear like mistakes where you completely misunderstand the physics of how an ultrasonic anemometer could work. Maybe filtering code and text through an AI is changing things to look more like the common as-designed use of the devices, rather than the necessary mis-use of these devices for one-way measurements.

The simultaneous triggering of the devices is necessary for the one-way speed measurement calculations for an ultrasonic anemometer using the common HC-SR04 modules.

1 Like

All of the posts by @DaveX and @jremington beg for the additional question:

How could the OP's professor possibly have...

It would be interesting for the OP's professor to "join this chat".

There's no way I'm going to get any better advice than this—I really appreciate you for helping me understand where I was going wrong and for giving me that super well formulated answer.

However, at the moment I have to put the project on hold due to a heavy school workload. I've already submitted the work to my teacher (the project using the sensors on the same pin), and it turns out that the readings are only accurate about 1 in every 4–5 attempts. This suggests there might be calibration issues or additional interference that I haven't been able to address.

For now, I'll be pausing development, but I might return to it in a couple of months.

Thanks to everyone who contributed to this thread; your help has been incredibly valuable.

Kind regards!

This is a proof of concept. With our tests we saw that there were accurate values even on a very big size sample, so the problem lies in calibration, interference with some tests or (very unlikely) on one of the sensors. And I don't think he would be very keen on joining, he even recomended me to be careful on the tips i saw here that could lead me to a dead end.
Thanks still

1 Like

I'm skeptical about that, for all of the reasons mentioned in this thread (which your professor apparently did not consider, so it is unfortunate that he didn't join the chat; if he did, he may have learned something).

In other words, it is possible (and likely imho) that your "accurate values" are just accidents.

1 Like