Audio Library and LED components question

Status
Not open for further replies.

Mrichard

New member
Hello Everyone,

I am a long time user of PJRC products, but almost always for LEDs only. This time I am working on a fast turn around project that requires the incorporation of the audio library, SD card, imbedded RTC, two external optical switches, and several hundred WS2812b LEDs. I am worried that with such a short deadline I am going to parts order myself into corner. Looking to the community to make sure none of the components are going to interfere with each other pin wise or data wise. Here is the project breakdown:

Two sides of a rectangular pillar have audio handsets on hangers and animating LED strips climbing up the pillar from above the audio handsets. A small reflective infrared sensor is placed behind each handset so I can monitor when a handset is picked up from the hanger. When a user picks up a handset, the LED animation changes in color and a 2 second timer begins(time it takes to move handset to ear). When timer completes, the audio file (wav file on sdcard) for that handset plays. When the audio file ends playing, the LED animation changes color again and another timer begins, this time 6 seconds. When this timer ends, it triggers the easter egg audio of some fun elevator music. This easter egg audio will be used on both handsets for this purpose. I fully expect multiple users to be engaging with both handsets at the same time.

Here is a fully list/breakdown of what I think I need:

Micro Controller: Teensy 3.5 or 3.6 (not sure if the 5volt tolerant pins of the 3.5 are better than the faster clock of the 3.6).
Audio In: .wav from sdcard - SanDisk 16GB Ultra UHS-I - 98MB/s, C10, U1, Full HD, A1
Audio Files: wav format, less than 45 seconds in length.
Audio Out: DAC0 and DAC1 - each DAC is connected to a kiosk handset, one handset per audio clip. Need audio to play on handset when sensor is triggered. I fully expect the need to play both audio files off the SDcards at the same time.
Handset(speaker): 2 x Stop&Listen Gorilla Audio Handset https://www.stoplisten.com/gorilla-handset/
Sensor: 2 x Miniature Reflective Infrared Optical Sensor - https://www.adafruit.com/product/3930 These will point at the handsets and alert the program when one is in use(or at least not on the hanger :D )
RTC: using embedded RTC to get a relatively close sync with multiple setups(making 12 of these setups) to create animations based on time.
LEDs: SK6812 series LEDs using the FastLED version of OctoWS2811 library - 5 strips (two strips of 321 LEDs, three strips of 192 LEDs). I will use a SN74HCT245N Level Shifter to convert signal from 3.3v to 5v.

So what do you all think? Should I be good to go? Should I switch from the SD card to RAM memory chips? How about using the Teensy 3.5 vs 3.6? Thanks so much for taking the time to read. Cheers!
 
If you have the need of the fastest solution, I suggest to use APA102 LEDs instead of WS2812 or similar. Because of the odd signal protocol which is mostly implemented as a bitbanging function, this will use or block a lot of device performance. So the APA102 are controlled via SPI, this is standard, works fine and on most SoC this is supported by the hardware without blocking anything. Just my thoughts ...
 
This should be pretty do-able. The place to expect trouble is keeping the analog audio signals clean with so much rapidly switching power to all those LEDs. You're going to heed small amplifier chips, because the DAC pins can't directly drive a 32 ohm headphone. Strongly suggest you get dedicated not-grounded (floating) power adaptors for those amps. Also recommend having the audio ground isolators on-hand. Hopefully you won't need them if the amps are powered by dedicated clean power.

While APA102 has a faster protocol, WS2812 types usually work better for integrating with audio, because of the non-blocking libraries. You *really* want non-blocking LED output, so it doesn't tend to glitch or disrupt the audio processing. As far as I know, there is currently no non-blocking lib available for APA102.

Either Teensy 3.5 or 3.6 should be able to do this project. Since you don't need the 5V tolerance, might as well get the extra speed in 3.6.
 
While APA102 has a faster protocol, WS2812 types usually work better for integrating with audio, because of the non-blocking libraries. You *really* want non-blocking LED output, so it doesn't tend to glitch or disrupt the audio processing. As far as I know, there is currently no non-blocking lib available for APA102.
It could be that I missed some information here.... since I am currently on the road professionally in the context of ESP32 and Mongoose OS (the omnipresent IoT topic...), it is exactly the opposite in this world: APA102 is non-blocking (hardware SPI), WS2812 blocked (GPIO bitbanging). I'm sorry if I caused some confusion here... :confused: :cool:
 
