PING Sensor Code Not Working [SOLVED]

Hardware
21

Jack, attempting to fire a 10ms blocking event every 7ms is not a good approach, even if the pulseIn function is interrupt driven. Requiring data which takes 10ms (or more?) to generate every 7ms is not going to work.

Not knowing you application, I would say you need to separate the two events (pulseIn vs 7ms event) based on who generate the data and who consumes the data. What I mean by that is the distance measuring code should run all the time while the other (7ms) event that requires that distance simply takes the ā€œlatestā€ distance data. They are out of sync but that may be fine depending again on what you are trying to do. If you can elaborate more on that, I may be able to guide you better.

22

I realize that it would not be a good approach, but In practice, it could happen unexpectedly.

I thought one of two things may happen.

  1. The core would just slow down, but still continue to run.
  2. The core would lockup, and not run anymore.

Number 1. would normally be acceptable, but if itā€™s number 2. I want to really avoid such an event.
What do you think would happen?

If the pulseIn() is a blocking function, then nothing else can run, but if pulseIn() was not blocking, then other tasks could still be running. Since we donā€™t have pulseIn() yet, I donā€™t know if it is(will be) blocking or not. Do you know?

Its not really that important, I was just curious,and I could not find the answer myself.

23

I has thee answer!

Design the pulseIn() function to be non-blocking. Done! :smile:

1 Like
24

@BDub, you still canā€™t sample a 10ms device at 7ms intervals. The 7ms calling event will have to wait for pulseIn() to finish before it can call it again. I propose having pulseIn() run all the time (ideally interrupt driven) and the 7ms event simply uses the ā€œlatestā€ pulseIn() results. That way they are decoupled.

25

You can if itā€™s non-blocking :smile: You are of course also right on the money with the interrupts, which is a non-blocking approach.

I was hoping to avoid debating over the proper implementation of Jackā€™s hypothetical use case. As I read it, he was throwing out a hypothetical use case just to see how weā€™d handle it. Since he said, ā€œIts not really that importantā€ I decided not to spend too much time on this until it was important :smile:

How Iā€™d handle it, properly design the pulseIn() function to be non-blocking, and donā€™t read it faster than necessary. If itā€™s measuring distance at the speed of sound 340.29 m/s, Iā€™m assuming your application is moving an order of magnitude slower, which should mean you donā€™t need to read it faster than every 50-100ms. Iā€™m probably wrong though, because this is hypothetical. O_O

Sure you can design everything to be non-blocking, but sometimes a simple deterministic super-loop type of program will get the job done quickly as well.

An effective way to design anything youā€™re going to use soon is to have an idea of what you need to accomplish first, then take steps to achieve your goals. Or you could just say, heyā€¦ what would it take to build the fastest transistor in the world? When you set goals like that the outcome is typically more ground breaking in the long run, but less tangible in the short run.

Is this a science project @Jack, real application, or fake application?

If you need an application to design to, hereā€™s one! I need to use the PING sensor on my Spark Core Sumo Bot. Itā€™s doesnā€™t move very fast, maybe 0.6m/s tops. How do I keep it from crashing into walls when I command it to go forward? How can I make it find walls (aka other bots) and keep pushing them until they disappear?

1 Like
26

Thanks all. My question was hypothetical.
if a slow function was called by interrupts to fast, what will happen (1. slow system down) (2.halt system) ?
But as icing on the cake, it will be great if pulseIn() will be non blocking.

My project is resource management for a water tank, used for garden/greenhouse. Want to know how full the tank is.Then determine when to disburse water, and when to refill with commercial water. It will be filled by rain water, and water from a far away creek using a hydro ram pump also.

27

@Jack, if a slow function is called the interrupts too fast and that specific interrupt is disabled until the slow function finishes then nothing except the fact that some interrupts will be missed will happen. If the interrupt is not disabled and the ISR code is not written to be re-entrant then a fault will most likely occur (stack overflow possibly).

The application you outline does not require fast servicing. Your main loop should sample the water height at regular intervals (30 secs?) then make decisions based on that height. You will need to average your results so you donā€™t get hysteresis. None of the events you describe have a ā€œreal-timeā€ in the order of 7ms!

28

The 7ms thing was just an example, hypothetical, not needed for my project. Thanks for all the info, I have learned a lot.

BTW, I found code for the ultrasonic sensor in the library of the IDE, it was called ā€œhc-sr04ā€, if anyone is looking for it. It works pretty well on the core.

I think we have solved the questions for this thread (and more). If anyone is able, you may want to mark this as [SOLVED].

1 Like
29

You mean this one?

I had this bookmarked as well :wink:

30

No. The one I found is like

#include "HC_SR04/HC_SR04.h"

double cm = 0.0;
double inches = 10.0;
double inchesLast = 10.0;
double inchesAverage = 10.0;
int trigPin = D4;
int echoPin = D5;

/*
Connect an HC-SR04 Range finder as follows:
Spark   HC-SR04
GND     GND
5V      VCC
D4      Trig
D5      Voltage divider output - see below

Echo --|
       >
       < 470 ohm resistor
       >
       ------ D5 on Spark
       >
       < 470 ohm resistor
       >
GND ---|
31

Thanks to whoever fixed my code quoting. I guess it may not be ā€˜ā€™ā€™ but ```. I will try that next time.

32

Yes, you made a Grave mistake :wink: haha

3 Likes
33

Nice, I didnā€™t even know we had this in the Particle Libraries! :wink:
https://build.particle.io/libs/54e1b12ed3ab2814f5000a99/tab/HC_SR04_Variables.cpp

34

Hi, Did anyone on this thread have a problem where the reported measured number was inversely proportional to the distance? The closer you are to the object, the larger the number the sensor read-out ā€˜in the dashboardā€™. And the further away from the object, the lower the sensor read-out ā€˜in the dashboardā€™. I wouldā€™ve expected the equation to be something like 34300 = (distance) / (time / 2). Iā€™m using the *.cpp library from the Particle Build() site. Any ideas?
https://build.particle.io/build/55bbf855ef0aa273fe0008d4/lib/54e1b12ed3ab2814f5000a99/tab/HC_SR04.cpp