Above is a bunch of HC-SR04 ultrasonic ranging sensor.

Above is a plot of the simulated dam level measured over a fixed range of about 2.4m. For hours, the data is pretty tightly clustered, and would be quite suitable for this application. This is after tweaking algorithms to take the median of 13 measurements to try to eliminate ridiculously wrong measurements.

Then…

we see occasional spikes that make the sensor quite unsuitable to the application.

The four units tested all show similar problems.

These are relegated to the Cheap Chinese Junk category.

A work in progress…

]]>Above is the HC-SR04 ultrasonic ranging sensor, it was purchased for around $6 from a local eBay seller and delivered within days. Note that there are somewhat similar looking things with a second board on the back and a different interface, the basic HC-SR04 as pictured suits this project.

In this second trial, the battery saving feature has been activated. It powers the HC-SR04 on for each measurement, waiting 600ms for the HC-SR04 to stabilise.

Previous versions of the tanklevel project have used a switch designed around two bipolar transistors, this test was of a AQY212EH Photomos chip which is easily driven by the 3V MCU pin via a 470Ω resistor, and the MOS output can switch 500mA with 60V withstand and very low ON resistance.

The Photomos has been very successful, works very well, very simple circuit, and very low cost.

A series of tests were conducted of range to a hard surface at a distance of about 2200mm and calculated ‘tank’ level and temperature plotted over time. Temperature is measured on the prototype breadboard using a DS18B20, and calculation of distance is compensated for the variation in velocity of sound with temperature.

We might expect some measurement noise, but the occasional glitches are unexpected.

The problem might be with the individual device, it is cheap Chinese hardware and that hints low quality. Some more are coming (on a slow boat from China) and will be trialed.

A work in progress…

]]>Above is the JSN-SR04T-3.0, a waterproof transducer on a cable and the electronics board. The protocol is HC-SR04 PWM. No specifications or datasheet were found (other than the seller’s brief description).

A short trial was conducted with range fixed at 2.3m. Occasionally the measurements were wild.

Above is the plotted simulated dam volume, occasional spikes that are grossly in error.

0.00718 0.007198 0.008108 0.009086 0.01335 0.013393 0.013413 0.013421

Above is an example set of eight successive pulse width measurements sorted ascending. There is a huge spread and not even the median would be a good estimator.

Nevertheless, zooming in on the data we can see that the temperature compensation scheme is working.

The sensor did not respond proportionately to range for range less than about 0.25m.

This is one to dismiss as unsuitable.

A work in progress…

]]>Some correspondents have expressed problems using BME280 modules that they bought online, and it is usually because they have been cheated by online sellers misrepresenting BMP280 as BME280.

My projects that include code to initialise and read BME280 humidity will fail on a BMP280… check to see if the humidity results returned look sane. A driver may read the ChipID and fault on the ID returned by a BMP280.

The Bosch chips are usually visually different, and most clones likewise.

Above, the BME280 is a small square package, about 2.5mm each side.

Above, the BMP280 is a smaller rectangular package. The modules are usually quite a bit cheaper, but they are NOT compatible with the BME280.

If you don’t want humidity measurement, the BMP280 is sufficient, and usually quite a bit cheaper.

The words replaces or compatible are strong indications of an attempt to confuse and perform a “bait and switch”. My own practice is to scour the eBay listing for any pics or specifications that are for BMP280 and if found, reject them. Listings that describe the module as including temperature pressure and humidity, and with pics that show the small square chip are lower risk. That said, I have obtained eBay refunds for more than half my purchases, BMP280s wind up in the bin.

]]>So far, support is provided for HC-SR04 (and things that emulate its PWM mode), MB1242 (and emulations like GY-US42v2).

A work in progress…

]]>

Above is the GY-US42v2 ultrasonic ranging sensor, it was purchased for around $14 on Aliexpress delivered within 10 days.

This sensor has three operating modes, I2C, RS232, and PWM (HC-SR04 compatible). The tests reported here are PWM mode, so it is working with exactly the same code as IoT water tank telemetry project – HC-SR04 – first trial.

The basic operation is that a short pulse is sent on the TRIG pin and a short while later, a pulse occurs on the ECHO pin of duration equal to the round trip time. The speed of sound is about 340m/s @ 20°, and so the distance to the water can be calculated. Because the speed of sound is a little dependent on air temperature, the project incorporates a DS18B20 one wire temperature sensor to feed a compensation calculation.

We might expect some measurement noise, and over this trial the standard deviation is 1.9mm over the last 100 observations. To the eye, it appears that the temperature compensation is fairly good.

