I have two ESP32 controllers that continually receive live data that I don’t know where its coming from. On the WLED Web or smartphone UI, I will see the message “WLED is receiving live USB Adalight/TPM2 data”.
This data isn’t consistent in that the message will pop up anywhere from every 60 seconds to 5 mins. When it does come up it will last for anywhere from 1 second to 5 seconds. During the live data, my controller’s lights will turn off, and then back on again when the live data message is no longer displayed on the screen.
I have multiple WLED controllers and these are the only two that are experiencing this. These two controllers have internal IPs of 192.168.86.143 and …145. Of the 16-18 controllers I have, these are the only WLED controllers in the 140 IP range. I’m wondering if there is some other smart device in my home that is trying to broadcast in this IP range. But I’m not sure how to figure this out.
On both of these devices, when the live data dialog appears, I can click on the “Override until reboot” button and the issue goes away. Until I reboot and then it comes back. I’ve gone into settings and turned off any sync options and turned off the “Receive UDP realtime” option. Neither of these helped.
I’d like to know if it’s possible to turn off this feature on these specific boards?
Thanks, this was a hunch of mine as well that I was leaning too. I’m 99% sure the issues are all on my end. Even though I didn’t mention it, I was also getting a flickering on my strip which looked a lot like a strip that needs logic level shifting, even though I had a shifter in use.
These two boards in particular are a custom PCB design of mine. This includes custom firmware (although the firmware has very minor changes). These two boards are the latest version where I added LEDs to the TX and RX lines as a visual indicator when uploading code. I desoldered the LED and resistor on the board’s TX line which solved the problem, kind of.
For more detail, here is what I believe was happening. I’m no electrical engineer, just a hobbyist, so take all of this with a grain of salt. I could be wrong:
THE SETUP:
Custom firmware where I was using Serial.println() for debugging messages.
Custom board with an LED each on the TX and RX lines (led connected to resistor connected to 3.3V).
THE PROBLEM:
I believe the serial print message was sending data down the TX line which went through the LED and then its resistor on the 3.3v line. The TX resistor was very close the to RX’s LED’s resistor, also connected on the 3.3V line. I think sometimes, but not always, the RX line would pick up those serial print messages and interpret them as live data.
On one of the two boards, as mentioned above, I desoldered the TX’s LED and resistor and that seemed to solve the problem. This worked without removing the serial print lines in the firmware. I was able to remove the serial print lines and upload to the other board which still had the LEDs\resistors on both TX and RX lines and so far, so good.
Ultimately, I need to rethink these LEDs. Either remove them completely, or redesign them (maybe incorporate a diode or send them to ground instead of 3.3v).
I believe I’m good for now and the problem is all mine and not what I first thought it was (an external source sending messages).
Crosstalk noise on data lines is often through the power connections, not common that resistors near traces would be the actual issue. I’m not doubting your solution worked, just suggesting there may be another underlying . If you don’t have one in place, I’d recommend a buffer IC to handle driving the LEDs with enough current and keep the signal at TTL levels.
If you’re willing to post the schematic for your setup, we might be able to offer other suggestions.
There are two related symptoms here, both involving two different types of LEDs.
Single PCB LED (603 smd type) on each of the TX and RX line. Whenever a Serial.println() command was called, I believe would send interference that WLED interpreted as Live Data. Removing either the print statement in the code or the LED/resistor from the PCB made the issue go away.
My LED strip (WS2812Bs) was flickering, even though its data line went through a SN74AHCT125, had a 330ohm resistor before the first pixel and had 1000uf of capacitance at the start of the LED strip’s power line. This issue also went away when I removed the print statements in the code.
When you say “not common that resistors near traces would be the actual issue” are you referring to the ws2812 data line? Or the ESP32’s TX/RX lines? The resistors that I mentioned are the TX/RX ones on the 3.3v line.
Here’s the programming section of my schematic if this is helpful:
I understood the effects you were describing, it’s just unlikely (IMO) that there would be any appreciable signal transfer from a ~1.5mA (3.3V/2k2) current through an LED either via the LED or the resistor. There’s just not enough energy involved.
I’m not disputing your reporting of the symptoms and/or your fix, it’s just that the cause your ascribing doesn’t ring true. I’d guess there’s another effect at play here. What else is connected to the TXD/RXD lines?
Understood. Again, I’m a weekend hobbyist who is learning by trial and error. I’m really only guessing here based on symptoms and results. I could be totally wrong and like you said, there is some other issue here.
The only other component is on the RX line, there is a IN4148 diode. It was placed elsewhere on my schematic so it didn’t make it into my screen grab on my last post.
