Atom light advancement

[prschguy1]

Wanted to let any Atom light builders know that some lines were removed from the code that was hindering capability. With the help of Robert and Rutger those changes were merged from a pull request. If you found your displays or other were not working on Atom light project, I suggest you try again. I now have Atom light working on M5 Stack. It has pretty generous memory, and have had 65+ effects running on it. For whatever reason, this chip running strip effects is prone to flicker if your power supply isn't really clean. While I had been using a 15 amp brick for my other chips, it wasn't clean enough for this one. Now using a 18 amp Mean Well power supply, and it looks like that has cured the flicker. While I am still tweaking the build, this is what I did to make it work. Feel free to point out any mistakes I might have made here. While stable, could probably use some work still.

[env:atomlight]
extends = dev_m5stack
build_flags = -DATOMLIGHT=1
;-DSHOW_VU_METER=0 ; if set to one, displays vu meter on 1 spoke ???
-DM5STACKCORE2=1
-DEFFECT_SET_VERSION=0 ;should effect persist, or restart list after re-start
-DLOAD_GFXFF
${psram_flags.build_flags}
${remote_flags.build_flags}
${unity_double_flags.build_flags}
${dev_m5stack.build_flags}
board_build.partitions = config/partitions_custom_noota.csv

#elif ATOMLIGHT
#ifndef PROJECT_NAME
#define PROJECT_NAME "Atom Light"
#endif

#define ENABLE_WEBSERVER            1   // Turn on the internal webserver
#define ENABLE_WIFI                 1   // Connect to WiFi
#define INCOMING_WIFI_ENABLED       0   // Accepting incoming color data and commands
#define WAIT_FOR_WIFI               0   // Hold in setup until we have WiFi - for strips without effects
#define TIME_BEFORE_LOCAL           5   // How many seconds before the lamp times out and shows local content
#define COLORDATA_SERVER_ENABLED    0   // Also provides a response packet
#define NUM_CHANNELS    4
#define MATRIX_WIDTH    53     // My maximum run, and about all you can do at 30fps
#define MATRIX_HEIGHT   1
#define NUM_LEDS        (MATRIX_WIDTH * MATRIX_HEIGHT)
#define ENABLE_REMOTE   0                     // IR Remote Control
#define ENABLE_AUDIO    1 
 
#define LED_PIN0 33
#define LED_PIN1 32
#define LED_PIN2 27
#define LED_PIN3 19
#if USE_PSRAM
    #define MAX_BUFFERS         500
#else
    #define MAX_BUFFERS         10
#endif

//#define IR_REMOTE_PIN 
#define NUM_INFO_PAGES 2
#define NUM_FANS        1
#define FAN_SIZE        NUM_LEDS
#define LED_FAN_OFFSET_BU       0
#define FAN_LEN                 (NUM_FANS * FAN_SIZE)
#define POWER_LIMIT_MW (INT_MAX)              // Unlimited power for long strips, up to you to limit here or supply enough!

#define DEFAULT_EFFECT_INTERVAL     (1000*20)
#define NUM_RINGS   1    
#define RING_SIZE_0   NUM_LEDS

I will say this chip does not have a lot of open pins. May have to steal some from other functions to make remote work. With that being said, will focus now on getting Atom Light to work on Esp32-s3 Devkitc. Any Progress or ideas you have using that chip would be appreciated.

[robertlipe]

On Sun, Oct 8, 2023, 3:57 AM prschguy1 ***@***.***> wrote: have had 65+ effects running on it.

We have 65 strip effects? I should read more. For whatever reason, this chip running strip effects is prone to flicker if

your power supply isn't really clean.

That shouldnt be a trait of chip/board. Noise filtering and distributing the power are key. Don't make one long run if power, especially with 5v strips. Use heavy-ish wire from your PS and shoot dc into every few meters of strips. Otherwise, parasitic resistance and voltage drop will make the downstream an orangey, flashing, spastic mess. While I am still tweaking the build, this is what I did to make it work.

Success stories make me happy. Feel free to point out any mistakes I might have made here. While stable,

could probably use some work still. [env:atomlight] extends = dev_m5stack build_flags = -DATOMLIGHT=1 ;-DSHOW_VU_METER=0 ; if set to one, displays vu meter on 1 spoke ??? -DM5STACKCORE2=1 -DEFFECT_SET_VERSION=0 ;should effect persist, or restart list after re-start -DLOAD_GFXFF @${psram_flags.build_flags} ${remote_flags.build_flags} @ ${unity_double_flags.build_flags}

${dev_m5stack.build_flags}

@board_build.partitions = @config/partitions_custom_noota.csv

