Show Posts
Pages: 1 [2] 3 4 ... 35
16  Using Arduino / Sensors / Re: Ultrasonic sensor HC-SR04/SR06 to measure water level on: May 29, 2014, 04:18:29 pm

Is anyone using HC-SR04 or  HC-SR06 for measuring water level?
How accurate is it?
Are you using temperature compensation?
I'm planing on using it from 5-30cm. Is it accurate in that area?

Thanks, Matej

Lots of people use the HC-SR04 or HC-SR06 to measure water.  They work quite well for that.   I would suggest using my NewPing library for faster/better results.  Also, when doing so, use the ping_median() method that will do multiple pings and give you the median value.  As most water measurement projects don't need to be fast, you can have the ping_median() do many iterations to give you a much more accurate reading and still do readings many times even a second.

Are you doing something like a sump pump logger/alarm?

17  Using Arduino / Sensors / Re: NewPing Library: HC-SR04, SRF05, SRF06, DYP-ME007, Parallax PING))) - v1.5 on: May 29, 2014, 04:12:46 pm

I noticed SR06 sensor has a temperature sensor on the board as well, which can be used for temperature compensation.
Are those measurements more accurate?
How much more? Let's say I have a sensor without temperature compensation and I set my code to 20°, but ambient temperature is 30°C. How big of a deviation would I see?


The formula for the speed of sound is:  m/s = 331.3 + (0.606 x C°)

So, at 20°, the speed of sound is 343.42 m/s and at 30° it's 349.48.

Towards the extreme edge of the sensor range, lets say you get a ping time of 29,000 ms.  That would give you:

29,000 ms / 10,000  x 343.42 m/s / 2 = 497.96 cm
29,000 ms / 10,000  x 349.48 m/s / 2 = 506.75 cm

So, temperature does make a difference, in this example, almost 9cm.  Likewise, at 100cm, the difference would still be about 1.75 cm, so still sizable.

With this said, it's typically not an issue.  Because for normal uses, the sensor is not being used to measure an exact distance, but instead to see if something is approaching or too close relative to a previous ping.  However, if you're using the sensor to measure an exact distance (say a water level) and you must get very precise distance results over a long period of time at various temperatures, then using a thermostat and doing the above calculation would be very important.  All depends on your need.  NewPing is designed to work easily with the built-in ping_cm() method, or you can roll your own with ping().

18  Using Arduino / Sensors / Re: HC-SR04: tests on accuracy, precision and resolution of ultrasonic measurement on: May 28, 2014, 03:22:38 pm
Thanks a lot, Tim - I promise that I'll never ever write again that a sketch is "pretty simple"...
The typo in the sound speed expression is quite probably the cause of the large absolute errors that I "observed".
Regarding the room temperature, I checked it and was 23-24ºC - as you mention, not a big difference, but if I added the possibility I should have made use of it...
And I will look at the possible numerical errors related to using too many floats!
Hope to have it all done by this weekend!

I expect you will see very little difference.  But, a few slight inaccuracies could add up to a *slight* measurable difference.  Not dividing by 10,000 till the ping alone will fix the numerical errors (as shown in my previous post).  Converting everything over to not using floats will make things just run faster and use less program space, it won't make much of a numerical error difference.

Anxious to see if there's a measurable difference...

19  Using Arduino / Sensors / Re: HC-SR04: tests on accuracy, precision and resolution of ultrasonic measurement on: May 28, 2014, 08:20:48 am
Having spent a lot of time on this myself, I would suggest the following...

First, your calculation of the speed of sound is incorrect and you probably shouldn't be dividing by 10,000 for your speed of sound variable.  The reason is that float is only accurate to 6-7 decimal digits of precision and by dividing by 10,000 you're putting a lot of undue zeros in your variable (thus possibly reducing accuracy).  Instead, use the following:

soundSpeed = 331.3 + (0.606 * tempAir); //  m/s

Then, for your actual distance calculation:

distance[j] = duration / 20000.0 * soundSpeed; // converts the time into a distance (cm)

