OLA RPI - SPI with APA102 Digital LEDs

[Stefan Krüger]

Hello List,

has someone tried to use the relative new 'APA102' Digital-LEDs with the OLA-SPI Plugin on an RaspberryPi?
the APA102 have a two wire interface: Clock and Data - so they are not so timing critical to control.
According to the adafruit-dotstar learning guide this should also work directly with python and the right sub lib..
adafruit is selling these LEDs in Strip form and as bare chips:
and there is a crazy tight packed version with 144LEDs/m.
(for germany: Exp-Tech is selling these as distributor)
you can find the Datasheet of the LED at adafruit: APA102 LED Datasheet

some time ago i tested the ola RPI image with some WS2801 and it worked fine.

my goal is to have a relative long chain - so about 600Pixel - i haven't made the calculations mentioned in the OLA Pixel Tutorial jet.
would it make more sense to use an usb2pixel adapter (i can build one i think - based on the RGB-Mixer project) to get a faster update rate?

iam looking forward to some input from you guys :-)

sunny greetings
stefan

[Peter Stuge]

Stefan Krüger wrote:
> APA102

https://cpldcpu.wordpress.com/2014/08/27/apa102/ writes "Due to the
critical timing requirement it is not possible to control the WS2812
from SOCs with multitasking operating systems, such as the
Raspberry Pi." which I believe that my simple software demonstrates
is plain wrong.

The SPI hardware on the RPi and on any other SoC running Linux can
drive WS2812B without any problems.

> adafruit is selling these LEDs in Strip form and as bare chips:
> and there is a crazy tight packed version with 144LEDs/m

You can also buy 144/m strips of WS2812B from German sellers:

http://www.ebay.de/itm/371132446360

And 60/m:

http://www.ebay.de/itm/351300164098

I expect that you can buy full 5m rolls of either if you contact them.

> my goal is to have a relative long chain - so about 600Pixel - i
> haven't made the calculations mentioned in the OLA Pixel Tutorial

> <https://www.openlighting.org/ola/tutorials/ola-led-pixels/> jet.

> would it make more sense to use an usb2pixel adapter (i can build one i
> think - based on the RGB-Mixer project) to get a faster update rate?
>
> iam looking forward to some input from you guys :-)

Transmitting data for one WS2812B takes 30µs, plus >=50µs reset.

600 LEDs mean 600*30 + 50 = 18050µs = 18.05ms = 55.4 updates/s.


The APA102 datasheet does not state what the maximum input clock for
the controller is, which I find quite worrying, and enough of a
reason for me to avoid ever buying the product.

The closest I can find is "refresh rate 400 cycle" which suggests
that one LED can handle at most 400 updates per second, meaning that
transmitting data for one APA102 may take up to 2.5ms.

Then there is an example using FCKI = 512kHz on the next page.

APA102 requires 32 bits data per LED plus 32 bits start frame and
a >=32 bit end frame, whose length depends on how many LEDs are chained.

Transmitting 32 bits at 512kHz takes 62.5µs; just over twice as long
as 24 bits at 800kHz to WS2812B.

For 600 LEDs that's a 32 bit start frame, 32*600 bits of data and a
300 bit end frame. (I'll cheat and round the end frame up to 320 bits.)

62.5 + 600*62.5 + 625 = 38187.5µs or 38.2ms = 26.1 updates/s.


https://cpldcpu.wordpress.com/2014/11/30/understanding-the-apa102-superled/
writes in the summary

"I have no recommendation for a maximum or minimum SPI clock speed.
There is no specification for this in the datasheet. So far, it seems
that the LED is able to handle any clock setting that is thrown at
it. I had no issues with 4 MHz and others have successfully tested 10
MHz and above."

..which suggests that APA102 in practice can work much faster than
512kHz. But do you want to accept the risk on that when the
manufacturer doesn't specify this in their documentation? I would not!


//Peter

[Peter Newman]

Hi Stefan, given it has an external clock, it should be possible within the existing SPI plugin. Do you want to have a go yourself or open a feature request on the OLA issue tracker?
https://github.com/OpenLightingProject/ola/issues

[Stefan Krüger]

@ Peter Stuge
thanks for the detailed calculations -
you are right - the datasheet is no real datasheet - it is missing about every interesting detail...

thanks for the links to the detailed analyses on these blog.. i did not found this till now..
with some more searching i found printed a APA101 on the picture of the chip in the http://www.neon-world.com/pdf/led.pdf 'datasheet'
so i thought - hey eventually in the APA101 datasheet are some more infos - but - not really....
http://www.neon-world.com/pdf/apa-rgb%20color%20led%20contorer%28se%29.pdf
the only timing information (other than the 512kHz) around are from people that try different SPI clock speeds... i have read in the comments about 35MHz...

@ Peter Newman
i will try to get it to work and let you know. (will take some days to get to it..)


thanks you both for your help!

sunny greetings
stefan

[Antoine Villeret]

Hi there, 

is there any news on APA102 support in SPI plugin since February ?

I'll need it for a project and would like to know all effort that have been done to walk on some steps.

cheers

Antoine

[Peter Newman]

I've not done anything, and not seen a PR from Stefan, feel free to have a go yourself, it shouldn't be too hard. If you search on here, Simon has posted some pointers in the past for someone who asked something similar.

[Stefan Krüger]

Hi Antoine,

i think i can look into this in about a week...
its the next point on my sparetime todolist ;-)

