Hello everyone!

I am currently working on a project for Maker Faire in which audio signal is converted to light through a number of relays. The 'adc~' signal comes into the Bela, through the Pd patch, and the relays get turned on and off when the signals is over a threshold, turning lightbulbs on and off. It's a direct sound-to-light conversion.

The problem that I am encountering is that when I increase the rate of the bulbs turning on and off (somewhere between 10-50ms), at some point, the code just stops running. The Bela IDE doesn't give any kind of indication of an error. It just stops working. If I am printing the adc signal to the console, it stops printing.

I can't figure out whether I am asking the Bela to turn relays on and off too quickly or if my Pd patch is dysfunctional. I've went in and recreated the patch again, building it piece by piece. My impression is that the Bela doesn't like the incredibly quick speeds, but I don't see a reason why the relays wouldn't be able to be turned on and off at such quick rates, when an Arduino should be able to do the same with no problem.

If anybody has any ideas for how to fix this, I would greatly appreciate it. The installations needs to be left unattended over the weekend, and I obviously can't sit by constantly with my laptop having to reset the patch every few minutes.

Thank you!

Maks

Are you using the digital or analog out from Bela?
If you are using digital, are you using audio rate or message rate?
What happens if you disconnected the relays from the outputs? Does it still stop printing?
A minimal and reproducible example of a non-working patch would help.
It should be able to switch the digital outputs every 22 microseconds, the digital outputs at message rate every 180microseconds, the analog outputs every 44microseconds. so much faster than your requirements.

