text: Hello,I would like to ask if it is possibly to read the cm with decimal like 10.4 cm e.t.c.Thank in advance.Best regards,Tasos
  Interesting!
  Well that's a good point, but it is still likely to jump around between 10 and 11 cm.
  Quote from: teckel on Feb 04, 2013, 10:23 pmInteresting!Well it did it for me at least. Hopefully it helps someone else as well.The operating voltage for the HC-SR04 should apperently be 4.50 to 5.0V. But I did some quick measurements which shows that that's not the case for my sensors:With Ethernet shield:1. Power via USB port1.1. With LCD screen connected as well, at 3 HC-SR04 ultrasonic sensors: 4.55 V1.2. Without LCD Screen: 4.60 V2. Power from power outlet2.1. With LCD screen connected as well, at 3 HC-SR04 ultrasonic sensors: 4.98 V2.2. Without LCD Screen: 4.98 VWithout Ethernet shield:3. Power via USB port3.1. With LCD screen connected as well, at 3 HC-SR04 ultrasonic sensors: 4.76 V3.2. Without LCD Screen: 4.82 V4. Power from power outlet4.1. With LCD screen connected as well, at 3 HC-SR04 ultrasonic sensors: 4.98 V4.2. Without LCD Screen: 4.98 Vi.e. since it doesn't work properly for me with just the sensors and the Ethernet shield connected (using just USB), over 4.60V seems to be needed.
  Quote from: tasosstr on Feb 09, 2013, 08:42 pmHello,I would like to ask if it is possibly to read the cm with decimal like 10.4 cm e.t.c.Thank in advance.Best regards,TasosYes, simply use ping() which will return the milliseconds and then divide by whatever number you want to convert ms to cm (defaults to 57). The library uses integers to save program space (saves about 1k by avoiding floating point). Also, the accuracy isn't really better than a cm and there's other variables like temperature that will change the speed of sound and mess up your calculations.However, keep in mind that doing any of this will really be of no good as the sensor is not accurate enough to actually give you a consistent reading of 10.4. If you did use a floating point number for ms to cm conversion, the ping results would probably jump around from 10.9 to 10.1, with everything still. So, I'm sure sure what use you'd really get from it. All you'd really be doing is wasting 1k of program space and getting a bunch of different readings and not knowing which one was right.Basically, I'd suggest leaving it as-is and accepting that the sensor is really only accurate to 1cm or 1in. And, enjoy the extra speed and 1k of program space you saved by not using floating point calculations on things that are not accurate below an integer anyway. NewPing is designed to be small, fast, and accurate. Making it floating point would not help the accuracy and it would make it slower and larger. So, it would hurt the library in every way. But, you're free to use floating point if you wish by using the ping() method along with your own conversion (after also monitoring the temperature).Let me know if you actually find this useful, I've yet to hear of it being at all useful or more accurate.Tim
  #include <NewPing.h>#define TRIGGER_PIN 12 // Arduino pin tied to trigger pin on the ultrasonic sensor.#define ECHO_PIN 11 // Arduino pin tied to echo pin on the ultrasonic sensor.#define MAX_DISTANCE 500 //. float uS = sonar.ping(); // Send ping, get ping time in microseconds (uS). Serial.print("Ping: "); Serial.print(uS / US_ROUNDTRIP_CM); // Convert ping time to distance in cm and print result (0 = outside set distance range) Serial.println("cm");}
  I need this because i want to get the height of a petrol tank, so now i can have more better results because of you :-)
  Ultrasonic sensors don't work well with petrol/gasoline.
  QuoteUltrasonic sensors don't work well with petrol/gasoline. Was the problem simply one of calibration, i.e. the speed of sound in vapour-laden air vs. speed of sound in air?
  I'm building a little robot with an HC-SR04 for obstacle avoidance, and I'm finding NewPing to be very nice. Thanks for your hard work, Tim.I'm using NewPing in timer-mode, but I don't really need to do anything inside my echoCheck() function... I just want a distance value to be available to other parts of the code.Here's where I run into a problem... I'm not seeing a good way to directly determine the difference between "timed out without an echo" and "still waiting for an echo" conditions. check_ping() returns false in both cases, and x.ping_result is only updated on receiving an echo. So x.ping_result always indicates the distance of the last successful ping, but it will always be a positive value even when pings are timing out without an echo.So inside my echoCheck(), I have to assign the value of ping_result to a global variable, and then when I read the global variable elsewhere in the code, I have to remember to set it to zero. This is effectively doing the same job as ping_result, except it's happening in my code instead of inside NewPing.Would it make sense for the timeout reset portion of check_ping() to set ping_result back to 0? ping_result isn't used anywhere else in NewPing, so it wouldn't affect internal behavior. I don't know how it might affect behavior of existing programs, but I suppose it could.With this minor change, I could eliminate my global variable and just look at ping_result any time I want to know the status of the last ping.On one level, I'd like the option for the timer-driven model to be even less involved. I'd like to start the "ping engine" in setup() and have it ping every 50 usec "forever" without calling ping_timer() again, and be able to just check ping_result any time I like. I can't call ping_timer(echoCheck) from within echoCheck(), because again, check_timer()'s return value doesn't differentiate between "timed out" and "still waiting". (And despite being a career developer / system architect, I'll admit that I may be missing something here and that the problem is easily solved.)If check_timer() returned an int... -1 for "still waiting", 0 for "timed out" and a positive value (distance) for an "echo received", it would be a lot more flexible. And it would break existing code, since its' an API change.I suppose I could peek at the timer value itself to see if it's still enabled, but having the library help with that would be ideal. Maybe a function or variable I could call/look at to find out why check_timer() returned false? Of course, an alternative function to ping_timer(), say, ping_forever(), that didn't (or optionally) require a echoCheck() and handled running the ping over and over on its own might be ideal. (And I'll admit, this is what I expected when I first dug into the timer-driven mode.)I may make some tweaks to the library and see which ideas pan out.
  #include <NewPing.h>#define SONAR_NUM 3#define MAX_DISTANCE 200#define PING_INTERVAL 33unsigned long pingTimer[SONAR_NUM];unsigned int cm[SONAR_NUM];uint8_t currentSensor = 0;uint8_t pingStatus = 0;NewPing sonar[SONAR_NUM] = { NewPing(4, 5, MAX_DISTANCE), NewPing(6, 7, MAX_DISTANCE), NewPing(8, 9, MAX_DISTANCE)};void setup() { Serial.begin(115200); pingForever();}void loop() { for (uint8_t i = 0; i < SONAR_NUM; i++) { // Loop through all the sensors. if (millis() >= pingTimer[i]) { pingTimer[i] += PING_INTERVAL * SONAR_NUM; sonar[currentSensor].timer_stop(); currentSensor = i; cm[currentSensor] = 0; pingStatus = 1; sonar[currentSensor].ping_timer(echoCheck); } } /* At any time, you can get the value of pingStatus, currentSensor, or read the values of the last pings in the cm[] array. It's up to you to figure out what you want to do with this data. */}void pingForever() { pingTimer[0] = millis(); for (uint8_t i = 1; i < SONAR_NUM; i++) pingTimer[i] = pingTimer[i - 1] + PING_INTERVAL;}void pingStop() { for (uint8_t i = 0; i < SONAR_NUM; i++) pingTimer[i] = -1; pingStatus = 0;}void echoCheck() { if (sonar[currentSensor].check_timer()) { cm[currentSensor] = sonar[currentSensor].ping_result / US_ROUNDTRIP_CM; pingStatus = 0; }}
  I asked my wife, and she said vapor was one issue, and another is that gasoline has a high thermal expansion ratio... to get an accurate volume measurement, you have to know the temperature of the fuel as well as its level. But that wouldn't be an issue if you're only concerned with "the tank's getting low". Apparently a float was a cheaper and more reliable method, at least at the time.
  #include <NewPing.h>#define SONAR_NUM 4 //(12, 11, MAX_DISTANCE), // Each sensor's trigger pin, echo pin, and max distance to ping. NewPing(10, 9, MAX_DISTANCE), NewPing(8, 7, MAX_DISTANCE), NewPing(6, 5,(cm[i]);}!!!
  Please enter a valid email to subscribe
  We need to confirm your email address.
  To complete the subscription, please click the link in the
  Thank you for subscribing!
  Arduino
  via Egeo 16
  Torino, 10131
  Italy