(dev_elecrow_mesmerizer) For which board is this meant?

[heidepiek]

Was just fiddling with the nightdriverstrip code for the dev_elecrow_mesmerizer. Know that it is a spectrum analyzer. Got it working on a YD-ESP32-23. (clone of the ESP32-S3-DevKitC-1) Web server is working fine. But if I got it right it also uses libraries for a screen.
Been doing some nosing around and found in the libraries this header file: LovyanGFX.hpp There the ili9341 is referred to as screen. Tried to get it working with an ili9341, but so far no success. Would like to know what board it is for though. (Curiously inclined. Or eager to learn)🙈
It will be an esp32 s3 with a screen. And I think of the elecrow brand. But which one? Surely it is not the ESP-WROVER-KIT-VE Development Board ESP32-WROVER-E ESP32 With Vga-Interface 3.2 Inch Lcd. I don't think that one has the esp32 s3 chip. Who knows what this dev_elecrow_mesmerizer was originally intended for?

greetz Harrie

[prschguy1]

I have that build working with an authentic ESP32-S3-WROOM-2-N32R8V from espressif. I think the only real difference here is that this board uses memory type opi_opi , where as your board I think is still using quad memory. The display I am using is a bit smaller: found on amazon as HiLetgo 2.2 Inch ILI9341 SPI TFT LCD Display 240x320 ILI9341 LCD Screen with SD Card Slot. Works well with a few minor changes in screen.h. Re-numbered some pins to neaten it up a bit, and adjusted resolution. I'm also using PDM mic on this build, and tossed out the settings for this build in soundanalyzer.h. Works well, but have some memory issues running strip effects (I use many, 60+) . Have been trying different board define files, and different partition tables to use the 32mb flash size. Will try mesmerizer build on this chip as time allows. Congrats by the way for your lolin pro build . Enjoyed watching you progress through it.

Craig

[prschguy1]

20240108_191857.mp4

[robertlipe]