Are you using a transistor to switch the solenoid or using the raw bela output? Are you using a protection diode?
Something like this should work (though that was for actuating solenoids).

    Another question is what power supply are the relays being switched from? You might be glitching your Bela power supply when several relays are switching simultaneously.

    If sometime in the future you want to update the design you may consider solid state relays. Something like this would handle a full 20A power circuit:
    http://www.mouser.com/ds/2/205/CPC44055ST-768224.pdf

    But there are much cheaper options if powering something with a few hundred mA loads.

      giuliomoro Thanks for the response! I am using analog out 0-7 and am controlling a 16 channel relay. Each analog output connects to two relay switches and one of them connects to only one (15 total relay switches used). The Beaglebone is powered with a 5v 1amp jack and the relay is powered separately by a 12v connector.

      Frankly, I'm not too familiar with all the jargon, but I am not using a transistor or a protection diode. I unfortunately have no way of disconnecting the relays from the outputs as the installation is hanging twenty five feet up in the air. Therefore, I've been mainly concentrating on the code and figuring out whether my Pd patch is flawed.

      When I recreated the patch for troubleshooting purposes, I found that it could indeed print the adc signal indefinitely. There was no pause whatsoever. I walked away for twenty minutes, came back, and found it still running. Over time, I added in each part of the original patch until it was the same as I had originally made it. It was only when I added a 'metro' object that controlled the tempo of each flashing "pattern" (turning relays on and off) that I found the patch began to pause again (indicated by the lights no longer flashing and being frozen in place). This indicates to me that there is something wrong with either the Pd patch or with how the relay is wired to the Bela.

      Frankly, I've been having a lot of issues with consistency and have found that sometimes the patch works, and sometimes it doesn't. I don't know if this has more to do with simple errors in the Pd patch or issues with the Bela IDE and making sure that I stop and run the code appropriately. At this point in time, I am able to get the low-latency reaction of sound-to-light pretty consistently, but occasionally it still pauses, forcing me to grab my laptop and reset the patch from the IDE.

      There isn't too much more that I can do at this time as the Faire is running for the next couple of days and I don't have a 30 foot ladder available. I'll have to deal with having to occasionally reset the patch. Regardless, I'd love to figure out why it works the way it does. I'm confident that it'll be useful to know when I'm working on other Bela projects in the future.

      ryjobil The relays are being powered by a 12v wall-wart. The Bela is powered by an independent 5v 1amp jack. Frankly, I'd be surprised if the Bela was glitching from the relays. The power from both devices is isolated so I get the impression that they wouldn't necessarily affect one another.

      I don't know too much about the solid state relays but thanks for the tip! I'll be sure to take a look.

      Could you post a link to the relays you are using? What current do they require?

      It seems just the wrong thing to do to connect the relay straight to the analog outs, and I am surprised they did not get damaged by the flyback voltage spike generated when the output goes down.

      Yet, what I would expect as a symptom of an excessive current draw or missing protection would be the board hanging, shutting down or the analog outputs to get permanently damaged, so I still struggle to explain the behaviour you are observing.

      One further troubleshooting step you can take is to run your patch exactly as it is, with the [metro] and everything, just disconnect all the [dac~] objects: this way you can test whether it is something inside the patch or something to do with the actuation of the relays.

        giuliomoro The relay looks like this: https://www.sainsmart.com/products/16-channel-12v-relay-module. I'm not sure if this is the EXACT model or whether mine is a Chinese knockoff. I borrowed it from a friend. However, it does look exactly like that.

        You mean that connecting the Bela's analog outs to the Relay is incorrect and can damage the relays? Or the Bela? Or both? Should I have used the digital outputs instead? I guess in a way it would make sense since I'm dealing with 1's and 0's. At the time of testing though, for some reason I was unable to get it to function properly so I had to resort to using the analog outputs.

        I actually don't have any [dac~] objects at all. I only have an incoming [adc~] object. Do you mean disconnect that one and see whether the metro still runs accordingly?

        Thanks again for the immense feedback by the way. I'm still learning quite a bit about the Bela so having further information on it can only help.

          Traditional electromechanical coil-based relays would require extra protection in order not to damage the board, but these ones you linked now are solid-state, so there should not be any such problem.

          MaksymPrykhodko Should I have used the digital outputs instead? I guess in a way it would make sense since I'm dealing with 1's and 0's. At the time of testing though, for some reason I was unable to get it to function properly so I had to resort to using the analog outputs.

          This could be explained because the analog out give a higher voltage (5V) than the digital (3.3V). The "datasheet" you linked mentions TTL, so 3.3V should be enough to trigger the relay, but perhaps it is happier with 5V.

          MaksymPrykhodko I actually don't have any [dac~] objects at all. I only have an incoming [adc~] object.

          So how do you send the output signals to the analog outs? The only way to send signals to the analog out from Pd is to use the [dac~] object, unless you use a custom render.cpp file.

            giuliomoro My mistake on that last answer. Yes, I indeed have a [dac~ 3 4 5 6 7 8 9 10] object in my Pd patch. It doesn't transmit sound to any speakers so I forgot that I was using it for a second there.

            I'll try your suggestion and temporarily remove the [dac~] object to see whether the Bela still crashes. I'll get back to you on that soon. Thanks again.

              MaksymPrykhodko An update to my last reply:

              I removed the [dac~ 3 4 5 6 7 8 9 10] object from my patch and ran it. The [adc~] is printing values with no problems whatsoever and the Bela doesn't crash. Does this imply that the issue is with the relays or how I physically made the connections to the relays from the Bela?

              It seems to be the case, yes. I am not sure what would cause such behaviour, though. Are you connecting the grounds of the 5V and 12V supplies together? That could cause some problems

              Maybe @ryjobil has a better idea?

              I don't think that an object in Pd can detect whether there is anything connected to its outlets, but in order to take care of this case, just to be sure, could you try the following: instead of deleting the [dac~] object, could you replace it with something like[expr~ $v1+$v2+$v3+$v4+$v5+$v6+$v7+$v8] ? This is just a dummy object with 8 signal inputs, to make sure that nothing changes as far as the objects that are connected to it are concerned.

                giuliomoro The ground of the relay is connected to the ground of the Bela. I don't think that they would work in unison otherwise.

                I will try and test out that expression object in place of the dac~. I get the impression that it must all be physical.

                I looked at the relay board schematic (downloaded the .rar file). The bottom line is I wouldn't recommend ever buying another one of those and give them 1-star rating.

                Basically you are having to drive an opto coupler LED with the analog outputs. The "low level inputs" require 15 mA to 20 mA to drive them. This really could cause a substantial ground bounce on the Bela board when you switch them simultaneously.

                What I see is a big ground loop with up to ~100mA trying to get from your DAC ground pin back to the relay board when all DAC's are simultaneously trying to pull down on the relay board inputs.

                I haven't taken time to look at the DAC datasheet but I would guess 20 mA sink current is pushing the limits already.

                This could look like a big transient spike ground bounce on your Bela board, which could couple into something in the CPU and make it crash. It might be upsetting I2C operation and maybe your program crashes because the I2C bus gets put into an illegal state.

                You would be best served to drive these each with a MOSFET, like a 2N7002, populated directly on the relay board. Put a 10k resistor in series with the MOSFET gate to decouple the driver signal from gate capacitance since this can also cause transient currents.

                It would look something like this:

                                  |-----IN1 on relay board
                                  |
                               |--
                 --/\/\/------||<-  2N7002 or similar small-signal switching MOSFET
                |   10k        |--|
                |                 |
                |                GND (at relay board)
                |
                |----Bela DAC 1 output, or GPIO (2N7002 gate is compatible with 3.3V output level)
                
                Note:  The switching function will be inverted

                The recommended configuration keeps the LED drive loop currents localized to the relay board and very little current is required from the Bela DAC or digital output to toggle the state.

                The way they designed that board serves as a good example of how NOT to do it.

                The use of the industry's top quality optocoupler isolation, strong anti-interference ability, stable performance

                Makes me laugh.

                The optocoupler isn't actually isolating anything because they are bridging the isolation boundary through the 5V converter on the board. It's just serving as a really inefficient transistor. Even worse, by routing the 5V out to a pin suggests you should connect 5V there to operate the board -- and now you have (2) different 5V converters fighting each other if you actually do this.

                You're still ok for isolation because it's the relay that isolates your circuit from the high energy power stuff. It's just that all of the circuitry on their board could be replaced with the circuit snippet I showed above with a catch diode for each relay coil -- they would have saved a ton of cost per board AND it would have been a better product.

                If they wanted your circuit to be isolated from the 12V supply then they should have given you both ends of the opto-isolator LED without connecting 1 side to the 5V bucked from the 12V.

                Actually you can do this with an Xacto knife. It looks from the board layout there is a clear distinction and a nice open run of 5V trace that you can carve off the board and then you will have 100% isolation from the 12V converter. In that case you would not use the ground at all -- Just 5V from your board and the Bela analog outputs.


                If you're not handy with a soldering iron and you just want to live with it, there are some things you can do to possibly work around this problem:
                1) If it's due to ground-bounce on fast changing edges, then you can help mitigate it by slewing the analog outputs more slowly. Ramp the analog outputs on and off more gradually over a longer period of time -- like use more than 10 steps to transition the edges. This will work if the problem is due to the fast edge current pulse from trying to switch several from high-to-low all at the same time.

                #2) Reduce total currents. Finally you can play with the logic thresholds of the buffer IC. You probably don't need the full 15 mA to get it to change state, so you can set a lower-limit on your analog outputs so you are driving just barely low enough to get the relay to change state, then come up with some kind of margin around that so you aren't skipping

                3) Pulse the outputs in a pattern where only 2 or 3 can be sinking current simultaneously. In this relay board you linked, pulling low (toward analog 0V) is when it's conducting current, so the variable you want to play with is how low it can go.