@ lines should be defaults inherited from parent. * MATRIX_HEIGHT)

#define ENABLE_REMOTE 0

You inherited remote above.

// IR Remote Control #define ENABLE_AUDIO 1 #if USE_PSRAM #define MAX_BUFFERS 500 #else #define MAX_BUFFERS 10 #endif Note to self: we need to move this out of per-project, maybe even making

it dynamic. I will say this chip does not have a lot of open pins. May have to steal some from other functions to make remote work. With that being said, will focus now on getting Atom Light to work on Esp32-s3 Devkitc. Any Progress or ideas you have using that chip would be appreciated

S3 boards usually have more. They go from 23 to 45 gpio5, I think, but

some are always taken by spi. For ram/flash, USB, etc. Otoh, there's a point of overkill in these. Instead of going to a bigger soc and attaching eleventh hundred LEDs, often just adding a second $5 board is the way to go. Congratulations!

…

[prschguy1]

Well Robert, as you mentioned, we don't have 65 + strip effects. Instead, have been working to incorporate all the fan effects as well as ring effects into the atom light project. While some might not be multichannel effects, some of the single channel effects look pretty good on Atom light. Will repeat a previous request: can a statement be made that would allow a single channel effect be displayed on multiple channels?

[robertlipe]

Interesting. I've been kind of madly copy-pasting and finding that some of the effects for Mesmerizer aren't totally hideous on a Spectrum-style layout. Some of them get wiggy with 48x16 resolution and some just won't work. Some of them are pretty even when broken. :-) I don't understand your request for "a statement". Is the goal to define one effect and have it displayed on multiples? Are you trying to generalize it, "I'd like this effect on 0, 2, 4, and 8, this one on 1 and 3, and the other one on what's left?" Or is it brute force, whatever goes to zero goes to everything and if your strips are different lengths and you're expecting something like the Cylon effect to work 'right' on shorter lengths, that's just too bad. If this were something for my own use where I didn't care about generalizing it or any of those edge cases or power estimates working sensibly or previews rendering it correctly or whatever, here's where I'd start: We fundamentally have two layers in the path you're describing. There's the NightDriver stuff that actually allocates the channels, giving us a unique LED buffer of pixels per channel and generates/receives the effects by scribbling them into those arrays of pixels. Those arrays at the (logical) bottom then hands the code off to either [FastLED](http://fastled.io/)) (WS281x) or [SmartMatrix](https://github.com/pixelmatix/SmartMatrix) (HUB75) that actually does the hardware bit flipping. My starting place for what I think you're asking, would be to squeeze into vertex between edges and stick a big wrench into it. In globals.h, I'd set NUM_CHANNELS=8 . I'd be sure that LED_PINx were all pointed to happy places. That should let the top of ledmatrixgfx.h biuld and initialize eight different channels. Time passes. A frame gets drawn and it's time to pass this hot potato over to FastLED to let it shuffle the bits over the wire. That's the task of the lone function in ledstripgfx.cpp. The meat of that is: for (int i = 0; i < NUM_CHANNELS; i++) { FastLED[i].setLeds(effectManager.g(i)->leds, pixelsDrawn); fadeLightBy(FastLED[i].leds(), FastLED[i].size(), 255 - g_ptrSystem->DeviceConfig().GetBrightness()); } FastLED.show(g_Values.Fader); //Shows the pixels We have an instance of FastLED for each channel. For each channel, we tell FastLED, "here is the stream of pixels", then we do some fading stuff. Then at the end, we pull the trigger and ask FastLED to show them. (Why do we have multiple FastLEDs but only ask the first to show. I dunno. That's sus.) In that loop, instead of passing the i'th instance of FastLED the i'th member of the leds arrays (the punctuation might be a bit trippy, but that's what it distills to.) we just tell it to ALWAYS use the 0'th such member? That would look like: FastLED[i].setLeds(effectManager.g(/* no, not i*/ 0 )->leds, pixelsDrawn); Would that work for you? Dunno. That's the naive approach. It's kludgy as everything, probably gets power and timing wrong and doesn't handle preview right and a bunch of other stuff, but I *think* it would get you the same pattern on all NUM_CHANNELS of strips. Probably. While typing this, I recognized this is a software solution that could probably be done in software. I'm not sure what the total resistance of simply fanning out a single DATA_OUT pin to multiple 2812 DATA_IN pins in, but particularly if you're going through a "sacrificial pixel" or other level shifter on the board, it's likely you can drive multiple strings from the same output. Now in electronics multiplying a load times eight (you never said eight...) is hardly a given, particularly given the limited drive current from the SoC output. Without consulting data sheets, I'd expect to be able to power "a couple" from the SoC output and "more" if that output come from a sacrificial pixel, is robbed from a neighboring strip, or comes from a logic level converter. Heck, a TXS0108E or pcf8575 would probably make the math dead simple. From my stash, I'd probably start with the 4-channels because that's what I have in stock and would bet the SoC would drive four input pins and that each output would drive the data in for two strips. Epiphany, the third. Using a collection of obscure features in the silicon (this is known as "programming" :-) that's present only in specific variations of the ESP32 (read: a support nightmare) you can get [24 pins driving ](https://www.reddit.com/r/FastLED/comments/bjq0sm/new_24way_parallel_driver_for_esp32/)"8800 WS2812 pixels at 90 FPS", so there may not be motivations to work too hard to share. I can't tell that we're turning that flag on, but if you KNOW your hardware supports it, just let 8 independent variations of the same effect run and sleep well knowing th DMACs are going to pluck pixels from the frame buffer without CPU help. You have options. So many options.