sunny greetings
stefan

[Stefan Krüger]

Hello List,

i have tried to start this evening to add the APA102..

but first i wanted to check if my hw setup is working with an WS2801 string.
i got some stones in the way - and have now tried to descripe what i have done.
so eventually that helps others...

i started with following OLA on Raspberry Pi tutorial with the GIT Repo Image.
i started olad -l 3
all worked fine - up to the point i tried to add a spi output. there was no SPI Output in the list..
the startup log told me
..
olad/PluginManager.cpp:104: Trying to start SPI
olad/PluginManager.cpp:108: Started SPI
...
in the web-view there was no spi output device shown...
(i thought that if it is started it would show up in the webview list......)

so i got back to reading the OLA LED Pixels Guide
in the 'Software' section there was this nice link to the 'SPI Plugin configuration'
and i checked the two point there (comment blacklist and udev rule)
the blacklist was already done. i think i had to do the udev rule.
after i rebooted (i use the 'shutdown -r now' command) i started olad -
and there was no spi output in the web ui..
so i jumped on the irc and Sean told me to check the SPI Plugin configuration options..
i had done this - but to be sure i have checked all things again
 i reread the pixel guide-
and in the section 'OLA SPI Plugin' i triped over the part 'Each SPI interface (/dev/spi*) is represented as an OLA Device.'
so i checked if there are some spi* devices in /dev/
and there was no spi devices...
quick search found: 'How to enable spi on the Raspberry Pi'
and there it told me to additional add
'dtparam=spi=on' to '/boot/config.txt'
(i think this option is also available in the 'graphical' config menu)

after an reboot now all works fine:

olad/PluginManager.cpp:104: Trying to start SPI
plugins/spi/SPIWriter.cpp:58: Created SPI Writer /dev/spidev0.1 with speed 1000000, CE is 0
plugins/spi/SPIDevice.cpp:97: spidev0.1, Software backend, 1 ports
common/thread/Thread.cpp:190: Thread , policy SCHED_OTHER, priority 0
olad/DeviceManager.cpp:105: Installed device: SPI Device:15-spidev0.1
plugins/spi/SPIWriter.cpp:58: Created SPI Writer /dev/spidev0.0 with speed 100000, CE is 0
plugins/spi/SPIDevice.cpp:97: spidev0.0, Software backend, 1 ports
common/thread/Thread.cpp:190: Thread , policy SCHED_OTHER, priority 0
olad/DeviceManager.cpp:105: Installed device: SPI Device:15-spidev0.0
olad/PluginManager.cpp:108: Started SPI

so would be good to add this new info to the SPI Plugin config wiki.
additional - i would like it if the SPI Plugin prints an info that no spi device was found...
so you know that there is something wrong in the system config..

additional to the textual description in the Hardware section of the Pixel Guide i have 'missed' a quick link to the elinux RPi header overview.
that would make it easier to have a 'visual reference' and some additional explanations about the pinout..

so now my WS2801 are working ;-)
(iam using the Bi-Directional Level Shifter - TXB0104 from Adafruit on a breadboard for testing)

tomorrow i will try to get the APA102 working..
its the first time i do something with compiling code on linux..
(and my windows borland delphi time was long long ago)

sunny greetings
stefan

[Peter Newman]

Thanks Stefan. I've updated the SPI section of the device specific config docs, hopefully that covers it:
https://wiki.openlighting.org/index.php/OLA_Device_Specific_Configuration#SPI

[Antoine Villeret]

Thanks for the work, 

I'll give it a try asap (maybe next week) and i'll keep you aware of any trouble

rainy sunday greetings

antoine

[Stefan Krüger]

Hey :-)

i have nice news - APA102 is now working (in my fork)
for some details / pictures see https://github.com/OpenLightingProject/ola/pull/722#issuecomment-99557853

if someone has a nicer test setup (i had only 5leds laying around) pleas test it.
for me it worked :-)

in the code i have tried to comment everything that i have added so that it is easy to understand..

if you have questions just ask ;-)

sunny greetings
stefan

