Hardware Compatability Tracking Matrix on Git Home Page

[smilima]

I had a 6 hour drive today and spent some time thinking about this project.

There are many combinations of ESP-32 hardware, each with specific capabilities which makes it a difficult task moving toward a user friendly "plug-and-play" NightDriverStrip library. I believe this is important for many hobbyists. Some people could care less about DMA or how things work under the hood (or they are children). I think they just want their pool umbrella light up like fire, or display dynamic messages using LED matrices in their store/mancave/bedroom.

If Dave and the community agrees this is a good idea, I was thinking we should start documenting test results and tweaks needed for specific combination of LED strips, LED matrices and ESP-32 development boards we all have been using and display the results. I think we could possibly start a compatibility matrix on the Git repo landing page. We could have links to all of the parts which can be ordered using @davepl amazon links which would pull in more funds for Dave's autism charitable contributions.

My thoughts are we have a matrix of development boards vs. LED strips/matrices and in each intersection we annotate whether it is fully compliant, works partially with a few tweaks, not tested yet, or verified not working due to hardware limitations. This would be indicated in a legend, preferably color-coded with links to notes.

We all have a various assortment of hardware we purchased, and between us few, I think we could cover a majority of real-world testing and update the compatibility matrix after confirming results.

I was also thinking we could have a master/stable fork, a beta fork, and an alpha fork. I am having a hard time figuring out who has latest features I would like to read over and deploy to my hardware for testing and learning. I am not sure how to address this, but maybe links and instructions to our talented contributors would be helpful before Dave decides to commit changes into the master codebase.

What are your thoughts?

[prschguy1]

I would like to say your idea is very noble in intent. However I think the task of that would be a huge task in effort. There are people like me who have been working with the code for a year now and have not unlocked the secrets of it. While I am not a programmer, I am a mechanic by trade, and am willing to run my head into the wall many times till I realize I just can't get there. Not sure My feedback would help you any, and whatever data may be unsuccessful should be given a fair amount of scrutiny. Take for instance my current project with M5stack. While there was of an obvious solution posted by Dave, and Robert, I just wasn't seeing it. Now that I have moved forward Into making a 4 channel strip on M5 stack , there are the problems I'm seeing, that may be due to my lack of programming prowess, or a lack of understanding the code fully. While this project works mostly, has some bugs to work out. While I can get 65 + effects to work on it, the results are not expected. Some strips are flickering, and audio is not always as expected. Is that a shortcoming of the code, my lack of programming experience, or is working as designed. Another instance is, Atom light does not want to let go of the Oled display. Doesn't matter what chip I try, there is a deep link I cannot find to oled. If you can help us all, would surely be grateful, but I think it would be very difficult.

[robertlipe]

Andrew, I think a description and perhaps even photo/video describing each project (DEMO vs. SPECTRUM vs INSULATOR, etc.) would be great help. I personally really struggled with that. Some effort to decouple the controller from the project would be similarly helpful. In general, I think there's a lot we can better do to differentiate the effects configuration, the host board configuration, and the light configuration. It seems like there's yet a fourth complete axis, but it's late and not really the point here.

mostly, has some bugs to work out. While I can get 65 + effects to work on it, the results are not expected. Some strips are flickering, and audio is not always as expected. Is that a shortcoming of the code, my lack of programming experience, or is working as designed.