I would also suggest making the last line:

return(pulseIn(pinO, HIGH, 35000));

So it doesn't wait for a full second if no "pong" is heard (also prevents echo's generating false results).

Further, I question your generic "20.0" for the temperature.  While minimal, an exact reading should be taken for accurate results.

Personally, I would also rework the code so it doesn't use any floats.  This would reduce the compiled code size, speed up the program, and therefore increase accuracy.  It would be quite easy to do and still give you the same precision of results.  However, I'd doubt it would make any measurable difference so it would probably be a useless exercise, it's just how I would do it for accuracy's sake (and I avoid floats at all cost).

20  Using Arduino / Sensors / Re: NewPing Library: HC-SR04, SRF05, SRF06, DYP-ME007, Parallax PING))) - v1.5 on: May 28, 2014, 07:27:05 am
here's the video of the Intervention I did with my installation in Copacabana
and you can see the sensor working at its best

I could tell the dog's ego was inflated due to your project.

21  Using Arduino / Sensors / Re: Help interfacing with this ultrasonic sensor - DYP-ME007Y on: May 27, 2014, 10:33:05 am
@teckel - did you ever confirm this sensor works with NewPing?

Would need the sensor to confirm myself.  Others have got it working.

22  Using Arduino / Sensors / Re: NewPing Library: HC-SR04, SRF05, SRF06, DYP-ME007, Parallax PING))) - v1.5 on: May 23, 2014, 12:57:11 pm
why serial.print do'nt exactly distance "?
please help me!

Yes, what he said --^   Use double quotes, not single quotes.  For example:


Let us know if that fixes things for you.

23  Using Arduino / Sensors / Re: Is there a voltage regulated, level shifted I2C bus solution for AA powered unit on: May 23, 2014, 09:56:15 am
I had heard it said that 1MHz was the sweet spot for low power

It really depends on the task.  If awake only long enough for computation, 8 or 16 MHz uses less power.  If you're waiting for a communications reply or something like that, 1 MHz would use less power.  So in your situation, I'm sure 1 MHz is the way to go.

Have you had any problems running at 1 MHz?  I got some unstable results at 1 MHz.  2 and 4 MHz were fine, but at 1 MHz there were timing issues.  It could have just been the sensors I was working with.

I'm really happy with the way the data logger works and the power consumption looks like it probably exceeded my expectations by a fair amount. The logging cycle can be as short as 15ms depending on sensors. Just received data from a couple loggers that were in Northern Michigan through the winter. The first was inside an insulated but unheated cabin where temperatures got down to 1°F.  Its regulator was configured for 3.3V. It started with a less-than-fresh pair of AA cells, that measured 3003mV at the start, and 2987mV after 184 days. The second logger was in an open shed. It used 5V, and its battery started at 3255mV and ended at 2844mV after 195 days with temperatures as low as -22°F. It had more sensors and more complex sensors than the first unit; I don't have current measurements but I imagine its sensors drew 2-4 times more current than those of the first unit, and for longer intervals.

I can tell you get a kick out of the low power capabilities these MCUs have. So do I!

Yes, I'm a little passionate about ULP MCUs.  I love the battery stats you provide, I do the same thing.  I have an ULP test unit I've setup as a torture device on my desk at work.  I just tested the voltage again and at 230 days the average AA battery voltage is 1.41 volts (down from a 1.62 volt start).  This is my torture device, which is setup to trigger much more frequent than normal.

What voltage regulators do you use?  I've been using the Microchip MCP1700/MCP1702 which has a very low quiescent current (2 µA).  What are you using for a boost regulator?

24  Using Arduino / Sensors / Re: Is there a voltage regulated, level shifted I2C bus solution for AA powered unit on: May 22, 2014, 02:52:02 pm
Oh, there's one other thing.  Also when doing an ultra low-voltage system I monitor the input voltage by using the ATmega8's internal bandgap reference voltage.  Basically, I monitor the voltage of the batteries.  During development, I'll use a variable voltage source where I can turn down the voltage till the system fails.  I'll then add something like 10% to that voltage and set that as my limit.  Every so often (like once a day) the ultra low-powered system will get a battery voltage reading.  Once it's below the set range, the blinking changes from once every 60 seconds to a double flash or flashing every 8 seconds.  Something so you know the battery is low and needs to be replaced.