I’ve had pretty good success running APA102s (FastLED library) along with PJRC Audio Library -- including a fair amount of FFT number crunching. But, I’ve only gone up to about 120 or so LEDs. I recall a post written by Paul describing that while the APA102 documentation leads you to believe that they do digital signal regeneration at every step, there’s actually degeneration (especially to the clock) as you go down the chain. So, that needs to be taken into consideration as the number of LEDs grows.

For WS2812, both regular FastLED and NeoPixel libraries disabled interrupts to maintain protocol timing. That can interfere with the Audio library. PJRC has a DMA-based library that maintains the timing without disabling interrupts. The cost (nothing is free) is extra memory usage. I think FastLED may now have an option for this too. Disclaimer -- I’ve never used either of the DMA-based libraries.
 
So, that needs to be taken into consideration as the number of LEDs grows.
Indeed, that's why you have to add some additional "recreational" clock cylces at the end of the transmission, depending on the count of the LEDs, if not, some data will stay unhandled. I added this into my SPI transmission length calculation (wrote my own library) - and I'm driving a 660 LED matrix without any loss (generally speaking, be aware, as I told already, in this specific project I use an ESP32 with Mongoose-OS - but there is the same problem with interrupt disabling which blocks nearly the whole system ...). Perhaps I can get some inspiration from Paul's DMA-based lib ... but ok, I'm way off the theme of the TOP, so I'll end my little APA102 excursion here, if WS2812 works fine along with the audio lib, than there's no need to switch.
 
Thanks everyone for your replies. Fms1961 and gfvalvo, APA102 was my first consideration and was in my cart. But then I stumbled on Paul's post regarding clock degradation over long strips and I decided to pivot to parallel output using WS2812b strips. I am actually making 6 of these columns, so I needed to really make the correct choice first before ordering. No room for error in budget or time, the best kind of projects :p .

Paul, would using the Audio Adaptor Boards be good for amplifying the DAC signals? I will grab some of the audio ground isolators from the PJRC store as well.
 
But then I stumbled on Paul's post regarding clock degradation over long strips and I decided to pivot to parallel output using WS2812b strips.
I tried to reproduce the measurements Paul published here - and I can't reproduce his results. However, under slightly different circumstances: since my ESP32 system cannot clock SPI at 24MHz without problems, so I go from 1 to 8 MHz and the problems do not occur. I think that 24MHz is too fast for the APA102 (the Newstar datasheet shows the maximum clock rate at 15MHz). So it is clear that clocking at 24MHz is no longer valid because it is not specified. This is not an APA102 problem, if you try to use them out of specs. So if some of them work at 24MHz, you're lucky, but it's not guaranteed. And of course, if such a device is overclocked, data degradation occurs, that's obvious. Aside from that in the communities the advice is circulating to use the APA107 - a new version of the APA102 that would be better and cheaper. So the statement, that the APA102 shows data degradation per se is - well, from my point of view - a myth. As I already mentioned: I control APA102 stripes of up to 660 LEDs with any problems, and 2MHz are enough, even for some animations.
 
Last edited:
At the time I did those tests, there were no clear specs for APA102, and FastLED was using a default of 24 MHz.

Daniel changed the FastLED default to only 12 MHz. Since then, the regular complaints about APA102 not working on long strips mostly ended. The few remaining cases could have been all sorts of other signal quality issues.
 
Yeah, the lack of clear documentation. So the new defaults are making sense. Thanks for the clarification!
 
Thanks for the replies regarding the stability of APA102 addressable LEDs not degrading signal over longer runs. I do have a few questions in other areas:

Short Question: Can I use the following combination - teensy 3.6 > teensy 3.6 sdcard > audio adaptor (i2s headphone jack) > octo2811 adaptor?
If I can use this setup, my rush PCB design can get a lot easier. I am racing the clock due hiccups in the design phase and now the tech team is scrambling, I am sure most of you have been here before :/

Paul, I tested the audio I will be using with the handset plugged into the teensy audio adaptor and powered it from a power supply running 1200 LEDs and the audio sounded fine enough(audio is supposed to sound like a telephone call). I looked at the ground isolating pass throughs you have in the store and they appear to be for audio input, not output.

Thanks again for the comments and advice, really hoping I can pull this off :D
 
Status
Not open for further replies.
Back
Top