Above is an example using I2C mode where the range reading is rounded to cm. In this scenario, the target range is constant, but we we some variation in temperature and compensated range measurement rolling into the simulated dam volume measurement. The steps are due to the cm rounding, and we observe that those coarse steps do not appear in the PWM mode.

The code was written to deal with the variance of the HC-SR04 sample, and it made eight measurements, discarded the two highest and lowest, and took the mean of the remaining four for a significant improvement in variance of observations. This is not necessary with this sensor, the standard deviation of a set of eight measurements is similar to that of 100 observations, so it proves the the outliers with the HC-SR04 were due to the HC-SR04 rather than the tanklevelu code and hardware. More HC-SR04 are on order and will be tested to see if the issues are exhibited by the type in general.

Performance is much better than observed with the HC-SR04 trial. This device has the advantage of a single transducer, and support for I2C.

The I2C mode unfortunately returns range as an integer number of cm, so it becomes quite coarse… not very suited to a shallow tank such as a machine coolant tank. Further, that on tests in I2C mode, it gives unreliable results for ranges less than 20cm, typically indicating longer distances possibly multiple round trips.

These are sold to the UAV market, but I don’t think I would try one as finding that at distances below 20cm, the readings double or worse suggesting that might cause serious instability to an automated landing using the ultrasonic for altitude sensing.

Overall, a much better sensor than the HC-SR04 tried, but the short range limit and limitations on its I2C mode may be unacceptable in some applications.

Searches for a datasheet have been unsuccessful. Some sellers point to the Maxbotic MB1242, suggesting then that this might be a cheap clone of that device.

A work in progress…

]]>Above is the HC-SR04 ultrasonic ranging sensor, it was purchased for around $6 from a local eBay seller and delivered within days. Note that there are somewhat similar looking things with a second board on the back and a different interface, the basic HC-SR04 as pictured suits this project.

A series of tests were conducted of range to a hard surface at a distance of about 250mm and calculated ‘tank’ level and temperature plotted over time. Temperature is measured on the prototype breadboard using a DS18B20, and calculation of distance is compensated for the variation in velocity of sound with temperature.

We might expect some measurement noise, but the step variations are unexpected. The steps do not correlate well to temperature, are they the results of some periodic internally triggered recalibration process?

Within each step zone, variance looks to be 2mm, but there are steps of 7mm or so that really degrade overall variance. The plot does not give reason the question the temperature compensation.

Is this a defect in an individual device, or is it somethings they all exhibit?

Now there are different ‘versions’ of the HC-SR04 sold online, the question is whether they share the same firmware and might inherit the same defect.

I have purchased some more of these from China, the item listing showed a different PCB silksceen, but hey this is China, you never know what you get till you get it, if you get it, get it?

I also ordered another type of sensor, a GY-US42 which appears to be ‘inspired’ by an I2CXL-MaxSonar-EZ MB1242. It is an I2C device, so requires some code rewrite to support it. It is a more expensive device, but has some advantages, include that it transmits and receives from a single transducer.

This can also be used in RS232 mode and HC-SR04 compatible pulse mode.

Another interesting device is the JSN-SR04T-3.0 which uses a waterproof transducer separated from the electronics. This appears to support HC-SR04 compatible pulse mode. This appears to be a wide angle sensor, and possibly not suitable to the application… nevertheless one was ordered for trial.

A work in progress…

]]>Above is the HC-SR04 ultrasonic ranging sensor, it was purchased for around $6 from a local eBay seller and delivered within days. Note that there are somewhat similar looking things with a second board on the back and a different interface, the basic HC-SR04 as pictured suits this project.

The basic operation is that a short pulse is sent on the TRIG pin and a short while later, a pulse occurs on the ECHO pin of duration equal to the round trip time. The speed of sound is about 340m/s @ 20°, and so the distance to the water can be calculated. Because the speed of sound is a little dependent on air temperature, the project incorporates a DS18B20 one wire temperature sensor to feed a compensation calculation.

The project incorporates a means of calculating the volume of water from depth.

For simple tanks with vertical sides, the volume per increment of depth is uniform, but for more general shapes, eg a natural earth dam, that is not so.

Agricultural agencies have published lots of guides on estimating dam volume from surveys of the form during or after dam construction. For the purpose of testing of the software, a simple ‘sperical cap’ form is assumed. This example is that of a spherical bowl of radius 100m and maximum depth of 5m, giving a maximum capacity of 7.7Ml.

The dam profile is characterised by a small set of points from which a cubic spline interpolation provides a stepless response.

Above is the dam characteristic, volume in m^3 vs height in m.

To make things easier for the system, the dam characterisation is formatted in a file dam.xy in a way that makes interpretation quicker / easier for the lua system.