[Zeph Smith]

A few updates to the info here on the APA102, which is becoming the favorite chipset of the FastLED folks (using Arduinos and Teensy's), and of Adafruit.

They have operated it at up to 24Mbps SPI clock, so it's much faster than the example calculations used in this thread (it does take 32.5 bit times per pixel vs 24, though, but at up to 30x the clock rate of the 2811 family this is a small disadvantage).

It has by far the fastest PWM rate of any pixel chips - around 20 KHz (vs 400 Hz for the 2811 family).  So updated values can be displayed with very short latency, eg for POV applications.

The "400 Hz" spec is about a stupid extra feature that nobody uses (in addition to the very fast 8 bit PWM on each the 3 RGB channels, there is a second layer of 5 bit slow PWM overlaid on all 3 channels; nobody can figure out why anybody would use this, so it's just ignored.  The only guess I have is that they were trying to compete with the 5 bit current control of the 1829 pixels, which is analog control of pixel current in mA, a very different thing).

So I'm very interested, but I want to use a Pi rather than arduinos.  Before I buy a bunch of apa102's, however, I would like to understand the reported Open Lighting spi timing.

On page https://www.openlighting.org/ola/tutorials/ola-led-pixels/ there are some very slow timings for 2801 pixels.

At 1 MHz spi clocking, each byte takes a minimum of 8 uSec,  so 75 bytes would take at least 600 uSec; while there is typically some overhead which reduces real world rates, this still makes the reported 11,100 us dramatically slow.  Is that really accurate?  Why would OLA be so slow, and is there any fix?  There's not much advantage to faster SPI pixels if the software radically reduces the effective rate anyway.

@stefan, how fast are your apa102's running?

(by the way, in the Timing section the second example says 32 WS2801's require 75 bytes of SPI; I suspect it should be changed to 25 pixels or 96 bytes)

[Arjan van Vught]

Alternatively you can run the SPI code on RPi baremetal. It will remove the overhead of Linux and gives a very fast accurate SPI update.

I have a framework here https://github.com/vanvught/rpidmx512/blob/master/rpi_rdm_responder/lib/dmx_handle_data.c.

With a DMX output refresh rate of 40 packets per second and with 512 slots per package, this (empty) routine is called approximately 43000 per second.

- Arjan

Op woensdag 13 mei 2015 19:07:46 UTC+2 schreef Zeph Smith:

[Simon Newton]

It's not OLA, it's the write to the SPI device through the kernel. It
may be faster (or slower!) on the Pi2 or with a newer kernel.

https://www.raspberrypi.org/forums/viewtopic.php?t=19489 has some details.

Simon

>There's not much advantage to faster SPI pixels if the
> software radically reduces the effective rate anyway.
>
> @stefan, how fast are your apa102's running?
>
> (by the way, in the Timing section the second example says 32 WS2801's
> require 75 bytes of SPI; I suspect it should be changed to 25 pixels or 96
> bytes)
>

> --
> The Open Lighting Project: open-l...@googlegroups.com, #openlighting
> (irc.freenode.org)
> To unsubscribe from this group, send email to
> open-lightin...@googlegroups.com
> For more options, visit https://groups.google.com/groups/opt_out?hl=en

[Jason Kyle]

-----Original Message-----
From: open-l...@googlegroups.com [mailto:open-l...@googlegroups.com] On Behalf Of Simon Newton
Sent: Sunday, 17 May 2015 7:14 a.m.
To: open-lighting
Subject: Re: [open-lighting] Re: OLA RPI - SPI with APA102 Digital LEDs

On Wed, May 13, 2015 at 8:24 AM, Zeph Smith <zha...@gmail.com> wrote:
> A few updates to the info here on the APA102, which is becoming the
> favorite chipset of the FastLED folks (using Arduinos and Teensy's), and of Adafruit.
>
> They have operated it at up to 24Mbps SPI clock, so it's much faster
> than the example calculations used in this thread

I'd be a little cautious radiating 24Mbps from some improperly terminated impedance mismatched dangling wires. I imagine it would only work reliably over a fairly short distance from controller to first LED module. Perhaps careful consideration should be given to what clock rate is actually required in a real application? Unless your goal is to run 1000's of APA102 modules in 1 chain there really isn't much justification for such high clock rates.

[Stefan Krüger]

Hi @all

i had tested the APA102 at different speeds (125kHz, 1MHz, 10MHz - see https://github.com/OpenLightingProject/ola/pull/722#issuecomment-99557853)
but that was just a single shot trigger..
in about a week or two i can make some more tests with some more leds (1,5m / 90Leds)
i have tested today with some fast changing dmx values and as fare as i can tell (25leds)  it was fine -
but the tests are not representative.. (i have not written down the results..)
so stay tuned for some more timing tests.

sunny greetings
stefan

[Steve French]

Stefan,

Great work on the APA102 stuff!!  I am getting ready to test the APA102C on both the BBB and the rPiB and rPiB+ here in the next few days hopefully.  I have a few generic/simple questions/comments for you:

1) How do you change the APA102 SPI clock rate?  Is this just an OLA config file thing or do you actually dive into the SPI kernel driver?  (I am wondering how different this experience will be on BBB vs rPi).

2) I am surprised you were having good luck through a breadboard @ such high (10MHz) clock rates.  I wonder if this was limiting your high frequency results?

3) I have been noticing that most APA102C flex strip providers do not design-in decoupling capacitors on their strips.  I actually asked my Chinese factory about it and they responded "APA102C more stable, dont need".  I recently designed some APA102C panels (10x10array) and I was getting crazy flicker on the 2nd panel in the chain (FastLED/Teensy3.1)...as soon as I added 10uF bulk capacitance to the 2nd panel, the flicker immediately went away.  I am also working on a new installation using APA102C strips (310 total pixels) and I was having flicker problems that I was attributing to FastLED/Teensy3.1 clockrates, but today I have a pocketful of capacitors and I have a feeling they will improve the problem...

4) I was noticing on some of your oscilloscope captures that the lower frequency stuff was square waves, but the higher frequency stuff was turning into "Sharkfins"....most likely bandwidth limitations of your oscilloscope/probes.  I had a recent situation where I was testing Peter Stuge's special code for the WS2811 pixels, but it wasnt working and I kept getting sharkfins...I wasnt sure if it was a BBB pin-muxing problem or a bandwidth problem of my Picoscope2203 (Analog Bandwidth = 5MHz)....I was too embarrassed to share my results and I never got back to it.  What is the bandwidth of your scope?

5) I just got myself the new Saleae Logic Pro8!!  Let me know if I can use it to help you and the OLA pixel efforts in any way!!

