Problem with NewPing Median library and Ra-O2 and SSD1306

I’m using the NewPing Mediantimer example. It works fine as is. HOWEVER when I try and slightly modify it to use with the LoRa library I have problems…
It will compile fine. However it won’t process the line LoRa.print( o /US_ROUNDTRIP-IN);
I only get 0 the reading at the receiver end. If I substitute a simple mathematical equation say, 100/5 in place of ( o /US_ROUNDTRIP-IN) it happily computes 20 and sends it off to the receiver.
I’ve tried redefining the equation as and integer “depth” and see if that would help, but get the same result.

Here’s the sketch

#include <NewPing.h>
#include <MedianFilter.h>
#include <Wire.h>
#include <MedianFilter.h>
#include<LoRa.h>
#include <SPI.h> // Not actually used but needed to compile




#define TRIGGER_PIN  7  // Arduino pin tied to trigger pin on the ultrasonic sensor.
#define ECHO_PIN     8  // Arduino pin tied to echo pin on the ultrasonic sensor.
#define MAX_DISTANCE 450 // Maximum distance we want to ping for (in centimeters). Maximum sensor distance is rated at 400-500cm.


NewPing sonar(TRIGGER_PIN, ECHO_PIN, MAX_DISTANCE); // NewPing setup of pins and maximum distance.

MedianFilter filter(31,0);

void setup() {
  
  Serial.begin(115200); // Open serial monitor at 115200 baud to see ping results.

  
 while (!Serial);
Serial.println("LoRa Receiver");
  
 if (!LoRa.begin(433E6)) 
  {
  Serial.println("Starting LoRa failed!");
    while (1);
    while (1);
    
     }
LoRa.setSpreadingFactor(10);
LoRa.setSignalBandwidth(62.5E3); 
LoRa.crc();  
  
}

void loop() {
 int depth; 
  delay(50);                      // Wait 50ms between pings (about 20 pings/sec). 29ms should be the shortest delay between pings.
  unsigned int o,uS = sonar.ping(); // Send ping, get ping time in microseconds (uS).

  filter.in(uS);
  o = filter.out();

depth =( o / US_ROUNDTRIP_IN);
  
  Serial.print("Ping: ");
  Serial.print( o / US_ROUNDTRIP_IN); // Convert ping time to distance in cm and print result (0 = outside set distance range)
  Serial.println(" inches");

  LoRa.beginPacket(); ///send packet
 LoRa.print( o / US_ROUNDTRIP_IN); 
 LoRa.endPacket();
  delay(200); 
}

I’v had the same problem when I’ve tried to use the sketch (altered of course) with the SSD13006 library. Just get the 0. I’ve read on line that the SSD library has a bug where it can’t display computations. Wonder if the same is true with the LoRa library although I’ve had no problems with it before. It must be something in the NewPing library it doesn’t like.
Any suggestions for a work around?
Jeff

I've read on line that the SSD library has a bug where it can't display computations.

Bullshit. Do you have a link to that nonsense?

That library usually has a RAM problem as it uses half of the UNO's memory for a screen buffer but the computations aren't done in the library.

I only get 0 the reading at the receiver end.

Have you tried to print the "o" variable directly? What values do you get? Remember, you do an integer division by 146, so any value of 0 smaller than 146 will result in 0.

Here is the link for your bullshit.
https://lastminuteengineers.com/oled-display-arduino-tutorial/
About half way down the article under installing the library.
Thanks for your help

the "o" variable is generally a large number. For instance the distance of about 1 foot yields a value of 1200.

I guess you mean that paragraph:

Known Problem with SSD1306 Controller

Although the SSD1306 has a built-in GDDRAM for the screen, we cannot read the contents of it (according to Adafruit). Therefore, it is not possible to manipulate the screen buffer to perform mathematical operations.

As an alternative, the library allocates 1KB (128×64)/8 bits) of memory from ATmega328P as buffer. So, it can manipulate the screen buffer and then perform a bulk transfer from the ATmega328P’s memory to the internal memory of the SSD1306 controller.

That simply explains why the library needs that much memory of the controller and this is absolutely true but has nothing to do with what you inferred from it.

the "o" variable is generally a large number. For instance the distance of about 1 foot yields a value of 1200.

