Tank sensors/Raspberry Pi fun...

[chalsall]

So, I'm working on a DIY project to measure the water levels in our various pottable-water and rain-water tanks using a Raspberry Pi and HC-SR04 ultrasonic sensors.

I wrote a quick and dirty C program to trigger the USS module as fast as the specs allowed (10 ms delay after falling edge to next trigger), and measure the echo pulse. Things worked fine on the breadboard so next, I installed a sensor in one of the tanks.

The tank was full, and I got a steady and accurate measurement. Reproducible +/- 0.2 mm accuracy (average of approximately 65 measurements per second every one minute). Great, I thought.

So, to make sure it would be able to measure the tank when empty, I started slowly moving the water from this tank to another, logging the measured distance vs. physically measured water levels every hour or so. Everything was fine for a while; ~0.3% standard deviation.

And then, suddenly, the SD jumped to ~11%, with wildly unrepeatable measurements.

Thinking maybe there was some background task interfering with my process, I tried shutting down as many services as I could, including the WiFi and Bluetooth hardware. Nope. Tried setting the process affinity explicitly. Nope...

Finally, I noticed that while the "Highest" returned measurement within a sample set wasn't that far from the expected, the "Lowest" was often wildly low.

Increased the 10 ms delay to 50 ms, and the SD returned to sane. I'm guessing that as the water level dropped there was an increased amount of echoing of the ultrasonic waves still bouncing around in the tank which was triggering the sensor.

Real-world sampling is fun!!!

[Xyzzy]

Wouldn't a few samples a minute be just as useful?

[chalsall]

Originally Posted by Xyzzy

Wouldn't a few samples a minute be just as useful?

Nope. Each individual measurement from the HC-SR04s can be out by as much as +/- 8mm. Since I'm doing measurements of slow-changing water levels rather than real-time robotics, taking the average of lots of samples is working fine.

[xilman]

Originally Posted by chalsall

Nope. Each individual measurement from the HC-SR04s can be out by as much as +/- 8mm. Since I'm doing measurements of slow-changing water levels rather than real-time robotics, taking the average of lots of samples is working fine.

The phrase "robust statistics" comes to mind.

Have you tried using the (perhaps running) median rather than the arithmetical mean to estimate the level?

[chalsall]

Originally Posted by xilman

The phrase "robust statistics" comes to mind. Have you tried using the (perhaps running) median rather than the arithmetical mean to estimate the level?

Looking into all kinds of things, including that. I just started getting data out of my code, so I plan to pull the raw data into some Perl code to see what would work best (and then implement in the C code).

I also forgot to mention that I already know how much the tanks fill as a function of rain-fall. So I plan to implement an automatic valve activation for our drip irrigation based on how much rain has fallen, taking into consideration how much water we have available.

[chalsall]

Originally Posted by chalsall

Looking into all kinds of things, including that.

Something weird is going on. Probably the stupid programmer; perhaps trying to use a non-RT kernel to take precise measurements is ill-advised. But why is the Low (relatively) sane, while the High flutters so much? Perspiring minds want to know.

But, early empirical suggests I need a thermistor...

[xilman]

Originally Posted by chalsall

And then, suddenly, the SD jumped to ~11%, with wildly unrepeatable measurements.

Thinking maybe there was some background task interfering with my process, I tried shutting down as many services as I could, including the WiFi and Bluetooth hardware. Nope. Tried setting the process affinity explicitly. Nope...

Finally, I noticed that while the "Highest" returned measurement within a sample set wasn't that far from the expected, the "Lowest" was often wildly low.

Originally Posted by chalsall

Something weird is going on. Probably the stupid programmer; perhaps trying to use a non-RT kernel to take precise measurements is ill-advised. But why is the Low (relatively) sane, while the High flutters so much?

Let me see if I understand you. "High" and "low" refer to different quantities in these two posts, right? In the first post it referred to the depth of the water in the tank, whereas in the second it refers to the readings within a set of measurements? This latter assumption is based on the time scale shown on the x-axis of the plot.

If my assumption is wrong, please clarify, If it is correct, where do the separate high and low readings come from? Two different sensors perhaps?

In other words, I'm still confused but it souds like an interesting exercise.

You don't have a resident frog in the tank do you?

Please feel free to take this to email if you think it's inappropriate for public discussion.

[xilman]

Originally Posted by chalsall

Something weird is going on. Probably the stupid programmer; perhaps trying to use a non-RT kernel to take precise measurements is ill-advised. But why is the Low (relatively) sane, while the High flutters so much? Perspiring minds want to know.

But, early empirical suggests I need a thermistor...

Interesting diurnal rhythm there. You use water fairly steadily from 8 am to 6 pm and refill in the evening and overnight. I doubt it's thermal expansion and contraction because the thermal inertia must be immense.