Flickering is probably not working as designed. We're all about the blinkage, not the flickering. In a way that's hard to express, just like you can surely tell the difference in "it sounds funny" whether it's the intentional squeak of a brake pad vs the squealing of an alternator bearing, maybe someone on the group can recognize it if we can see it. Flickering can be power supply (it's kind of flashy and the bulbs slightly upsteam will be more orange-y - and reducing the brightness will often put it in remission. A voltmeter on the tailing end can also verify if you're within 10-20% of target voltage.) or an open/unshared ground between the controller and the lights (the electronics explanation is a page on its own, but floating grounds will make one crazy to debug) or an unbuffered data length that's too long ***@***.*** from these ESPs just doesn't go a huge distance over copper before turning to mush) , which tends to have the ones near the end kind of spark-y. If you can show us a few moments of video, a schematic of your setup, the software configuration you're using, maybe someone will have some ideas. I'll certainly look and while I might not be able to configure your case exactly, I might try. If you rearrange the strips, do the problems stay on the pins or do they follow the strips? Like I mentioned to someone here (I think) recently - in computer science, there are no accidents. Everything obeys laws of physics and rules. They can be freakin' hard to figure out sometimes and that also means that for everything to work right, ALL the things have to go right. It's OK to ask for help. So far, I have one bad strip, one bad circle-strip, and one bad 2812 matrix panel. Everything past the magic spot acts weird, if at all. Those can be a real bear when debugging software because no matter how much logic I throw into the pulses going into the bus, they are bound by the physics of being unable to blink by the bulb upstream from them being burned out. Not random at all. (...and because I seemingly like to torture myself, I keep mixing these back into my general population so I can "rediscover" their brokenness all over again.) Another instance is, Atom light does not want to let go of the Oled

display. Doesn't matter what chip I try, there is a deep link I cannot find to oled. If you can help us all, would surely be grateful, but I think it would be very difficult.

I can't even tell what this means. ATOMLIGHT as an effect shouldn't have anything to do with OLED panels like used by the ARDUINO_HELTEC_WIFI_KIT_32_V3 host boards.

[robertlipe]

[ record scratch ] Wait, wot? https://github.com/PlummersSoftwareLLC/NightDriverStrip/blob/8505161c76d857a0a6e418953b99ac384e929e99/include/ledstripgfx.h#L127 This code surely can't be right. It's certainly not right if you're trying to use any of those as LED_PIN outputs. The above ADD_CHANNEL would set them to output, but this would come along and disconnect those pins internally from our ability to drive them and just instead let them float as inputs. That whole section seems deeply bogus to me. Can you whack that block between #if ATOMLIGHT/#endif and see if your case gets better? This would work for an ATOMLIGHT that's configuring one pint for output (probably 5) but not for other stands if you happened to put them on those pins. I'm 95% sure that block is just plain bogus. Dave or Ruger, can I get a code review on PR#453, please? #453

…

On Thu, Oct 5, 2023 at 11:28 PM Robert Lipe ***@***.***> wrote: Andrew, I think a description and perhaps even photo/video describing each project (DEMO vs. SPECTRUM vs INSULATOR, etc.) would be great help. I personally really struggled with that. Some effort to decouple the controller from the project would be similarly helpful. In general, I think there's a lot we can better do to differentiate the effects configuration, the host board configuration, and the light configuration. It seems like there's yet a fourth complete axis, but it's late and not really the point here. > mostly, has some bugs to work out. While I can get 65 + effects to work > on it, the results are not expected. Some strips are flickering, and audio > is not always as expected. Is that a shortcoming of the code, my lack of > programming experience, or is working as designed. > Flickering is probably not working as designed. We're all about the blinkage, not the flickering. In a way that's hard to express, just like you can surely tell the difference in "it sounds funny" whether it's the intentional squeak of a brake pad vs the squealing of an alternator bearing, maybe someone on the group can recognize it if we can see it. Flickering can be power supply (it's kind of flashy and the bulbs slightly upsteam will be more orange-y - and reducing the brightness will often put it in remission. A voltmeter on the tailing end can also verify if you're within 10-20% of target voltage.) or an open/unshared ground between the controller and the lights (the electronics explanation is a page on its own, but floating grounds will make one crazy to debug) or an unbuffered data length that's too long ***@***.*** from these ESPs just doesn't go a huge distance over copper before turning to mush) , which tends to have the ones near the end kind of spark-y. If you can show us a few moments of video, a schematic of your setup, the software configuration you're using, maybe someone will have some ideas. I'll certainly look and while I might not be able to configure your case exactly, I might try. If you rearrange the strips, do the problems stay on the pins or do they follow the strips? Like I mentioned to someone here (I think) recently - in computer science, there are no accidents. Everything obeys laws of physics and rules. They can be freakin' hard to figure out sometimes and that also means that for everything to work right, ALL the things have to go right. It's OK to ask for help. So far, I have one bad strip, one bad circle-strip, and one bad 2812 matrix panel. Everything past the magic spot acts weird, if at all. Those can be a real bear when debugging software because no matter how much logic I throw into the pulses going into the bus, they are bound by the physics of being unable to blink by the bulb upstream from them being burned out. Not random at all. (...and because I seemingly like to torture myself, I keep mixing these back into my general population so I can "rediscover" their brokenness all over again.) Another instance is, Atom light does not want to let go of the Oled > display. Doesn't matter what chip I try, there is a deep link I cannot find > to oled. If you can help us all, would surely be grateful, but I think it > would be very difficult. > I can't even tell what this means. ATOMLIGHT as an effect shouldn't have anything to do with OLED panels like used by the ARDUINO_HELTEC_WIFI_KIT_32_V3 host boards.

