Also note that the message-rate digital channels using libpd are quantized to blocks of 8 samples, so your timing resolution will in turn be quantized to $\tau = \frac{8}{44100Hz} = 181\mu s$ and accordingly the spatial resolution to $l = 3.12cm$. If you need higher resolution (up to $\tau = \frac{1}{44100Hz} = 0.23\mu s$ , $ l = 0.39cm$) then you would have to use the digital input at signal rate and check for edges in the signal (e.g.: using [rpole~ 1]).
How to mimic HS-R04 C++-Code (Ultrasonic_Distance.cpp) in PD
Thank you for your quick reply!
I made it work. I checked the pinout how you desribed and changed the input to bela_digitalIn12.
The datasheet suggests to divide the time in µs with 58 to get the value in centimeters. After fiddling around for a bit I figured that this must be wrong because I get the right cm values when using the actual value in Seconds!! not even Milli-seconds, no seconds!
The current prototype I'm using looks like this:
I'm planning to use 5 of those sensors and I found that there is an issue when I set 5 input channels to signal rate.
- Edited
I am surprised your example works at all. You are initializing [in 11 ~(, that is setting input "11" (i.e.: P8_07) to signal rate. This would come in through [adc~ 11], which you are not using. Rather you are using [r bela_digitalIn12], which should not receive anything at all unless you initialized [in 12(...
SteffenE and I found that there is an issue when I set 5 input channels to signal rate.
Could you elaborate on this?
- Edited
Oh yes, sorry I changed the i/o initializer list before making the screenshot in order to not confuse anyone who is reading this thread. I guess it's even more confusing now :-/
This is the sub-patch I'm using:
When I initilized all 5 inputs to signal rate, it didnt end initializing. In the console it didnt start to deliver the distance values at all. I will try to find out on what number of signal rate inputs this starts to happen, or maybe if it just takes a long time to initialize.
Edit:
Okay, it seems like inputs only work with signal rate if they get data on the configured pin. I have initialized a second digital in channel, but it only worked when I attached a second sensor. They currently work at the same time with this patch.
Edit 2: no this is not the end of the story, I dont know if what I stated is correct. Have to experiment a little.
Again, not sure what you are trying to achieve. Each digital pin can at any time have only ONE of the following functions:
- input signal rate
- input message rate
- output signal rate
- output message rate
So if you set, e.g.: digitalIn12 to input at signal rate, you will not receive any message to [r bela_digitalIn12], rather you will see the signal on [adc~ 12]
I cannot think of any reason why having more than 5 inputs set at signal rate would brake things, unless you are overriding pins that you expect to be at message rate.
giuliomoro
Based on your explenation about distance measurement accuracy.....
"If you need higher resolution (up to τ=144100Hz=0.23μs\tau = \frac{1}{44100Hz} = 0.23\mu sτ=44100Hz1=0.23μs , l=0.39cm l = 0.39cml=0.39cm) then you would have to use the digital input at signal rate and check for edges in the signal (e.g.: using [rpole~ 1])."
(I dont know how to quote in this forum)
....I thought I could just change the needed Digital IN's to signal rate ..and add in the [rpole~] later.
Well actually the distance measuring accuracy at message rate seems like its good enough for my use case.
I want to use 5 of these sensors and the distance determines the volume and "intensity" of the synth on a dedicated loudspeaker.
to quote you select the text you want to quote and then a pop up should show up "quote", click on it and the text will appear down here in the editor.
SteffenE ....I thought I could just change the needed Digital IN's to signal rate ..and add in the [rpole~] later.
If you switch them to signal rate they will come in through [adc~ XY] instead of [r bela_digitalInXY].
SteffenE Well actually the distance measuring accuracy at message rate seems like its good enough for my use case.
Good then!
4 years later
- Edited
I'm rather late coming to this thread, but it looks like the right place to throw in my question:
I've gotten a HC-SR04 distance sensor up and running with Bela, thanks to soravis' Pd patch, as referenced here, and thanks also to some kind pointers from @giuliomoro.
I wouldn't mind getting greater distance measurement accuracy though, as the resolution isn't the best.
giuliomoro If you need higher resolution (up to $\tau = \frac{1}{44100Hz} = 0.23\mu s$ , $ l = 0.39cm$) then you would have to use the digital input at signal rate and check for edges in the signal (e.g.: using [rpole~ 1]).
Any pointers anyone as to where and how this might be implemented in that same Pd patch?
I am not sure what the best vanilla solution for that would be ... rpole~ can help you detect an edge, but what you'll do with it I am not sure. If there was a sample-accurate way to reset a phasor~ or similar, then you could use my peak~ external to "sample and hold" the "phasor~"'s high peak before the reset.
Hmmm ... I guess you could use [samphold~] to sample the [phasor~] in response to an edge (hopefully [samphold~] is sample-accurate !!). Then reset the [phasor~]'s phase at the same (block-aligned) time as you are setting the output pin. The [phasor~] would act as your "timing capacitor": it will have to be set to a low frequency and the longer the it takes for the ECHO pin to toggle, the higher the value the phasor will reach. The phasor's period needs to be longer than the maximum time you are expected to wait for the ECHO pin, or it may self reset too early. Given how you are supposed to reset it manually anyway, maybe you could use a line~ instead of a [phasor~] to avoid this issue.
Does any of this make sense?
- Edited
Bits of it - but being out of my depth is a way of life for me 
. I'll certainly do some reading up on this and see if I can get to grips, noob though I be. As my coding skills are still weak, I've been reluctant to venture outside Pd as yet; that said, as regards going for a solution for now that is already out there, would you say I was better off having a crack at the C++/Pd solution as spoken about here and here - would that yield greater accuracy of distance measurement? I've already been having a go at that, and eventually got something running with no errors in the console - a victory by my standards - but with nothing showing from the HC-SR04 in the scope either, which kind of defeats my purpose... still hunting for what's missing...
- Edited
This is more or less what I meant:
As I don't have a HC-SR04 around, I had to emulate the signals going out and back in. For use with the actual device, you should delete the central block (delread~, delwrite~, tabwrite~ and the arrays).
Source code: here
5 days later
giuliomoro
giuliomoro thank you so much for your brain cycles! I've been prodding your code on the HC-SR04 and spending some time with it to try and follow what's going on. It works a treat, and the resolution of distance is definitely higher. I kept to the Analog Out in my wiring, as per recommendations for the HC, and so switched [dac~ 11] to [dac~ 3].
There's a fair bit of noise in the incoming values too, though, regular pulsing jumps which I've been trying to filter out. I experimented with the [delay] object for the output and found that a higher setting, around 20, eliminated a lot of these jumps, though the results do not seem directly proportional to the changes made - I'm not sure I understand why this is. I then found a vanilla version of [delta] to address the remaining jumps and did a little smoothing, all of which introduce some lag in the responsiveness, but this is a definite win for me on my learning curve... thank you again sir 
.