# Ultrasonic gas analyser

Hi,

I am working on a ultrasonic gas analyzer and I used a hc-sr04 sensor for the first test.
To minimize reflection problems I desoldered the transducers and fixed them face to face in a tube.
So the distance is fixed and I measure the time of flight.
From these values I can calculate the speed of sound.

Temperature is also measured. And at a given gas mixture (for example air) the speed of sound can be calculated.
c= (kRT/M)^0,5

When I compared the theoretical and measured values at a given temperature, there was a big difference.
The only thing I can do to calibrate my setup is to change to distance in my code, until the theoretical and measured values are identical.

The real distance between the tx and rx is ~150mm. In my code I had to modify it to ~133mm.
So the difference is quite big.

I also measured the wave form of the hc-sr04 with a scope, the real frequency is ~39.22 kHz.
But the speed of sound in a material is not influenced by the frequency.

So, where this big difference comes from?

My guess is that in that module, the ultrasonic transmitter sends out a burst of say 8 pulses, then the timing circuit starts (rather than at the start of the pulses), and is stopped when the first reflected pulse is detected.

I can't think of anything else that would give you a distance shorter than the actual.

You could try using different distances and seeing if the delta / change in distance is accurate

......or the sensor does not take temperature into consideration and is 'set-up' for a different temperature to that which you are using.

I think the sensor do not need to consider the temperature.

c=(kRT/M)^0,5
c=d/t

R - universal gas constant
T - absolute temperature
M - molecular weight
d - distance of tx/rx
t - time of flight

From these two equations : t =(d^2M/kR*T)^0,5

d,M,k,R are constant for a given gas
T - can change

If T goes up, t goes down so the speed of sound gets higher
My setup measures the time while distance is fixed. So I always get the real speed of sound at a given temperature.

The measured frequency of the tx 39,22 kHz
The periodic time: 1/39220 = 2,549719e-5 sec

Example:

d=0,15m (150mm)
c=343,9 m/s in air at 293,15K temperature

t=d/c=4,36173e-4 sec the time of flight

If the timer starts only at the 3rd pulse, the TOF will be longer by t=t+2*T (skip the 1st and 2nd pulse)

t+2*T =4,87171e-4 sec the time of flight, from this the speed of sound c=0,15/4,87171e-4=307,902 m/s

The difference is 343,9-307,9=36 m/s

How long d is necessary to compensate it?

d=307,9/t=307,9/4,36173e-4
d=134,3 mm

This d=134,3mm correlates quite well with my experiences, but it could be only accidental.

Who knows?

sitto:
Hi,

I am working on a ultrasonic gas analyzer and I used a hc-sr04 sensor for the first test.
To minimize reflection problems I desoldered the transducers and fixed them face to face in a tube.
So the distance is fixed and I measure the time of flight.
From these values I can calculate the speed of sound.

Temperature is also measured. And at a given gas mixture (for example air) the speed of sound can be calculated.
c= (kRT/M)^0,5

When I compared the theoretical and measured values at a given temperature, there was a big difference.
The only thing I can do to calibrate my setup is to change to distance in my code, until the theoretical and measured values are identical.

The real distance between the tx and rx is ~150mm. In my code I had to modify it to ~133mm.
So the difference is quite big.

My guess would be that there is a time bias somewhere in the sensor setup rather than a distance error, that is, I'd adjust the time of flight rather than the baseline distance in the calculation. The HC-SR04 receive detection isn't particularly sophisticated and a time error equivalent to 17mm isn't much to worry about in the typical "collision avoidance" application.

I also measured the wave form of the hc-sr04 with a scope, the real frequency is ~39.22 kHz.
But the speed of sound in a material is not influenced by the frequency.

The HC-SR04's embedded microcontroller has a crystal so I'd expect it to be better than the 2% error you observed, something on the order of 0.1% probably. I have access to a frequency counter, so may try measuring some sample devices when I get a chance. I'd question whether the scope measurement of frequency is accurate to that level.

As an aside, motivated by a poster doing something similar to your project, I collected and posted some time of flight vs temperature data on this thread that you may find of interest: https://forum.arduino.cc/index.php?topic=672863.msg4557324#msg4557324

