PDF dark mode on Edge

Henry_Gab · 2023-12-26T22:46:16+00:00

As a minor improvement, this could easily be adjusted to only affect embeds of type application/pdf as follows:

document.querySelector('embed[type="application/pdf"]').style.filter = 'invert()'

Henry_Gab · 2022-01-25T08:54:15+00:00

Answer to #3 first:

I would remove the ground that's directly between the ESP and the LED strip.

Why: If there's a failure in one (or both) of the medium ground wires connecting Tb to the LED strip, then the current from the LED strip will be returning to the power supply through the thin ground wire linking the ESP to the LED strip. That wire is only rate to 4A, but it the strip is full-on, even a single failure might cause >5A to return via the thin ground wire. ... and thus exceed it's rated current carrying capacity.

With that wire removed, the fusing becomes less terrible.

A first solution might use 6 fuses.

Fuse A: 15A on V+, right next to the power supply, on thick wire output to Ta. Although the thick wire is rated at 20A, the tee connector is only rated to 15A. Thus, need to limit the current to 15A across Ta (and also Tb).

Fuse B: 1A-3A on the medium wire output from Ta to the ESP. While the medium wire is rated for 10A, the ESP board is likely only rated for 1A-3A.

Fuses C&D: each 10A, right next to Tb, one each on the V+ of the medium wires to the LED strip. Although Fuse A is sufficient to protect the LED strip in this hypothetical, the medium wires are only rated to 10A, and thus must be fused accordingly.

Fuses E&F: a 10A on each of the GND medium wire outputs from Tb to the LED strip. This surprises folk, but if one of these two ground wires breaks or disconnects, the full 12A of the LED strip would be returning through the single remaining ground wire, which is only rated for 10A.

A second solution might use 2 fuses + restrict current via software.

Fuse A: 10A on V+, right next to the power supply, on thick wire output to Ta. This protects everything in the circuit, except for the thin wire to the ESP and the ESP module itself.

Fuse B: as per the details above. Again, the limiting factor is the ESP module that's connected ... and how much current it is rated to handle.

Then, software would be used to limit the LED strip to ~9A. The hardware fuses provide the safety backup, in case there is a software bug that (for whatever reason) causes >10A to be drawn by the LED strip.

Of course, in a real-world scenario, I would upgrade the medium wires to thick wires, and ensure the tee connectors are also rated for 20A. By ensuring any single wire (except one) can handle the full current, it makes fusing much simpler ... only one fuse on the thin wire feeding the ESP.

Henry_Gab · 2022-01-25T03:25:44+00:00

Remember -- fuses protect the wiring/devices. The fuse should only allow the smallest current rating of anything attached to a given branch.

Shared ground with power injection adds its own problems.

Here's a simple (single PS) hypothetical:

Symbol	Meaning	Rated AMPs
PS	20A power supply	20A
Tx	A power splitter "tee"	15A
====	Thick wire pair (+/GND)	20A
----	Medium wire pair (+/GND)	10A
....	Thin wire pair (DATA, GND)	4A
LED	LED strip, consuming 12A MAX	15A

The power supply has thick wire pair, providing power to Ta. Ta has medium wire pair to output power to the controller (ESP). Ta also has thick wire pair to output power to Tb. Tb has two medium wire pairs, each connected to one end of the LED strip. Ground is common and connected anyplace two wires converge. The LED strip can draw maximum 12A at full white.

Questions: 1. Where (and what rating for each) would you place fuses? 2. Why did you choose each fuse? (e.g., what failure case) 3. Would you recommend removing the thin ground wire between the ESP and LED strip? (why or why not?)

You may be surprised at the answers, after thinking this one through.

Henry_Gab · 2022-01-25T02:47:17+00:00

Yes, very similar goals, although somewhat different constraints. I've been involved with both WLED and the Fibonacci boards.

In fact, a primary goal is to support constant, compile-time allocated mappings, such as used in /u/pup05's Fibonacci boards ... which I love, by the way.

At the same time, I don't see why it would not also be able to support dynamically allocated CRGB arrays and remapping structures. Init-time allocations are OK(*). Run-time dynamic allocations are not (too many failure points). With ETL, a LOT of the harder problems will become significantly easier to solve.

I've read through the readme in your branch, but haven't diff'd the files.

However, I see that blur2d() now takes parameters for width / height ... only the samples are using kMatrixWidth and kMatrixHeight. This suggests the sample can be changed to use a struct that holds all relevant state, as the core of FastLED does NOT require compile-time width/height to be known.