Talk soon!

frenchy (Steve French)

www.voltvision.com

[Peter Stuge]

Steve French of Volt Vision wrote:
> 1) How do you change the APA102 SPI clock rate? Is this just an OLA config
> file thing or do you actually dive into the SPI kernel driver? (I am
> wondering how different this experience will be on BBB vs rPi).

This will be same on all Linux systems where the spidev kernel
interface is used. If it isn't already an OLA configuration item then
it will be.

> 3) I have been noticing that most APA102C flex strip providers do not
> design-in decoupling capacitors on their strips. I actually asked my
> Chinese factory about it and they responded "APA102C more stable, dont
> need". I recently designed some APA102C panels (10x10array) and I was
> getting crazy flicker on the 2nd panel in the chain
> (FastLED/Teensy3.1)...as soon as I added 10uF bulk capacitance to the 2nd
> panel, the flicker immediately went away.

Do you connect the power supply every 100 LEDs or so? So you have a
star network for power and ground? This greatly helps signal
integrity as well as voltage levels at high current draw.

> I had a recent situation where I was testing Peter Stuge's special
> code for the WS2811 pixels, but it wasnt working

Please note that I haven't tested that code myself and while I was
looking at it just yesterday I believe I found some bugs in it. I've
attached an updated version of the source code. Please try it out.

> and I kept getting sharkfins...I wasnt sure if it was a BBB
> pin-muxing problem

Please show me your dts file that you use to enable spidev.

> I was too embarrassed to share my results

Please stop wasting time and get in touch with me maybe on IRC in the
next couple of hours. I will not be around the rest of this week but
I have some time right now.


//Peter

[Peter Stuge]

Peter Stuge wrote:
> I've attached an updated version of the source code.

Let's try that again.


//Peter

[Steve French]

On Monday, June 1, 2015 at 1:13:35 PM UTC-4, Peter Stuge wrote:

Steve French of Volt Vision wrote:
> 1) How do you change the APA102 SPI clock rate?  Is this just an OLA config
> file thing or do you actually dive into the SPI kernel driver?  (I am
> wondering how different this experience will be on BBB vs rPi).

This will be same on all Linux systems where the spidev kernel
interface is used. If it isn't already an OLA configuration item then
it will be. 

So, how can I ask the spidev kernel what the current SPI clock is?  How do I know that it actually worked on the BBB?

 

> 3) I have been noticing that most APA102C flex strip providers do not
> design-in decoupling capacitors on their strips.  I actually asked my
> Chinese factory about it and they responded "APA102C more stable, dont
> need".  I recently designed some APA102C panels (10x10array) and I was
> getting crazy flicker on the 2nd panel in the chain
> (FastLED/Teensy3.1)...as soon as I added 10uF bulk capacitance to the 2nd
> panel, the flicker immediately went away.

