Go Down

Topic: NewPing Library: HC-SR04, SRF05, SRF06, DYP-ME007, Parallax PING))) - v1.5 (Read 128 times) previous topic - next topic

robtillaart

@Terry
Every published library is open, so users can allways "roll their own" variation of the library. I think Tim does a very good job keeping the lib as simple as possible because that means small footprint and performance most of the time. My additions and ideas is just searching the "edge of the possible" :)

@Tim
You should use the link to this thread in your library so people can reread the arguments somewhere in the future. e.g. add a header like
Code: [Select]
//
//    FILE: newPing.cpp
//  AUTHOR: Tim Eckel
//    DATE: 2012-05-xx
// VERSION: 1.1
//
// PUPROSE: new implementation of ping)))
// LINK: http://...
// HISTORY:
// 1.0: ...
// 1.1: ...
Rob Tillaart

Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -
(Please do not PM for private consultancy)

terryking228

Hi, Rob..
You are always  (cut-paste) on the "edge of the possible"  :)

Many Arduino users have no idea of what the source of a library looks like, or why it has that structure, or how to force it to recompile. They are happy (and capable) using a documented library.  But maybe if they could access the library functions at both a lower and higher level it would be useful. Maybe.

I'm not sure what side of the divide I'm on, or even where it is...

I really glad you guys are digging into this.
Regards, Terry King terry@yourduino.com  - Check great prices, devices and Arduino-related boards at http://YourDuino.com
HOW-TO: http://ArduinoInfo.Info

teckel


Tim, This is an approach that could perhaps be taken more often with libraries in general: Expose relevant internal (previously private) variables for the user who wishes to do additional calculations.

Maybe the library could even be structured so that if a user does that, the code for further/final calculations in the "usual" application is not compiled?

I'm still semi-illiterate about library details and conventions so this is just conjecture.


Terry, that's exactly how I see it.  I think the primary goal of the NewPing library is to measure the ping/echo time and distance as easily, quickly and accurately as possible.  But, when we get into advanced distance conversion, the requirement to consider temperature and to a lesser extent humidity take it outside the scope of an ultrasonic/ping library as other sensors are required.  For those with this need, the NewPing library provides the user with the low-level ping/echo timing.  And those with this need and knowledge of what other sensors are needed should already know the equation they need to use.

Not that I'm going to wash my hands of this and off-load it.  There's just more primary issues, like making pulseIn event-driven and a generally more accurate echo time sensor first.

Tim
Arduino - Teensy - Raspberry Pi
My libraries: NewPing - LCDBitmap - toneAC - NewTone - TimerFreeTone

teckel


@Terry
Every published library is open, so users can allways "roll their own" variation of the library. I think Tim does a very good job keeping the lib as simple as possible because that means small footprint and performance most of the time. My additions and ideas is just searching the "edge of the possible" :)

@Tim
You should use the link to this thread in your library so people can reread the arguments somewhere in the future. e.g. add a header like
Code: [Select]
//
//    FILE: newPing.cpp
//  AUTHOR: Tim Eckel
//    DATE: 2012-05-xx
// VERSION: 1.1
//
// PUPROSE: new implementation of ping)))
// LINK: http://...
// HISTORY:
// 1.0: ...
// 1.1: ...



Thanks for the suggestions!

Tim
Arduino - Teensy - Raspberry Pi
My libraries: NewPing - LCDBitmap - toneAC - NewTone - TimerFreeTone

teckel

Thanks to Terry King and YourDuino I did a round of range testing with 6 ultrasonic/ping sensors and the results were not as I expected.  I tested with 3 different models, (4) SF04, (1) SRF05, (1) SRF06.  The testing environment was in an air conditioned room at 75 degrees.  I tested at distances of 5cm, 10cm, 25cm, 50cm, and 100cm.  Longer distances were not tested in this round.  I believe the accuracy within 100cm or important as that's within the primary measurement distance.  Beyond 100cm it's not as much of an issue in most situations.  Once the pulseIn echo code is reworked, I'll do round 2 of testing out to a further distance.

The good news is that the sensors were all very consistent.  With all the SF04 and SRF05 generating nearly identical results (makes sense as the PCBs are nearly identical).  The SRF06 uses different components and yields slightly different measurements as a result.  It does appear to be a slightly better sensor (makes less clicking noise, hardly no lag, and results closer to actual speed of sound).  The maximum distance of the SRF06 seemed to be slightly lower, but that will be answered in round 2 of testing.

The results don't fit at all with the speed of sound calculations previously being used.  For the SF04 and SRF05 sensors, the calculation from microseconds to cm is:
cm = (microseconds + 37) / 48

For the SRF06 sensor, the calculation is:
cm = (microseconds + 5) / 51

Using these calculations, I could accurately measure any distance in the 5cm to 100cm range with all 6 sensors.  Albeit, not even close to speed of sound at this temperature, which should be right around cm = microseconds / 58.  If it was simply a long sensor lag, the additional microseconds added in the equation would be much higher, which they're not.

I have two theories as to why this is happening:
1) The pulseIn function is simply way off.  It's not even measuring time, but counting processor cycles, so there's a good possibility the time conversion is wrong.
2) Because I'm using port registers the code is faster.  And, since the formulas used to compute pulseIn are not based on port register manipulation but using the known slow higher-level digitalWrite command that's where the error is.  This doesn't seem likely as while digitalWrite is slow, it's not THAT slow.

At this point, I think diving into the pulseIn code and replacing it is a wise choice.  Then at least I'll have some other information to figure out the source of the time discrepancy.

Tim
Arduino - Teensy - Raspberry Pi
My libraries: NewPing - LCDBitmap - toneAC - NewTone - TimerFreeTone

Go Up