Hi @GodmanchesterGoblin ,
Update files can be applied manually by using the /recovery.html tool on a Pixelblaze, or if that is missing it can be uploaded via the /update built-in page.
The recovery tool is nicer because you can see your update progress even for manual files. For the /update page you just have to wait a few minutes without knowing whats going on.
Risks
There may be bugs in this version, probably relatively minor ones, but they might cause some patterns or features to not work.
You can revert to the released version by using the built-in firmware update tool on the settings tab, or by using the â/recovery.htmlâ tool.
It is unlikely to completely brick your PB.
The most common issue happens if there is a problem updating the main web app file, usually when the system is low on storage. 500-600K seems like a safe bet. Less than 300k seems to frequently cause issues. If this happens, the recovery tool can still be used to attempt to repair or revert to the release version.
There is a different update file for each kind of PB v3. One for Standard with the pb32 in itâs name, and one for the Pico with pico32 in the name. Uploading the wrong file wonât cause anything bad to happen, it just wonât update.
@wizard - thatâs really helpful info. Many thanks for taking the time to explain. I shall certainly give this a go. I have a standard PB v3 wired up to a test panel that I can use for this (350 LEDs mapped in 35 rows to look like a 2D Christmas tree).
I am now testing this with a wearable LED board running off of a 3.7V battery (https://twitter.com/GeekMomProjects/status/1498158499527680002) and I LOVE it!!! Iâve just started looking at both changing the clock rate and also WiFi off mode, so I donât have quantitative results yet, but qualitatively, just running animations at 160 MHz vs 240 MHz has made the board run MUCH cooler without noticeable reduction in animation quality. Fairly high heat output from the PixelBlaze Pico was a significant problem for me with the Pico & wearables, and I think this will solve it. Turning off WiFi takes the current down another 90 mA or so (judging by eye - will do more quantitative testing later) and takes the temperature of the board down from âwarm but wearableâ (at 160 Hz) to unnoticeable.
Also - just tried the 80MHz mode with WiFi, and (qualitatively) the framerate has dropped to about 70 FPS from close to double that, and while I can see a difference, I doubt that anyone else would . This board has only 61 pixels, so I donât know whether it would be more obvious in a larger, more complex LED array, but it works great for my purposes, and, more importantly, doesnât run too hot to wear.
Thank you for implementing this. Will be getting myself some more Pico boards ASAP!
Mostly, âyeah, no problemsâ. Frame rates are unchanged, for all practical purposes, I really love the new power management features.
The preview in the editor though, is not working for any of the matrix and cube configurations Iâve tried. The colors seem to be correct, but the pixels are displayed out of order. Output to LEDs is fine. Did I maybe miss something in the configuration?
There can be a bit of weirdness if the pixel map size doesnât match the pixel count. If you regenerate the pixel map (add a whitespace or something) does it fix?
You might also see gaps if the pixel count is over 1000. Thereâs a setting in the global for fill gaps that can help, but it picks a neighbor pixel based on index, might not look good for all maps.
If that doesnât fix it, can you post a screenshot / video?
Thanks, @wizard!
I played with this a bit more last night and it looks like itâs due to an upgrade that didnât quite succeed, possibly due to low memory. (This PB3 was at 317k available when I upgraded.)
I restored it to its pre-upgrade state with esptool, erased a bunch of patterns and did the upgrade again. Now everything works fine.
My only remaining issue is that LED output frame rates are running at 80-90% of what they were in v3.20. Turning the previews off doesnât make a significant difference. Probably just debug code, so no real worries. The new UI is really beautiful. And useful too!
Works well for me so far, the speed options are cool for wearables
And yes Iâve noticed a small drop in reported speed too, serpinski rainbow down from 147 fps to 112. My eyes couldnât tell the difference though even after bumping the speed to medium and I was getting 98fps
New version, this is a release candidate, and will go live in a day or so unless folks see bad things! Not too much changed over last version, but a few nice quality of live improvements.
The pixel mapper has a setting to maintain aspect ratio:
Fill - If necessary, the map will be stretched or squished to fit every dimension.
Contain - The map keeps its aspect ratio, but is resized to fit the largest dimension.
Changes to config write two copies and only overwrite the second file if the first is successful. This should prevent any kind of wifi/power issues from losing your working config. A revision counter keeps track of modifications so that it loads the newest valid config if they donât match.
Added a small cross in the center of the preview so you can tell where the center is.
Mapped pixels beyond the configured number of pixels show as gray.
Backup + restore moved to main settings tab, reboots after a restore to load config.
Added docs for new controls
Given the limited space in V3 and the huge preview size increase for 1K pixel previews, it now downscales the saved previews to 100 pixels wide (same as previous versions), and try to compress them to 5KB.
Fixed sliders on safari (was black on black)
Hidden stuff for the curious:
previewSettings.globalCompositeOperation can be changed. Handy if you have many very tightly packed pixels.
Working well here! Upgrades went smoothly and performance is very good. What Iâm seeing is that it is roughly the same as v3.20 on patterns that use frame buffers, and appreciably faster on patterns that donât. (Matrix Green Waterfall is up from 78fps to 90!)
The FPS differences are interesting⌠Nothing on the rendering side changed. I wonder if things are subtly shifting flash locations and causing more instruction cache hits/misses depending on where they get linked.
Interesting. That sounds possible. Is this reproducible for you?
I tested again on couple of Pixelblazes hooked to 256 pixel WS2812 displays, with different pattern lists. The performance change is consistent.
The patterns that show the most difference for me are things like Matrix Green Waterfall and Spinwheel 2D. Both of these patterns have relatively uncomplicated code in render2D(), and spend most of their rendering time just calling math functions in the vm.
Can you ID those (any other patterns I mean) for me? I have a set of performance unit tests that I run, but it does a small single thing at a time. Might be some combination of diverse code that snags. I can add snippets of the patterns to the unit tests, get a baseline, and monitor for the future.
Iâll look at âMatrix Green Waterfallâ and âSpinwheelâ
@wizard, jsut to be sure weâre on the same page those two patterns are actually about 10fps faster on the new firmware than on v3.20!
One other small thing: Preview quality is slightly better on Chrome than on Firefox. I wouldnât advocate messing with it right now - just something to play with in the future when you have time.
Hereâs a terrible picture, many reflections. Left to right are (1) Firefox 90.0.1, (2) Pixel Teleporter, (3) Chrome 99.0.4844.74. You can see Firefox looking a bit odd. (And Pixel Teleporter is here to show how good these previews actually are â I wrote PT to help with development, and and for most purposes, Iâll now be using the web previews for development instead!)
The dotScale2D is the size of the circle it will draw, this is scaled down based on the number of pixels and the aspect ratio.
The dotMidStep2D setting defines the midpoint for the gradient, the first element is the position/radius, the second is the alpha, going from solid to the midpoint setting to transparent.
Youâre right - a little playing with previewSettings fixes it. I suspect itâs caused by weird stuff unique to my setup. Iâm running on a high DPI monitor with a custom (large-ish) UI scale factor. (This is how I dodge needing reading glasses to program!)
Firefox probably ignored a piece of scaling information somewhere. Or thereâs a browser setting I donât know about. Here in the Land of Flawless Browser Compatibility, itâs not that surprising.
Iâm pretty sure I actually can get PTâs geometry and shaders running in WebGL. I was planning to, because I want to do a P5.js port. When I do, if you like how it looks and runs, youâre welcome to it! In any case your 3D previews look miles better than the current Pixel Teleporter build. IMO, this firmware update is a real triumph on a lot of fronts!