[rbergen]

@smiliea I love the idea of documenting "confirmed working" combinations (NightDriverStrip project, controller, strips/panels, other hardware used, ...), or even combinations that were attempted and failed. For one, it would give us some insights into what this project is actually used for, and it could also help focus our efforts to make "general" improvements on the most useful areas.

However, considering the amount of information one could document about each (possibly including pictures like @robertlipe suggested, problems encountered, descriptions of tweaks made to code, other "good to knows", etc.) I'm not sure a table on a single page would be the best format. I was thinking this may actually be a very good reason to get started with this repo's Wiki, that we would link to from the main README.md, of course.
I'd be happy to think up a basic Wiki structure, put that in place and then open it up for general editing to see how it goes.

[prschguy1]

In my opinion, I think what the best help for those debugging their boards would be a basic sanity check of the effects. Which ones are single or multi-channel, which ones are sound reactive or static effect. Not sure if there is a simple way of identifying those traits, or if they must just be all tried and categorized on a stable build. If there are identifiers that can be recognized, would it be possible to make a statement that when a single channel effect is displayed on multichannel, can all channels display the same single channel effect? I think it would be a better way to determine if the build has crashed, or if it's supposed to be that way.

[robertlipe]

I don't totally follow the end of your message, but the beginning part touches on an interesting area where I think you could really help. Here comes another of my long "teach a man to fish" explanations. The process of getting from an effect's name, as it would appear in the web server, to the exact code in include/effects/strip (I trust you're not doing matrix coming out of the gate, so let's put that in a box to the side) is not always easy. I probably can't teach you to program this weekend, but I can probably help you wade through enough of the code to at least get a good run on making such a list. There's the kink that some effects only show up in some builds, so just spinning "a stable build" and looking at the web interface isn't necessarily the way to generate complete coverage. (Lipe Pro Tip: I think that zero of the effects - I'm almost certain for USE_281x - actually require attached LED to do their thing. I actually do a moderate amount of debugging with literally just a thumb-sized chip dangling from a USB cable and zero LEDs. So a suitably determined person probably COULD spin through at least all the builds that Rutger puts in the web build and toss them all onto the same ESP32 one-by-one. (Not that Dave's Belt wasn't (probably) awesome, but it's reasonable to have some kind of bottom floor, right.) So all the strip effects are in include/effects/strip, but there's a one to many mapping. Some files can have many effects. Kind of the classic pattern is in bouncingballeffects.h: BouncingBallEffect(size_t ballCount = 3, bool bMirrored = true, bool bErase = false, int ballSize = 5) : LEDStripEffect(EFFECT_STRIP_BOUNCING_BALL, **"Bouncing Balls"**), The key parts of this pattern is "Make a thing internally called BouncingBallEffect ... with some internal knobs about size and such. The important part for making a list is the next part ":" here means "inherits from", which means what it does in English. All the effects are a LEDStripEffect, so this is good term to search for (usually colon space LEDSt...) the all caps is a number that corresponds to a list in include/effects.h. It looks like #define EFFECT_STRIP_BOUNCING_BALL 1 so that might be handy for making a wiki-style list because that is a list of ALL the effects, but even if you add the 38 to the Star Variations, there's more to it. But we'll come back to that. The second part is the name as it shows on screen on Mesmerizer or on the Web interface. Well, usually. But in the example above, the quoted Bouncing Balls is probably the most official Human-spoken name. Your next question is "Is it audio reactive?" I honestly don't think I've seen that written down anywhere. Fortunately, I know how to find the answer to this one. For an effect to be AR, it has to call a function ProcessAudio(). Searching for that word in that file finds no hits, so I'm going to say that Bouncing Ball is not AR. To give you a crude sort (remember that a file can have more than one) I'll limit the search area for AR effects: grep -l Audio include/effects/strip/*.h include/effects/strip/fireeffect.h include/effects/strip/laserline.h include/effects/strip/musiceffect.h include/effects/strip/particles.h include/effects/strip/tempeffect.h Remember when I said the name comes from the second argument (the list after the comma) to LEDStripEffect? That's true, but it's not always that easy. For example, we have: FireEffect(const String & strName, int ledCount = NUM_LEDS, int cellsPerLED = 1, int cooling = 20, int sparking = 100, int sparks = 3, int sparkHeight = 4, bool breversed = false, bool bmirrored = false) : LEDStripEffect(EFFECT_STRIP_FIRE, strName), but we also have : LEDStripEffect(EFFECT_STRIP_BASE_FIRE, "BaseFireEffect"), : LEDStripEffect(EFFECT_STRIP_CLASSIC_FIRE, "Classic Fire"), The last two are easy. The one for "STRIP_FIRE" is harder to chase upstream. Where does strName come from? It's passed in from the line above. Well, where does THAT come from? Remember that "unique" number? It's an effect number, but we can have lots of different types of those. Let's introduce yet another hidey-hole: src/effects.cpp If we search for "STRIP_FIRE, " (the comma helps us not find anything related to the other two) we see we have three variations of this effect: Two are in the Umbrella build named Calm Fire and Medium Fire. We have another "Calm Fire" that's only in the Lantern Build. (Now your list has a challenge - if it makes a list, does it have to be by effect product output (Umbrella, Insulator, Lantern...) because we have two different "Calm Fire"? {shrug}) In some bad dream for your list, one could be AR and the other not. But if we look to see where ProcesAudio() happens, it's only in proximity of MusicalPaletteFire (hey, that name might have been a hint!) so when we bop back into src/effects.cpp we see we have actually TEN different entries for EFFECT_STRIP_MUSICAL_PALETTE_FIRE. Take a peek at just one: ADD_EFFECT(EFFECT_STRIP_MUSICAL_PALETTE_FIRE, MusicalPaletteFire, "Green Fire", CRGBPalette16(CRGB::Black, CRGB::DarkGreen, CRGB::Green, CRGB::LimeGreen), NUM_LEDS, 2, 3, 150, 3, 10, true, false); The "what is it called" answer is now pretty obvious. Understanding all the rest of that is a drag, but just using English is enough to confirm the components that go into a Palette (just like the painting board) of Red Greens Blues (all light is made of those three, so you'll see a lot of RGB in the code). What's in green fire? Black, Dark Green, Green, Lime Green. If I were crushing up a box of crayons, that sounds about right. (Crayons are pigments and not light and follow different blending rules, but that, too, is a distraction.) As you read src/effects.cpp, you can very easily (assuming your head has not yet exploded - I'm almost done, I promise!:) see what effects are turned on in each build. Just like you've been exposed to include/globals.h, it's very much kept in one big ole list separated by #if hunks based on project name. In this file, you can also see some mixing between the pervasive ADD_EFFECT and the special cases like ADD_STARRY_NIGHT_EFFECT or stanzas like EFFECT_STRIP_METEOR that is the 'same' effect five times in a row, just with different tuning factors. (I'm not going to go through them, but I might imagine them to be the number of stars, their size, their twinkle times, their speed, and all those other traits one might assign to such a celestial body.) Now, with some cooperation and time, I think that someone that isn't quite a programmer probably can work through the internal data structures and work through a list of effects, what builds they'd appear in and whether they're audo reactive. Super Double Bonus Round. There's allegedly a way to capture pixel data from the NDL board. I've never succeeded in making it work, but my attempts were pretty feeble. I've been envious of projects like https://github.com/Aircoookie/WLED/wiki/List-of-effects-and-palettes that have a good preview. I think that'd be super cool to help someone figure out what effects they want before digging through a whole bucket of them. I know there's code in NDL under COLORDATA_SERVER_ENABLED (the comment says one port number, the code says another) but I could never make the data make sense. I remember wondering if the data could change during that memcpy but never really followed it up with a client thingy that splashed pixels on a screen. I'd be interested in pairing up to help build/automate an automated effect png thingy if there were demand in it and someone interested in presenting it in a useful way. beyond 247 gif files that are 12 frames long. For the question "how many effects are multichannel?" we can dig around in globals.h: grep NUM_CHANNELS include/globals.h | grep -v 1 #define NUM_CHANNELS 4 // One per spoke #define NUM_CHANNELS 8 So our answer is "two", making the answer to the next question, that you didn't actually answer, "ATOMLIGHT" and the catch-all "DEMO". We can spot-check this to be true by searching for LED_PIN3 and getting only two hits. (Tip: there's a comment in Umbrella saying it supports 8. Doesn't seem to in reality as only 4 pins are defined. As to the very tiny end, by design, if the device crashes, it'll dust itself off and boot back up again .... potentially right back into the same code that made it crash. I do this a lot in development. :-/ The code is reasonably bomb-proof, but if you have a unit with power supply issues or in a box with poor circulation and it overheats, crashes are inevitable. For the voltage thing, you can actually telnet to the box and type 'uptime'. It'll tell you how long it's been running since the last boot and WHY it last reset. It will record low voltage brownouts. At 3.3V, there's not a lott of headroom and starting the radio transmitter can pull up to about .6A for a fraction of a second. With a wimpy regulator, poor power supply/regulator, absence of decoupling and filtering caps, etc., brownouts can be nasty to diagnose. Uptime will actually tell you if it restarted because the power got wimpy - Telling you WHY it browned out usually involves an EE-type person. :-) So, with these lessons in hand, I think you should have the skills and confidence to assemble a list of effects, with names, AR status, and such for all product combinations. If you get stuck on one and you can describe it well enough that I can build it and zip to it, I'll help you slug through the code to answer any that are tricky. Hopefully, you and other -also- have a little more knowledge to add some flesh to Rutger's lovely guide at https://github.com/PlummersSoftwareLLC/NightDriverStrip/blob/main/CODEBASE_INTRO.md. You should be able to take this information and re-mix the existing effects in novel ways. Maybe you want more, fainter starts. Hopefully you now have the basic skills to wade in and comment some effects out and copy/modify others or add your own seasonal twists to color palettes and such. If you have to deliver red and green stars to get permission to spend more on toys, we won't judge. Most of all, Have Fun!

…

On Fri, Oct 6, 2023 at 4:24 AM prschguy1 ***@***.***> wrote: In my opinion, I think what the best help for those debugging their boards would be a basic sanity check of the effects. Which ones are single or multi-channel, which ones are sound reactive or static effect. Not sure if there is a simple way of identifying those traits, or if they must just be all tried and categorized on a stable build. If there are identifiers that can be recognized, would it be possible to make a statement that when a single channel effect is displayed on multichannel, can all channels display the same single channel effect? I think it would be a better way to determine if the build has crashed, or if it's supposed to be that way. — Reply to this email directly, view it on GitHub <#452 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCSD3ZWPL3UTQJ664JYCL3X57E4LAVCNFSM6AAAAAA5TRNPGSVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TEMBXG42DC> . You are receiving this because you were mentioned.Message ID: <PlummersSoftwareLLC/NightDriverStrip/repo-discussions/452/comments/7207741 @github.com>