That’s in open air, circulation, and no sensor board. I’d be wary inside that closed mask of it climbing higher. Especially lithium in face range.
Can you move the battery to the other section?
Might help the weight balance too?
the other section where the other battery is? sure, but I’m not convinced that would help…
I need a temp gun. I gave up on all white and am just running rainbow patterns. Even with the diffusion covers on after an hour or so the battery is warm to the touch, and the PixelBlaze is hotter than I’d want to touch for long, but the foam tape insulator seems to be holding.
Ah, didn’t realize you had two batteries in it.
I had been meaning to get to frequency scaling settings and a mode where wifi was on demand only. That would really drop power use and heat. That and sync multiple pbs for costumes. Haha. Guess I know what’s in 3.20!
1 Like
Will “syncing multiple PBs” include expansion board sensor data? If so, that will save me a lot of work over the winter; I was planning to port parts of Firestorm to ESP32 and add synchronization of pattern variables so I can extend sound-reactive patterns across multiple portable PBs.
Also on the wishlist: How about a “render1D(index, x)” function that respects the map? All the various store-bought matrices are laid out differently (in my collection the 8x8s wrap around, the 16x16s are a vertical serpentine, and the 8x32s are a horizontal serpentine, and panels built from multiple modules add another level of complexity) so the 1D patterns don’t render the same way unless I add:
matrixWidth = sqrt(pixelCount); // different for rectangles, obviously
matrixHeight = pixelCount / matrixWidth;
export function render2D(index, x, y) {
row = floor(x*matrixHeight);
col = floor(y*matrixWidth);
offset = row * matrixWidth + col;
render1D(index, offset/pixelCount);
}
export function render1D(index, x) {
render(floor(x*pixelCount));
}
I realize that just changing the value of index in render2D before calling render(index) would accomplish the same thing, but I think it’s clearer to explicitly declare the dimensionality of the renderer. IIRC, the original render(index) function predates the mapper function; it could eventually disappear in v4 since all the existing patterns would still work the same with their render(index) function renamed to render1D(index, x).
1 Like
Yes! to the above…
I’ve also noticed that the PB (up to 3.19b) fails to handle when the map is 3D but only a render2D exists. Does nothing, with error of no render function. Adding a shim is easy enough:
export function render3D(index,x,y,z){
render2D(index,x,y)
}
But that’s annoying to add, when it should be smart enough to try that anyway (ie fall backwards if needed to a lower dimension of render if we have more data than expected)
…and while I’m asking for things, could we have case-insensitive sorting of the pattern list?
1 Like