I am trying to get an HC-SR04 Ultrasonic Ping Sensor working. The sample code I have tried from a couple of sites throws errors that I don’t know how to fix. Does anyone have sample code to get one of these working with the Core?
I started here: https://code.google.com/p/arduino-new-ping/
Thanks in advance!
You’ll need to add this code after your setup and loop blocks:
Let me know if that helps. 
Looking at the code, there’s quite a number of libraries required to get the examples going,
@timb you beat me to speed. haha!
I actually added your code to the other examples and made sure it could compile before typing this:
PulseIn function from: https://community.spark.io/t/pulsein-function-version-0-1-beta/2276
hc-sr04 example from: https://gist.github.com/flakas/3294829
Combined code https://dl.dropboxusercontent.com/u/36134145/hc-sr04.txt
Thanks @timb that was exactly what I was missing!
@kennethlimcp Thanks for your code as well, I will look to see if this improves what I already hacked together.
Right now this is keeping a robot from hitting walls, so thanks very much for the quick save!
Hi Guys, I took a slightly different approach and used interrupts and the microsecond timer. This is working well for me.
giterdone by clicking here…
I almost went that route with my library, however the uC timer is unreliable because it overflows in a short period of time, so you may not get a valid reading. Secondly, interrupts can actually cause said timer to not iterate correctly.
If you simply need to know if the sensor has changed, your code will work fine, however it’s not reliable if you want repeatable performance every time.
By the way, my pulseIn function should be integrated in the core Wiring library soon as I’m about ready to push it into the master repository.
I get an error 404 trying "Combined code https://dl.dropboxusercontent.com/u/36134145/hc-sr04.txt". Has it moved somewhere else that I can find it.
@Jack, this was @timb’s thing and he has not been in the forum for at least a year. I will work on getting a working pulseIn() in the next few days.
thanks @peekay123. My ultimate goal is to get an ultrasonic sensor to work. Maybe it can work without the pulseIn() command, or maybe it needs pulseIn() to work. Thanks again.
@Jack, I think you will need pulseIn(). Have you calculated the estimate pulse length for the shortest distance? If not, could you?
Sorry @peekay123, I don’t know how to do that. I do know the shortest distance can be adjusted a bit, 7 to 9 inches. Max distance is about 6 foot. Accuracy of about 10% will suffice.
I suspect the test function would require less than 1/10 second (probably less than 1/60 second), so during that time, other processes could wait. What do you think?
OK the speed of sound is around 343 m/s, 7 inches is 0.1778 m and 6 ft. is 1.8288 m. The pulse has to travel down and back, so we have to double those distances. So that works out to around 1.036 ms for the shortest path and 10.66 ms for the longest.
@bko, OMG you are fast! So using digitalRead() would be fine since it runs at 2us on a Core and probably less than 1us on the Photon. That would mean an error way less than the 10% that @Jack is looking for. The sampling loop time would need to be timed for the correct conversion however.
Don't put it any high priority on my account. It's not a high priority to me. But would be a welcome addition to core/photon commands.
I normally don't count on actual numbers from sensors, rather I calibrate and then use map().
@Jack, if @bko agrees with my approach (he’s got a brain the size of Manhattan) then modifying the pulseIn() function for your purposes will take very little time.
We should definitely get pulseIn() working on Photon so that part is a no-brainer.
With the problem at hand having about 1ms timing accuracy requirements, that could be done many different ways as you say. But pulseIn() is a very natural and easy way to solve that problem.
And @peekay123 is no slouch in the brains department either! You can ask my wife how stupid I can be sometimes 
!
Don’t worry about pulseIn() missing on my core. I have some Photons on order,and expect them this month. Then I will retire my core to some minimal tasks.
@peekay123, I was wondering about the coexistence of pulseIn() functions, and interrupt driven events.
Would it be a problem if a function using pulseIn() was called (by interrupt) before it had finished its last sequence. What if that happens over and over ?
Jack, I would not call pulseIn() via an interrupt I could help it since it is a blocking function. A better pulseIn function would be interrupt driven itself (fired on one or both edges of the pulse). Can you give me use scenario so I can make some suggestions?
So, do you think the pulseIn() could be designed to use interrupts, therefore not being a blocking function?
The example I was thinking of was using the ultrasonic sensor library. It could take 10ms to process, and If I was calling that function ever 7ms, what would be the result.