Just to be clear on your setup, my understanding is that you've removed the transducers from the HC-SR04 board and placed them on opposite ends of a sealed tube with wires to the original board to extend the connect to the transducer. Thus you're measuring a one-way time of flight through the tube.

Please keep us posted on how this project works out.

I used a hantek 6022be scope for the measurement. I do not know how accurate it is.
I measured the wave form directly on the terminals of the tx.

17mm is ok for a collision detection, but I have to measure the speed of sound within 1-2 m/s for accurate gas concentration calculation.

The question is where this time bias comes from. And is it constant or varies with gas composition, temperature....

Can it be influenced by the speed of the arduino board?

I will share my code.

How long is the tube in terms of ping travel time end to end?

Are you timing with millis() or micros()?

``````/* Example code for HC-SR04 ultrasonic distance sensor with Arduino. No library required. More info: https://www.makerguides.com */

#include <RunningAverage.h>

// Define Trig and Echo pin:
#define trigPin 2
#define echoPin 3

int sensorPin = 0;

// Define variables:
double duration;
double distance = 133.45;
double sos = 0;
RunningAverage RA0(20);         // average on xx values
RunningAverage RA1(20);         // average on xx values

void setup() {
// Define inputs and outputs:
pinMode(trigPin, OUTPUT);
pinMode(echoPin, INPUT);

//Begin Serial communication at a baudrate of 9600:
Serial.begin(115200);
}

void loop() {

//getting the voltage reading from the temperature sensor

// converting that reading to voltage, for 3.3v arduino use 3.3
float voltage = reading * 5.0;
voltage /= 1024.0;

// now print out the temperature
float temperatureC = (RA1.getAverage() - 0.5) * 100 ;  //converting from 10 mv per degree wit 500 mV offset
//to degrees ((voltage - 500mV) times 100)

// Clear the trigPin by setting it LOW:
digitalWrite(trigPin, LOW);
delayMicroseconds(5);

// Trigger the sensor by setting the trigPin high for 10 microseconds:
digitalWrite(trigPin, HIGH);
delayMicroseconds(10);
digitalWrite(trigPin, LOW);

// Read the echoPin, pulseIn() returns the duration (length of the pulse) in microseconds:
duration = pulseIn(echoPin, HIGH);
sos = ((distance) / RA0.getAverage()) *1000;

// Print the distance on the Serial Monitor (Ctrl+Shift+M):
Serial.print("Speed of sound = ");
Serial.print(sos,2);
Serial.println(" m/s");
Serial.print("Temperature degrees C = ");
Serial.println(temperatureC,1);

delay(50);
}
``````

You should know that Arduino double is The Same As Arduino float. You get 6 places of sand and dirt IEEE FP.

Kernighan and Plauger: "Floating point numbers are like piles of sand; every time you move one you lose a little sand and pick up a little dirt." If the errors occur at random, we might expect a cumulative error of sqrt(N) εm.

sos = ((distance) / RA0.getAverage()) *1000;

is inherently less accurate than

sos = (distance * 1000) / RA0.getAverage();

You should also not convert the analog read, you lose accuracy doing that (sand and dirt again).

If you want, I can help with integer-izing the average... using read x 1000 for 3 places to average into.
There's room in flash for a square root table with perhaps 2000 elements that can be fetched in under a microsecond.

EDIT: PS

distance = 133.45; // gee I hope that's not 133.45 mm.

The question is where this time bias comes from.

The HC-SR04 circuitry and hardware, obviously. The detectors have to "ring up", the on board microprocessor has to detect one or possibly several pulses, make decisions, etc.

With a little effort you should be able to calibrate the setup, and with different gases, demonstrate that the time offset does not depend on the gas. Vary the distance between the TX and RX elements to get the slope and zero intercept of the detection time as a function of distance.

The 133.45 was the distance when I played with the code and tried to calibrate. "If you want, I can help with integer-izing the average... using read x 1000 for 3 places to average into.
There's room in flash for a square root table with perhaps 2000 elements that can be fetched in under a microsecond."

Could you explaein it a bit more detailed?