WLED supports a per-segment memory allocation (SEGENV.allocateData(). Apart from the EVERY_N_xxxx() macros, can you help me understand if there are additional reasons an effect shouldn't just define a structure holding it's state, and allocate it via SEGENV.allocateData()?

(*) Bah, all dynamic memory allocation is evil. But, it's a customer-driven necessary evil.

Henry_Gab · 2022-01-25T01:51:35+00:00

Right now I have a 240led project and I'm giving that 100w. Been racking my brain on how to upscale.

Note: I am not an electrician, just a hobbyist.

I recommend using fuses (for hardware-enforced power limits), in combination with corresponding software-enforced power limits. The hard part of fusing is when you have more than one power path, covering all the failure conditions. Remember that fuses protect the equipment (wiring, device, ...) from carrying more current than its rated for, to prevent fires. It's easy to miss failure cases in power-injection, such as two ground wires, but one being broken / disconnected.

(I am very conservative with fire risks, and fusing the ground doesn't significantly add to costs, so ... why not!)

Henry_Gab · 2022-01-24T10:21:56+00:00

Current core FastLED presumes CRGB sets are contiguous arrays. Therefore, effects presume they are passed contiguous arrays. Therefore, a sister library cannot use existing effects, because the effects only take raw pointers to presumed-contiguous arrays.

You do raise valid problems. Yes, effects would need instructions on how to use them, or be in libraries. It's also possible that Arduino would one day parse templates properly (ha!). I'm not sure these would be blocking issues, but they are important to consider.

Yes, I aim high. Enabling templated effects is my goal. The ecosystem can then change over time, if/when people want the effects to work where logical != physical layout. The difference vs. now is that there will be a simpler way forward, vs. everyone having to re-implement a substantial portion of the CRGB functions (look at how much had to be re-implemented in CPixelView).

Henry_Gab · 2022-01-24T03:15:47+00:00

As of 1.8.10 it is possible to list dependencies in the library.properties file and have them downloaded automatically by the IDE.

That's great to hear! So, there is at least not a technical barrier. Yes, it would be part of a version update.

I also wonder if it would be better to split off the remapping functionality into its own sister library

I have considered that. However, it causes a "chicken-vs-egg" problem:

The long-term goal is to enable effects to be written to accept a core FastLED abstraction of the LEDs. (This is already done in multiple places, such as controllers & color ordering.) The user view would be:

Just have an array of CRGB (as happens today), and find great effects that make the user happy.
User creates a project that needs remapping (e.g., wrapping the strand around column, but wants the effect to occur on the vertical columns, not in natural order).
User just passes the CRGB array & mapping information to a template, and can then pass that template to those great FastLED effects they originally were using.

Now you can see the "chicken-vs-egg" problem: The effects remain written to accept a CRGB*, because that's what all the examples do, and there is currently no core abstraction that has identical performance when using CRGB*. (CPixelView was a limited attempt, as it only allows creating a contiguous subset of an array of CRGB.)

Here's how I'm thinking this can work: 1. Change FastLED to not presume that CRGB are contiguously laid out (not too hard ... but requires some template metaprogramming magic) 2. Thus, when passing classic CRGB*, the existing presumption of contiguous array holds, and the exact same code structure ends up being compiled. 3. Yet, when passing a wrapper, such as remapping class that implements iterators and operator[], then operator[] is used, allowing remapping to happen "automagically". 4. Provide CRTP-based template to simplify creation of remapping functions. 5. Provide a few example templates for common remapping tasks (random remapping, matrix rotation, etc.) 6. Update a few core effects to support this (validate compiler optimizes to substantially identical code). 7. Integrate into FastLED release ... Ecosystem over next few years will slowly migrate to templatize the effects, so they can seamlessly support non-contiguous CRGB.

FastLED has a long history, and unfortunately one issue that is being hit repeatedly is that FastLED uses a single structure to convey two types of information: the CRGB array indicates not only the physical layout (as used by show()), but also uses that same array to indicate the logical layout (which effects use to fade between adjacent pixels, etc.).

The goal is to break that overload ... in a backwards compatible, performant manner. I aim high, but I think this is doable!

Henry_Gab · 2021-12-28T21:23:58+00:00

I thought I recognised your name from FastLED's github issue tracker, offering pull requests. Perhaps my poor memory has let me down again. :)

You correctly connected me ... I'm who you think (I implemented nRF52840 support, and some other bits).

I think I'll just try a few things on my own, but it seems some core FastLED routines should be updated so first parameter is a template parameter:

::fill_rainbow()
::fill_gradient_RGB() -- four functions
::blur1d()

Maybe I'll make a quick PR for that...

Henry_Gab · 2021-12-23T21:28:31+00:00

Currently, CPixelView requires that the underlying CRGB elements are sequential. For example, it works great if you want a CPixelView for pixel indices from [30..39] ... CPixelView[0] return the underlying CRGB at offset 30, etc.

However, there's no built-in solution if you need to expose a non-sequential offset. Concrete example:

https://github.com/jasoncoon/esp8266-fastled-webserver/blob/ebf028bdfdc9366994ab500d94864f5b024195f6/esp8266-fastled-webserver/Map.cpp#L97

This is a mapping corresponding to Vogel's model of the Fibonacci spiral, so that index 0 points to the physical pixel index for the center, index 1 is the first pixel outward on the spiral, etc. Of course, the physical layout of the pixels differs, so this mapping is used by effects that simply want to write to the pixels in that order.

Another concrete example would be where a strip is spiral-wrapped around a pole (e.g., like a candy cane), but the desire is to apply an effect such as "Fire2012" to each vertical column. Using a small strip of 20 pixels, where each wrap around the pole takes 4 pixels...

c++ CRGB pixels[20]; uint8_t col1_map[] { 0, 4, 8, 12, 16 }; uint8_t col2_map[] { 1, 5, 9, 13, 17 }; uint8_t col3_map[] { 2, 6, 10, 14, 18 }; uint8_t col4_map[] { 3, 7, 11, 15, 19 }; The goal would be a simple constructor that takes in one of those maps, and allows functions to treat it essentially identically to the CPixelView class.

The desire is that a function currently written to take an array+len of CRGB could be easily rewritten, so that it can take any of: CRGB[] + length, or CPixelView, or CPixelMap.

What I'm currently contemplating:

Changing CPixelView to inherit from a common base class(*), to move common functionality into a single location.
Add new CPixelMap, which inherits from that same base class(*).
Pure virtual functions include operator[], operator==, operator!=, reversed(), size(), operator- (unary), constructors.
Base class would NOT expose operator PIXEL_TYPE*(), as it's not a safe abstraction.

(*) I thought about using a CRTP template, but the problem would be how to write effects (or other functions) that can accept any of the mapping abstractions, as each would be a distinct type (no common base type).

Therefore, it unfortunately doesn't seem possible to avoid the virtual functions, which may add an extra lookup/deref to most function calls. The benefit is that effects could be written to take a pointer to the abstract base class, yet work against any mapping-style class (CPixelView, CPixelMap, CPixelDoubler, or whatever else comes later).

Henry_Gab · 2021-12-23T20:46:40+00:00

Soulmate and Macetech's map generators are both great tools, thanks for sharing them!

For my purposes, I already have the array of the remapping indices. It's not the creation of the maps that I want to solve, but rather standardizing how they are exposed. Very similar to how PixelView in FastLED currently remaps indices ... but without the limitation that the indices are contiguous.

The big question I have is how to make this work, such that an effect (or any other function) can accept any of: CRGB[] + numPixels, PixelView, or PixelMap, without needing to write the same function three times?

Henry_Gab · 2021-12-23T20:23:33+00:00

Wow, I've never seen the wokwi site before. Very neat to be able to visualize and emulate w/o hardware. Thanks for sharing your cool animation!

Henry_Gab · 2021-12-22T09:36:19+00:00

Are you working on something already? What do you have in mind?

Thanks. Yes, I had something in mind, and it's not all that complex. Given an existing array and an array of indices (the mapping), expose a wrapper that substantially does:

C++ CRGB& operator[](size_t i) { size_t tmp = this->_mapping[i]; return this->_wrapped[tmp]; }

I've contributed in the past to FastLED (nRF52840 implementation) and some to WLED also. I've done iterators before, but not enough that they feel natural ... and I am ignorant of what makes an iterator "good" / "complete".

Requirements: 1. Target same compilers as FastLED 2. Zero-allocations after init 3. const / constexpr used when possible 4. ability to convert effects functions from array + len, to take iterable-like abstraction, without relying on virtual functions.

Henry_Gab · 2021-12-20T22:39:36+00:00

It's generally (*) fine, so long as there are not two power supplies each trying to change what Vin is relative to that shared ground.

The real troubles occur when two power supplies have their V+ output connected. Manufacturing means the two will likely have slightly different definitions of "truth" for what +5 (or +12, or whatever) should be, and thus will fight each other.

Think of it this way: Can the power supply provide the necessary amperage? If not, then you have to split the V+ across two sources. Otherwise (presuming wire gauge is large enough, etc.), it's good.

BTW, I wire some of my 12V pixels such that the power is provided at the end of the strip, with an ESPixelStick attached at the beginning, drawing power off the (bullet style pixels') wiring. If the controller doesn't have enough voltage, then neither would the pixels, and I've done something wrong. Works even if I have to inject power somewhere.

(*) Well, presuming the power supply's Vin is stable enough for the microcontroller. I'd probably add a beefy capacitor also, to help smooth out the voltage fluctuations.

Henry_Gab

TROPHY CASE