Show Posts
Pages: 1 [2] 3 4 ... 35
16  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.

17  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.

18  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.

19  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?

20  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

21  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.

22  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.

23  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.

24  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.

25  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!

26  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

27  Using Arduino / Programming Questions / Re: Delay and digitalWrite Inconsistency on: May 21, 2014, 10:43:32 am
Now to remove notifications of replies to this thread...
The equivalent of putting your hands over your ears and saying "nana nana" I am not listing any more. Mainly because as fas as I see it you have no real technical arguments to back up what you are saying.

Because it's too hard for you and Mr. grumpy troll to write faster code that makes me wrong?
It is not hard to write port direct manipulation code it is quite trivial actually and I use it when it is needed. However, it it does have its disadvantages mainly it is not portable across other arduino platforms and it has a certain obfuscation factor for a beginner.
I wonder how you can call me a Trol as I was the one that sorted out the OPs problem in the first place and that it was indeed that he was using too little delay not too much.

I have a lot of experience developing video game controllers.
Then you should know better that to think that 2uS or 0.0625uS makes any difference to the feel of anything. You can't even perceive the difference between 2uS and 200uS lag. In the context of a video game anything less than the frame rate of the video is fine, which you will know if you were a real games designer.

Tell you what:- make a game where two LEDs come on 200uS apart, then you have to press a button indicating what LED came on first. If the result is anything significantly greater than the chance 50% results I will concede you have a point, which you don't.

Sorry, but reducing lag is the #1 goal of a video game controller,
Your assertions remind me of the gold plated mains connector Hi-Fi brigade. Full of assurance but with no substantial technical claims to back it up. Once the lag has been reduced to imperceptible proportions the prospect of halving that lag holds no great appeal to anyone who is actually interested in the game.

But, digitalWrite() and delay() will work too, just not as well, accurate, and with more lag.
There you go again, making a statement with no justification, no reasons, and what is more totally wrong.

In any games controller the signals have to be slow enough for the controller to recognise them, make them too fast and they will not all get picked up, which is precisely what the OP was having trouble with.

Seems you're worked into quite a froth.  Even though I've developed video game controller hardware for 20 years and was featured in Popular Science on the subject, I conceded to your prowess and desire to argue over nothing and I'll take the adult route here.

28  Using Arduino / Sensors / Re: NewPing Library: HC-SR04, SRF05, SRF06, DYP-ME007, Parallax PING))) - v1.5 on: May 21, 2014, 09:54:49 am
I am doing an installation that works with two sr04, and I am quite satisfied with the results I am achieving so far.

and I just wanted to turn on a pair of relays based on the sensors activity, and so far i got it to work almost the way i want, the sensors will work almost in parallel (slightly different angles to give'em more viewing angle).  I found the cast operator to be more friendly to deal with the cm array, but I am not sure if its the proper way of doing it.

as of the relays, i want them to turn on when there's somebody in the range of the sensors, otherwise it must be turned off, any advice or suggestion will be much apreciated, and what I got so far is, they turn on on presence, but turn off only when somebody is 10 cm or closer, but not when out of range, i tried to stop and turn the ping on again as suggested on page 19, but I'm not achieving the results I seek

and Teckel, excelent job, and thanks a bunch for your activity in this thread, as an arduino lover and a maker, I am obliged to thank people like you!

I'm not sure why you're creating the floating variable "f" and why you're then dividing the distance by two.  That will just add a lot of overhead to your code.  But, a distance of "0" means out of range.  So, if you want to turn something on when in rage and off when out of range your code would look something like this (I cleaned it up a bit too):

#include <NewPing.h>

#define SONAR_NUM      2
#define MAX_DISTANCE 350
#define PING_INTERVAL 33

#define RELE1 7
#define RELE2 8

unsigned long pingTimer[SONAR_NUM];
uint8_t currentSensor = 0;

NewPing sonar[SONAR_NUM] = {
  NewPing(13, 12, MAX_DISTANCE),
  NewPing(4, 2, MAX_DISTANCE)

void setup() {

    pinMode (RELE1, OUTPUT);
    pinMode (RELE2, OUTPUT);
    pingTimer[0] = millis() + 75;
    for (uint8_t i = 1; i < SONAR_NUM; i++)
      pingTimer[i] = pingTimer[i - 1] + PING_INTERVAL;

void loop() {
  for (uint8_t i = 0; i < SONAR_NUM; i++) {
    if (millis() >= pingTimer[i]) {
      pingTimer[i] += PING_INTERVAL * SONAR_NUM;
      currentSensor = i;
  // Other code that *DOESN'T* analyze ping results can go here.

void echoCheck() {
  if (sonar[currentSensor].check_timer())
    pingResult(currentSensor, sonar[currentSensor].ping_result / US_ROUNDTRIP_CM);

void pingResult(uint8_t sensor, int cm){
  if ( cm == 0 ) {
    digitalWrite (RELE1, LOW);
    digitalWrite (RELE2, LOW);
  } else {
    digitalWrite (RELE1, HIGH);
    digitalWrite (RELE2, HIGH);


The problem with this code however is that you have two sensors.  One may detect an object and the other may not.  So, it could turn on and off so quickly you can't even tell.  You probably need to use the original multi-sensor sketch that stores the results in the array and then process the results where you can make logic decisions based upon results of maybe one sensor detecting an object and the other not, or distances that are wildly different.

Basically, while my above sketch will work the way you asked, it won't really work the way you want.  Going back to the original sketch and storing the results in the array and then using different logic is probably what you really want.

29  Using Arduino / Programming Questions / Re: Delay and digitalWrite Inconsistency on: May 21, 2014, 08:54:26 am
I agree the topic is a little heated right now, however teckel brings some good point to the table.

Regardless of the accuracy required in one step the CPU would have additional cycles to spend elsewhere from a saving gained in another task which has been optimized and is running in the same time slice.

If you do not need those precious cycles, that extra time can be used to sleep, ultimately preserving battery life.

However, 2 hz is incredibly slow when I think back to the button mashing days of Tekken and such.

Thanks, I have a lot of experience developing video game controllers.  Heck, I was featured in Popular Science for developing arcade game hardware.

The ATmega8 is well-adapted to providing a low-lag and low-power solution at a low cost with easy programming and a good support community (usually).  A very fine controller can be made with the ATmega8 at the core.  But, only if fast and power-efficient code is written.  Sure, other sloppy or easy ways will work, and it will "work" using digitalWrite() and delay().  But, I would highly suggest an event-driven programming paradigm instead of block.

Interrupt and timer based programming paradigms can work great for a project like this.  But, digitalWrite() and delay() will work too, just not as well, not as accurate, and with more lag.

30  Using Arduino / Programming Questions / Re: Delay and digitalWrite Inconsistency on: May 21, 2014, 08:11:33 am
Look we are talking about human interaction here, you are talking about the difference between an instruction being executed within 4uS or 0.0625uS, in the context of a human reaction these two are identical.
Yep. You'd have to be Superman to continuously press and release a button any faster than about 2Hz (500mS), so what does a few uS matter? For most of the posters here, digitalWrite is easier to understand and sufficient for their needs.  Although I've written in Assembly (admittedly, 25 years ago) I haven't got my head around port manipulation yet, mainly through lack of need.

Reducing lag is the #1 goal of a video game controller, and 2Hz is SLOW!  Are you really saying that you can't hit a button more than twice a second?  Honestly, you've never played a video game, have you smiley-wink

For this project, using the ATmega8 microcontroller, port manipulation is the best way.  You can suggest that maybe it isn't required, but it's not wrong to suggest a faster method.

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