When you first started describing the problem, my guess was a power problem: if you're powering the neopixels from the board's regulator, you might be getting close to brown out when the WiFi goes to transmit. It's usually better to power the neopixels directly from your 5V power supply (though still be sure it can provide enough current for everything). A downside is that the 3.3V signal with the neopixel data borders on unreliable when the neopixels are powered by 5V. I've heard that using a diode to drop the neopixel supply voltage to 4.4V will make it more reliable for shorter strings (for longer strings, the voltage drops start to affect the color). But then you mentioned memory corruption. That *can* be a power problem (if the RAM doesn't have quite enough power to maintain its state). But that's more likely to be a software bug somewhere. I've got a cheap Chinese ESP32 board using WiFi and neopixels (as a nightlight). It's running the stock WLED software (which I think uses FastLED for the neopixels). That probably doesn't help with your project, sorry. IIRC, FastLED will use the ESP32's I2S hardware to send the neopixel data (instead of bit banging a GPIO), as long as you use the correct pin (I2S is one of the few functions that can't be reassigned to other pins). As for why it finally started working with the RTC code in a separate task, that makes me think there is a timing problem in one of the libraries. Perhaps a library is not disabling interrupts while directly accessing hardware registers. By putting the RTC code into a separate task on the same core as the neopixel stuff, it would make it impossible for both to run concurrently. (But could one interrupt the other? I'd have to explore the task preemption documentation for ESP32's variant of FreeRTOS.)
Yes, software is the cause but exactly what remains to be seen. You mention timing and that is Prime Suspect #1 for me. That and interrupts, which is a sort of timing issue.
Did you update all the libraries/boards? I have many projects that use wifi and neopixes on esp32 (classic, C3, S3). One that I'm working on now is a mp3 player, so it uses SPI to the SD card, I2S and I2C to the audio chip, and then 32 neopixes controlled via a webpage. No issues at all... I'm using Adafruit NeoPixel 1.11.0, and ESP32 2.0.7. I have had issues in the past with various versions of the ESP32 releases, but 2.0.7 seems to be working well for me now. I also have another ESP32/NRF24l01 project that was working for over a year that stopped working when I recompiled it. Ended up fixing it by getting the latest version of RF24. I have my own boards made, but use the ESP32-S (AiThinker), ESP32-Wrover, ESP32-C3-F12, ESP32-C3 mini 1,ESP32_S3 Wroom. Be careful to check the strapping pins on each module. Especially IO12 can trip you up... Also, on the neopixels, I drop down the VCC using a diode so that I can drive the DIN directly from the ESP32. I feel your frustration, when it is something that should be an easy change...
@@RalphBacon I was looking at your files and noticed that the PIR used pin 17 for signal and the RTC_SDA had 17, but was commented out in wifiHelper.h (also commented out in main.cpp). But if you were trying to use 17, that may have been the RTC I2C issue.
GPS receiver - connected via I2C or serial, is also a good way of getting the time. Seems strange to use a GPS when you don't need position information, but it's a good, fairly cheap, way of getting the time (with incredible accuracy) without relying on WiFi, internet connections, etc.
This is a good idea but GPS inst very good indoors however £15-20 for a GPS repeater has helped me in the past, so much so I have left mine on and I get GPas signal indoors, of course the location is fixed to one location of the rx antenna but that's fine for me as the flat isn't very big 😂
Yes, I agree. But the Wi-Fi component of this project was primarily supposed to allow me to communicate with the device (via my phone), send me messages if I had left a bin lid open, AND get the time as a beneficial side-effect!
If you use tasks, my guess would be that neopixels get to use same core as wifi. When wifi gets it's turn, it screws up timing for neopixel routines if it was running on same core but neopixel routines can perhaps interrupt other routines at time they should not be interruptable. I had mysterious problems like crashes with NTP library I used Arduino time library. It had random crashes every now and then if time zone info was given in text format. With numeric time zone differences crashes were gone. Things like these are sometimes beast to solve!
Running gag aside. Your problem does smell kinda brown out related. Had the ESPs (and other microcontrollers) do lots of weird stuff due to it. :) wifi is taking a not insignificant amount of powah
Certainly Wi-Fi takes a considerable amount (for very brief periods) but then I would expect a brown out message in the crash not some weird Heap Memory corruption or some other weird message! The power supply to this device is quite beefy (because of the NeoPixels).
Option. use the 2nd i2c bus instead of of the first for the rtc possibly the nrf module uses i2c inside its library for its data comms and changing the i2c pins causes the module to not be able to communicate
I thought it strange you had problems with Neopixels with wifi since so many have been successful with it. Someone mentioned power, and that could be a factor. I breadboard a project that used wifi for producing a website, measured two temp probes, and would operate a valve depending on temperatures. Also had a small OLED display. I frequently had issues where ESP32 would have a hard time booting. Added caps which helped but still often unstable. When I perfboarded the project I put my caps under the ESP32 socket really close to the ESP power input. Never had a boot problem after that. I did try adding a battery voltage monitor using an ADC pin. Voltage reading was inaccurate and messed up temp readings from the digital temp probes.
Yes, power was certainly a suspect for me but even when driven with mega power supplies it still had the same issues. No, this is software related, I'm certain.
@Ralph S Bacon you can have all the source power you want but if there's enough wire resistance, a sudden draw can cause enough of a sag that the ESP32 can reset or have other issues. Especially on breadboards.
ESP32 is powerful, but often frustrating. It's difficult to understand exactly what's going on inside. Documentation is all over the place and often contradictory, or vague. When a project allows it, you'll usually complete it faster, and enjoy it more, using a simpler 8-bit microcontroller. When your project needs WiFi for some simple task (getting the time or a simple web server), then you can add an ESP8266 or ESP32 to do just that one part. It seems wrong to use an 8-bit processor, with a 32-bit slave coprocessor, but because the project is simpler you save time. Sometimes you can even save power - when the 'coprocessor' is only doing a simple task, it's a lot easier to switch it in and out of sleep mode - or have the main 8-bit processor switch it off/on using a GPIO ouput and a transistor or MOSFET.
Yes, it is tempting to use two devices, but using an ESP32 "just" for Wi-Fi is such a waste (IMHO) when it can do _everything_ I require. Well, if it worked.
Hi, In a previous video you showed how to use a pir to detect presence and disable the display if no one is there for a minute or so. I've used this on a clock I made. This has the advantage of turning on if you venture into the shed in the middle of the night! You could also use an ldr to detect darkness. I appreciate this 'over engineering ' is very educational though.
Spot on, Mike. My World Clock project (a beauty, though I say it myself) does just that. And now my Bin Lid Monitor does too, because the "overnight time detection" was just a nice freebie with the Wi-Fi that I was going to use for web pages. As I can't do that anymore, the overnight switching off of the LEDs might as well be controlled by a $1 PIR device. And so it is!
Hello Ralph, this is the reason why I use the ESP8266. Here I have realized numerous project with WiFi and Neopixel. And all of them work fantastic. A word clock, a binary clock and a controller for my laser cutter. All projects need the current time and control Neopixel. I have made the experience with the ESP32 that here some things still do not run completely smoothly. Especially in connection with WiFi. Greetings Frank
I suspect, Frank, that is I were to ditch the tasks and just run each NeoPixel ring in a time-sliced function (using millis) from the loop( ) it would work. I need to test this theory out.
@@RalphBacon Hello Ralph, yes that could also be a cause/solution. In my projects I have "only" one NeoPixel ring/strip. (with up to 114 Pixel) Maybe this is also a solution for you. Connect the three single rings to one strip. Then there is only one NeoPixel instance. This might be easier to handle. Greetings Frank
SO my version of this is the heltec lora esp32 wouldnt run the nrf2401 and the lora radio at the same time , unless you use tasks . now why any one would want to do this is kinda ridiculous , i wanted to put the heltec on a uav with two different radios in case i flew out of range. I have several solutions to this but this particular case took forever to figure out. It was one of those thing that just kept not working and i should have gave up on but just kept trying anyway did you try to ask ChatGPT why , that thing is incredible
I've asked chatGPT a few things and, yes, it's amazing. Is this the dawn of true "robots" (not the mechanoids, the chatty computers in all Sci-Fi films)? Anyway, sounds like you also stumbled on a similar issue. We will get to the bottom of this.
Just a thought, that may already have occurred to you, neopixels are known for switching current spikes. Changing the layout, even slightly may change how much those spikes affect other stuff, such as the processor running interrupts... Is it worth trying the arrangement that would not work but with some deliberate decoupling of the neo pixels??
Hi Ralph, sounds like library assuming things or using common variable names. I have changed libraries to make things work in the past. NeoPixel have tight timing so did this change the timers on Wire or even Internet. When in a task then only one thing at a time and perhaps the stack and variables have a cleaner environment. I have resorted to RTC as interent seems to have a higher priority on timed outputs, and just update once a day in your case at night. It will easily keep time. I know internet can hog core 1 and core 0 should be independant but I think it must check what each core is doing now and then. One trap is to make sure that the RTC has valid time. Don't just use the status flag as all zeros seem to pass. Also check if year is not 2000 and month is not zero.
That "hey" at the end always makes me bust up laughing. You are never without a challenge, Ralph. Definitely makes life interesting. My father sits in a chair all day watching cable news so consider yourself lucky no matter the challenge. Thanks for sharing your knowledge and time with all of us.
Right on! I've always been interested in "doing stuff" and had a career of doing just that so now I'm (sort of) retired it just gets better because I do the projects I want to do!
I2C is timing sensitive, especially at higher speeds. Task switching can cause the protocol to be violated. The processor core should therefore be locked to the I2C task during data interchange. Using WiFi may aggravate the situation as it, IIRC, operates on only one core of the ESP.
Yes, I agree with that hypothesis. So if my NeoPixels were controlled not by tasks but just from the loop (eg a function called every millisecond or so) it might work. Need to test this.
Poor old Ralph! Don’t chuck the board - just replace the wroom! Weird problem with neopixels but remember you are using Arduino ide and it decides where Wi-Fi and your tasks run unless you tell it differently. I’m guessing that you tried diverting tasks to the other core?
Tried all cores, all variations. The PANIC was sometimes on Core 0 when I am not (specifically) using Core 0 at all, except as a consumer of Wi-Fi which is pinned there.
Had a sketch that ran fine on USB power(4.82v) but went wonky on a separate power supply(5.00v). After may days of tearing my hair out, I padded flash memory with useless data thereby moving the sketch into a new section of memory and now everything works as it should. Bad memory cell???
I don't know if this is relevant but a couple of years ago I tried running three I2C devices (inlcuding that RTC) on an Esp32, Two would run but not all three. I added 330ohm pull-ups to the wires and that solved the problem
Pullup resistor is sometimes required when using more than 1 i2c device on the same bus. But 300 ohms sounds very low. Often the pullups on i2c is about 10Kohm.
Yes, pull-ups are required but often the modules have them built-in. Too many modules means that the SDA line is always being pulled down (lots of resistors in parallel) and they must be removed. Or add a very low resistor like you did to bring it back up again! However, on this project, the ONLY I2C device is the RTC, so no joy there.
@@digihz_data It was several years ago so it may have been more like 10k. Anyway, messing about with electronics is now not possible - age. health and failing eyesight have got in the way. Vicarious pleasure is all that's left....😄
@alan mon sorry to hear that. Well hope you have something else to occupie yourself with.i am 58 years,but still going strong about microcontrollers. :)
@@digihz_data Thanks - I still have my memories of building electronics in the 1960s, programming IBM1130 in Fortran 1970, working with valves, commissioning relay based simple computers, designing a relay controlled switch for my car headlights spots and fogs, designing a ne555 auto wiper for my single speed car wipers, designing a ne555 based charger for my programmable calculator, built two home computers (bare pcbs, trannies, caps resistors etc) from scratch, finding stupid bugs on the first electronic telephone exchanges (single 1 amp fuse failure crashed the exchange, the exchange could not make calls to London).
one more note, most probable reason (wifi failure in combination with neopixels) is.. you are too heavily communicate with neopixels, ie. most of the processor time, interrupts are in disabled state - too often and too long. circulating led is visualy nice, but try something simpler, ex. turn all leds ON, wait second, turn all LEDs OFF.
I have had intermitant problems with WiFi & I2C & SPI as well. With the Arduino 2.0 IDE. After some random number of deepsleep's, I can no longer connect to WiFi. But if I power down my board & wait for about 20s and power it on, it will connect to WiFi just fine. My I2C has a temperature sensor on it. I have a display on my SPI , two buttons and a MOSFET to turn my display on when I need it. It's usually off. I store my temperature log in 500KB of internal flash (SPIFFS). I go into deepsleep every two minutes to minimize self heating and it works fine. The work I do after deepsleep takes about .4s. Your problem sounds like there is a global variable for SDA & SCL in one thread. You might unknowingly be talking the wrong protocol to your I2C devices.
Unfortunately, it's an Adafruit library, plus the nRF24 library, plus the Time library... the list goes on. Who knows what they all do (wrongly) but get away with it, most of the time?
Personally I don't use the neopixel library but I always use the FastLed library which is faster and works way better, try using the FastLed library instead.
Totally not an ESP32 expert but I notice that the NRF24 is an SPI device, and the RTC is I2C. Is it possible that they are trying to use the same hardware module as other microcontrollers do? Or does initialising the RTC try to unmap the default pin assignment whch is messing up the SPI? Changing the order of the initialisation mught help. Howerver there are people here who actually know what they are talking about so I'll leave the rest to them! I think by now I'd have just run a cable from the microswitches on the bin to some LEDs in the workshop :D
why would order of init cause issues? is this a common issue/quirk as on my last project with both spi and i2c i did i2c first, then spi, and i2c failed, doing it 2nd failed also, but commenting out the begin and just accessing it both work!
I suspect there's a grain of truth in what Ian says here. Or that the libraries I'm using are working in isolation but are breaking something (like SPI).
Hi Ralph! For neopixels and anything that requires a tight timing, given that my plan is to use a wifi board to control an LED project, one thing I've thought of doing is having my main program on ESP8266 (or ESP32) and the program controlling the ws2812 LEDs on a dedicated 328P(B) either having the bare arduino as an I2C device or even through serial. Then even if the ESP or whatever completely shuts down to full sleep, the dedicated "processor" would keep controlling the light show. I also wonder - I've found that the WS2812 LEDs once they've been given the show() so long as you're not doing an animation (static colour) they usually keep that without any further updates from the micro controller, so theoretically if you didn't use an animation, that might at least ease the situations in which crashes happen - Just thinking of ideas though I haven't actually played with ws2812 on anything other than the Atmel 8bit micros yet, suppose I've got all that fun to come :D
There's already an Adafruit product (called Seesaw) for offloading the NeoPixel bitbanging to a different microcontroller. It is meant for managing your GPIO tasks while your main microcontroller talks to it via I2C
Hey, Jess, where have you been hiding? Yes, the timing is the thing. I think Adafruit do some naughty things that works mostly but when used in a multitasking environment it makes things go wrong. I shall deffo check out my hypothesis. Yes, I could NOT use animation but that, to me, is the tail wagging the dog. I am the master! Well, apparently not. 😔
@bornach That's interesting - I shall check out Seesaw. It's almost as though Adafruit recognises the issues with bit-banging NeoPixels. learn.adafruit.com/adafruit-seesaw-atsamd09-breakout/overview
Strange... I am using literally hundreds of Neopixel in my atomic firelamp and I control it via a wifi connected Webinterface. It's based off some code from Dave Plummer and uses fastled. It's running day in and day out in my office and I have no issues whatsoever! Strange
But are the NeoPixels running in one or more tasks, or just from the main loop( )? I ask, because I suspect the use of tasks may be relevant here (and you can now confirm) 🙏
@@RalphBacon my comment was deleted by RU-vid probably because it contained a link! It's all in the main loop. Please search for LED-Strip-WS812b-288-ESP32 and you find my github fork. There is a branch called atomic firelamp wifi manager something something. That is the one I mean. Please excuse any messy programming or github housekeeping (or the lack of it). Just doing it for me and ease off use. I hope it helps you to isolate the problem. Dave has expanded the nightdriver library vastly since the examples he posted on RU-vid which I based my variant off. He is on github with it and on YT Daves's Garage
@@arminth NightDriverStrip seems to also be using fastLED instead of Adafruit's NeoPixel library. Is FastLED using HW SPI to communicate with the WS2812B strip by default on ESP32? That might explain why there is lower risk of affecting the timing sensitive WiFi communication
@@arminth FastLED uses a well known SPI-to-NeoPixel hack where you fill a buffer with sequences of zeros and ones of the appropriate length and then send the buffer to the WS2812B data in pin at just the right bitrate to mimic the long and short pulse protocol that addressable LED uses. One scheme is to send a zero bit by putting 3 bits 100 into the SPI buffer; to send a one bit, SPI buffer will have 3 bits 110, and the buffer is then transmitted at 3MHz to the NeoPixel. One advantage of this method over bitbanging is by using dedicated SPI hardware you don't have to disable interrupts which risks messing up other concurrent tasks such as WiFi communication.
You said that your workbench was a mess... I will not show mine. It is not improving in time either. But the way you made this video was different and interesting as it was not like a "narrative" video but one where we see you explaning things. I vote for that!
Yes, just for a change this was a different format, and why not!?! My workbench was tidied up but is now messy again. No, I didn't take a photo of the tidy workbench for evidence 😲
Hey Ralph! Love the videos! I know very little about the ESP32 and when I was trying to build a dual temperature gauge for my RV fridge, I too fell into the group, "Try try again and then give up!" I wanted to use the ESP32 because it had WiFi and dual I2C. I need to run two identical OLED screens that I couldn't change the I2C address. However, I couldn't get the bloody thing to work with the Dallas Temperature probes and the displays at the same time. I went to every website that I could and everyone had an example that worked for them...but not for me! I never figured it out. I concluded that WiFi wasn't that important to the project and went with two Seeed Studios XIAO SAMD21s. Tiny, very powerful, and easy, and I already had them. My disaster with an ESP32 happened when I was first trying to get to know them. I had purchased several screw terminal boards and didn't realize that the pinouts were very different from the 36-pin models and the 38-pin models and also the model for the ESP32-S2. Yes, wouldn't want to put 5-volts on the 3.3 pin! Ah, no explosions...just never worked again. Oh well, grab another one ... NOoooooo. Hahaha, funny now!
Ouch! I feel that moment of despair, James, when you realise exactly what you did. And you also know, instantly, that there is not coming back from that mistake, not without changing the chip, anyway. Oh well, lessons learned. Regarding the two OLED screens, I would have used an I2C multiplexer / extender as that seems to work nicely (and your ESP32 thinks there is only one). Something like a TCA9548A, on which I did a video #148.
Suggestion: why you do not get rid of the nRF24 and use a cheap ESP8266 in your trash bins with ESPNOW and also in in the ESP32 (off course you need to figure out how to use WiFI and ESPNOW in the ESP 32 (probabilly disable ESPNOW during WIFI communication)! For me nRF24 is very sensitive and does not tolerate anything. Bad Humor chip.
If I were redesigning this entire project, I would most certainly use ESP32s in each bin, communicating with ESP-NOW back to the "hub" device. It just seemed like simple idea, at the time. Now I don't want to just throw away perfectly working modules.
or use a raspberry pi pico w, drive neopixel using pio, is the esp32 the access point, probably not if it was getting time from ntp server. was bluetooth used to communicate with the bins ?
I use nRF24L01 modules to communicate with the bins (so some proprietary protocol, I imagine). Yes, I _could_ offload the Wi-Fi (or Neopixels) to some other processor - but I should not have to!
Yes, indeed, Paul. It's still running all the hours I'm in the workshop, although I do hop about stations a bit. Lovely case, works nicely! BTW I now have a 3D printer! I know, I'm as surprised as anyone 😲😂
Great video. Had me laughing a number of times while saying "Yup! I've been there too!" My first ever ESP32 project was polling a device very frequently (~every 300ms ) over WiFi while updating the status on an LED matrix display. Works 100%. Then tried making a variant using an ESP32-C3, which is when the roof caved in. No way could I get that going. That's when I found out about interrupt issue conflicts between the ESP32 WiFi Library and FastLED. Core issue is NeoPixels and the matrix I am using are using the WS2812B LED chipset which uses a clockless protocol over the data line. There are very tight tolerances on that timing which get perturbed with both FastLED and WiFi running on a single core machine. Then found the same issues when porting the project to an ESP32-S3 so that tells me there is something off with the FastLED library on the new silicon. Currently futzing about with ESP-IDF and their WS2812B driver for the RMT peripheral to see where that leads. Anyway, you're not alone in this quest! (Note that FastLED uses the ESP-32 RMT peripheral to drive clockless LED's like the WS2812B/NeoPixel.)
Yes, it seems this problem is quite common, all down to the timing of the NeoPixels. I notice that Adafruit (I think) now have a separate "module" to drive the NeoPixels to avoid this issue. Funny that.
Hi Ralph. I feel your pain. Spent the last 4 days trying to get ePaper displays working again on a project I last looked at in 2021. I think I figured it out last night. Maybe not efficient, but could you have used something like an ATTINY85 to just control the neopixel rings and communicate with it via 2 pins for serial tx/rx? Then you wouldn't have to mess with your wifi time-getting functions and wireless comms with the bins? Maybe I'm adding complication to the situation, but it's a way to offload a relatively simple task of controlling the neopixels to an inexpensive, simple isolated processor.
I've tried the PCBs from several sources (as a paying customer) and these ones are excellent, and pretty quick to deliver too (highly dependant on the method used and the attitude of the delivery driver 😁)
My phone mirrors the video so my left is shown to me as my left (even though it's my right) otherwise it is very odd to video oneself. The downside is that everything (including text) is mirrored too, of course.
Most JTAG/emulators have a register comparison / recording function. Do a register dump and compare the working with the non-working. I find that trick so useful, I have scripts that gather the data, compare it, and tell me the differences. So may times the tool has illuminated the register or bit(s) that aren't being set correctly.
Good idea. What worries me is the code that is failing is the Adafruit NeoPixel code (probably timing issue... or something) so not as useful to me as it would be otherwise.
Yet Wled uses an esp32 with wifi and can drive multiple led strips whilst doing many other things with no problem including html web pages. However they use freeRTOS for network tasks and fastled to drive the Neopixels
First of all I would not use the default i2c pins for anything but i2c. Secondly...are you using fastled library for the neopixels or some other library? And what library are you using for the nrf20?
I'm using the "adafruit/Adafruit Neopixel" library and "nrf24/RF24" for the guess what. But using the I2C pins as general purpose IO pins or SPI pins should not cause an issue.
Well Ralph. I think you could make that project work (even without tasks). Fastled v3.4.0 for the neopixels with a resistor about 330 or 470 ohm on each data line. And if you used other pins than the default i2c pins on the nrf24. And default i2c pins for the clock. But I understand...you already have the pcb wired up the way you choose from the beginning.
I can always change the software (eg use FastLED if that is the answer). Or not use tasks, if they are causing issues (or being impacted by context switching interrupts). But as you say, I don't want to change the hardware (not the PCB, anyway).
You could try putting the NeoPixel rings in series and just running them from one task. They would be fed by values in an array appropriate to the length of the series connected rings, and you just update one third of the array for each ring.
Well, I could but (a) I shouldn't have to, tail wagging the dog and all that, and (b) I'm not convinced it would necessarily help. But when I found out what it was I shall let you know!
It sounds like the Asian Bird flu has migrated to humans syndrome. In your case it's a Bill Gates Windows bug migrating to the ESP32 platform. Everytime Microsoft fixes something or adds something they manage to break something that was running perfectly fine.
I'm using PowerToys on my PC and they keep breaking "Fancy Zones" which is very useful but not when it puts the windows on the wrong screen every time I unlock my PC. 😡
I'm using Makuna's NeoPixelBus and have no issues with WiFi on the ESP32 (but I'm using a ws2812 LED strip, not a NeoPixel ring). I use separate tasks for WiFi and LED control
Commenting for the algorithm mostly... Would a simpler solution have been to use an LDR to detect when the lights in your workshop are on - so your code would only fire up the bin LEDs when you are in there tinkering?
It would. And about an hour after doing this video, I ripped out the RTC (and code) and did just that! I knew that would work because I do it for my World Clock project (the long 0.9m length of LED matrix using MAX7219 chips). And yes, that is even more efficient because the lights go off even over lunch!
This would be a good idea too. 20 minute intervals is crazy frequent. Once a day is a a good deal better or even once a week, the RTC will do the rest very accurately. Heck a good approach is to say check NTP once when the RTC reports the time to 12:00 or something, adjust if needed then add a condition to prevent it trying to check again if the RTC time was wrong by a negative time, preventing NTP being spammed. If NTP is loaded too heavily it can have a noticeable effect of services that need NTC time to be accurate such as financial services, alarms and online security tools because the latency added to the reported time increases.
No that's fine. It's not the NTP that's the problem (I don't check every 20 minutes, I check the time from the ESP32 quite often, but that in turn doesn't synchronise its internal clock with an NTP very often).
I would chain the leds together, you can sort out which ones to turn on and off in the chain in software. I think your issue is related to interrupts and timers as everything you mentioned uses one or both. I am sure it can be made to work but without having one in front of me exactly like your I can't comment more on the issue. Look into which devices are using which timers and which are using the interrupts. I am sure you have more than one connected to the same timer or interrupt. It may be as simple as changing pins, or as complex as doing your own timing for something like the timings needed to talk to the led. But I can almost with certainly tell you the communications issues are related to timers and interrupts.
I would have used a LDR to detect light in your room and only show the Neopixels when the LDR is in certain ranges. I have also had issues with the Neopixel library and interrupts on Pro Minis.
As it happens, we're thinking along the same lines. I'm using a mini PIR that detects movement. Absence of movement for 15 minutes switches off the NeoPixels. And yes, interrupts are probably to blame somehow.
Very interested to see if you come across a root cause of this problem. Actually a bit surprised about your problems with the neopixels, since (as mentioned by others as well) they work so easy on a ESP8266 with WLED installed.
Sounds complicated Ralph. My initial thoughts are 'I wouldn't start from here' 🙂. I would have used ESP-Now. I'm assuming that there are some sort of ESP boards in the bins doing the monitoring. Each of the bins broadcasts a structure, the same for each board. In the structure I would use 3 integer variables. If, say board 1 (in bin 1) is open it sends a number greater than 100 in position one of the structure. If board 2 (bin2) is open it sends a number greater than 100 in position 2 of the structure. A similar system for bin 3. Obviously, an integer less than 100 is an indication that the bin is closed. Inside the workshop there is the ESP32 which is receiving the broadcasts from the bin boards over ESP-Now. Its sole task is to get the time, monitor the broadcasts from the bins and to set a relevant pin high or low to switch on/off the appropriate neopixels to the desired state. No NRF wifi shenanigans, no pins used. What do you think?
I wouldn't disagree with you, Hari. If I were designing the project _today_ I would use ESP-NOW with some ESP32s (even 8266s) in the bins to send the code. Also, you can make the ESP32 sleep for as long as you want, not just 8 seconds like the ATMega328p. Unfortunately for me, that is all water under the bridge. I designed the ATMega328p / nRF24L01 circuit because it was quick and easy (I have experience of these). Since then, I've acquired experience of ESP-NOW and use that with my three temperature sensors scattered about my house - but too late for this particular project! No, I'm not going to start again!
@@RalphBacon I am just in the process of learing about Blynk. Never bothered in the past, but with your bin system on an ESP_Now system, you could check the state of the bins whilst out shopping via blink. I'm building a greenhouse sensor system.
Does it have to do with a fact that esp32 wifi uses and reserves ADC2 for its operation? Try using ADC1 instead when using wifi. I wonder if it could be the cause.
Certainly we can't use ADC2 pins when Wi-Fi is being used; I can't remember which pins I used (this project went to the great breadboard in the sky last year).
Ran into a similar problem with malfunctioning WS2812B (NeoPixel) LED's when moving a project to an ESP32-S3 whilst using WiFi. Long story short, that--and inspired by your "Create a Library" video--led to porting the led_strip driver from the esp-idf-library to an Arduino library. It's available now using the Arduino IDE Library Manager. Search for "LiteLED".
i really have to thank you. you can't imagine how much your comment helped me. i was just going crazy because my whole project was ruined because of that NeoPixel library. i have spent two days searching and just changing my code all in vain. thank you so much..
Before you pay for the burial of your ESP, can we group dig as I have a 3v3 regulator which didn't like 13V apparently and 2 high end audio TosLink boards which (also 3.3V) have died in unexplained ways. Its not been a good week. "Bring out your dead!"
Adafruit's NeoPixel library is quite timing sensitive (and last I checked disabled interrupts), but there are a few other libraries available which work better. I personally use FastLED without issue, and it uses the SPI peripheral rather than bitbanging (but you have to use an SPI capable pin).. I wonder whether it was the ESP32 itself or just the 3v3 regulator that died? The ESP32 will have an internal voltage regulator down to say 1.8V for the internal logic, and that might survive a short time with a 5V input.
I think that the ESP32 can use most pins for SPI (it's very flexible, but just _how_ flexible I have not tested) so I might try the FastLED library, thanks. And I will check the regulator and other bits before I discard anything!
I to had problems when using wifi on esp32-Cam together with neopixels and mcp23017 port expander. as soon as wifi were being used strange things happend. I finally figured out that my pull up resistors to the SDA and SCL (for the mcp23017) was to big. I started with 10Kohm pullup resistors...When i changed the pullup resistors to 4.7Kohm everything worked together. (No code for tasks or cores needed.)
Hi Ralph, when all’s said and done it’s kinda reassuring to know that someone with your years of experience can still make schoolboy errors like connecting 5V to the 3V3 pin 🤪
I had the DuPont cable in my hand. The RTC was dangling ready for connection. I connected one end of the Dupont to the 5v. Then for some some reason connected the other end instead of to the RTC, to the 3v3. I was distracted (that's my excuse and I'm sticking to it). 😢
Hi Ralph, I have just got into Esp 32. I have tried to connect a PS3 contoller and found it mine field as there are multiple versions of the library, and some are broken. I followed another youtube about it, and it looked straightforward.
Oh, it _always_ looks straightforward. "Look what I made", is the mantra of RU-vidrs the world over. What they don't tell you (but I do) is the shenanigans they had to get it working!
Not sure why you need wifi and internet connectivity for this project. Am I missing something? Seems ESP32 is overkill for this. I have extensive use of nrf24 and rtc connected to Mega, Nano, and some with addressable leds. No problems....but I use SPI for nrf24. I found that nrf24 libraries with I2C capabilities erratic with I2C connection. Set the RTC time while programming and connected to the IDE, it will be accurate as long as the coin cell lasts or there is no power interruption.
Well, you've sort of missed something, but mainly because I haven't explicitly mentioned it yet. 😮 As you know, most of my ESP32 projects have a web interface so my phone (or other browser) can connect and read info or even make the device "do stuff" without me being present. So having Wi-Fi is required and getting the time is then almost a beneficial side-effect. But now it's not, so I am still investigating.
You make a lot of copies of the Adafruit_NeoPixel objects, that is at least very inefficient. For the array building it just wastes space, for the initialization, I think it's strange that it works at all. Better use pointers or references. The frequency of the NRF channel 124 would be illegal here in Germany, check your local regulations. Your NRF structs need explicit packing to be compatible between ESP32 and 8-bit Arduinos.
We don't want to use pointers in C++, right? 😮 I don't make _copies_ of the Adafruit objects, I'm creating 3 objects of the Adafruit class, so each object only deals with its own NeoPixel ring. Sounds ideal to me. It generally works fine, but trying to use WiFi with it obviously has an issue. I'll sort it out one day!
Hi Ralph, I have one question, why is some of your video showing backwards, e.g. the writting on your draws are back to front and the time scrolling is backwards? Love your videos, I'm make lots of ESP32 projects keep up the great work
That's because I was filming some segments of the video with my front facing phone camera, and I've mirrored the phone output to make it easier for me to show left and right - the downside of this is that the recorded output is like a mirror, which I didn't think to correct in the editing stage 🤦
Interesting, I got into ESP because of driving pixels. I've got projects ruining 100s of pixels while connected to WiFi, ESP mesh, Artnet, and trust me I'm not a very good programmer! Would be interesting to see the code 🤔
Probably in the GitHub for video #214 ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-P4Em7H0vtsU.html but it was updated in video #221 ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-eLnfiYkxCQ4.html so might be there.
Right you have intrigued me. I'm up to my eyes in trying to learn how to write Android apps at the moment funny enough for pixel project, but when I have time I'm going to have a play (ps love the channel)
I find the ESP32 suffers from crap frameworks. You have the Espressif IDF (of various incompatible flavours/versions). On top of that, like literally grafted and hot glued on top you have the Arduino framework. But that's not enough. AdaFruit have got involved. Their libraries are isane. I work in Enterprise software engineering and it's rare I would see something that simple made that complicated. It is only beginner friend if it works. FACT. When it doesn't work, this stack of frameworks piled on top of each other are NOT, repeat NOT written for beginners. A lot of them, particularly the AdaFruit libraries are more C++ over engineering and mast-or-bation and "flexing". If you have to lift the covers and try and understand how all that works.... it's not going to be any fun. Even as an experienced software engineer I have dumped and ran away from Adafruit libraries because they are not worth the time and effort you will waste on them when they don't work.
That may work, but it's still a workaround for something should "just work". As it happens, life events have overtaken this entire issue, more of which in a future video!
@@RalphBacon Yes, not the totally understanding solution, but a workaround for a frustrating situation. Lately I've been working with the Pico W and have had less frustration than from the ESPs. The level of documentation is amazing especially for such a new module and the software is coming along nicely. Dual cores are useful to handle chores that benefit from true parallelism. I made a networked self setting clock using Pico W and Max7219 8x32 matrix LED a couple days ago and it worked so quickly it was amazing. Five wires, Pico, Max and a 3d printed case, even a 3d printed filter for the LEDs. About a hundred lines of MicroPython and done. Enjoy! :)
@@RalphBacon Why not do it sequentially? Tasks wil be randomly interrupted outside your control. Interruption = glitch. See "BinClock_WS2812.ino" on git example.
If the NeoPixels were just jumping about and displaying the wrong colours and so on, I'd be certain it was just timing (interrupts). But the fact is crashes (sometimes on Core 0) just bemuses me what is going on!
Hi Ralf. I had a peek into your code and found a possible error. Within some Header files you declare some *variables* as *static* storage type. This means that on every Module that includes this particular header these Values will become a *new* instance / storage in memory! These are *not* shared and treat as one variable! Or in other words the Variable what you have declared as static has *not* the one and only storage! And this is surely not what you intended with the static declaration! What you really want is a *global* variable with *one* storage in memory*. So then just do so. *Declare* the variable in the header as extern (*not* static!) and *define* it in a Compile Unit (.c / .cpp file) where the compiler / linker then will assign to its actual storage (memory) to. and this one then is *really* unique! As a rule of thumb: *NEVER* declare *variables* within Headers as *static* storage type that you want to be *unique* / *share* within several modules within your code. If you do so you'll run in serious trouble... ;-) If you need a snippet which demonstrates my concerns, don't hesitate to drop me a note here in the comments. ;)
I'm wondering if the static variables are for the tasks where I want each "instance" of the task to have its own set of variables... but until I check I won't know. I will check this all out this afternoon. Thank you very much for reviewing my code, I need that more often! 👍
@@RalphBacon Well, a Realtime OS just partitions your System Stack (which is defined by your Linker Script) that way that every Task has its own piece of this System Stack as defined in the Task- Parameters. The Task scheduler then takes care to restore the CPUs stack pointer to each assigned stack frame. However static Variables will *never* be located on the stack - disregard if your program runs on a Realtime OS. Static vars are located on the (global) *heap* memory space. See stack memory has to be treat as valid within a functions scope only. Hence one should *never* return a pointer (or C++ reference) to a local variable because upon return this memory has treat to be invalid. But this an different story… 😉 Well I n this matter you did it right to use a global variable in order to share some data between Tasks but take care about *static* vars, because these are technically stored on the global heap (what you want) *but* there may be multiple of them (different memory locations) as *defined* in *each* compilation unit! This multiple presence is not a problem because static vars are not exported by the linked. So long story short: For sharing Data between Tasks *never* use static vars rather than _real_ global ones which guarantees the one and only storage in memory. Or better - use the OS capabilities to exchange data between tasks such as Message Boxes or global storage in combination with Semaphores / Mutex in order to perform the access _atomically_ …
And welcome back to the comments for me, sorry but someone said the I have copied you by saying "welcome back" at the start of my video. :-) I use my own driver to bit bang the WS2812B's with no problems with WiFi as yet. Its just another bit of code that runs in a task. Use it esp8266 and exp32.
I say that imitation is the sincerest form of flattery! If I disable (do not start) the NeoPixel tasks, the Wi-Fi runs as it should. It's something (like timing) do with NeoPixel control, running in a task. I'll find out what it is and then send hate mail to Adafruit for causing me all this hassle! (Just kidding, I quite like Adafruit products and code).
@@RalphBaconI suppose it also depends on how often you are updating the LED’s as the number of LED in your rings should update in no time at all. then you think the longest pulse is the reset at >= 50us. But I would suggest putting the rings in series and only having one LED driver routine to worry about. And work out how often you need to update them, so if you’re flashing them at 1 second intervals it should give the WiFi plenty of time to do what it needs to do. I expect that the library is using some form of blocking code to get the timings right and this is stopping the Wifi thread running at the correct interval. Causing the Wifi to drop out etc. But if your on dual cores this should not be a problem. So it could be a hardware issue, some shared resource getting held for too long. Bit bang your own driver so it’s running on your core and directly accessing the I/O should get around the issue. For low numbers of LED’s you don’t need DMA to do it.
Recorded using my phone which mirrors 😲 the image. I tried it un-mirrored but then left is right and vice versa. Next time I'll use my usual video camera.
Face it Ralph, your whole series of projects are to fix 1st world "problems" 🥲 I suspect the required and ridiculously tight timing of the Neo Pixels is at the core of the issue.