By the way, I've yet to actually reach a low battery level warning in an actual system because they really will last for around 7 years.  I've only simulated it.  I've also done projects where I could press a button and it would flash out the voltage via an LED.  So I know it works, just a little too well.  Duracell hates me smiley-wink

25  Using Arduino / Sensors / Re: Is there a voltage regulated, level shifted I2C bus solution for AA powered unit on: May 22, 2014, 02:37:24 pm
Have you considered just running everything on 3.3V? I designed a data logger that runs on 2xAA cells and uses an MCP1640 boost regulator, that when not enabled, simply passes the battery voltage straight through. The logging cycle is: Wake up (via RTC interrupt), enable boost regulator, increase system clock speed to 8MHz, power sensors on, take readings, save data, program next wake time, power sensors off, reduce clock to 1MHz, disable boost regulator, go to sleep. Using 1MHz allows the MCU to operate down to 1.8V when running on battery voltage, but while reading sensors and saving data, everything runs on the regulated voltage.

The regulator can be configured to supply either 3.3V or 5V; exclusive of sensor requirements, everything else on the board is equally happy with either but of course 3.3V will provide better battery life. Sleep current is only a few microamps. It uses EEPROM for logging memory (hence the 512kB limitation). I've thought about redesigning it with an SD card but that's a low priority project.

For ultra low-power projects, I've found that voltage regulators in general (boost or buck) use too much power.  Instead, I go with using  3-4 batteries and a diode to drop the voltage a bit and to protect the circuit from batteries being inserted the wrong way.  The goal is to put the circuit slightly above the rated voltage with fresh batteries.  For example, I commonly have ATmega8 projects running at 5.5 volts with fresh batteries.  Sure, out of spec a bit, but I've never had anything blow up, even with 6 volts.  Same goes with a 3.3V system, 3 batteries with a diode.

By taking out the voltage regulator, you really can create a system that uses 1uA when the ATmega8 is in sleep mode.  Sure, you use an extra batter or two.  But batteries are cheap and you can design systems that can log or interact for SEVERAL years.  I have a few projects that draw less current than the battery looses just sitting on the shelf with nothing connected.  You need to shut everything down, even the brown-out detector.  If you need my ultra low-power code, write me, I'll probably eventually make it into a library.

My typical ultra-low power project will put the ATmega8 in almost total sleep (just waiting for a trigger pin or timer).  I typically attach an LED that blinks every minute so you know it's still working.  The trick with the LED to use the least amount of power is to use a very bright LED, use a larger resistor to limit the current to maybe 1mA, and use the built-in sleep of the ATmega8 for the time the LED is on.  In other words, turn on the LED (only using 1mA) put the ATmega8 to sleep for 15ms, wake back up, turn off the LED, then return to long sleep.  This uses less power because it's only using 1mA for 15ms instead of leaving the ATmega8 awake for 5ms during a shorter blink and consuming more than 10mA.  The little things add up, and I'm a bit of a current Nazi.

Also, I would not suggest reducing the clock speed to 1MHz.  I've found you'll use more power at 1MHz than at 8MHz.  The reason is first there's not much of a power savings from 8MHz to 1MHz, and secondly your code takes 8 times as long to run.  The end result is you actually use a lot more power at 1MHz.  16MHz would be slightly more efficient, but then you need external crystal/caps which raises component cost/complexity.  So, I typically use the internal 8MHz oscillator.  Makes it easy, cheap, and more energy efficient than 1MHz.

Keep in mind that I've spent hundreds of hours developing ultra low-powered systems.  I've measured the actual current used and calculated everything to the nth degree.  In other words, I'm not guessing what I'm saying is true, I've done it, countless times.  The ATmega8 is a VERY good platform if low power is the goal.  Also, I'm talking about using a ATmega8 chip and a custom circuit, not an Arduino, which will never work in an ultra low-power system.

