LED Cube 2nd Attempt

[Adam Davies]

Afternoon everyone,

I posted on here a while back under 'Speeding up' ArtNet' about my LED cube. Everyone was super helpful but I fear like I backed myself into a corner slightly and was attempting to run before I could even walk. Having had a break I'm now coming back to it with fresh eyes and a tighter brief

Goal: To have an LED cube that responds to a Universe of ArtNet generated from a device elsewhere on the network

Setup: I have an 8x8x8 LED cube, each column has the positive leg joined together and each layer has the negative legs joined together to a transistor

Hardware: I have 5x MCP23S17 chips daisy chained together. The first 64 outputs are wired to the 64 columns, the next 8 to the layers, the final 8 are unused. These are connected to a Raspberry Pi 4

I want to try and create a Python file (I have 0 knowledge of C) that will receive ArtNet and if each channel is above a certain threshold, turn the LED on by cycling/multiplexing through each layer at 10ms intervals until a new ArtNet frame is received. Possibly using the RPiMCP23S17 library??

I know the documentation on the OLA client in the Python file is being updated but I'm still very confused as to how it runs (I come from an Entertainment Lighting background so used to have ArtNet just 'work'). Any help creating this python file much appreciated.

Currently in Quarantine for a week as I'm visiting Iceland for work so hoping to be reunited with the Pi and the cube towards the end of the month

Thanks for making it this far

Adam

TL;DR - trying again, help with the python file much appreciated

[Glenn Meader]

You could experiment with one of the Python libraries (see GitHub) available that simply receive ArtNet. Get that working so that you can print out/display channel values for the received universe. 

Maybe no need to use OLA? 

Next write a separate experimental Python program that lights your LEDs according to the values in a 512 element boolean array. 

On May 17, 2021, at 5:33 AM, Adam Davies <adam....@tsllighting.com> wrote:

Afternoon everyone,

--
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
---
You received this message because you are subscribed to the Google Groups "open-lighting" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-lightin...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-lighting/bd1c5696-4629-418b-926d-dbb40e7a881bn%40googlegroups.com.

[Peter Stuge]

Hi Adam,

Adam Davies wrote:
> I posted on here a while back under 'Speeding up' ArtNet' about my LED
> cube. Everyone was super helpful but I fear like I backed myself into a
> corner slightly and was attempting to run before I could even walk. Having
> had a break I'm now coming back to it with fresh eyes and a tighter brief
>
> Goal: To have an LED cube that responds to a Universe of ArtNet generated
> from a device elsewhere on the network
>
> Setup: I have an 8x8x8 LED cube, each column has the positive leg joined
> together and each layer has the negative legs joined together to a
> transistor

So far so good!

> Hardware: I have 5x MCP23S17 chips daisy chained together. The first 64
> outputs are wired to the 64 columns, the next 8 to the layers, the final 8
> are unused. These are connected to a Raspberry Pi 4

These output connections are good, but unfortunately it turned out
that MCP23S17 can't be daisy chained; the 5 chips have to be
connected in parallel and given different addresses. See the
attached schematic, which shows everything but the outputs, which you
already have connected correctly.

The addressing results in more overhead, but is unavoidable with the MCP23S17.

> I want to try and create a Python file (I have 0 knowledge of C) that will
> receive ArtNet and if each channel is above a certain threshold, turn the
> LED on by cycling/multiplexing through each layer at 10ms intervals until a
> new ArtNet frame is received. Possibly using the RPiMCP23S17 library??

Your number of LEDs approaches the practical limit for SPI performance
in a userspace program (such as Python code) without visible artifacts.

Any time operating near the limit it becomes essential to avoid every layer
(library, framework, interface) technically possible. This in turn requires
more time for research and development, substantially more if the base
system isn't already well-known. Optimization problems like that are
really horrible to face in any beginner project, but we'll help.

Hardware on the CPU board (Pi) must do as much of the SPI communication
as possible. Python code can achieve that by directly using the kernel's
ioctl API for SPI. A good helper file makes that easy.

> I know the documentation on the OLA client in the Python file is being
> updated but I'm still very confused as to how it runs (I come from an
> Entertainment Lighting background so used to have ArtNet just 'work').

With OLA you're kindof working inside the desk, so yes, it's different..