[chalsall]

Originally Posted by xilman

Let me see if I understand you. "High" and "low" refer to different quantities in these two posts, right?

Nope. Sorry; I should have been clearer.

The High and Low values are the highest and lowest level reported by the USS over the one minute sampling period. Note that the readings are the distance from the top of the tank.

Originally Posted by xilman

In other words, I'm still confused but it sounds like an interesting exercise. You don't have a resident frog in the tank do you?

Yeah; I'm having fun. And, LOL... No, no frogs. But, mosquitoes are trying to replicate. We place "Dunks" in the tanks to kill the larvae.

Originally Posted by xilman

Interesting diurnal rhythm there. You use water fairly steadily from 8 am to 6 pm and refill in the evening and overnight. I doubt it's thermal expansion and contraction because the thermal inertia must be immense.

Again, I should have been clearer. Except for the very beginning of the plot (where I was finishing draining the tank) the water level has been static for the last two days. There is definitely something thermally related affecting the readings. Probably not thermal expansion, as you say, but possibly the speed of sound through the air (possibly further complicated by humidity).

Need more sensors. Also, I'm in the process of installing another USS in a separate tank in a different building. This should help determine if I have a bad sensor, if there's a SPE, or if this is just how things really are.

Originally Posted by xilman

Please feel free to take this to email if you think it's inappropriate for public discussion.

I'm more than happy to discuss this publicly, in case anyone else tries to do this kind of work in the future. But perhaps a SuperMod could move these messages to a separate thread somewhere.

[LaurV]

Originally Posted by chalsall

taking the average of lots of samples is working fine.

You don't need to average. One trick I do in my daily job is reading 10 values, summing them and computing the min and max on the fly, then at the end discarding the min and max. This has the advantage that is simple, extremely fast, as it doesn't do any division, neither multiplication, it discards the min/max (they may be aberrations, it is always better to discard values that "stand out" from the other samples, but checking the "standing out" condition would be too time-costly, when you are on Cortex M or smaller toys), and not at last, it gives me 3 additional bits of precision. For example, giving a 12 bits ADC, this routine will return a 15 bits number, which is quite accurate (being the sum of 8 samples, no averaging - you have to think of the fact that averaging does not bring any additional accuracy, just keeps the parameters "in size", and takes additional time to do the division, or the shift, if you keep the number of samples to be a power of 2). Of course, if you have enough time, you can extend this to get additional bits, or/and to eliminate more "standing out" samples (which can be bad contacts, bad wires, whatever).

//==========================================================================
//get the 'cleaned' ADC value for a channel, with 3 additional
//bits of precision (i.e. 15 bits ADC, instead of 12, hehe)
//The channels can be those defined in main.h:
uint16_t getAnalog(uint32_t chnl)
{
  uint16_t min=0x0FFF;
  uint16_t max=0x0000;
  uint16_t sum=0;
  uint16_t tmp=0;

  // Convert the ADC Channel with 55.5 Cycles as sampling time 
  ADC_ChannelConfig(ADC1, chnl, ADC_SampleTime_55_5Cycles);
  
  for(int i=0; i<10; i++)
  {
    //start a conversion and wait for it
    ADC_StartOfConversion(ADC1);
    
    //wait for the conversion to end
    while(ADC_GetFlagStatus(ADC1,ADC_FLAG_EOC)==RESET);
    
    tmp=ADC_GetConversionValue(ADC1);
    if(tmp>max)
      max=tmp;
    if(tmp<min)
      min=tmp;
    sum+=tmp;
  }
  sum-=min;
  sum-=max;
  return sum;
}

Of course, mod it by your own needs, or use interrupts, DMA, whatever. This is just a sample, and YMMV.

[chalsall]

Originally Posted by LaurV

Of course, mod it by your own needs, or use interrupts, DMA, whatever. This is just a sample, and YMMV.

Thanks for the feedback. However, I'm still trying to "make friends" with the kit; confused by the large amount of noise in the samples (the discrete jumps in the "Highest" value is particularly concerning).

Yesterday I tried sampling using a kernel module I wrote using interrupts triggering on rising and falling edges of the GPIO, reading the system's clock with nanosecond resolution. While the readings are better, I'm still getting lots of (very similar) noise. The temperature correlated variation is to be expected and can be factored out once I have a temperature sensor alongside each USS module.

This might just be the way the USS modules behave. My next exercise is to use a single core of the RPi busy sampling the pins. If that doesn't improve things I'll try the Real-Time patch for the Linux kernel. Then go "bare-metal", and eliminate the OS entirely.

Just for anyone who might be interested, attached are two additional plots. The first is the polling data over three days. The second is about 17 hours of interrupts derived data.

A little frustrated, but having fun too.