Do you connect the power supply every 100 LEDs or so? So you have a
star network for power and ground? This greatly helps signal
integrity as well as voltage levels at high current draw.

 

Yes, but with no capacitors in the system at all (outside of the power supply), things are definitely less stable than they were with the WS2811.  At least the WS2811/WS2812 strips had distributed capacitance @ each pixel.

 

> I had a recent situation where I was testing Peter Stuge's special
> code for the WS2811 pixels, but it wasnt working

Please note that I haven't tested that code myself and while I was
looking at it just yesterday I believe I found some bugs in it. I've
attached an updated version of the source code. Please try it out.


> and I kept getting sharkfins...I wasnt sure if it was a BBB
> pin-muxing problem

Please show me your dts file that you use to enable spidev.

==========================

Not sure what you mean by dts file.  The last time I enabled the SPI and UART on the BBB I did this:

root@vBBB12-bassAmp:~# cat /sys/devices/bone_capemgr.*/slots

 0: 54:PF---

 1: 55:PF---

 2: 56:PF---

 3: 57:PF---

 4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G

 5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI

 6: ff:P-O-- Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN

Notice how the SPI and UART are not present above.

• sudo nano /boot/uboot/uEnv.txt

Add these lines...and save...and reboot...

optargs=capemgr.enable_partno=BB-SPIDEV0,BB-UART4

• sudo reboot
  

The reason I am choosing UART4 is because UART0 is used on boot for console.

…also I think SPI1 is conflicting with HDMI

Here they are!!

debian@vBBB12-bassAmp:~$ cat /sys/devices/bone_capemgr.*/slots

 0: 54:PF---

 1: 55:PF---

 2: 56:PF---

 3: 57:PF---

 4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G

 5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI

 6: ff:P-O-- Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN

 7: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-SPIDEV0

 8: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-UART4

I have been using the above method because "it sticks" after a reboot.

 

> I was too embarrassed to share my results

Please stop wasting time and get in touch with me maybe on IRC in the
next couple of hours. I will not be around the rest of this week but
I have some time right now.


//Peter

ok, I will take you up on this.  I just re-scheduled my customer appointment to be tomorrow instead.  I am heading back to my office now to work on this.  Thanks for the push.  You should see me appear in IRC in about 1hr from now.  Thx and talk soon!

[Stefan Krüger]

Hi Frenchy,

i commented inline..

sunny greetings
stefan

On Monday, June 1, 2015 at 7:09:54 PM UTC+2, Steve French wrote:

Stefan,

Great work on the APA102 stuff!!  I am getting ready to test the APA102C on both the BBB and the rPiB and rPiB+ here in the next few days hopefully.  I have a few generic/simple questions/comments for you:

1) How do you change the APA102 SPI clock rate?  Is this just an OLA config file thing or do you actually dive into the SPI kernel driver?  (I am wondering how different this experience will be on BBB vs rPi).

you can change the clock rate in the OLA config file:

nano ~/.ola/ola-spi.conf

the Pixel-Tutorial has some Example-Configurations in it:

base_uid = 7a70:00000100                                                                                                                                    
device_prefix = spidev
enabled = true
spidev0.0-0-dmx-address = 1
spidev0.0-0-pixel-count = 25
spidev0.0-0-personality = 7
spidev0.0-backend = software
spidev0.0-ports = 1
spidev0.0-spi-speed = 10000000

there you can change the pixel-count and the spi-speed -
when you set the spi-speed the driver uses the next lower available speed.
the personality is changeable with the RDM-Web interface (7 will be the APA102 Single mode = every Pixel is controllable)

2) I am surprised you were having good luck through a breadboard @ such high (10MHz) clock rates.  I wonder if this was limiting your high frequency results?

it worked with 'flying cable' and breadboard -  so in some ways thats definitive not the best base setup ;-) - but if this works a good setup will work too ;-)

3) I have been noticing that most APA102C flex strip providers do not design-in decoupling capacitors on their strips.  I actually asked my Chinese factory about it and they responded "APA102C more stable, dont need".  I recently designed some APA102C panels (10x10array) and I was getting crazy flicker on the 2nd panel in the chain (FastLED/Teensy3.1)...as soon as I added 10uF bulk capacitance to the 2nd panel, the flicker immediately went away.  I am also working on a new installation using APA102C strips (310 total pixels) and I was having flicker problems that I was attributing to FastLED/Teensy3.1 clockrates, but today I have a pocketful of capacitors and I have a feeling they will improve the problem...

