16x16x16 Possibility?

[kvmuse]

Hi!

I was wondering if you would ever code something similar for the larger 16x16x16 cube- or if there's a way to adjust this 8x8x8 to operate with the 16x16x16?

I've made some adjustments to the code myself with the 16x16x16 cube but its scrambled and a bit of a mess.

I hope this is the right place to ask this... If not I am sorry!

[Sliicy]

Hi there! This sounds like an awesome idea! I don't have a lot of free time lately, but I tried to design the C# classes to be independent of the size of the cube. I believe we would need to update both the firmware code and C# code for this to work.
When I have the time, I can look into the code, but I won't be able to test without a 16x16x16 cube. Otherwise feel free to submit a Pull Request if you can also test that it works.

[kvmuse]

Thank you for getting back!! I have a 16x16x16 cube; happy to test it on my end. :) On Wed, Apr 10, 2024 at 8:34 AM Sliicy ***@***.***> wrote: Hi there! This sounds like an awesome idea! I don't have a lot of free time

…

lately, but I tried to design the C# classes to be independent of the size of the cube. I believe we would need to update both the firmware code and C# code for this to work. When I have the time, I can look into the code, but I won't be able to test without a 16x16x16 cube. Otherwise feel free to submit a Pull Request if you can also test that it works. — Reply to this email directly, view it on GitHub <#5 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BHKHUIZXKNH656JKA5I2LGTY4VLZLAVCNFSM6AAAAABF3Z3BT6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBXHA3TIMBTGY> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[Sliicy]

Hey @kvmuse, I just pushed commit 6604d5a to the main branch. It should theoretically support custom cube sizes, but the firmware will need to be modified as well to support receiving larger sizes (https://github.com/Sliicy/8x8x8-LED/blob/master/Firmware/RGB/8x8x8_RGB_LED_iCubeSmart/8x8x8_RGB_LED_iCubeSmart.ino). I'm also concerned that we might not have enough bandwidth over USB serial to have so much data being updated at once (we might need to send them in chunks, kind of how I added the functionality for color blending). I did not create a release yet since this is in beta.

Realistically, I'm not sure I can mess around with the firmware without having a cube handy to test with. There may be more chips/multiplexers on your board than my code is aware of, and a schematic would be very helpful of the board.

[Sliicy]

Closing this as I haven't heard from @kvmuse any updates.

[kvmuse]

Hello! Sorry for the delayed response; had a family matter to tend to. Schematic wise: https://drive.google.com/file/d/1eVVJzDvNRT6HEUTgv75-o2CGbikz15w0 iCubeSmart provided most information in the google drive link. Starting to tinker with the firmware on my end! Do you think there's a possibility of displaying any camera or kinect data in these cubes?

…

On Sun, Apr 14, 2024 at 1:48 PM Sliicy ***@***.***> wrote: Hey @kvmuse <https://github.com/kvmuse>, I just pushed commit 6604d5a <6604d5a> to the main branch. It should theoretically support custom cube sizes, but the firmware will need to be modified as well to support receiving larger sizes ( https://github.com/Sliicy/8x8x8-LED/blob/master/Firmware/RGB/8x8x8_RGB_LED_iCubeSmart/8x8x8_RGB_LED_iCubeSmart.ino). I'm also concerned that we might not have enough bandwidth over USB serial to have so much data being updated at once (we might need to send them in chunks, kind of how I added the functionality for color blending). I did not create a release yet since this is in beta. Realistically, I'm not sure I can mess around with the firmware without having a cube handy to test with. There may be more chips/multiplexers on your board than my code is aware of, and a schematic would be very helpful of the board. — Reply to this email directly, view it on GitHub <#5 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BHKHUI363MNOOENNSKXXPLTY5LTSNAVCNFSM6AAAAABF3Z3BT6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANJUGE4DAMZUHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- *Katria Phothong-McKinnon | คัทรียา โพธิ์ทอง * freelancer *|* interdisciplinary artist *|* dancer *|* email: ***@***.*** | socials: @kvmuse <https://www.instagram.com/kvmuse/>

[Sliicy]

@kvmuse good to hear back! I'm not sure I understand the question - can you describe your camera or kinect idea?

[Tariomka]

Hello @Sliicy,

I recently purchased a newer version of the same 8x8x8 cube. I tried out your code and I couldn't make it work on my cube. I started writing my own program and managed to figure out some stuff why your code wasn't working, the findings should be equivalent to the 16x16x16 cube if you're going to implement the bigger cube functionality.

1. The demultiplexer configuration is a bit different on the newer 8x8x8 board and the 16x16x16 board - In your arduino code I see you've programmed pins PB0, PB1, PB10 and PB11 for 74HC138 demux, while the newer boards use 74HC154 with the address input A0-A3 pins set to PB0, PB1, PB10, PB11( for my 8x8x8 cube this pin is always set to low) and Input Enable pin PA8 (this was the issue for me - if this pin is not set to low, the pin has about 1.4v on it and the demultiplexer doesn't do anything)

2. If I understand correctly your comment (line 142) "// G G B B R R...", the older boards have staggered color control, meaning every third shift register controls the same color. The shift registers on the newer boards are configured differently - on my cube the first 4 registers (first 8 bytes) control the color Green on all 8 lines, next 4 registers control color blue and the last 4 - red, so instead of being staggered, they are all sequential. I don't have the bigger cube to test it, but I would presume that the layout is the same, just scaled 2 times.

I haven't played around with the USB serial data transfer, but it seems like if the baud rate would be doubled, the entire cube state data for a single color depth should be easily passable without chunking data.

Hope this information will be useful for you

[Sliicy]

Hi @Tariomka, thank you for your findings!
Do you have any recommendations on merging this into the project so that others can build for a 16x16x16 cube? Should we split the .ino files into 2, or is there a way we can incorporate it both into that single file?
Thank you,

[Tariomka]

TL;DR version - I would suggest just to have 2 separate .ino files for ease of use and maintainability.
I can make a PR with the code for the newer board, I'll test it on my cube, but as I don't have the 16x16x16 cube, it would be a good idea for someone who has the bigger cube to test it as well.

Long version:
C++ has compiler directives so it's definitely possible to shove everything under one file. The problem here is that making a "#define SOME_FLAG" and shoving the differing code into "#if SOME_FLAG == some_value ... #else ... #endif" blocks is bad for code readability, maintainability and the users would manually need to change the flag depending of which cube they have. I wouldn't recommend using this approach unless there is only a few lines of code of difference and documentation explicitly states what the user needs to do to make it work for their hardware, or better yet - if the user doesn't even need to fiddle with the code at all.

[Tariomka]

Oh boy, I actually didn't take into consideration one thing - all of the configured light programs in the desktop application have been configured accounting for the staggered shift register configuration.

While I made the corrections for the initial cube state, which actually looks nice:

All of the programs from the desktop app don't show up correctly, example - Sent Red Color packet from my computer (only the outer 2 rows match up):

As the serial data is sent in 32bit ints, there needs to be some byte manipulation added when setting up the cube state after reading incoming data.