Sub cm Measurement, ESP32 Support & Data Types

Issue #62 resolved
Xylopyrographer created an issue

Hi Tim. Thank-you for the library. First ever use of an SRF05 board. I’m running it on an ESP32 Dev Board. Noted this is not officially supported? Running on the Arduino IDE (v1.8.19) & the arduino-esp32 v 1.06 core. All compiled fine though the compiler threw: “WARNING: library NewPing claims to run on avr, arm, megaavr architecture(s) and may be incompatible with your current board which runs on esp32 architecture(s)." Just tested with the basic included example (wiring requires the use of level shifters for the logic, but no big deal). With that as background:

Questions:

  1. Is is possible to get sub-cm accuracy measurements with sonar.ping_cm() ?
  2. Any issues using the timer dependent functions with an ESP32?
  3. Are the data types returned by the various methods documented? I could’ve missed that in the Wiki. Wouldn't be the first time for me 🙂 .

Couldn’t see another way to communicate, so apologies if this isn't proper. Please let me know if there his another preferred way to do this.

All the best.

Comments (3)

  1. Tim Eckel repo owner

    @Xylopyrographer As far is the compile warning you’re getting, could you change the library.properties file architectures line from avr,arm,megaavr to avr,arm,megaavr,esp32? I believe that will stop that warning message.

    As far as your other questions:

    1) The sonar.ping_cm() method just divides the result the sonar.ping() method would return by 50, which converts the ping time in uS to cm. Basically, converting the speed of sound to distance. These two lines from the code give descriptions that could help:

    #define US_ROUNDTRIP_CM 50  // Every 50uS PWM signal is low indicates 1cm distance. Default=50
    #define US_ROUNDTRIP_IN 127 // If 50uS is 1cm, 1 inch would be 127uS (50 x 2.54 = 127). Default=127
    

    The only difference between the ping() and ping_cm() methods is this echoTime / US_ROUNDTRIP_CM which is dividing the ping time by US_ROUNDTRIP_CM, which is 50. So, if you wanted to return results millimeter, you could just do a sonar.ping() and divide by 5 instead of 50 (US_ROUNDTRIP_CM).

    With that said, sonar sensors are not very accurate. 1cm is about as accurate as they can be. So, while you could easily create a mm result (with sonar.ping()/5) don’t expect the results to be more accurate, and expect them to give all kinds of different readings. You can’t correct the physical limitations of a sensor with code. If the sensor is only accurate to about 1cm, dividing by 10 won’t make it more accurate, it will only make the results vary more, as you’re under its accuracy level. This is the reason there’s not a sonar.ping_mm() method, as it would give users a false sense of more accuracy, and complaints that the results were never consistent. It’s tough to get consistent results at the 1cm level, 1mm is just beyond the ability of the sensor.

    2) You won’t be able to use the timer functions with the ESP32 as that requires specific code to that particular processor. NewPing does have processor specific timer code for a few microcontrollers, but not the ESP32.

    3) The header file shows the data type returned from each method. Here’s the non-timer public functions:

    unsigned int ping(unsigned int max_cm_distance = 0);
    unsigned long ping_cm(unsigned int max_cm_distance = 0);
    unsigned long ping_in(unsigned int max_cm_distance = 0);
    unsigned long ping_median(uint8_t it = 5, unsigned int max_cm_distance = 0);
    unsigned int convert_cm(unsigned int echoTime);
    unsigned int convert_in(unsigned int echoTime);
    

  2. Xylopyrographer reporter

    @Tim Eckley Thanks for the great reply. Much appreciated.

    Editing the library.properties file does indeed remove the warning. I think I’ll leave it there though as it may stop me from doing something bad in the future.

    All the best.

  3. Log in to comment