Open to PR?

[GeorgeHahn]

Hi bbx10,

I've modified this code to add interrupt driven frame display, buffering, and support for receiving multiple frames in a single packet. Using these modifications, I am able to achieve upwards of 30fps on 480 LED strands.

I would love to contribute these changes back to your project. Unfortunately, I've made some pretty broad changes to the code, so a PR will be pretty messy. If it's alright by you, I'll create a PR and then we can chat about how to clean up and merge the changes in. There's still a bug or two in the buffering code that results in some pretty nasty jitter. I suspect this is due to an uncaught buffer overrun, but I haven't had the chance to investigate further.

Cheers,
George

[shootdaj]

@GeorgeHahn Could you point me to the location of your repository? I would like to use it as I want to run some very hi bandwidth algorithms against a lot of LEDs. Thanks.

[GeorgeHahn]

I've uploaded my changes to a gist here: https://gist.github.com/GeorgeHahn/7adecc9bc960ba16a741330fd323c0a2

Note that I had issues with OPC's use of TCP: somewhere in the ESP8266's TCP stack there is a buffer that grows until the device runs out of memory and crashes. At 30FPS this happens pretty quickly. For this reason, I modified OPC to use UDP packets.

Some notes: The buffers can be shrunk by quite a bit. Three or four frames should be fine. Right now, rendering happens at 30FPS. This should be tweaked. There are two goals: consistent playback (eliminate jitter by playing frames at their average rate of arrival) and ability to set color by sending a single frame. These two use cases are easy to recognize and the timer interrupt should be modified to do this.

If you think you will use this code without making huge modifications, please let me know and I'll set up a proper repo so we can collaborate.

[shootdaj]

@GeorgeHahn I will give this a try soon and get back to you. My goal is to use this as a starting point for an efficient and long-running algorithm that can run without hiccups for months at a time. For me, UDP would suffice as I don't need guaranteed delivery but yes the buffer overflow issues would be a problem. My question is: since Websockets are a TCP technology, did you just bypass Websockets altogether? Or did you do something else? Thanks.

[GeorgeHahn]

I don't use websockets at all - I was using raw TCP sockets and then switched to UDP. I send data to these devices using a variety of languages, but always using direct socket access.

[shootdaj]

Oh was the original code also using direct socket access and not Websockets? I had just assumed it was Websockets. In any case, I would like to work on this as an ongoing project. Do you think you could setup a new repo so we can collaborate?

[GeorgeHahn]

Sure. See here: https://github.com/GeorgeHahn/espopc2/

[shootdaj]

Thank you. I'll post any follow ups there.

[alexmizell]

y'all,

i'm also doing large scale LED matrix work, and i'm watching this thread closely. i've made george's code work with UDP datagrams of OPC-formatted data but i also observe frequent buffer under and overrun issues. it feels like if i had more memory for frame buffers then perhaps i could smooth it out better, but i can't get more than about 35 with available memory on a WeMos board. if anybody solves this, please let me know, or else i will try to contribute a solution myself. i'm sure there is some best practice method of handling video buffering in a UDP situation (or could we find a stop-gap solution to ESP's TCP stack crash and use TCP after all?)

anyway, thank you all for your contributions to this hub.

alex

[alexmizell]

y'all,

i'm not a pro develeoper, but after looking into this code carefully it's my sense that the interrupt timing is squirelly. a continuous ping to the ESP while sending OPC data to it shows periodic spikes in latency after every 5 to 10 seconds of video, and at those same moments the video gets choppy and you log a long string of frame buffer underruns.

i think it's probably not kosher to run a non-async network call in the middle of a frame timer interrupt like that because there's no way to guarantee that you'll come back from the UDPClient.read() or the pixel shifting routines before it's time for your next frame. i'm not sure why this doesn't cause a total lockup, maybe i'm diagnosing wrong, but the fact is the timing is not working here and the fix will be closer to a total-rewrite of the routine than a quick adjustment. i do believe that the ESP has enough horsepower to send several hundred pixels' worth of data at 30 FPS, but the timing would need to be managed more carefully than it is here.

so, not to disrespect this git but in the end it seemed easier to abandon OPC protocol altogether and flee to E1.31 (sACN) protocol which does exactly the same thing but better.

An E1.31 packet sender for .Net (my client is Windows native)
https://github.com/iKadmium/kadmium-sacn

ESPixelStick is for E1.31 what I hoped this project would be to OPC:
http://forkineye.com/espixelstick/

Thanks and good luck in your endeavors,
Alex

[alexmizell]

btw here is a "before" post with video examples of the results. the first example with long pauses in the video playback is the BBX10/ESPOPC on a Wemos D1 board, the second example where i (incorrectly) say i fixed the jitter is George Hahn's code - better but ultimately it was unstable as well.

https://www.facebook.com/photo.php?fbid=10154585763203017&set=a.144728373016.110480.520133016&type=3

and here is "after" with E1.31 and espixelstick firmware on the same Wemos board

https://www.facebook.com/alex.mizell.3/videos/10154612789518017/

[GeorgeHahn]

Hi! Happy to have someone else looking at this code. Unfortunately I think this repo is dead. If you wouldn't mind making an issue over on my repository, I'd be happy to discuss further. There shouldn't be any networking code in the interrupt, is that in my code? Thoughts: - we can definitely run with fewer buffers - playback rate needs to sync to receive rate or overruns will continue to happen - the code could use a lot of love Thanks again! Sent from Outlook for Android