26  Using Arduino / Sensors / Re: NewPing Library: HC-SR04, SRF05, SRF06, DYP-ME007, Parallax PING))) - v1.5 on: May 22, 2014, 01:38:34 pm
Didn't realize this thread was a main support for this library (or at least it seems to be from what I am reading).  Can anyone help with my issue, I'm using the DYP-ME007Y sensor but it isn't working as expected:

Thanks Everyone!

Glad you got it working!  A bad connection like that can be hard to track down.

27  Using Arduino / General Electronics / Re: For slow digital circuits, do I need ground between each wire? on: May 22, 2014, 11:34:54 am
I'm designing a pass-through circuit for a project at work, and I'm running in to space issues. I have a block of thirteen digital signals and I'm wondering if I need a ground wire between each. The ribbon from my circuit to the next board is maybe 6 inches, and the signals are 0-5V logic that change states maybe once per minute. Seriously slow.

Do I really need to ground every other conductor in this case?

You could also consider twisted pair if you're getting EMI noise.  But my guess is that the cable distance isn't long enough to cause a problem.

28  Using Arduino / Sensors / Re: NewPing Library: HC-SR04, SRF05, SRF06, DYP-ME007, Parallax PING))) - v1.5 on: May 21, 2014, 03:09:29 pm
It works like a champion!
Thanks a bunch, next time, i will send pictures and videos of the final project!
Best Regards,

Glad I could help!  Would love to see the final project.  I hope it's something fast-moving that chases your cat around the house or something cool like that.

29  Using Arduino / Sensors / Re: NewPing Library: HC-SR04, SRF05, SRF06, DYP-ME007, Parallax PING))) - v1.5 on: May 21, 2014, 12:42:07 pm
When I first tried the example sketches, I printed every single piece of code I found could be handy to work with, the objects in the array cm
  • and cm [1] where the variables I found most important (all other I just couldn't print), but, again I couldn't do much with them as I have poor code skills, I was looking for some piece of code that could convert whatever I was looking at to something I could do some math with , later I found I was merging the results into one, so I decided I needed to divide the result by two. Ok, not a smart decision, I know...

And with your sketch, I did came to similar results as yours before, and what happens is, when something approaches to the sensor, it turns on, but never turns off, therefore, there's no 0 coming out when there's no activity. I thought this was a good approuch to achieve my goal, which is, when there's activity on the sensor, turn on, else, turn off


Without totally writing the sketch for you (what fun would that be?) I can suggest that you start again with the standard 15 sensor sample sketch that puts the results in an array.  Then, analyze the results in the array and decide what you want to do with the data.  The distance variables are simply cm[0] and cm[1].  You wouldn't want to add them and divide by two, as that would not give accurate results.  Instead, you would need some better logic.  For example, maybe one OR the other needs to be a positive value to consider something in range.  So, you would do something like:

void oneSensorCycle() { // Sensor ping cycle complete, do something with the results.
  // The following code would be replaced with your code that does something with the ping results.
  if (cm[0] || cm[1]) {  // At least one sensor detected something in range, activate relays.
    digitalWrite (RELE1, HIGH);
    digitalWrite (RELE2, HIGH);
  } else {  // Both sensors can't detect anything, turn relays off.
    digitalWrite (RELE1, LOW);
    digitalWrite (RELE2, LOW);

Hope that helps!

30  Using Arduino / Programming Questions / Re: Delay and digitalWrite Inconsistency on: May 21, 2014, 11:13:57 am
Even though I've developed video game controller hardware for 20 years and was featured in Popular Science on the subject,

But I see you have a closed mind so let's call a halt to it. Shame you can't learn a new perspective.

Grumpy old man, I see it the other way around, so let's call it a tie.  Shame you can't learn new programming tricks at your age. smiley-wink

Pages: 1 [2] 3 4 ... 35