Simple UI mode is perfect
yeah it’s all wired as 1 long strip.
It sounds like this may be resolved by getting the panels made in WS2812-C
Given the heat concerns with the current model, I’m just going to delete the all white pattern or reduce the hsv(1,0,1) to hsv(1,0,0.2) or something so low it doesn’t get hot.
Can anyone recommend a good small inline fuse for this? I have some mini-blade 4Amp fuses, but the inline cases for those are a bit too bulky. With the PB standard, sensor board, lipo, and adafruit lipo charging backpack it’s getting a bit cramped inside the first can.
I didn’t realize @wizard’s lipo charger had a 4A protection. The adafruit backpack does not that I saw. The only thing I like about the adafruit backpack is the red led for charging and green led for done. I didn’t see that on the one you linked so how do you know when it’s done charging?
Also the 212ma charge rate is a bit low for my 2ah batteries, that would take 10 hours. the adafruit backpack does 500ma charging so 4 hours on my batteries. probably not a big deal, I assume most people just leave it charging overnight (I know never charge unattended, but it happens).
LilLiPo might be a bit too little for your 2AH batteries.
It doesn’t have a charging LED. For what I use em for its either a fast charge for really tiny batteries where the charge current is about 1C, so an hour or so, or for larger setups I tend to leave em overnight. The IC I used could do 500mA, but the PCB isn’t designed for the thermal ramifications and would likely go into thermal throttling. The adafruit board uses the same style linear charger and would have the same heat generation, but probably has more copper spreading it around so the IC can keep going. I bet it gets hot to touch even so!
It seems like a waste, but you could use both where LilLiPo is just for battery protection (short protection and under voltage) and you charge via the Adafruit board. Similar protection ICs can be found in small lipo packs (it depends, many dont, some do), but rarely integrated into 18650 style cylinder cells.
Also the HD108’s use less power when turned “off”. Supposed to be like 90% less… so if you are using patterns that have some off pixels that could also help reduce heat.
What if anything would anyone recommend for heat insulation between the PixelBlaze V3 (which to me gets a lot hotter than the V2 right?) and the lipo battery I’m using (in this case I switched from the 18650 cylinder to a flat lipo so I could fit the audio sensor).
I have some double sided gaffers foam tape (https://www.amazon.com/gp/product/B01LXJGLMC/), or some heat resistant double sided acrylic tape (https://www.amazon.com/gp/product/B0796Q7N4F/).
I was also considering buying a silicone mat and cutting up some squares, but my understanding is it’s only heat resistant in short term, then it eventually heats up and can actually continue to emit heat after power is turned off. maybe that’s true for all of these, idk. Any tips appreciated.
@Sunandmooncouture,
You are using a Standard, right? They do get a little warm, warmer than V2, but shouldn’t be getting hot in open air as the PCB and metal shield help spread the heat over a larger area.
The heat has to go somewhere, otherwise with perfect insulation and infinite power and time it would eventually turn into a small star. Rather than insulate it, which traps in heat, can you move the heat to a location that can breathe?
I’d get a cheap IR thermometer and take some readings. If you aren’t getting over 100F I wouldn’t worry about it as it won’t harm the lipo. If it is, I’d worry about why its getting that hot in the first place!
@JasonCoon so WS2812-C is perfect for now, but what would it take to make these panels in HDR chipsets? Do they even sell 4mm strips in HDR? I’m not even sure I can see the difference, need to build a side-by-side test harness. Maybe time to buy one of each of @wizard’s matrices for testing. or does anyone have a video of side by side comparison? Can you even tell the difference in videos or just in person?
Generally the advice around lipos seems to be to keep them under 115F. Higher temps can damage them - reduce battery life and can cause them to puff up. For skin contact, “painfully hot” generally starts around 111F.
For what it’s worth, I have 2 Standards on my desk at the moment and one measures 100F and the other 105F. The first feels just slightly over body temp, and the other feels slightly warm.
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.
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!
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).
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)
