Go Down

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

Stanley



Dear Tim,

Are you able to add the option to have the distance measurement/pulse width based on LOW signal instead of HIGH signal ? With this, the URM37 passive PWM mode should work with the NewPing library...

Thanks


It would be possible.  But would be like shooting in the dark without an actual sensor to test with.  There could be a host of other problems.  From your testing, is it sending out a single low pulse or is it pulses as the documentation states?

Tim


From my observation on the scope, it is sending multiple pulses based on the returned ping timing/distance..

I'm not sure what the NewPing does on the trigger pins but it surely trigger the PWM pins to send a LOW pulse per trigger on a constant basis...

I thought if the library read a high pulse whereas the URM37 reads a low pulse, a "simple"  #if define URM37 would change the codes whereas all the other codes and timing would remain the same...


*** I could be wrong or it just sounded too simplified...


teckel


I thought if the library read a high pulse whereas the URM37 reads a low pulse, a "simple"  #if define URM37 would change the codes whereas all the other codes and timing would remain the same...


*** I could be wrong or it just sounded too simplified...


You're right, that would be all that's required to read a LOW pulse instead of a HIGH pulse.  It's a little more complicated as it waits and makes sure the signal is LOW before it times the HIGH pulse.  But, it's still shooting in the dark without the sensor in front of me.

You can try the following changes to NewPing.cpp, which just changes the pulse measurement from HIGH to LOW:

Code: (Line 38) [Select]

while (!(*_echoInput & _echoBit))                   // Wait for the ping echo.


Code: (Lines 97 and 98) [Select]

while (!(*_echoInput & _echoBit) && micros() <= _max_time) {} // Wait for echo pin to clear.
while (*_echoInput & _echoBit)                                // Wait for ping to start.


Code: (Line 122) [Select]

if (*_echoInput & _echoBit) {    // Ping echo received.


Give it a go.  Keep in mind that this is just a guess, and we're still assuming a lot.  But, it's a simple thing to try.  There's other issues as well, like this could give a reading, but it may not be consistent or accurate due to timing issues.

Let me know what happens.

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

Stanley



You're right, that would be all that's required to read a LOW pulse instead of a HIGH pulse.  It's a little more complicated as it waits and makes sure the signal is LOW before it times the HIGH pulse.  But, it's still shooting in the dark without the sensor in front of me.

You can try the following changes to NewPing.cpp, which just changes the pulse measurement from HIGH to LOW:

Code: (Line 38) [Select]

while (!(*_echoInput & _echoBit))                   // Wait for the ping echo.


Code: (Lines 97 and 98) [Select]

while (!(*_echoInput & _echoBit) && micros() <= _max_time) {} // Wait for echo pin to clear.
while (*_echoInput & _echoBit)                                // Wait for ping to start.


Code: (Line 122) [Select]

if (*_echoInput & _echoBit) {    // Ping echo received.


Tim


Dear Tim,

I made the changes to the suggested codes and it WORKS on the URM37 using the Examples codes...

I'm using Pin4 for PWM & Pin5 for Trigger...

I also tried with TWO sensors and it is still working without any delays between reading the sensors...

Let me capture a scope output and post it here later...

Thanks a lot!!!

Stanley


teckel


I made the changes to the suggested codes and it WORKS on the URM37 using the Examples codes...

I'm using Pin4 for PWM & Pin5 for Trigger...

I also tried with TWO sensors and it is still working without any delays between reading the sensors...

Let me capture a scope output and post it here later...

Thanks a lot!!!

Stanley


We got lucky for sure.  Is it reading accurate distances?  3 distances are a good test (10cm, 50cm and 200cm) something like that.  It probably won't be prefect, but within about 1cm is about the best you can hope for with ultrasonic sensors.  As it is now, we're assuming 50uS is really 1cm.  Also, you should probably try to test the ping_in() method to make sure the inches are also correct.

I've implemented changes to the NewPing Library to a allow support for the URM37 sensor in PWM mode.  v1.6 will include this support.  There's a URM37_ENABLED define you set to "true" to enable support (which measures the low signal length instead of the high and adjusts the length so each 50uS is 1cm).

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

Stanley


We got lucky for sure.  Is it reading accurate distances?  3 distances are a good test (10cm, 50cm and 200cm) something like that.  It probably won't be prefect, but within about 1cm is about the best you can hope for with ultrasonic sensors.  As it is now, we're assuming 50uS is really 1cm.  Also, you should probably try to test the ping_in() method to make sure the inches are also correct.

I've implemented changes to the NewPing Library to a allow support for the URM37 sensor in PWM mode.  v1.6 will include this support.  There's a URM37_ENABLED define you set to "true" to enable support (which measures the low signal length instead of the high and adjusts the length so each 50uS is 1cm).

Tim


I did some measurements, the distance of the following looks good :-

10cm - ok
50cm - ok
100cm - ok
150cm - ok
200cm - ok

With +/- 1 to 2cm variance for distance above 100cm...

I have a strange issues, one of the URM37 sensors, after operating for 7-9 hours, it just stop working... ( I think this is related to the sensors and nothing to do with the NewPing lib ), even after I do multiple reset, it is still not responding and gives a 50,000us ( means reading is invalid )... 

I'll report this issue back to DFRobot for this...

Go Up