…

On Mon, Oct 9, 2023 at 5:50 PM prschguy1 ***@***.***> wrote: Well Robert, as you mentioned, we don't have 65 + strip effects. Instead, have been working to incorporate all the fan effects as well as ring effects into the atom light project. While some might not be multichannel effects, some of the single channel effects look pretty good on Atom light. Will repeat a previous request: can a statement be made that would allow a single channel effect be displayed on multiple channels? — Reply to this email directly, view it on GitHub <#458 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCSD32HL2AF5DTBWPJMJ4LX6R5RXAVCNFSM6AAAAAA5XRIJZ2VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TEMZUHEYDQ> . You are receiving this because you commented.Message ID: <PlummersSoftwareLLC/NightDriverStrip/repo-discussions/458/comments/7234908 @github.com>

[rbergen]

Will repeat a previous request: can a statement be made that would allow a single channel effect be displayed on multiple channels?

I'm also not exactly sure what you're looking for? Is it a "formal OK" to run an effect that was originally made for one channel on multiple channels, "merely" repeating its output? If that's the question then the answer is "absolutely, if it looks good on the actual hardware project!" - in the end that's really all that matters in all cases.

At the source code level it would be great if this could be achieved without effectively duplicating the code of entire effects, and that's the only "faux pas" I can think of off the top of my head. (It is 5AM for me when I write this, so forgive me if something else pops up if I were to actually review a change of that nature after I've had a coffee.)

In any case, if it's another kind of statement you're looking for then please elaborate a little to help me understand what it is.

[prschguy1]