in my last project i used the Dotstar (APA102) 144Leds/m strips from Adafruit - with a total of ~ 900 Pixel in on single data-line - power was hooked in every  50cm and longest continues (power wise) strip was ~1,5m. (as Power supply's i used 2x MeanWell RSP-150-5 and power distributed the 2x30A with car-style fuses so every segment had his own fuse; the strips needed a lot less power as i designed in) 
as controller i used a DMX4ALL MultiPixxController (i don't know what clock speed this thing is generating)
i had no problems with flickering - there were two custom segments (pcbs with the APA102C assembled by me) for this i also used one 10uF capacitors for about 4 Leds.
i only had some problems during assembling - i have no reflow so i tried with an hotair rework station - and the leds died away..
they had moisture under the silicon and if i solderd theme the water poped / cracked the silicon... :-(
about 10 out of 50 leds died this way..
in the end it was easyer to solder them with an iron than with hot air..
will think about getting a pizza-reflow-oven ;-)

4) I was noticing on some of your oscilloscope captures that the lower frequency stuff was square waves, but the higher frequency stuff was turning into "Sharkfins"....most likely bandwidth limitations of your oscilloscope/probes.  I had a recent situation where I was testing Peter Stuge's special code for the WS2811 pixels, but it wasnt working and I kept getting sharkfins...I wasnt sure if it was a BBB pin-muxing problem or a bandwidth problem of my Picoscope2203 (Analog Bandwidth = 5MHz)....I was too embarrassed to share my results and I never got back to it.  What is the bandwidth of your scope?

i have an old HAMEG HM407 - 40MHz Analog-/Digital-Oszilloskop - but it has a high-frequency-problem on channel1 - so i only have a nearly correct waveform picture on channel2. (and i have some 'Conrad' probes so not the best...)

[Antoine Villeret]

Hi,

I just started to play around with APA102, OLA and Rarspberry Pi

and I can't figure out how the first DMX channel is used.

When I change it, the LED blinks and I'm wondering why.

Also what about controlling the global brightness value of each LED with this first DMX channel ?

Global brightness is hardcoded to 0xFF for now.

What do you think ?

Cheers 

Antoine

[Zeph Smith]

On Wed, May 13, 2015 at 8:24 AM, Zeph Smith <zha...@gmail.com> wrote:
> A few updates to the info here on the APA102, which is becoming the
> favorite chipset of the FastLED folks (using Arduinos and Teensy's), and of Adafruit.
>
> They have operated it at up to 24Mbps SPI clock, so it's much faster
> than the example calculations used in this thread

I'd be a little cautious radiating 24Mbps from some improperly terminated impedance mismatched dangling wires. I imagine it would only work reliably over a fairly short distance from controller to first LED module. Perhaps careful consideration should be given to what clock rate is actually required in a real application? Unless your goal is to run 1000's of APA102 modules in 1 chain there really isn't much justification for such high clock rates.

Point well taken - I'm not suggesting that 24MBps become the new default rate for them, or that it's needed everywhere.  My point was that the APA102 chipset can handle much higher frequencies than had been described here, so it's not the limiting factor.  Any particular installation needs to scale that back depending on many other possible limiting factors.

And another of those limiting factors is whether you have a good electrical driver sending signal to the first pixel.  A 5v driver may help, especially if your first pixel is further away; various chips can be used for 3.3v to 5v buffering, like the 74HCT08 quad and gate (which could interface to 2 SPI strips, or 4 of the single wire chips like WS281x, and also provide an enable function to allow sharing the same SPI port).

[Zeph Smith]

On Monday, June 8, 2015 at 10:11:04 AM UTC-7, Zeph Smith wrote:

And another of those limiting factors is whether you have a good electrical driver sending signal to the first pixel.  A 5v driver may help, especially if your first pixel is further away; various chips can be used for 3.3v to 5v buffering, like the 74HCT08 quad and gate (which could interface to 2 SPI strips, or 4 of the single wire chips like WS281x, and also provide an enable function to allow sharing the same SPI port).

Oh, and if you don't want to wire in a buffer chip but it's too far from the uC to the LEDs, consider using one deteched pixel near the controller, to buffer the signal to the first visible pixel.  You just send a dummy first pixel value to skip past it.  This works for many pixel chipsets. 

[Stefan Krüger]

Hi Antoine,

i hardcoded the global brightness to 0xFF as this was the logical decision after reading Tim's Blog:
https://cpldcpu.wordpress.com/2014/08/27/apa102/
Tim mentions that he has found the global brightness uses a PWM frequency of 580Hz. And this is easily visible as flickering..
also he found that the separat color channel PWM frequency seems to be 19.2 kHz - so a better fit for smooth visual appearance.

so i decided that 8bit per color per pixel is enough and the global brightness makes it 'worse' for handling.
so you have three channels per pixel.
and other features should be done by the pixel manager/controlling software as virtual thing..

but to get some APA102 Packets to transmitt you have to change tree ore more channels - because otherwise there is not enough data to send a Packet..

sometimes i had flickering problems with high clockrates and my 'flying wire - breadboard test'
i will do some more tests and timing measurements next weekend.

sunny greetings
stefan

[Antoine Villeret]

Hi, 

I've also read Tim's blog :-)

580Hz is only visible when LED are moving very fast.

So this is not suitable for POV application.

But it is very useful to reduce the brightness.
I've build some flexible displays with APA102 and I'm using it at the lowest brightness for 3 reason : 

- power consumption 

- heat dissipation that make the plastic meld

- the very first step is much smoother at this brightness : the gap between off and the 1/255 brightness is very thin, which is why I choose those LED :-)

