SteffenE Last question. Can I plug the bela to my computer AND simultaneously to the power supply?
Yes you can, no problems at all. Even better, you can disconnect either at any time and it will still run off the other one.
SteffenE Last question. Can I plug the bela to my computer AND simultaneously to the power supply?
Yes you can, no problems at all. Even better, you can disconnect either at any time and it will still run off the other one.
Hi,
I am trying to create a virtual piano. For this I am planing to using an ultrasonic module for getting the input. I have followed the same voltage divider circuit as mentioned in this discussion. Unfortunately, when I tried to run the provided example (examples/06-Sensors/ultrasonic-distance) it is not giving me an output as expected. But I can see some fluctuations in the scope though the rt_printf("pulseLength: %d, distance: %fcm\n", pulseLength, distance); is not giving me any output.
It would be a great help If someone can help me this.
Thank you in advance,
Jonath John
Can you tell us how you wired up the device?
What does the scope show exactly? Does it show any signal at all on the first channel? that is where the digital input should come in: scope.log(digitalRead(context, n, gEchoDigitalInPin), distance/100);
Thank you for replaying.
I have connected vcc to 5v, Trig pin to analog out - 0, Echo pin to digital 1 which is taken out from the voltage divider and the rest is grounded.
echo-/\/\/\--|--/\/\/--gnd
2.2k | 4.2k
|
Bela digital -1
Regarding the scope, it is showing signal on the first channel, but it is not printing the distance or the pulse length.
Where did you get 5V from on Bela? You should get them from P9.07
, not from the analog out header.
Jonath Regarding the scope, it is showing signal on the first channel, but it is not printing the distance or the pulse length.
The scope is not supposed to print anything, the print should happen in the console in the Bela IDE. If there is no printing in the Bela IDE, then show a screenshot of the scope, please.
Ok, I was taking 5V from analog out. Let me just ry it from p9.07. Regarding the distance, I mean it was not printing in the Bela IDE. probably changing to p9.07 should solve the problem.
Thank you so much
Even after changing to p9.07 it wasn't printing the output. After making some changes in the code it started to work fine. I tried both using p9.07 and and from analog out. Taking out from p9.07 is giving much more accurate and stable output.
I appreciate your time
Kind regards
what changes were necessary?
To print the value, I just put the print statement out of the "if(pulseLength >= gMinPulseLength)" statement.
if(gcount > 50000){
rt_printf(" Distance: %fcm\n", gdistance);
gcount = 0;
}
++gcount;
Hi, I hope it's ok to jump in on this thread (please let me know if I should start a new one!)
I've been following this and another ultrasonic bela/Pure Data thread to get two sensors working with my Bela and audio capelet.
So far each sensor is setup for a pair of digital triggers/echoes (P8_07/P8_08 & P8_09/P8_10) with voltage dividers. Each sensor works individually and sending fine to Pure Data when powered by the analog out 5V pin (but the sensors don't work when both connected, I'm assuming because the voltage drop is too low).
When I swap the voltage supply from the analog 5V pin to P9_07 to try and power both sensors, both sensors stop working/receiving/sending data, even when tested individually. This is with using barrel jack & USB power.
Is there something I'm missing to use the P9_07 as 5V supply with two sensors - e.g. is this pin still usable with the audio capelet and is there anything I need to add to the code? Or could I have made a mistake with the voltage division or sensor setup?
Any help/thoughts much appreciated. Forgive me if I'm misunderstanding anything obvious/crucial too!
Cheers
There shouldn't be any problem from the power supply: these sensors do not require much current.
Can you try to connect both sensors but only enable the code to use one at a time and verify that they both work fine (individually)? It may well be something in your code or in the library code I wrote 3 years ago that breaks the software when using two at a time ...
Thanks a lot for getting back to me!
This is great, I hadn't even thought to check the code side of things! I'll check that out... I followed the detailed advice on the other large ultrasonic sensor thread too which was really helpful, so the render is mostly that too. Can you advise what's the best way to enable each sensor in the code one at a time - is there a line I can write in...? (I'm sure that's a dumb question, sorry - very new to the scripting side of things. Though absolutely loving Bela and what it can do).
you probably are using some code based on this. If you have two sensors connected, I would assume that you will have duplicated some lines of code. Comment out the duplicated lines.
Hint: posting your code would help in helping you.
Thanks a lot - I do believe to my best of my memory and knowledge that this is what the code is based on!
And you're very right, a top tip haha - here is the code... I imagine there's probably redundant stuff in there too from myself not knowing exactly what to chop out etc
Thanks a lot for your help, I really appreciate having some support with this
EDIT by giuliomoro: I deleted the 600+ lines cpp code that was making it hard for me to browse the thread. The diff in the post below highlights the important parts of it.
These are the changes you made to the core/default_libpd_render.cpp
file:
diff --git a/core/default_libpd_render.cpp b/other.cpp
index ac789c65..5590dd5a 100644
--- a/core/default_libpd_render.cpp
+++ b/other.cpp
@@ -1,3 +1,4 @@
+
/*
* Default render file for Bela projects running Pd patches
* using libpd.
@@ -11,12 +12,14 @@
extern "C" {
#include <libpd/s_stuff.h>
};
-#include <libraries/UdpServer/UdpServer.h>
-#include <libraries/Midi/Midi.h>
-#include <libraries/Scope/Scope.h>
+#include <UdpServer.h>
+#include <Midi.h>
+#include <Scope.h>
#include <string>
#include <sstream>
#include <algorithm>
+#include <stdlib.h>
+#include <PulseIn.h>
enum { minFirstDigitalChannel = 10 };
static unsigned int gAnalogChannelsInUse;
@@ -31,6 +34,24 @@ static unsigned int gFirstDigitalChannel;
static unsigned int gLibpdDigitalChannelOffset;
static unsigned int gFirstScopeChannel;
+PulseIn pulseIn;
+PulseIn pulseIn2;
+Scope scope;
+int gTriggerInterval = 1323; // how often to send out a trigger. 2646 samples are 60ms
+int gMinPulseLength = 7; //to avoid spurious readings
+float gRescale = 58; // taken from the datasheet
+unsigned int gTriggerDigitalOutChannel = 0; //channel to be connected to the module's TRIGGER (digital) pin
+unsigned int gTriggerDigitalOutChannel2 = 2;
+unsigned int gEchoDigitalInPin = 1; //channel to be connected to the modules's ECHO pin (digital pin 1) - check the pin diagram in the IDE
+unsigned int gEchoDigitalInPin2 = 3;
+int gTriggerCount = 0;
+int gTriggerCount2 = 0;
+int gPrintfCount = 0;
+int gPrintfCount2 = 0;
+float* gScopeOut;
+void* gPatch;
+bool gDigitalEnabled = 0;
+
void Bela_userSettings(BelaInitSettings *settings)
{
settings->uniformSampleRate = 1;
@@ -295,13 +316,18 @@ void fdLoop(void* arg){
}
#endif /* PD_THREADED_IO */
-Scope scope;
-float* gScopeOut;
-void* gPatch;
-bool gDigitalEnabled = 0;
-
bool setup(BelaContext *context, void *userData)
{
+ // Set the mode of digital pins
+ pinMode(context, 0, gTriggerDigitalOutChannel, OUTPUT); //sending TRIGGER from digital out
+ pulseIn.init(context, gEchoDigitalInPin, HIGH); //detect HIGH pulses on this pin
+ pinMode(context, 0, gTriggerDigitalOutChannel2, OUTPUT); //sending TRIGGER from digital out
+ pulseIn2.init(context, gEchoDigitalInPin2, HIGH); //detect HIGH pulses on this pin
+ if(context->analogInChannels != 8){
+ fprintf(stderr, "This project has to be run with 8 analog channels\n");
+ return false;
+ }
+
// Check Pd's version
int major, minor, bugfix;
sys_getversion(&major, &minor, &bugfix);
@@ -328,7 +354,7 @@ bool setup(BelaContext *context, void *userData)
//gMidiPortNames.push_back("hw:0,0,0");
//gMidiPortNames.push_back("hw:1,0,1");
- scope.setup(gScopeChannelsInUse, context->audioSampleRate);
+ scope.setup(2, 44100);
gScopeOut = new float[gScopeChannelsInUse];
// Check first of all if the patch file exists. Will actually open it later.
@@ -466,6 +492,65 @@ bool setup(BelaContext *context, void *userData)
void render(BelaContext *context, void *userData)
{
+ for(unsigned int n = 0; n<context->digitalFrames; n++){
+ gTriggerCount++;
+ if(gTriggerCount == gTriggerInterval){
+ gTriggerCount = 0;
+ digitalWriteOnce(context, n, gTriggerDigitalOutChannel, HIGH); //write the status to the trig pin
+ } else {
+ digitalWriteOnce(context, n, gTriggerDigitalOutChannel, LOW); //write the status to the trig pin
+ }
+ int pulseLength = pulseIn.hasPulsed(context, n); // will return the pulse duration(in samples) if a pulse just ended
+ float duration = 1e6 * pulseLength / context->digitalSampleRate; // pulse duration in microseconds
+ static float distance = 0;
+ if(pulseLength >= gMinPulseLength){
+ static int count = 0;
+ // rescaling according to the datasheet
+ distance = duration / gRescale;
+ libpd_float("distance1", distance);
+ libpd_bang("foo");
+ //rt_printf("Sending distance to pd\n");
+ if(count > 5000){ // we do not want to print the value every time we read it
+ rt_printf("pulseLength: %d, distance: %fcm\n", pulseLength, distance);
+ count -= 5000;
+ }
+ ++count;
+
+ }
+ // Logging to the scope the pulse inputs (gEchoDigitalInPin) and the distance
+ scope.log(digitalRead(context, n, gEchoDigitalInPin), distance/100);
+
+ }
+
+ for(unsigned int n = 0; n<context->digitalFrames; n++){
+ gTriggerCount2++;
+ if(gTriggerCount2 == gTriggerInterval){
+ gTriggerCount2 = 0;
+ digitalWriteOnce(context, n, gTriggerDigitalOutChannel2, HIGH); //write the status to the trig pin
+ } else {
+ digitalWriteOnce(context, n, gTriggerDigitalOutChannel2, LOW); //write the status to the trig pin
+ }
+ int pulseLength = pulseIn2.hasPulsed(context, n); // will return the pulse duration(in samples) if a pulse just ended
+ float duration = 1e6 * pulseLength / context->digitalSampleRate; // pulse duration in microseconds
+ static float distance2 = 0;
+ if(pulseLength >= gMinPulseLength){
+ static int count = 0;
+ // rescaling according to the datasheet
+ distance2 = duration / gRescale;
+ libpd_float("distance2", distance2);
+ libpd_bang("foo");
+ //rt_printf("Sending distance2 to pd\n");
+ if(count > 5000){ // we do not want to print the value every time we read it
+ rt_printf("pulseLength: %d, distance2: %fcm\n", pulseLength, distance2);
+ count -= 5000;
+ }
+ ++count;
+
+ }
+ // Logging to the scope the pulse2 inputs (gEchoDigitalInPin2) and the distance2
+ scope.log(digitalRead(context, n, gEchoDigitalInPin2), distance2/100);
+ }
+
int num;
#ifdef PARSE_MIDI
for(unsigned int port = 0; port < midi.size(); ++port){
@@ -636,14 +721,6 @@ void render(BelaContext *context, void *userData)
dcm.processOutput(&context->digital[digitalFrameBase], gLibpdBlockSize);
}
- // scope output
- for (j = 0, p0 = gOutBuf; j < gLibpdBlockSize; ++j, ++p0) {
- for (k = 0, p1 = p0 + gLibpdBlockSize * gFirstScopeChannel; k < gScopeChannelsInUse; k++, p1 += gLibpdBlockSize) {
- gScopeOut[k] = *p1;
- }
- scope.log(gScopeOut[0], gScopeOut[1], gScopeOut[2], gScopeOut[3]);
- }
-
// audio output
for(int n = 0; n < context->audioOutChannels; ++n)
{
@@ -675,3 +752,4 @@ void cleanup(BelaContext *context, void *userData)
libpd_closefile(gPatch);
delete [] gScopeOut;
}
this looks like it should work (although it could be made much more compact).
One mistake you are doing is that you are logging to the scope
twice. You are only supposed to call log()
once per sample. In this case your scope output is going to be mostly unusable, but this shouldn't prevent the rest of the core from working correctly.
So, to apply my earlier suggestion of "enabling only one of the two sensors at a time" in the code, you shall do what follows:
pinMode(context, 0, gTriggerDigitalOutChannel2, OUTPUT); //sending TRIGGER from digital out
pulseIn2.init(context, gEchoDigitalInPin2, HIGH); //detect HIGH pulses on this pin
for(unsigned int n = 0; n<context->digitalFrames; n++)
block from render()
.setup()
:
pinMode(context, 0, gTriggerDigitalOutChannel, OUTPUT); //sending TRIGGER from digital out
pulseIn.init(context, gEchoDigitalInPin, HIGH); //detect HIGH pulses on this pin
for(unsigned int n = 0; n<context->digitalFrames; n++)
block from render()
.Testing:
If 2. and 4. fail, then it's most likely a problem of power supply. If all pass, then it's most likely a problem of code.
Hi again giuliomoro! Thanks a million for this, it's really helpful. Sorry for the slow reply too, I was away for a bit but I'm back on this now.
Ok so I followed your advice - I tried to enable only one sensor at a time, but when it came to enabling just the second sensor (channels 2/3) I kept running into code errors so I couldn't really properly enable only one sensor at a time (it was probably something I was doing wrong but I didn't want to fiddle with it too much - attached a pic of the errors for reference).
However when I had both sensors connected, but only the first enabled in the code (channels 0/1), neither sensor worked. So step 2 failed - which I'm assuming means it's a power supply issue, if I've understood that right?
I'm wondering if it's to do with trying to power both sensors off the analog 5V pin, and if their respective voltage/resistor divider circuits (for the trigger signal) could be messing with it...? This was all done while powering the Bela USB/from my laptop too.
What do you think?
Right, if step 2 failed then it should mean that it is a power supply issue, although I am surprised that it manifests itself this way, and it's also weird because each sensor only uses 15mA, while that supply rail should have 500mA! Granted, you have the Bela cape and the audio capelet connected as well, but still, you shouldn't be hitting the limit.
Just checking:
a- are you still using the 5V from P9.07/P9.08?
b- what did you do for step 2 above? Did you just connect the second sensor to the power supply, or did you connect its GPIO pins as well? Try to only connect it to the power supply (no GPIO pins) . Does it work?
Try a couple more things:
- measure the voltage at P9.07/P9.08 with no sensor connected, with one sensor connected and with two sensors connected.
- get yourself a 5V power supply. This could be a USB charger, with some sort of cable that allows you to easily break out the power (e.g.: a cable with barrel jack, or simply rip open an existing USB cable and extract the GND and +5V (they should be Black and Red respectively, but double check with a voltmeter). Connect the GND wire to Bela, and then power both sensor between this GND and +5V, but then connect their GPIO pins to Bela as above. DO NOT connect +to Bela the 5V from the power supply. Does this work ?
Not sure what the error you are getting on your code is, there is not enough information displayed there, but most likely you commented out the opening curly brace {
at the top of your comment, but not the closing one }
at line 522.
Thanks a lot for continuing to help crack this puzzle! This has been useful to go through as I've found some "anomalies"? Perhaps...
I realised as well I should probably clarify that when I say "doesn't work" I mean I'm getting constant "zeros"/no audio reaction on the Bela IDE console readings (instead of data readings/numerical values & reactive audio when the sensor is "working"). Just in case it could be an issue with how the data is being handled rather than the sensor "not working", though it does seem like a power thing or something weird with how I've circuited/hooked up the sensors maybe?
a- I was using the analog 5V, not P9.07/08!
b- I connected the sensor fully to Bela (it's vcc/gnd/trig/echo pins) when testing before - is this what you mean by GPIO?
I tried some multimeter tests and got these results...
Analog 5V:
- one sensor connected: 3.5V (working: sends/receives data on Bela IDE console/Pure Data audio reacts)
- two sensors connected: 2.9V (no data)
P9.07:
- one sensor connected: 4.9V (no data - weird?)
- two sensors connected: 3-4V (no data)
Not sure if this is weird or a clue - one sensor works/sends data when using the analog 5V, but switch to P9.07 and that sensor stops working. I get a pretty consistent 4.9V reading between P9.07 & GND (Bela pins) and just to be sure I checked on the Sensor Vcc/GND pins and it's about the same.
Tried your power supply suggestion too, using positive/negative voltages of a USB/barrel jack (with a USB battery pack), running negative to the Bela & sensor, positive just to the sensor, and trigger/echos to BELA (if I've understood this correctly?). I get fairly consistent readings of 3-4.5V, both Bela & sensor don't power on/no reaction.
RE the code error that's quite likely what I did wrong!
Does this give you any clues?
Unicorpse Analog 5V:
- one sensor connected: 3.5V (working: sends/receives data on Bela IDE console/Pure Data audio reacts)
- two sensors connected: 2.9V (no data)
ok this is expected. That pin has 100ohm in series, so the voltage goes down when you connect a load that is too high.
Unicorpse P9.07:
- one sensor connected: 4.9V (no data - weird?)
- two sensors connected: 3-4V (no data)
Now, this is very weird. One sensor connected should work just fine. Not sure what to say about it, have you tried both sensors (one at a time)? Where do you connect the ground of the sensor? It shouldn't make any difference, but make sure you plug it in P9.01/P9.02.
Unicorpse Not sure if this is weird or a clue - one sensor works/sends data when using the analog 5V, but switch to P9.07 and that sensor stops working.
Yeah this is crazy. Also, only now I notice that you wrote this in your first post, apologies for missing it.
Unicorpse running negative to the Bela & sensor, positive just to the sensor, and trigger/echos to BELA (if I've understood this correctly?).
Yes.
Unicorpse I get fairly consistent readings of 3-4.5V
this sounds pretty weird. You have "consistent" readings between 3V and 4.5V ???
Unicorpse both Bela & sensor don't power on/no reaction.
You should still power Bela through the USB port, it wouldn't be powered by the battery in this configuration.
Thanks a lot! I'm slightly reassured that I'm not the only one finding it weird.
I'll be back in the studio tomorrow so can come back to this properly then - I'm wondering though is it at all possible that something in the code is preventing the trigger from going, is there a part about voltage "send"?