I have just made a test.
The tx/rx was fitted in a tube in face to face. The internal diameter was the same as the sensors diameter.
I filled up the tube with CO2.
The difference was huge. The expected speed was 275.38 m/s, but I measured only 188 m/s.
So I removed the sensors and held them approxomately at the same distance by hand.
The measured value in air was different then before.

So the tube influences somehow the speed of sound. Most probably it reflects the waves.

I made another setup, without the tube. And now the result is pretty accurate.
Calculated: 347.14 m/s, measured: 347.45 m/s
And the distance is not compensated. Ofcourse we do not know exactly the source and target point of the sound, it is somewhere inside the sensor that we can not measure. So I set it in the middle of the sensor (in thickness).

I put a bigger tube between the 2 plates that holds the sensors, it still influences the measured value, but the influence is less.
So I have to find the minimal tube diameter which does not influence the speed of sound and than I can test it with different gases.

So the tube influences somehow the speed of sound.

No it does not.

You aren't measuring the speed of sound. You are measuring the total time of various processes, which happen to include the time it takes for pressure variations to move from TX to RX.

jremington:
No it does not.

You aren't measuring the speed of sound. You are measuring the total time of various processes, which happen to include the time it takes for pressure variations to move from TX to RX.

You are right. I was imprecise.

Based on the rough tests I have just made, a 60mm tube can be appropriate. A 162x60 mm tube contains too much gas and it needs to much time to refresh the gas in it.
I suppose if I decrease the distance between the transducers I can also decrease the diameter.

Can I calculate the shortest time of flight based on the speed of the processor that I can detect?
I know the max. speed I want to measure so I could calculate the min. chamber length. And than find the diameter.

For the final device I will use an ESP32 (or teensy).

As a start toward understanding the timing offsets, and how they depend on the experimental apparatus, I would measure the total response times for sensors placed at various accurately measured separations within tubes of given diameters.

At around room temperature the speed of sound in dry air is quite accurately given by 20.05*sqrt(T) m/s, for T in Kelvin, and you can subtract the transit time off to determine the other timing artifacts, and how they vary with other parameters.

sitto:
So the tube influences somehow the speed of sound. Most probably it reflects the waves.

I wouldn't expect the tube to influence the speed of sound unless perhaps the sound where coupled to the tube wall, propagates through that, and couples with the receive transducer.

I would expect that the receive sensor is somewhat sensitive to the amplitude of the signal which would be higher in the tube than in free space. The reason is that the receive sensor does simple leading edge amplitude detection, so the rise time of the receive signal to the detection threshold would be somewhat faster with a higher amplitude signal.

Hi,
What happens if you have a mixture of gases.

What is the application, what is going to use the gas analysis data?

Tom.. TomGeorge:
Hi,
What happens if you have a mixture of gases.

What is the application, what is going to use the gas analysis data?

Tom.. Based on the speed of sound you can calculate the fraction of gases in dual component mixtures.
For example corgon (Ar+He) which used for welding.

More components, more different sensors...

MrMark:
I wouldn’t expect the tube to influence the speed of sound unless perhaps the sound where coupled to the tube wall, propagates through that, and couples with the receive transducer.

I would expect that the receive sensor is somewhat sensitive to the amplitude of the signal which would be higher in the tube than in free space. The reason is that the receive sensor does simple leading edge amplitude detection, so the rise time of the receive signal to the detection threshold would be somewhat faster with a higher amplitude signal.

When the sensors were inside the tube the calculated speed of sound was lower. So more time is necessary for the wave to reach the rx.
That is why at first I decreased the distance in my code and tried to calibrate with it. But it was a wrong way.
The sonar beam is a cone and not a straight line, which intensity decrease in the outer regions. Most probably the sound bumps between the walls before reach the rx.

If you have similar sensor you can try it out. Position the sensor at a fixed distance from a wall. Measure the distance and than put an object close to sensor’s side surface (not in front of it ). You will see that the measured distance will change. There is a threshold when this object does not modify the distance anymore, I suppose it depend on the sensor’s distance from the wall.
If the measured distance is smaller I would expect less influence by the object. Because the sonar’s cone is narrower. But I have to test it.

http://www.acousticsunpacked.org/AcousticBackground/AcousticTransducers.html