So I think global brightness control for each individual LED would be a great feature.

Moreover, I go ahead with my tests and unfortunately, this doesn't work with more than 18 LED.

I can drive 300 LED with my RPi with some Python code (https://github.com/tinue/APA102_Pi).

But I can't do the same with Ola.

Maybe my configuration is wrong  ? Here is my ola-spi.conf : 

base_uid = 7a70:00000100

device_prefix = spidev

enabled = true

spidev0.0-0-device-label = SPI Device - spidev0.0

spidev0.0-0-dmx-address = 1

spidev0.0-0-personality = 7

spidev0.0-0-pixel-count = 300

spidev0.0-backend = software

spidev0.0-ports = 1

spidev0.0-spi-ce-high = false

spidev0.0-spi-speed = 8000000

spidev0.0-sync-port = 0

spidev0.1-0-device-label = SPI Device - spidev0.1

spidev0.1-0-dmx-address = 1

spidev0.1-0-personality = 1

spidev0.1-0-pixel-count = 25

spidev0.1-backend = software

spidev0.1-ports = 1

spidev0.1-spi-ce-high = false

spidev0.1-spi-speed = 1000000

spidev0.1-sync-port = 0

I push up the speed as suggested here : 

https://github.com/tinue/APA102_Pi/blob/master/apa102.py#L54

But this doesn't help.

Any advice will be appreciated.

Thanks

Antoine

[Stefan Krüger]

Hi Antoine,


hm you are right at full global brightness the first step is more a jump...

for the global brightness thing we can make a additional personality - so its possible to configure this.
i will have a look at this but i don't know when.
one questions on this is how to map a dmx channel (8bit) to the 5bit global brightness...
if we just map 1=1 the higher 3bits of the 8bit channel are unused - but you have accurate control of the gb
otherwise we can map the 8bit (256 values) range to the 5bit (32 values) range.
that way if you have a fader on this channel it behaves 'more normal' / expected..
what would you prefer?

for your config:
check
https://www.openlighting.org/ola/tutorials/ola-led-pixels/#Two_Pixel_Strings_using_a_single_output
you are only allowed to have a maximum of 170 pixels per universe. -> you need a second universe.
and the input will overflow  above 255 --> so it will be set to some other value you don't expect.
if you open up the config after stopping ola you will see it has changed..
(i did the same thing and wondered what happened... ;-) )

sunny greetings
stefan

[Peter Newman]

We should probably really call the channel intensity; global brightness implies it works over more than one LED.

I think we should map the full 0-255 to the 32 bit range, i.e. just take the top five bits of the channel, precisely because as you say the fader will behave normally then. If someone really needs to set it to a specific value for some reason they can always do the maths.

The pixel limit isn't about 255 overflowing, 170*3 = 510, so you can't get the pixel data for all three channels for the next fixture to fit in the 512 channels in the universe. When you implement the intensity channel, you'll need to handle this case in the code too.

[Antoine Villeret]

hello,

AFAIK, I'm driving the first LED with channel 2-4, the second with channel 6-8 and so on.

Channels 1, 5 and n*4+1 should be set to 255.

So only 512/4 = 128 LED fit in a DMX universe.

As far as I understand, I can't have more than one DMX universe mapped on SPI output.

And so come 2 questions : 

- in my setup I have OSC input and SPI output : why should I be limited by a slow 30 years old protocol aka DMX ?

RPi SPI output could drive more than 300 LED on the same wire.

- why my LED become crazy as soon as I send more than 18*4 bytes on the SPI ? (moreover, the same setup works great with Pyhton, so I'm thinking something is wrong with my setup or with OLA itself)

To see that, I made a chaser : only one LED is on at each step so it's not a power supply failure or something like that. 

I increase the chaser length one by one. 

As soon as the chaser length reach 19 LED nothing work as excepted.

I understand I could overflow my universe, but this shouldn't be the case with only 19 * 4 = 76 channels.

Cheers

Antoine

--
do it yourself                      
http://antoine.villeret.free.fr

[Stefan Krüger]

Hi @all :-)