Entry{0.000,0.000} Entry{1.000,313.112} Entry{2.100,1375.744} Entry{3.000,2799.159} Entry{4.000,4959.528} Entry{5.000,7723.082}

Above is the table of depth,volume pairs characterising our dam.

Above is a plot of the dam characterisation and a plot of the cubic spline interpolation.

In fact the sensor measures the height above the water, so depth must be calculated from that. The code incorporates a linear interpolation function that deals with the negative slope of the function to convert measured distance to depth, and provides also for an intercept to correct for offset.

The calculated depth is then used to calculate the volume using the cubic spline interpolation.

A test was performed indoors over a fixed distance of 0.75m to assess measurement noise (or jitter) and validate the temperature compensation.

Above is a chart of calculated volume and environment temperature. It looks pretty good, lets expand the scales.

The plots suggest that long term, the temperature compensation is good, though there might be some very small dynamic variations due to sensor lag and air currents. To put it in perspective, the standard deviation of volume over the 100 measurements is 0.074%, that is quite good.

A work in progress…

]]>Starting with some basic magnetism…

The inductance of an inductor is given by \(L=N\frac{\phi}{I}\).

For a closed magnetic circuit of high permeability such as a ferrite cored toroid, the flux is almost entirely contained in the core and the relationship is \(\mathcal{F}=\phi \mathcal{R}\) where \(\mathcal{F}\) is the magnetomotive force, \(\phi\) is the flux, and \(\mathcal{R}\) is the magnetic reluctance. (Note the similarity to Ohm’s law.)

Rearranging that we have \(\phi=\frac{\mathcal{F}}{\mathcal{R}}\).

Permeance \(\mathcal{P}=\frac1{\mathcal{R}}\) we can rewrite the above as \(\phi=\mathcal{F} \mathcal{P}\). Permeances of parallel magnetic paths add, so if we stack two cores sharing the same winding, the total permeance is the sum of that of each core \(\mathcal{P}_t=\mathcal{P}_1+\mathcal{P}_2+…\).

So, returning to the inductance of the toroidal ferrite cored inductor, we can write that \(L=N \frac{\mathcal{F} \mathcal{P}}{I}\) and since \(\mathcal{F}=N I\), \(L=N \frac{N I \mathcal{P}}{I}\) which simplifies to \(L=N^2 \mathcal{P}\).

Now for a toroid \(\mathcal{P}=\mu\frac{A}{2 \pi r}\) and so \(L=N^2\mu\frac{A}{2 \pi r}\). Since A=f(r), we must integrate A over r. (Note that \(\mu=\mu_0 \mu_r=4e-7 \pi\mu_r\).)

Inductance of a toroidal ferrite cored inductor then is given by \(L=\mu N^2 \int \frac{A}{2 \pi r}dr\) (noting that µ is a complex quantity and frequency dependent). More properly, the ‘inductor’ is a resonator and as you approach its self resonant frequency, inductance alone is not an adequate model… nevertheless consideration of the simpler inductance calculation gives valuable insight.

If we stack two cores of the same physical size side by side, then µ is not uniform across the cross section, so we must capture µ in the integral \(L=N^2 \int \frac{\mu A}{2 \pi r}dr\).

In the simple case where we stack n1 cores of µ1 and n2 cores of µ2, then the expression can be simplified to \(L=(n_1 \mu_1 + n_2 \mu_2) N^2 \int \frac{A}{2 \pi r}dr\) where \(\frac{A}{2 \pi r}\) is the geometry of the consituent cores.

Readers will see that stacking one #61 mix core with one #43 mix core of the same sizes is roughly equivalent to a core of the combined cross section area with µ characteristic an average of the two mixes.

This is not equivalent to series connection of two separate inductors with each core type and same number of turns, the effects around self resonances will differ. Since to some extent, common mode chokes rely upon self resonance (albeit low Q) for their operation, this difference in response is quite relevant. Dissipation capacity is likely to be different.

In the light of that understanding, put your thinking cap on when you see magic properties ascribed to this configuration.

Note, this analysis does not address the behavior near or above the self resonant frequency.

]]>This project is based on ESP8266 IoT DHT22 temperature and humidity – evolution 3, but uses the Bosch BME280 temperature, humidity and pressure sensor. The BME280 has been around for a couple of years, though recently, modules using the chip have become more expensive on eBay, around $10. If you find BME280s listed for much less than that, it is probably Chinese cheats doing a bait and switch… delivering BMP280 (pressure only).

Above is a screenshot of recent data displayed on Thingspeak.

Code is at https://github.com/owenduffy/bme280r .

The MQTT version is also under active development, the code as it evolves is available online https://github.com/owenduffy/bme280m/ .

]]>