Hi guys, I’m working on a new portal for Colorado burning man this year with more LEDs and switching to APA102s from the WS2012s I used last year. I used the output expander last year but this time due to the APA102s I have to go with a zig zag string because of the distance I’d have to run a wire back over to the other end and prefer not to do that. It’s a 8 by 150 pixel matrix basically since I’m using eight 5 meter strings of 30/m LEDs wired in a zig zag.
I’ve searched this forum and read documentation but it’s nit helping me.
The problem I’m running into is the pixel mapper is not working for a matrix with zig zag. I comment out the line for zig zag in the mapper and save and no difference. Leave the line in and it does not compensate for zig zag wiring. No change at all. The width is set to 150 pixels and it should work but I’m missing something or not understanding how the mapper works.
Is there a way to get the zig zag code to work correctly or if I’m missing something let me know. I don’t want to have to run 10 foot wires from the end of one loop to the beginning of the next. With the zig zag wiring it’s a 2 foot wire vs 10 ft.
Your pixel count in Settings is set to 1200 (8 * 150)
You didn’t modify the rest of the example matrix map other than setting the width and commenting out or uncommenting the zig-zag line.
Don’t forget to hit save when you’re done, even though the preview image adapts live.
For example, when I configure the example matrix map with 150 width (I’m using “constrain” mode), I have:
Map code, zig-zag line uncommented
function (pixelCount) {
width = 150
var map = []
for (i = 0; i < pixelCount; i++) {
y = Math.floor(i / width)
x = i % width
x = y % 2 == 1 ? width - 1 - x : x //zigzag
map.push([x, y])
}
return map
}
And this preview:
Compare this to when the zig-zag line is commented out:
Map code, zig-zag line disabled
function (pixelCount) {
width = 150
var map = []
for (i = 0; i < pixelCount; i++) {
y = Math.floor(i / width)
x = i % width
// x = y % 2 == 1 ? width - 1 - x : x //zigzag
map.push([x, y])
}
return map
}
If you’ve made other modifications to the map generator, there are some ways you can accidentally disable the zig-zag line from being able to work. Let’s say, for example, you’re using the “constrain” mode for maps but you also want to stretch out your vertical spacing. If I do that in a simple y = y * 6 way at the wrong point in the code, notice that the zig-zag line gets ignored now (because of how the math in the map generator works).
Map code, zig-zag line uncommented, stretched vertically
function (pixelCount) {
width = 150
var map = []
for (i = 0; i < pixelCount; i++) {
// NOTICE THE NEW "* 6" AT THE END OF THIS LINE
y = Math.floor(i / width) * 6
x = i % width
x = y % 2 == 1 ? width - 1 - x : x //zigzag
map.push([x, y])
}
return map
}
Notice the pulse no longer zig-zags (I know it’s harder to see in this preview - you’re looking to track the single brighter pulse)
If you think you might be having an issue like this, post your map code and we can take a look!
I’ve done what you mentioned and saved each time. No change on the led strings whether zig zag line is commented out or not. I’ve tried with both a v2 and a v3 pixelblaze. Here is the code:
function (pixelCount) {
width = 150
var map = []
for (i = 0; i < pixelCount; i++) {
y = Math.floor(i / width)
x = i % width
x = y % 2 == 1 ? width - 1 - x : x //zigzag
map.push([x, y])
}
return map
}
Is this code being run by the browser to generate the map? I’m using chrome on an iPad so maybe that’s the issue if so? I’ve tried Firefox and safari but no difference.
Hmm, this map code is successfully zig-zagging for me. I’m guessing it’s zig-zagging for you as well in the map preview (the one tat always renders a rainbow).
I just want to be sure you’re running 2D patterns when you conclude it isn’t mapping correctly, right? 1D patterns will not be affected by the mapper. You can tell what mode it’s rendering in for each pattern here:
Try this - run this pattern, and please take a short video of your pattern preview animation under out conditions (with the zig-zag line commented out, and with it in there):
var thickness = 0.125
var o = 1 + 2 * thickness
export function beforeRender(delta) {
t = 2 * (o * time(6 / 65.536) - thickness)
}
export function render2D(index, x, y) {
rgb(near(x, t), near(y, t - o), 0)
}
function near(a, b) {
v = clamp(1 - abs(a - b) / thickness, 0, 1)
return v * v
}
Hey Jeff, that’s it! My brain was working from other devices I’ve used where a map wasn’t used but code was embedded that compensated for the zig zag and my head was in that space. I was running index walk (since it worked with the output expander and ws2812s but for the APA102s in one long string in zig zag wiring it doesn’t. I ran fast pulse 2D and your code and it’s working! I’ll just need to be sure I only run 2D patterns with it.
I’ll have video of it at the event in a few months and post it on here.
I just needed to be steered in the right direction and understand that pixelblaze uses a map and not calculated with each sweep for zig zag setups.
Thank you for getting me on the right track, I appreciate the help! Now to get this thing built and ready to go in June.
Here’s a trick that might be helpful for your 1D patterns to make them all flow in the same direction: You can reverse the index ordering for every other segment of 150 pixels.
Paste this into any 1D pattern right after export function render(index) {:
if (floor(index / 150) % 2 == 1) {
index += 149 - index % 150
}
Thank you so much for getting me on the right track….in the past, before pixelblaze, I was driving led displays with a Teensy 3.2 and that is similar to the code I used for the zig zag wiring to compensate and my brain was just still in that space. Again I appreciate the help. I’ll post videos of the installation in June.