You have a HUB75 on S3? Interesting as SmartMatrix doesn't support that. I've wrestled a bit with the needed underlying parallel dma support. Please tell me more. (I thought this worked some time ago, but I've recently convinced myself this never worked and I used different modules than I thought I used.) I think if you're using official Espressif modules, at least for S3, the NnnRrr convention is that if N is 2, a 2mb board, it's quad SPI. If N is 8mb, it's octal, even though other combinations are technically possible. If a vendor isn't using the "cans" and are splashing down their own SPI chips, all bets are off. My LUATOS boards are this way; they don't use official modules and they're 8MB but quad. (I prefer to not think about regulatory certification about this...) I've had YD and LUATOS support for a while as I have a lot of those boards and a few other strays, too. Rutger and I have discussed how to add that in so we can all quit "rediscovering" it, but it's not clear how we should support raw modules like this that are, by definition, DIY projects. We're all making up our own pinouts and defining which effects we use with it. I use custom effects, Harrie apparently uses Spectrum, you've seemingly conquered Mesmerizer,. etc. We surely have equal mixes of pins for remotes, mics, and little screens. Like 1306 or LCD screens or whatever. I've been working on a way to not need separate entries for 2, 4, 8, 16, and (rare) 32MB flash as that would yet further explode the matrix. I have that tangled in with other changes that have overall moved slowly. I do have flash size detection and changes mostly working. Further still, some of the DevKit clones put the onboard LED on different pins. Do we add all these as separate boards? I've been happy to ignore that led. Now we have devkit-ledon22-8mb-qspi-1306withspionXY-miconM-{demo, laserline, spectrum, mesmerizer} as a matrix with, what, 8 dimensions? Gross. I've put a lot of thought into how to better support the hardware diy crowd (there's ar least 3 or 4 of us. We're a crowd, right?) and make it play nicely with our build and naming connections. We added the custom*in and globals to try to make it easier to add these without changing core files but maybe we should add a "demo" target with no peripherals and a single 2812 strand and a common flash/ram size and just punt the rest as documentation hints to customize the rest in your own. So, fellow hardware DIYers, how can we strike a reasonable balance to help people get going (the QSPI/OSPI mess, in particular, I think we could tame. I have code for memory and flash tests that can further help.) but without getting into the silly explosion of combinations I've hinted at above. How can we do this better without making a big mess of things? Have either of you pushed your changes so we can merge the best pieces of all our changes? I'm willing to lead this one if neither of you want to.

…

On Tue, Jan 16, 2024, 5:06 PM prschguy1 ***@***.***> wrote: I have that build working with an authentic ESP32-S3-WROOM-2-N32R8V from espressif. I think the only real difference here is that this board uses memory type opi_opi , where as your board I think is still using quad memory. The display I am using is a bit smaller: found on amazon as HiLetgo 2.2 Inch ILI9341 SPI TFT LCD Display 240x320 ILI9341 LCD Screen with SD Card Slot. Works well with a few minor changes in screen.h. Re-numbered some pins to neaten it up a bit, and adjusted resolution. I'm also using PDM mic on this build, and tossed out the settings for this build in soundanalyzer.h. Works well, but have some memory issues running strip effects (I use many, 60+) . Have been trying different board define files, and different partition tables to use the 32mb flash size. Will try mesmerizer build on this chip as time allows. Congrats by the way for your lolin pro build . Enjoyed watching you progress through it. Craig — Reply to this email directly, view it on GitHub <#592 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCSD34ZECQA4KBTM4F22A3YO4BXDAVCNFSM6AAAAABB5QTTJCVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DCNJQGE2TC> . You are receiving this because you are subscribed to this thread.Message ID: <PlummersSoftwareLLC/NightDriverStrip/repo-discussions/592/comments/8150151 @github.com>

[heidepiek]

Hello craig, i believe i saw this project in another discussion. Nice build of your ledscreen! @robertlipe i dont't think craig is using a hub75. But a selfmade screen of 3 ws2812 ledscreens with diffuser. I'm also working on something like that. Big aluminium plate for Cooling the leds, and three 3d printed diffusers. I know have to haull to work, when i Come home i wil try to alter the mentioned header files. @prschguy1 could you tell me your pinout?

Greetz harrie

[prschguy1]

Hello Robert, for this build I am still using the 3 panel setup that Harrie describes. Have not got around to trying the hub 75 mix yet. It would be really nice to get some working versions of the s3 chips working here. The smaller versions of that board are getting harder to find. Espressif has shifted most of their focus to the 32mb version that I have. Unfortunately, not a lot of people have it working very well. While it is working for me, to be honest, I think M5Stack was working better. I have a build of that that was 4 channel, and 77 effects and was mostly stable, although wifi would drop out from time to time. Have not tried that on the recent code base though, so not sure if that would still work. Have been focused on the various generic, and official s3 boards at the moment. Also was able to get the Lilygo t-display s3 working pretty well with display, sound, and remote. However, the display keeps it from working with spectrum, and I could only get 2 channels of led strip working at time of testing. May revisit that as time allows.

Craig

[prschguy1]

Hello Harrie, here is a txt file of the pins I used for the display.
[Elecrow.txt](https://github.com/PlummersSoftwareLLC/NightDriverStrip/files/13961417/Elecrow.txt

Craig

[heidepiek]

My son has ches practice, i have to go with him. But when i come home and it`s not too late, i wil try this on my esp. I wil keep you posted! Thanks craig.

Harrie

[heidepiek]

tried it with your pinout. I got this in my screen.h:

#if ELECROW
// ElecrowScreen
//
// Display code for the Elecrow display on their 3.5"

#define LGFX_USE_V1

#include <U8g2lib.h>                // Library for monochrome displays
#include <gfxfont.h>                // Adafruit GFX font structs
#include <Adafruit_GFX.h>           // GFX wrapper so we can draw on screen
#include <LovyanGFX.hpp>            // For the Elecrow display

// TFT Pinout

#define LCD_MOSI 11
#define LCD_MISO 8 
#define LCD_SCK  10
#define LCD_CS    14
#define LCD_RST  13 
#define LCD_DC   12  

class ElecrowScreen : public Screen, lgfx::LGFX_Device
{
    lgfx::Panel_ILI9341 _panel_instance;
    lgfx::Bus_SPI _bus_instance;

public:

    ElecrowScreen(int w = 240, int h = 320) : Screen(w, h)
    {
        // ... (existing code)

        {
            auto cfg = _bus_instance.config();
            cfg.spi_host = SPI3_HOST;
            cfg.spi_mode = 0;
            cfg.freq_write = 60000000;
            cfg.freq_read = 16000000;
            cfg.spi_3wire = true;
            cfg.use_lock = true;
            cfg.dma_channel = SPI_DMA_CH_AUTO;
            cfg.pin_sclk = LCD_SCK;
            cfg.pin_mosi = LCD_MOSI;
            cfg.pin_miso = LCD_MISO;
            cfg.pin_dc = LCD_DC;
            _bus_instance.config(cfg);
            _panel_instance.setBus(&_bus_instance);
        }

        {
            auto cfg = _panel_instance.config();
            cfg.pin_cs = LCD_CS;
            cfg.pin_rst = LCD_RST;
            cfg.pin_busy = -1;
            cfg.memory_width = h;
            cfg.memory_height = w;
            cfg.panel_width = h;
            cfg.panel_height = w;
            cfg.offset_x = 0;
            cfg.offset_y = 0;
            cfg.offset_rotation = 0;
            cfg.dummy_read_pixel = 8;
            cfg.dummy_read_bits = 1;
            cfg.readable = true;
            cfg.invert = false;
            cfg.rgb_order = false;
            cfg.dlen_16bit = false;
            cfg.bus_shared = true;
            _panel_instance.config(cfg);
        }
        setPanel(&_panel_instance);

        constexpr auto LCD_BL = 9;
        lgfx::LGFX_Device::init();     
        lgfx::LGFX_Device::setRotation( 1 ); 
        pinMode(LCD_BL, OUTPUT);
        digitalWrite(LCD_BL, HIGH);
        lgfx::LGFX_Device::fillScreen(TFT_BLUE);
        lgfx::LGFX_Device::setTextDatum(lgfx::baseline_left);
    }

I got the spectrum on the screen. But not as expected! How can i change this?

ili9341_3.2inch_spectrum.mp4

[robertlipe]

Responding first to Harrie, then Craig. (I typed the response to the first when the second came in.(

@robertlipe <https://github.com/robertlipe> i dont't think craig is using a hub75. But a selfmade screen of 3 ws2812 ledscreens with diffuser.

Right. That's a "spectrum <https://www.youtube.com/watch?v=c6xa0urXvZ0>" configuration in the parlance of this project. But the subject is "elecrow_mesmerizer" and the opening line of this thread was that you (and he?) had it working on an S3. So I thought someone was talking about mesmerizer on an s3 and to my knowledge, that's currently not an easy combination. (I have a loose plan that would make it work, but it's relatively major surgery and we don't seem to have a lot of people DIY-ing HUB75 configurations. It's not currently worth the disruption.)

. Big aluminium plate for Cooling the leds, and three 3d printed diffusers.

Those are indeed cool looking!

I know have to haull to work, when i Come home i wil try to alter the mentioned header files. @prschguy1 <https://github.com/prschguy1> could you tell me your pinout?

For a Spectrum (three 8x8 panels), it's just a single (long) strand on LED0, right? Well, plus whatever audio in you use, but that might be network input. As a project for a c++ dev that's into counting clock cycles, it seems likely that Espressif's own FFT library <https://github.com/espressif/esp-dsp>, which utilizes the multi-threading and DSP, including the advanced features present in the S3 is likely to outperform the lowest-common denominator arduino fft <https://www.arduino.cc/reference/en/libraries/arduinofft/>library that we're now using. OTOH, it doesn't look like we're exactly computationally bound so we're probably "fast enough" for the pixel sizes and frame rates that matter. Still, it'd be a cool undertaking for a math nerd looking to get involved in the project. And to Craig:

Have not got around to trying the hub 75 mix yet.

That will require more than the relatively minor fiddling you might expect. I've researched the hell out of this and don't have a clearly winning path forward. We use pixelmatix/SmartMatrix to drive the HUB75 boards. For ESP32-classic (henceforth called "ESP32") it uses the onboard I2S controllers to handle the necessary funky loading of multiple bitstreams to be simultaneously strobed and clocked out the parallel pins onto the HUB75 bus. That's kind of icky, but for that chip, that's the best option it has. Our problem is twofold: Pixelmatix has abandoned even routine maintenance of SmartMatrix, not even integrating patches that are provided and that the S3 (and later parts) have a massively changed I2S subsystem, with the result of it being better for I2S, but really not usable as a general purpose parallel port, as was used for the HUB75. Key background for anyone unaccustomed to SOCs like this: different peripherals (GPIO, I2C, I2S, LCD, SPI, etc.) are on various different busses running at different speeds and synchronizing motion across those clock domains is like shifting a manual transmission...with double-clutching. On cores like this, a 240Mhz part just toggling one bit to change a GPIO line, for example, can incur so much synchronization overhead that the CPU (on an 80Mhz bus) can actually only toggle at 4Mhz(!). There are additional rules like the various GPIO pins actually beig on different clock domains such that talking to GPIO0 and GPIO32 can actually take different speeds. We can talk about reasons later, but for now, just remember why we work so hard to outsource these glorified bit-banging tasks to weird-fitting peripherals so that they can be farmed out from the CPU to one ore more DMA controllers that doesn't have to do a bus transition and put the CPU into park between each cycle. The good news is that newer parts take away and newer parts give. In all parts newer than ESP32 (i.e. All Xtensa LX7, all RISC-V) there is a dedicated GPIO periphera <https://docs.espressif.com/projects/esp-idf/en/latest/esp32s3/api-reference/peripherals/dedic_gpio.html>l. With that, you can define bundles of pins that get mapped to individual bits in a fake register that you can read and write in one operation. This is reasonably nifty for devices like HUB75 if you're willing to control each cycle yourself. If you don't REALLY want high performance, this is OK andis the approach taken by HUB75 code like the AdaFruit Protomatter library for S2 as a step up from the original "works on everything" library RGBMatrix Library <https://learn.adafruit.com/32x16-32x32-rgb-led-matrix/library>, bu tfor S3 you have to go all the way and use generic GPIO dma to do this as was done here <https://blog.adafruit.com/2022/06/14/esp32uesday-hacking-the-esp32-s3-lcd-peripheral/>. (Footnote1: RGBMatrix <https://learn.adafruit.com/32x16-32x32-rgb-led-matrix/library> supports hub75 on all ESP32s, but looks of moderate performance. Footnote 2: Protomatter supports ESP32-S3 hub75 *better, but only for >= S3*) However, that quickly runs out of gas and we learn that the newer parts (S3 and newer) have a part dedicated to controlling LCDs (like hub75!) and that's what you really want to drive and it gets explained here <https://blog.adafruit.com/2022/06/21/esp32uesday-more-s3-lcd-peripheral-hacking-with-code/>, but that's a bit of a stop-gap as this is still entangled in Adafruit's classic parts and just doesn't abstract well to the S3. S3 is different enough that it deserves its own abstraction in Protomatter <https://learn.adafruit.com/adafruit-protomatter-rgb-matrix-library>. So Protomatter is one candidate for S3 + HUB75 abstractions for us. Another really strong source of inspiration for us is MrFaptasic's ESP32-HUB75-MatrixPanel-DMA <https://github.com/mrfaptastic/ESP32-HUB75-MatrixPanel-DMA/>. It seems like the kind of obvious successor to SmartMatrix. It has Espressif chip support <https://github.com/mrfaptastic/ESP32-HUB75-MatrixPanel-DMA/tree/master/src/platforms> for the original and S3 variations. So that's option 3 for us. Footnote 4 would be an interesting direction for us to grow. Marc Merlin's FrameBuffer_GFX <https://github.com/marcmerlin/Framebuffer_GFX?tab=readme-ov-file> takes all of these pixel abstractions (HUB75, NeoPixel, the small TFT displays) that we're currently treating as separate entities and provides one kind of superset abstraction for them all. This would get us HUB75 on ESP32-S3 via Faptastic's project, but also rolls in NeoMatrix (better than our FastLED code), but it's possible that this is targeting bigger SOCs than ESP32 (mostly Pi) so we might run into RAM issues if the various underlying libraries don't abstract the pixel buffers very well. I don't think this is interesting to us as a source of S3/HUB75 support on its own, but it'd be an interesting project to see if it'd let us smoosh ledgfxmatrix and gfxstrip and our various u8g2 and fastled and smartmatrix/matrixpanel abstractions into one flatter layer. (Of course, internally, that library looks not totally unlike our own...) I think we have 3 realistic ways forward in the short term: 1) Teach SmartMatrix about S3 and other newer chips. Pros: the devil we know. Cons: It's an abandoned project and we'd be forking it quite non-trivially. Sunken cost fallacy. Major con: a bunch of icky low-level programming. 2a) Port to RGBMatrix Library. Pros: all the chips, Adafruit's large ecosystem. Cons: Unsure it'll hit our performance goal, not a great future for newer chips. 2b) Port to ProtoMatter. It looks like they've recently added support for the original ESP32's, but performance story is unclear. We could do a split and just use ProtoMatter (or anything else) only if building for newer parts. Pros: same as 2a. Major pro: gets us a stepping stone off of ESP32 if we see STM32, RP2040, Teensy, or SAMD in our future - this seems the library most likely to make it to 'bigger' chips. Cons: Introduces a big split for legacy and newer parts. For me, it's a tossup between 1 and 2b, with 2b having a slight lead. It's likely to be a bunch of unpleasant work. So researching that is how I spent (one of my) holiday vacation(s)...

The smaller versions of that board are getting harder to find.

Espressif has only committed to supporting those original ESP32 chips for 4 more years: https://www.espressif.com/en/products/longevity-commitment In single-piece, hobbyist pricing the price difference is approaching nothing. I saw new customer intros (limit 1) of the N16R8's for $0.99 this weekend and pick them up on sale for $3.50 as filler items from time to time and rarely more than $5.10. The classic dev boards are less, but not THAT much less and that delta is only going to shrink as volume of the newer parts goes up.

not tried that on the recent code base

I made a change that stabilized S3 with multiple strips for me, but we (as a project) just really haven't explored the boundaries much. We had a chap just before the holiday with a large-ish configuration that was blowing up somewhere deep inside FastLED. Maybe we should stabilize and focus on that kind of thing more to get S3 up to first-class citizen status. I'm surprised there are 77 strip effects. :-) Or did you take some of the matrix effects and just glom them into a spectrum-like geometry?

was able to get the Lilygo t-display s3

Usually when I start with an S3 project, that's my starting place, though I don't have one.

could only get 2 channels of led strip working

See if #516 applies to your case.

, here is a txt file of the pins I used

This is the kind of thing I'd like to pull out of the source and into a custom_craigs_build.ini that sets those flags. Maybe we have a directory of contributed custom* files that enables/inspires the kind of zany DIY combos I described earlier. RJL

…

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

[heidepiek]

To the man who can type up a storm. Robert I know when you ask a question it is important that you ask it well. That's probably where I went wrong. Had downloaded a new version of the nightdriver strip to test the fanset. I had some problems with that. Dave changed some things. These alterations were implemented in the main branch this week. So thought I'd give it a try. The fanset works fine now! But when I was nosing around in the platformio.ini file I found this in the code:

[env:spectrum_elecrow]
extends = dev_elecrow_mesmerizer
build_flags = -DSPECTRUM=1
-DSHOW_VU_METER=1
-DELECROW=1
-DUSE_SCREEN=1
-DTFT_WIDTH=320
-DTFT_HEIGHT=480
-DNUM_INFO_PAGES=2
${psram_flags.build_flags}
${remote_flags.build_flags}
${dev_elecrow_mesmerizer.build_flags}
board_build.partitions = config/partitions_custom_8M.csv
board_upload.flash_size = 8MB
board_build.arduino.memory_type = dio_opi ; Without this magic incantation, PSRAM will not work on this board

In an email from you you advised me to buy an esp32 s3. Had to order some things from aliexpress so thought order two of those esp32 s3 boards. So I bravely uploaded the code to an esp32 s3 on Monday and when it booted up and got an ip address I saw it was a spectrum. And not a mesmerizer. So my question was: what device is this example for in the platformio.ini file? Craig answered first, and that best man has an esp32 s3 with an ili9341 screen working. But then the spectrum, and not the mesmerizer! That you linked to the mesmerizer I understand in my questioning. Sorry for the confusion robert! Need to formulate and ask things better first! The pinout I asked craig is for the separate screen, not the LEDs. But for which device is this piece written in the platformio.ini now? I didn't come up with it, it really is in the ini file. So someone must have used it, and would like to know on what device.

Harrie

[prschguy1]

At first glance it looks like your horizontal and vertical resolutions are reversed.CraigSent via the Samsung Galaxy S21 Ultra 5G, an AT&T 5G smartphone -------- Original message --------From: Harke Bosgraaf ***@***.***> Date: 1/17/24 3:39 PM (GMT-05:00) To: PlummersSoftwareLLC/NightDriverStrip ***@***.***> Cc: prschguy1 ***@***.***>, Mention ***@***.***> Subject: Re: [PlummersSoftwareLLC/NightDriverStrip] (dev_elecrow_mesmerizer) For which board is this meant? (Discussion #592) tried it with your pinout. I got this in my screen.h: #if ELECROW // ElecrowScreen // // Display code for the Elecrow display on their 3.5" #define LGFX_USE_V1 #include <U8g2lib.h> // Library for monochrome displays #include <gfxfont.h> // Adafruit GFX font structs #include <Adafruit_GFX.h> // GFX wrapper so we can draw on screen #include <LovyanGFX.hpp> // For the Elecrow display // TFT Pinout #define LCD_MOSI 11 #define LCD_MISO 8 #define LCD_SCK 10 #define LCD_CS 14 #define LCD_RST 13 #define LCD_DC 12 class ElecrowScreen : public Screen, lgfx::LGFX_Device { lgfx::Panel_ILI9341 _panel_instance; lgfx::Bus_SPI _bus_instance; public: ElecrowScreen(int w = 240, int h = 320) : Screen(w, h) { // ... (existing code) { auto cfg = _bus_instance.config(); cfg.spi_host = SPI3_HOST; cfg.spi_mode = 0; cfg.freq_write = 60000000; cfg.freq_read = 16000000; cfg.spi_3wire = true; cfg.use_lock = true; cfg.dma_channel = SPI_DMA_CH_AUTO; cfg.pin_sclk = LCD_SCK; cfg.pin_mosi = LCD_MOSI; cfg.pin_miso = LCD_MISO; cfg.pin_dc = LCD_DC; _bus_instance.config(cfg); _panel_instance.setBus(&_bus_instance); } { auto cfg = _panel_instance.config(); cfg.pin_cs = LCD_CS; cfg.pin_rst = LCD_RST; cfg.pin_busy = -1; cfg.memory_width = h; cfg.memory_height = w; cfg.panel_width = h; cfg.panel_height = w; cfg.offset_x = 0; cfg.offset_y = 0; cfg.offset_rotation = 0; cfg.dummy_read_pixel = 8; cfg.dummy_read_bits = 1; cfg.readable = true; cfg.invert = false; cfg.rgb_order = false; cfg.dlen_16bit = false; cfg.bus_shared = true; _panel_instance.config(cfg); } setPanel(&_panel_instance); constexpr auto LCD_BL = 9; lgfx::LGFX_Device::init(); lgfx::LGFX_Device::setRotation( 1 ); pinMode(LCD_BL, OUTPUT); digitalWrite(LCD_BL, HIGH); lgfx::LGFX_Device::fillScreen(TFT_BLUE); lgfx::LGFX_Device::setTextDatum(lgfx::baseline_left); } I got the spectrum on the screen. But not as expected! How can i change this? https://github.com/PlummersSoftwareLLC/NightDriverStrip/assets/104028471/804d3349-b195-48b9-93b3-8148f99e508b —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[prschguy]

Resolution looks to be off. Must be adjusted in your ini enviroment. Pay attention to the values for heiggt and width.

Craig

[heidepiek]

First to bed, back to it tomorrow night.
Thanks for the feedback 😉

Harrie

[robertlipe]

I answered the question - or tried to - "how do we make [ a board like ] dev_elecrow_mesmerizer (which is an S3 configuration) work?" based on the very first sentences of this thread ... as I'm completely unconvinced it currently does for the reasons I (probably painfully) explained. I now understand the question was *actually* "how do we make *spectrum*_elecrow work?" and the question wasn't about the mesmerizer part at all, but instead the little onboard LCD work with spectrum. So I gave an engineering analysis, battleship-grade answer to what seems now like the wrong question. "We need to blow out this wall, but only after we check the roofline and see if there's embedded gas or plumbing and do weight-bearing analysis in partnership with the engineering and architecture firms and updating the building permits and ...." "Whoa, whoa, whoa. I just wanted to paint this flowerpot." Sorry. RJL

…

On Wed, Jan 17, 2024 at 3:22 PM Harke Bosgraaf ***@***.***> wrote: First to bed, back to it tomorrow night. Thanks for the feedback 😉 Harrie — Reply to this email directly, view it on GitHub <#592 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCSD34CWHQBKKF27MR4HULYPA6KLAVCNFSM6AAAAABB5QTTJCVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DCNRRHE3TO> . You are receiving this because you were mentioned.Message ID: <PlummersSoftwareLLC/NightDriverStrip/repo-discussions/592/comments/8161977 @github.com>

[prschguy]

While the answers you provided were perhaps for the wrong question, the information provided will be quite useful to Harrie and I both. You actually probably saved me atleast a lot of head scratching, so thank you for that. In my opinion if esp32-s3 is to be integrated to any degree, we need to figure out why it is misbehaving here. While i can make all my s3 chips work, they don't work well enough for me to be proud of yet. I have the same display and chip that Harrie described working on another famous led project, and i am not seeing limitations there. So it seems in my opinion there is a difference in the memory or file handling between the 2 platforms. I have some questions I would like to ask, but want to check some things out first.

Craig

[heidepiek]

If robert is on a role he is very informative.

[heidepiek]

Craig, can you send me a copy of your platformio.ini file? So when i get home from work i can compare it with yours. So maybe i can get my hardware to work!

Harrie

[prschguy]

Hello Harrie, unfortunately I am at work, and away from code. From what I can see in your post, I think you just need to put the correct values in for width and height. In the elecrow env section of the ini file change the values there to what match your display. For my display, that is 320 height, and 240 width if i remember correctly.

Craig

[heidepiek]

I'm also at work. But tonight i wil take a look in the platformio.ini file if i can find something of the screen hight and widht. But maybe if you find the time if you Come home you can Send me a copy. Just in case i cant figure it out.

Harrie

[heidepiek]

In the platformio.ini file, I had indeed overlooked something. Adjusted the resolution to fit my little screen. Now it is nicely centered and displays properly. But now the next problem. The spectrum does not respond to the microphone. Use a max4466. The microphone pin on 41. But it only responds when I put the finger on the cable. If I understood correctly you had an inmp441 connected to your configuration craig. How did you do that? Can you give me some info on that as well? Then need a sck pin and a ws pin and sc pin.

https://github.com/PlummersSoftwareLLC/NightDriverStrip/assets/104028471/d03f0cef-86b8-47bc-a3c4-4aceb5fe05e1
harrie

[prschguy]

The bulk of the sound settings for Elecrow can be found hiding in sound analyser.h file. You can try setting your pins there for digital mic. My approach has been a bit different, as I am using a simpler mic, PDM, that uses just 2 pins. The reason I did that is I had no way of knowing if the audio section had ever worked for Elecrow. Intead, my approach uses the same setup as m5stick. M5stack is too complicated as is has speaker function to work around. M5stick setup has been working for lilygo t display, feather, and esp32-s3 builds.

Craig

[heidepiek]

Found this piece of code: #elif ELECROW

    const i2s_config_t i2s_config = {
            .mode = (i2s_mode_t) (I2S_MODE_MASTER | I2S_MODE_RX),
            .sample_rate = SAMPLING_FREQUENCY,
            .bits_per_sample = I2S_BITS_PER_SAMPLE_16BIT,
            .channel_format = I2S_CHANNEL_FMT_ONLY_LEFT,
            .communication_format = I2S_COMM_FORMAT_STAND_I2S,
            .intr_alloc_flags = ESP_INTR_FLAG_LEVEL1,
            .dma_buf_count = 2,
            .dma_buf_len = (int) MAX_SAMPLES,
            .use_apll = false
        };

        // i2s pin configuration
        const i2s_pin_config_t pin_config = {
            .bck_io_num = 39,
            .ws_io_num = 38,
            .data_out_num = -1,  // not used
            .data_in_num = INPUT_PIN
        };

        ESP_ERROR_CHECK( i2s_driver_install(I2S_NUM_0, &i2s_config, 0, NULL) );
        ESP_ERROR_CHECK( i2s_set_pin(I2S_NUM_0, &pin_config) );
        ESP_ERROR_CHECK( i2s_start(I2S_NUM_0) );

Connected the microphone according to the pinout. But have no response to the microphone. It strikes out wildly and does not respond to anything. Maybe someone has a solution. Have used different microphones now. But always with the same result. If I touch pin 41 with my finger or just connect a wire, it starts to go wild.

ili9341_3.2inch_spectrum2.mp4

Harrie

[Thermotronica]

Definitely not used.

[prschguy1]

As I said, I never tried using the Elecrow sound setup. 1 reason being is that I wasn't sure if it has ever worked. The second reason I did not try using it was in the interest of future proofing my build. The 3rd reason is, while I have not published many of my builds, I try to put them together in a way that they will go together with Dave's main branch, rather than conflict with it. The future proofing reason is due to the fact that audio for sure works with M5stick. Reason 2 is, the elders here have stated that no support will be given to audio that wasn't originally included on the original chip. Those are m5stick, and m5stack. As m5stick is a pretty good portion of this build, I know for certain they will keep that working. 1 red flag that came up for me was that there is only 1 pin defined in globals for Elecrow audio. To me that might imply that the chip was capable of analog audio in. From what I read, that is not possible in any quality fashion on s3 chips. Still, might be worth in your case playing with that pin define to get the standard digital mic working. That define is found in globals, line 1477 #define INPUT_PIN (44) . If you want to try my method, I am using the black adafruit PDM mic. While I have tried others, this one seems to match the M5 mics frequency response pretty well.

Craig

[robertlipe]

I swear we have so many false superstitions about S3 in this group... S3 has no DAC <https://esp32.com/viewtopic.php?t=22740> for analog OUTPUT, but it has analog input <https://learn.adafruit.com/adafruit-esp32-s3-feather/analog-input>. That's consistent with the define labeled "INPUT_PIN". But if you want analog out (and don't care much about fidelity), add a low pass filter <https://www.atomic14.com/2024/01/05/esp32-s3-no-pins.html>and boom, you're done. For customizing builds, you should be able to do most anything in a custom ini file. If it's not possible to override something from config.h, we should accept patches to it that allow overrides in custom*ini.

…

On Thu, Jan 18, 2024 at 5:41 PM prschguy1 ***@***.***> wrote: As I said, I never tried using the Elecrow sound setup. 1 reason being is that I wasn't sure if it has ever worked. The second reason I did not try using it was in the interest of future proofing my build. The 3rd reason is, while I have not published many of my builds, I try to put them together in a way that they will go together with Dave's main branch, rather than conflict with it. The future proofing reason is due to the fact that audio for sure works with M5stick. Reason 2 is, the elders here have stated that no support will be given to audio that wasn't originally included on the original chip. Those are m5stick, and m5stack. As m5stick is a pretty good portion of this build, I know for certain they will keep that working. 1 red flag that came up for me was that there is only 1 pin defined in globals for Elecrow audio. To me that might imply that the chip was capable of analog audio in. From what I read, that is not possible in any quality fashion on s3 chips. Still, might be worth in your case playing with that pin define to get the standard digital mic working. That define is found in globals, line 1477 #define INPUT_PIN (44) . If you want to try my method, I am using the black adafruit PDM mic. While I have tried others, this one seems to match the M5 mics frequency response pretty well. Craig Capture2.PNG (view on web) <https://github.com/PlummersSoftwareLLC/NightDriverStrip/assets/69419979/b9c8fb23-9fbe-4fba-bcd7-04ff9f2653ad> — Reply to this email directly, view it on GitHub <#592 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCSD34VUUICE3HA4ZO7BMLYPGXLZAVCNFSM6AAAAABB5QTTJCVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DCNZVGIZDI> . You are receiving this because you were mentioned.Message ID: <PlummersSoftwareLLC/NightDriverStrip/repo-discussions/592/comments/8175224 @github.com>

[prschguy1]

Alight Harrie, seems you have all your answers there. Might as well close down this thread.

Craig

[heidepiek]

I'll just quit this project. Goes over my head. Thanks for always giving us advice and thinking with us robert! But this is beyond my level! Craig, thank you too for helping me out!

Harrie

[prschguy1]

Hello Harrie, there is no good reason for you to quit this project. Like you, I am not a programmer, instead, I tinker. Dave sucked me into this project a long time ago when I saw one of his first videos about spectrum analyzer I'll call version 1. The code was very different back then, but I was able to piece it together and get many of the projects working there. Times change, and so does the code. Rather than let it beat us, instead, we read and learn all that we can. The best advice I can give you here is to not be afraid to try things. Think outside of the box. If you mess up your code base, no big deal, download another copy, or roll back your changes. I have probably a hundred copies of various versions of nightdriver from the beginning. I sometimes look back on those copies to remind me of what I was doing back then. I am here on this project mostly just to learn. If someone comes along like you, I'll help where I can. I am sorry I cut you off the other night. I shouldn't have done that. Unfortunately, Robert had misread what I had typed, and I let his comments get under my skin. It happens, so we'll just move on. I'll include the changes I made to get PDM mic working. You'll see it's really quite simple, and I didn't damage the code base for anyone that comes after. One of the advantages of having this mic is I know for sure the gain control works. I know you might not have that mic, so if I get the time, I'll see if I can get standard digital mic working on the original elecrow build for you. Remember, we are here to learn, and have fun. We have enough stress in our day jobs, so no need for it here.

Craig

pdm.txt

[heidepiek]

Craig, I indeed do not have the adafruit pdm microphone lying around. So I will have to order that one. So will be a while before I get back to this. Am glad you have thought carefully about your response and are reporting that here. I was indeed not amused by this comment:

(Alright Harrie, seems you have all your answers there. Might as well close down this thread)

What I said, we thought about it for a while. And now we just move on. No hard feelings.

Harrie

[rbergen]

I'm just catching up on a few things after a very work-focused week (that's not a complaint, by the way) and without going into the content of the discussion, I just want to say that as the "operational maintainer" of this project, I really appreciate anybody's efforts towards improving the project. Improvements can be at the codebase level, at the level of making that codebase work on formerly untried combinations of devices, in the area of helping others to understand and use it, and the many other ways one can contribute to making at least one other person's life a little better in a way that involves NightDriverStrip.

Personally, I'm particularly happy that there are other people who are diving into the hardware side of things, as I'm much better at working on the software myself. In the context of this discussion @heidepiek, those "other people" explicitly do include you. @robertlipe's contributions I think I don't have to enumerate, as they are objectively numerous and project-wide. And over time, @prschguy1 has also become a regular contributor in a number of ways.
I genuinely appreciate all of your contributions, input and creative thinking, as I do of all the others who do/provide them.

We're all doing this in our own time and we're all humans, so misunderstandings will occur (I've had my fair share myself), and I think we all get a little frustrated from time to time when things don't make sense in whatever way they don't. I would hate to see people disconnect because they feel "underqualified", if that's the right word. We're all figuring this out as we go along, after all. And, in a technology context that changes every single day (and boy, is that true for the hardware and software we're dealing with here!) I truly think that is the only way to go about it.

All that said, @heidepiek, if you've concluded that your journey with NightDriverStrip has come to an end, I will be sad to see you go, but ultimately respect your decision of course. In that case, I do hope we'll do something at some point that'll tickle you back in. :)

[heidepiek]

Sorry guys for the late response, helped my dad mount a tow bar under his car today. Couldn't let that oltimer wrestle with it alone!
Another babylon speech confusion, I meant quit the spectrum-elecrow project. Not nightdriverstrip. Been spending hours trying to get the spectrum-elecrow working with an ili9341 screen. When that succeeded I was still stuck with the microphone not working. Now that two people said the esp32 s3 doesn't work with analog input, I threw in the towel.

( rectification , robert said

S3 has no DAC https://esp32.com/viewtopic.php?t=22740 for analog OUTPUT,
but it has analog input
https://learn.adafruit.com/adafruit-esp32-s3-feather/analog-input. That's
consistent with the define labeled "INPUT_PIN". But if you want analog out
(and don't care much about fidelity), add a low pass filter
<https://www.atomic14.com/2024/01/05/esp32-s3-no-pins.html>and boom, you're
done.)

That went over my head!

But just read that craig responded again with some pointers again.
Want to take a shower and eat first. Rutger, thanks for the pep talk and Wise words! Craig, I'll keep you posted if I manage to get the spectrum-elecrow with screen and mic working.

Have a nice weekend guys.

Greetz harrie

[prschguy1]

Thank you for your words Rutger, you have always been very kind and helpful. As I am still a toddler here, you have always treated me well.

Craig

[Thermotronica]

Data out -.89**Sent from my iPhoneOn Jan 20, 2024, at 07:39, prschguy1 ***@***.***> wrote: Thank you for your words Rutger, you have always been very kind and helpful. As I am still a toddler here, you have always treated me well. Craig —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[prschguy1]

I should probably clarify what I posted to you Robert. I was not saying that the s3 chip did not have adc. What I said was that I had read that the quality of the onboard adc was very low. Yes, I know the s3 has 2 adc's, and the second is used for wifi. What I also read is that people streaming data into adc 1 were seeing huge errors over time. While that could be filtered out, why would I use that if I had a perfectly working digital mic. The answer is, I would not. Even on espressifs own website they offer that the adc is prone to noise, and that some input filtering might be required to limit that. They continue to say that the leads act like antennae and bring more noise in if not pulled to ground. Add to that the reports I have read relating to analog mics suggest that they are prone to producing a lot of power supply interference. So now we have a noisy mic, and a noisy adc. hmmm, think I'll just turn the other way.

Craig

[prschguy1]

Hello Harrie, you used a very interesting word in your response. I suspect you are much more intelligent than you indicate here. Please feel free to message me directly at prschguy1@gmail.com.

[heidepiek]

Craig, is this a valid email adres? prschguy1@gmail.com
Have tried twice now to send you an email, but get this each time: 550 5.1.1 The email account that you tried to reach does not exist.

Harrie

[prschguy1]

Hello Harrie, have spent some time digging into audio on the standard Elecrow build. While I can get the noise out of the system, it still is not working for the standard Elecrow build. As I said, I suspect digital mic never worked there. Think still the PDM mic settings I provided are our best option. Hope you are hanging in there. Don't give up.

Craig

[prschguy1]

Have not used that one in a while. Google might have shut it down. Try the same without the 1 please. CraigSent via the Samsung Galaxy S21 Ultra 5G, an AT&T 5G smartphone -------- Original message --------From: Harke Bosgraaf ***@***.***> Date: 1/24/24 2:21 PM (GMT-05:00) To: PlummersSoftwareLLC/NightDriverStrip ***@***.***> Cc: prschguy1 ***@***.***>, Mention ***@***.***> Subject: Re: [PlummersSoftwareLLC/NightDriverStrip] (dev_elecrow_mesmerizer) For which board is this meant? (Discussion #592) Craig, is this a valid email adres? ***@***.*** Have tried twice now to send you an email, but get this each time: 550 5.1.1 The email account that you tried to reach does not exist. Harrie —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[heidepiek]

Received my new microphone today. An m5Stack PMW Unit - SPM1423 Microphone. Not the same one that craig recommended, but this one I was able to obtain in foreseeable time. And it is also a PDM microphone. With this setup, I have a nice working copy of the spectrum analyzer on an esp s3 clone, and a separate ili9341 screen. To accomplish this, you do need to modify some header files. After some pointers from craig, and many tinker hours, I can show you what I modified. Give no guarantee, of course. But good chance this will work for others too!

Global.h header

Platformio.ini header

screen.h header (backlight pin)

screen.h header (lgfx::Panel_ILI9341 _panel_instance; and pinout)

soundanalyzer.h header (i2s_config_t)

Happy tinkering!

regards
Harrie

https://drive.google.com/file/d/1R8lxAXTDcdRSGIeK1gJkOHP4kgn6G6Ic/view?usp=sharing