i have some news regarding APA102-
for long time on my list was to do  some timing measurements:
http://blog.s-light.eu/ola-spi-apa102/

pleas let me know if you questions...

@Simon - does it make sens to add some of the information to the Pixel-Guide?

sunny greetings
stefan

[Peter Newman]

You probably want channels 1, 5 etc to default to 255 Antoine, but others may want to use that as a custom level.

You can have more than one universe's worth of pixels on an SPI output, but you'll need to deal with configuring sync ports, see https://www.openlighting.org/ola/tutorials/ola-led-pixels/#Two_Pixel_Strings_using_a_single_output and the plugin's description.

Regarding the limits, OLA is based around lighting, primarily DMX and its Ethernet equivalents, so yes, it's limited to 512 channels per universe. As mentioned above, with the sync port, and particularly if you're just going OSC in (from one device) to SPI out, it shouldn't really have any limitations.

Can you send a link to the Python script that works, I wonder if it's to do with clocking bytes or something and either the OLA code isn't sending enough, or your LEDs need more and the Python code is being generous. Do you see the same effect if you drive the LEDs from the web console or ola_dmxconsole, rather than OSC that you're presumably using?

On Wednesday, 17 June 2015 11:48:14 UTC+1, Antoine Villeret wrote:

hello,

AFAIK, I'm driving the first LED with channel 2-4, the second with channel 6-8 and so on.

Channels 1, 5 and n*4+1 should be set to 255.

So only 512/4 = 128 LED fit in a DMX universe.

As far as I understand, I can't have more than one DMX universe mapped on SPI output.

And so come 2 questions : 

- in my setup I have OSC input and SPI output : why should I be limited by a slow 30 years old protocol aka DMX ?

RPi SPI output could drive more than 300 LED on the same wire.

- why my LED become crazy as soon as I send more than 18*4 bytes on the SPI ? (moreover, the same setup works great with Pyhton, so I'm thinking something is wrong with my setup or with OLA itself)

To see that, I made a chaser : only one LED is on at each step so it's not a power supply failure or something like that. 

I increase the chaser length one by one. 

As soon as the chaser length reach 19 LED nothing work as excepted.

I understand I could overflow my universe, but this shouldn't be the case with only 19 * 4 = 76 channels.

Cheers

Antoine

--
do it yourself                      
http://antoine.villeret.free.fr

To unsubscribe from this group, send email to open-lighting+unsubscribe@googlegroups.com

[Antoine Villeret]

Hi Peter, 

thanks for the hints

but unfortunately I give up with OLA and now I'm using a python script that does the same better.

It is easier to configure number of LED, to control global brightness per led etc...

So I will not work anymore with OLA I think.

Sorry

Antoine

--
do it yourself                      
http://antoine.villeret.free.fr

To unsubscribe from this group, send email to open-lightin...@googlegroups.com

For more options, visit https://groups.google.com/groups/opt_out?hl=en

--
The Open Lighting Project: open-l...@googlegroups.com, #openlighting (irc.freenode.org)

To unsubscribe from this group, send email to open-lightin...@googlegroups.com

[Peter Newman]

No worries Antoine. Given the Python script already existed, and you were going OSC to SPI, it was probably a better fit anyway as you've said, rather than being tied to a universe of only 512 channels.

Sorry, I hadn't appreciated what you'd written before and didn't realise we don't expose control of the global brightness per LED at all and instead fix it to full.

The crazy behaviour when using more than 18 pixels certainly sounds like a bug, and I'd still appreciate a link to the Python script if you don't mind, so we can compare it. Even better if you're willing to spend a little bit of time diagnosing/testing bug fixes for the issue, even if you're not planning to use it for your current project. Likewise for the global brightness control, it should be easy enough to add, but I don't have any of that type of pixel to hand to test it with if I added it. We can do a lot of mocking and tests without, but its always nice to prove it works in the real world before merging. So if you were able to spend a little bit of time testing that too it would be appreciated.

On Thursday, 27 August 2015 08:21:23 UTC+1, Antoine Villeret wrote:

Hi Peter, 

thanks for the hints

but unfortunately I give up with OLA and now I'm using a python script that does the same better.

It is easier to configure number of LED, to control global brightness per led etc...

So I will not work anymore with OLA I think.

Sorry

Antoine

--
do it yourself                      
http://antoine.villeret.free.fr

To unsubscribe from this group, send email to open-lighting+unsubscribe@googlegroups.com

For more options, visit https://groups.google.com/groups/opt_out?hl=en

--
The Open Lighting Project: open-l...@googlegroups.com, #openlighting (irc.freenode.org)

To unsubscribe from this group, send email to open-lighting+unsubscribe@googlegroups.com