My goal here is to allow a user to use as many of the effects as possible without leaving anything on the cutting room floor that they might like. For me, I do not want to have to choose between multi channel, or falling back to 1 channel put out onto multiple strips (yes, this chip drives 4 strips from one output no problem). Take for example laser line. A very fast, wicked effect that in my opinion looks great on Atom light. However, when it is used on my multi channel setup it goes out only on 1 spoke. (might be sensory overload on umbrella, I'm not sure :-)) So in this case, I think it would still look great to have that same effect to just be output to all the channels. I don't think all channels need be unique to still have an effect look great. While I could use a mechanical or logic switch to accomplish this, I'm looking for a more simple solution in software. While I could use 2 chips having 1 for multi channel effects, and a second one for single channel effects. That I think would be a bit clunky as having a display is on my punch list. Down the road I would like to incorporate a potentiometer or encoder to control at least brightness, so again, wouldn't want too many knobs hanging around.

[robertlipe]

My goal here is to allow a user to use as many of the effects as possible without leaving anything on the cutting room floor that they might like.

My goal (which is generally consistent with the project's goals) is to help make reasonable developer requests possible or maybe even easy. Maybe not everything is brought out to a nice little pointy-clicky thing, but if you can express it, I may be able to help build it - whether it becomes part of the official tree or not.

For me, I do not want to have to choose between multi channel, or falling back to 1 channel put out onto multiple strips (yes, this chip drives 4 strips from one output no problem). Take for example laser line. A very fast, wicked effect that in my opinion looks great on Atom light. However, when it is used on my multi channel setup it goes out only on 1 spoke. (might be sensory overload on umbrella, I'm not sure :-)) So in this case, I think it would still look great to have that same effect to just be output to all the channels.

OK, let's talk through how this might look in a way that's not a special case and that's consistent with the rest of the code. How would we WANT this to work? So we turn on more channels. Let's say 4. #define NUM_CHANNELS 4 // One per spoke and bind them to pins #define LED_PIN0 through LED_PIN3 Now internally, if we're just making copies of the first channel to the rest, we've just burned a "lot" of memory here. LASERLINE has a WIDTH of 700 so that's 700 * 32 (it might be 24. Maybe) For 8 channels, that's 180k which is a lot on our 512K boards. This would be worth special casing IF we decide that mirroring channels is the goal. Maybe we have a special ADD_CHANNEL that passes the same leds[] to each of the different LED_PINs Edit: when I wrote that, I thought I was being clever, but that's actually how FastLED recommends doing this: https://github.com/FastLED/FastLED/blob/master/examples/Multiple/MultipleStripsInOneArray/MultipleStripsInOneArray.ino It seems pretty natural to think of this as another dimension beyond length, so is #define MATRIX_HEIGHT 1 // Number of pixels tall or is it 4 ? This might be interesting. I can't tell that MATRIX_HEIGHT is (intentionally) used outside the MATRIX effects. Maybe we use that as a hint that we duplicate the effect on the first strip to that many channels. We have configs that set it, but I'm not sure we should. Actually, should we just do this ANY time we have > 1 NUM_CHANNELS? Should we just repeat the effect to all the strips? That wouldn't be hard to implement and it'd be consistent with the style of config.h. DEMO would thus output the same pattern to all 8 channels You're probably right that on an umbrella, it would look a little too much like being bombed for my hyper reflexes. :-) This would be the software equivalent of dying all the DIN pins on each of the strips together at the source, but slower because have to actually transmit more pixels. Unlike a hardware shunt like that, you can click "next effect" and it can choose to do something different. I don't think all channels need be unique to still have an effect look

great.

To the contrary. If you have 8 visible strips running 8 independent effects, you have visual overload and no sense of pattern at all. Design decision time: **Would being able to declare LED_PIN0 through LED_PINn and just NUM_CHANNELS to n and have the data duplicated to all pins get you where you want to be? Does that hose any existing conditions? ATOM and DEMO are the only two configurations now setting NUM_CHANNELS > 1?** I'd consider it helpful/useful for DEMO to output to all. It'd be good for coverage/profiling and if you're debugging hardware, having 8 pins bounce around, it increases the chances of connecting to one. OTOH, it would also torment hardware configurations that happen to use those pins for things like onboard display. How does a TTGO react to having a WS2812 800Khz "rainbow" dumped nito the MOSI pin? (A: don't use DEMO.) If we can get consensus on that one question, I think I can make the code do it....efficiently. Down the road I would like to incorporate a potentiometer or encoder to

control at least brightness, so again, wouldn't want too many knobs hanging around.

I inventory both of those. If we decide how they should work, I can lay bricks. For brightness, it's going to be hard to beat the IR remote. You want to be able to set it from where the viewer is, not walking back and forth and tweaking a knob. There are other sensors I'd like to add, too. For now, let's keep this on "ATOM light advancement" and particularly "delivering a single effect to multiple strips". This seems like a tangible thing for us to do. RJL

…

Message ID: <PlummersSoftwareLLC/NightDriverStrip/repo-discussions/458/comments/7238248 @github.com>

[prschguy1]

Hey, just wanted to post a concern. Have not heard from stretch 911 for a while. Hoping he has just had his mind blown by mesmerizer, and there is nothing wrong there. While I know he was an active Atom light builder, am a bit surprised he has not responded here. while we had corresponded a few times on Atom Light, not seeing anything lately. Hope all is well with him, and that he is just otherwise occupied. Hope someone has had contact with him.

[robertlipe]

I know that Stretch911 comes and goes on this project. Don't assume he reads everything.

…

On Wed, Oct 11, 2023, 6:00 PM prschguy1 ***@***.***> wrote: Hey, just wanted to post a concern. Have not heard from stretch 911 for a while. Hoping he has just had his mind blown by mesmerizer, and there is nothing wrong there. While I know he was an active Atom light builder, am a bit surprised he has not responded here. while we had corresponded a few times on Atom Light, not seeing anything lately. Hope all is well with him, and that he is just otherwise occupied. Hope someone has had contact with him. — Reply to this email directly, view it on GitHub <#458 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCSD34QCCXZ6NXWQ66GQC3X64QHPANCNFSM6AAAAAA5XRIJZY> . You are receiving this because you commented.Message ID: <PlummersSoftwareLLC/NightDriverStrip/repo-discussions/458/comments/7257556 @github.com>

[stretch911]

sorry...been on sabbatical. (Building a house and that has been overwhelming to be honest). I'm starting to "pack" and got to my pile of led lights and microprocessors, which sparked the mad LED scientist in me again. I'll try to be more active here because this project really flexes my head muscle. I pulled a fresh copy of the code base and am hoping to get a build installed soon for atom light.