> Any help creating this python file much appreciated.

I've attached a script which should make the cube blink some LEDs
in one plane at a time if the SPI signals are connected as shown
in the schematic. See if it makes some sense.

If you like I'm happy to also send a version which receives values from OLA.


Best regards

//Peter

[Adam Davies]

Hi Peter,

Good to hear from you and hope you're keeping well!

Thanks for the comments, I had no idea that the chips couldn't be daisy chained so you've definitely saved me a fair few hours of head scratching and swearing!

Thanks for the file, it seems to mostly make sense to me. 

If you have time to build a file which receives OLA values and has uder defineable variables for the universe it listens to, and the 'threshold' (i.e. the 0-255 value a channel has to be higher than for an LED to turn on) I'd be most grateful. 

I suppose I'm trying to achieve 2 things, 1) to see if I can program something myself (thus, expect a very clunky Python file that barely works in the next few days haha) and 2) to check if the cube works. The Cube was a project I built at University that's sat in a cupboard for 6 years as I couldn't get the Arduino working at the time due to lack of knowledge and lack of time between assignments. Having a known, working file would allow me to achieve 1 of the goals!

Speak soon

Adam

--
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
---
You received this message because you are subscribed to the Google Groups "open-lighting" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-lightin...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/open-lighting/20210518044159.21655.qmail%40stuge.se.

--

Adam Davies Control & System Support t: +44(0)20 8629 2025 |w: www.tsllighting.com

This message contains confidential information and is intended only for the intended recipients. If you are not an intended recipient you should not disseminate, distribute or copy this e-mail. Please notify us immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Therefore we do not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version.

 

[Peter Stuge]

Hi Adam,

Adam Davies wrote:
> Good to hear from you and hope you're keeping well!

Thanks, you too - yes all good. I hope you'll enjoy Iceland once you
can move around. I haven't been but have heard wonderful things.

> Thanks for the file, it seems to mostly make sense to me.

Great!

> If you have time to build a file which receives OLA values and has uder
> defineable variables for the universe it listens to, and the 'threshold'
> (i.e. the 0-255 value a channel has to be higher than for an LED to turn
> on) I'd be most grateful.

All right, attached is a script with everything put together.

Note that it requires a spi.py helper file for calling the kernel,
the link to that is in a comment near the top.

I'm not sure that this script works since I can't test it, but any
problems should be minor, the big picture should be all right.

If it doesn't completely make sense or you have any questions please
ask away.

universe, threshold and output interval can be set at the top.

threshold is the minimum channel value to switch LEDs on. You should
be able to switch on all LEDs without the universe receiving anything
by setting threshold = 0, this is an interesting test to determine
whether performance is in fact sufficient for a pleasant visual.
I'm not super optimistic, I suspect there will be noticeable flicker.

It's good to do that test without any universe data coming it, because
processing universe updates also requires CPU time and if there's flicker
already without universe updates then the flicker will always be worse
once updates are added.


The 0x80 0x40 .. stuff deals with individual bits within byte values,
corresponding to individual GPIO pins within GPIO ports, and while
some may think that this should be abstracted more neatly this
software is short and simple enough, and the software is tied to the
particular hardware design strongly enough that I consider abstraction
to do more harm than good.


Channel mapping is implicit.

The first 64 channels map to the plane on MCP23S17 addr=4 GPA pin 7,
the next 64 to the plane on pin 6, and so on.

The channels within each plane map in order onto MCP23S17 addr=0 GPA pin 7
through 0, addr=0 GPB pin 7 through 0, addr=1 GPA pin 7 through 0, etc.

If this is a disaster for you then the ordering could be changed in
create_data() and NewData(), or a translation map added to the start
of NewData for all channels or for each plane.

> I suppose I'm trying to achieve 2 things

Good goals! Testing two unknowns at once is always dangerous, but
again, we'll help.

> Having a known, working file would allow me to achieve 1 of the goals!

Well, I'm curious whether my script is in fact working, heh. :)


//Peter

[Peter Newman]

Just because it may be relevant here, and I might even get round to merging it eventually, but there's also now a C++ based remap tool if you need to shuffle channel data within a universe (or universe) for things like this:

https://github.com/OpenLightingProject/ola/pull/1895