search

AronHetLam / ATEM_tally_light_with_ESP8266

Wireless tally light for use with ATEM switchers, which connects over WiFi, using an ESP WiFi module.
GNU General Public License v3.0
158 stars 39 forks source link

LED bar status error #49

Closed falcaobh closed 3 years ago

falcaobh commented 3 years ago

How do I use the Ws2812 5050 led bar working the same as LED1?

When I select none for the LED bar in the settings, the first LED plays the status role and the others show the Atem program or preview.

Regardless of choosing first or last LED for status, the led bar always shows the first one as status. How to solve this? I really appreciate your attention and help.

01 02 03

AronHetLam commented 3 years ago

Seems something else is going on in your pictures as the first LED changes color based on the camera state - as far as I can tell. If it was running as the status LED it would be (dimmed) orange no matter the camera state, as long as it's connected to the switcher. I assume you've modified the code since you have a screen on there. Maybe something's interfering? Also, does it work as expected when you actually select either the last or first LED as status LED?

I don't have Neopixels myself to test with, but by printing the LED colors to the serial monitor after every update made to it, it all looks good to me. You can enable the debug info by removing the two slashes in front of this line https://github.com/AronHetLam/ATEM_tally_light_with_ESP8266/blob/2d6ff1e83375210c36f885ae25e1df034aeeaf60/ATEM_tally_light/ATEM_tally_light.ino#L21

That'll make it print the RGB values for each LED after each update like this (example with 8 LEDs and last LED as status LED):

[... startup print cut out ...]
Status: 
0, RGB: 0, 0, 0
1, RGB: 0, 0, 0
2, RGB: 0, 0, 0
3, RGB: 0, 0, 0
4, RGB: 0, 0, 0
5, RGB: 0, 0, 0
6, RGB: 0, 0, 0
7, RGB: 255, 0, 255 [... Status LED pink while connecting ...]

Updated LEDs
------------------------
Connecting to switcher...
Switcher IP:         192.168.1.50
Status: 
0, RGB: 0, 0, 0
1, RGB: 0, 0, 0
2, RGB: 0, 0, 0
3, RGB: 0, 0, 0
4, RGB: 0, 0, 0
5, RGB: 0, 0, 0
6, RGB: 0, 0, 0
7, RGB: 25, 16, 0 [... Status LED dimm orange when connected ...]

Connected to switcher
Updated LEDs
Tally:  
0, RGB: 255, 0, 0
1, RGB: 255, 0, 0
2, RGB: 255, 0, 0
3, RGB: 255, 0, 0
4, RGB: 255, 0, 0
5, RGB: 255, 0, 0
6, RGB: 255, 0, 0
7, RGB: 25, 16, 0

Updated LEDs
Tally:  
0, RGB: 0, 255, 0
1, RGB: 0, 255, 0
2, RGB: 0, 255, 0
3, RGB: 0, 255, 0
4, RGB: 0, 255, 0
5, RGB: 0, 255, 0
6, RGB: 0, 255, 0
7, RGB: 25, 16, 0
paduino commented 3 years ago

I have the same error. Have you been able to find a solution? I didn't changed anything on the code. For me, the red part of the first pixel is light up. This means that when the status is preview (i.e. green), the first pixel lights up yellow (since the red part is still lighted). I have tried different pieces of LED tape. Everywhere the same error. The pixels work correctly with any other simple code.

paduino commented 3 years ago

Yay, I found the solution. In the BoardManager version 2.7.5 from esp8266 must be installed. The latest version 3.0.2 causes the bug. #@(https://github.com/FastLED/FastLED/issues/1260#issuecomment-895514462)

For all MacOSX BigSur users an extra hint. You have to do the following, otherwise the upload will not work.

Quote from User k2r79 of the esp8266 forum (https://www.esp8266.com/viewtopic.php?p=89446)

  1. Download https://github.com/espressif/esptool/archive/v3.0.zip
  2. Download https://github.com/pyserial/pyserial/archive/v3.4.zip
  3. Extract the contents to esptool/ and pyserial/ in the ~/Library/Arduino15/packages/esp8266/hardware/esp8266/2.7.4/tools/ folder (an equivalent must exist on Windows)
AronHetLam commented 3 years ago

Thanks @paduino for looking into it. With your description that would have been one of the places I'd look for the problem too. This is not the only problem v3 of the board manager has caused.. 😉 I'll update the guide at some point, specifying which version to download. 🙂

AronHetLam commented 3 years ago

What I don't understand is why it worked for you with simple examples, and not with the tally code. Any idea on why that's the case @paduino?

paduino commented 3 years ago

What I don't understand is why it worked for you with simple examples, and not with the tally code. Any idea on why that's the case @paduino?

Unfortunately, I don't have a solution for that yet. I had only found out that with the code below, the pixel then shines green instead of red.

#ifdef ESP8266
#define FASTLED_ALLOW_INTERRUPTS 0
#define FASTLED_INTERRUPT_RETRY_COUNT 1
#endif

And if you increase the CPU frequency to 160 MHz, the first pixel is completely off.

AronHetLam commented 3 years ago

As FastLED bitbangs the output on the esp8266 I think the CPU frequency increase would make the timings too fast for the LED controller to handle. (I guess it's the same with v2.7.5)

Since you're able to change the colour by changeing FastLed interrupt values it seems pretty likely that v3 in the board manager has changed something in how interrupts are handled, interfering in the first color being sent out. Not sure if that's a bug to report to FastLed or the esp8266 board manager's repo.

A led strip and an oscilloscope had been handy now.

AronHetLam commented 3 years ago

According to https://github.com/esp8266/Arduino/issues/8054#issuecomment-846471680 your simple examples probably worked since they didn't use WiFi.