I know that this is generally the case but you didn't check it, did you?

Post the serial output of that sketch!

I have the sketch sort of working now. The problem was my lack of patience. It takes a good five to ten seconds before the first readings come. After that there is a lag of about 5 seconds when the sensor is moved. I think it might have to do with the time the median program needs. Changing the delays in the sketch doesn't change much. The lag isn't a major problem for me as I don't expect the water in the tank to drop quickly even with a leak. My object was to try to eliminate outlier values that would trigger the alarm.

Suggest trying the simple median approach provided by the NewPing library:

sonar.ping_median(iterations [, max_cm_distance]) - Do multiple pings (default=5), discard out of range pings and return median in microseconds. [max_cm_distance] allows you to optionally set a new max distance...

For example...

unsigned int pingTime = sonar.ping_median(x); // median of x pings...in microseconds

Then you can ditch the MedianFilter library (which you have called twice, by the way) and related code.

That's what I'm using.

Dr_Bundolo:
That's what I'm using.

No you're not:

You:

unsigned int o,uS = sonar.ping();

Recommended:

unsigned int blahblah = sonar.ping_median(x);

Thanks again. In simple terms (not including the Ra-02 and OLED display) is this what you mean?

// ---------------------------------------------------------------------------
// Example NewPing library sketch that does a ping about 20 times per second.
// ---------------------------------------------------------------------------


#include <NewPing.h>
#include <MedianFilter.h>
#include <Wire.h>
#include <MedianFilter.h>

#define TRIGGER_PIN  7  // Arduino pin tied to trigger pin on the ultrasonic sensor.
#define ECHO_PIN     8  // Arduino pin tied to echo pin on the ultrasonic sensor.
#define MAX_DISTANCE 450 // Maximum distance we want to ping for (in centimeters). Maximum sensor distance is rated at 400-500cm.


NewPing sonar(TRIGGER_PIN, ECHO_PIN, MAX_DISTANCE); // NewPing setup of pins and maximum distance.

MedianFilter filter(31,0);

void setup() {
  
  Serial.begin(115200); // Open serial monitor at 115200 baud to see ping results.

  
  
}

void loop() {
  
  delay(50);                      // Wait 50ms between pings (about 20 pings/sec). 29ms should be the shortest delay between pings.
  //unsigned int o,uS = sonar.ping(); // Send ping, get ping time in microseconds (uS).
  unsigned int depth = sonar.ping_median(5);

 // filter.in(uS);
 // o = filter.out();
  Serial.print("Ping: ");
 Serial.print(depth); // Convert ping time to distance in inches and print result (0 = outside set distance range)
  Serial.println(" inches");

  
}

Yes, except you can change this:

#include <NewPing.h>
#include <MedianFilter.h>
#include <Wire.h>
#include <MedianFilter.h>

to this:

#include <NewPing.h>
#include <Wire.h>

and delete this:

MedianFilter filter(31,0);

and since ping_median returns uS, you will need to do some math before this shows a distance:

Serial.print(depth)

thanks.

Okay, I think I’ve got it now.
Thoughts?

#include <NewPing.h>
#include <Wire.h>
#define TRIGGER_PIN  7  
#define ECHO_PIN     8  
#define MAX_DISTANCE 450 

NewPing sonar(TRIGGER_PIN, ECHO_PIN, MAX_DISTANCE); 

void setup() {
    Serial.begin(115200); 
}

void loop() {
int dist = sonar.ping_median(5);
dist = sonar.convert_in(dist);
  Serial.print(dist); 
  Serial.println(" inches");
  }

Looks ok to me. Does it work? A style comment: to keep the variable names and their contents consistent, I'd probably do:

unsigned int roundTripTime=sonar.ping_median(5); //see comment below
Serial.print(sonar.convert_in(roundTripTime));

With your 450 cm max, a signed int should be ok, but unsigned is safer...in case you change your code later and forget to check...and it doesn't take up any more "room"...and it's what "convert_in" expects...

Yup. It works in that sketch. I'll integrate into the final sketch with display and Ra-02 and let you know. If it works I'll put it up for anyone else who wants to use or modify it.
Thanks for your help. Couldn't have done it without you.
Jeff

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.