Hello everyone, are you going to continue here?
I would be sad if not.
The arrangement of the panels was start at the top and end at the bottom. I don't know more, but I would go along with every decision.
@"Stephen Moraco" Is there an update planned soon?
My biggest problem then is the power supply with Lipos and getting this into the cube.
@AndreasS said:
Hello everyone, are you going to continue here?
I would be sad if not.
The arrangement of the panels was start at the top and end at the bottom. I don't know more, but I would go along with every decision.
@"Stephen Moraco" Is there an update planned soon?
Yes, we are continuing... but other projects have been taking my time which you have seen on our zoom calls. (IoT Gateway, updates to our VSCode syntax highlighting, and now our BLDC Motoro drivers.)
Upcoming work on this front:
working on new matrix driver using ¼ of the RAM and having better color rendering (default 4-bit all the way to 8-bit color, the trade-off for better color is lower more PWM frames per video frame, hence a lower video frame rate at more bits of color.)
finishing the driver for the MPU9DOF click module
The arrangement of the panels was start at the top and end at the bottom
I think the start and end panel rotation is affected by cable length and this rotation affects the loader... which is why I was asking to fix this to one or two wiring shapes. Each shape requires different loading order and/or rotation for the images for each, well top and bottom, panel. This is why I'm asking what shape is anyone who's wiring up an actual cube coming up with?
I'm using a linear (unwrapped cube) set of panels for my testing. So I haven't had the "fun" yet of trying to figure out how to get the panels to fit on top and bottom with the least amount of cable. Shorter cables work best and I've purchased a couple of longer cables which seem to not work at all. So there seems to be some length sensitivity to deal with.
Progress for our Cube! I've released a new driver version.
With this new version we get ~300 kB RAM freed up for our cube application use.
We also achieve the following frame rates:
110 FPS at 4-bit color (12bit RGB)
236 FPS at 3-bit color (9bit RGB)
Yes, this is painting all sides of the cube at once!
For v1.0.0 of RGB LED Matrix Driver the changes are:
**Compile-time Selectable color support, 1/4 RAM usage
Converted to new PWM generation mechanism allowing compile-time selection of desired display color depth of 3-bit to 8-bit/color (9 to 24bit RGB)
Now uses ~25% of RAM required by the previous version for the same 4-bit color depth.
Latest timing and memory usage info has been posted.
See the project ChangeLog at github-repo for more details.
I just wanted to provide an update here. I do want to continue with this project, but my hobby time has been extremely limited lately. I'm still hoping to get back on track with work/life and help finish this. In the mean time, I'll do what I can to keep it unblocked if others are pushing forward on it.
Comments
Hello everyone, are you going to continue here?
I would be sad if not.
The arrangement of the panels was start at the top and end at the bottom. I don't know more, but I would go along with every decision.
@"Stephen Moraco" Is there an update planned soon?
My biggest problem then is the power supply with Lipos and getting this into the cube.
Best regards Andreas
Yes, we are continuing... but other projects have been taking my time which you have seen on our zoom calls. (IoT Gateway, updates to our VSCode syntax highlighting, and now our BLDC Motoro drivers.)
Upcoming work on this front:
working on new matrix driver using ¼ of the RAM and having better color rendering (default 4-bit all the way to 8-bit color, the trade-off for better color is lower more PWM frames per video frame, hence a lower video frame rate at more bits of color.)
finishing the driver for the MPU9DOF click module
I think the start and end panel rotation is affected by cable length and this rotation affects the loader... which is why I was asking to fix this to one or two wiring shapes. Each shape requires different loading order and/or rotation for the images for each, well top and bottom, panel. This is why I'm asking what shape is anyone who's wiring up an actual cube coming up with?
I'm using a linear (unwrapped cube) set of panels for my testing. So I haven't had the "fun" yet of trying to figure out how to get the panels to fit on top and bottom with the least amount of cable. Shorter cables work best and I've purchased a couple of longer cables which seem to not work at all. So there seems to be some length sensitivity to deal with.
@"Stephen Moraco" I did a quick and dirty calculation. With 145 DMX universes, we could have a refresh of 14Hz on all 6 sides of the cube.
@ke4pjw good to know! Sounds like this would be a good interface to have! So, It's on my list.
NEWS
Progress for our Cube! I've released a new driver version.
With this new version we get ~300 kB RAM freed up for our cube application use.
We also achieve the following frame rates:
Yes, this is painting all sides of the cube at once!
For v1.0.0 of RGB LED Matrix Driver the changes are:
See the project ChangeLog at github-repo for more details.
The latest driver timings and video frame rates we can achieve are at Driver configuration by chip type - S/W Ver 1.x Timings
@AndreasS - we made some progress! ;-)
Thank you, will test it tomorrow
I just wanted to provide an update here. I do want to continue with this project, but my hobby time has been extremely limited lately. I'm still hoping to get back on track with work/life and help finish this. In the mean time, I'll do what I can to keep it unblocked if others are pushing forward on it.