Page 1 of 2 12 LastLast
Results 1 to 10 of 14

Thread: esp32 and Shelby's e131 test.ino

  1. #1
    Join Date
    Dec 2011
    Posts
    6,226
    Post Thanks / Like

    Default esp32 and Shelby's e131 test.ino

    Is there anyone currently experimenting with this ?

    I recently received one of these dev boards and just loaded this sketch .
    Unfortunately Shelby's code appears written in ROMAN ! . lol

    Is it now viable to assign the Universe directly to the pin as follows ?

    e131[1]assign(Pin 3, OUTPUT); // assign to pin 3 (GPIO 3) or similar

    Also , how are channels exposed ?
    I see the channels as packet.property_values[513]
    but what is this >>
    htons(packet.property_value_count) - 1
    Last edited by angus40; 01-03-2020 at 02:29 AM.

  2. #2
    Join Date
    Dec 2011
    Posts
    6,226
    Post Thanks / Like

    Default Re: esp32 and Shelby's e131 test.ino

    No One ?

    Thanks for your e131 test.ino worked great for seeing the data in monitor .

    For functionality I discovered the Wled firmware ,which employs your e131 wares .
    A treat to see pixels via the esp32

    I hope you extend on the esp32 with some examples as it would be great to add/build on as are enabled with your prior esp8266 neo- pixel example .

  3. #3
    Join Date
    Dec 2012
    Location
    Newtown CT
    Posts
    4,130
    Post Thanks / Like

    Default Re: esp32 and Shelby's e131 test.ino

    htons converts a 16 bit integer from host representation to network representation. This is an endianes correction operation that should be done any time you are sending a two byte data object via Ethernet. There are 32 and 64 bit versions of this function as well. The functions are null operation on systems where the host and Ethernet use the same endinanes.


    2020 Full sized show reworked for the new location. Only adding (famous last words) 13 RBLs that I finally got converted to using pixels
    2019 - Just moved into a new home (yet another change of plans). Will be dim but not dark. Too much to do at the new place to leave time for a show. Dim show (3000 pixels) had regular visits most nights.
    https://www.youtube.com/channel/UCyX...ttrsZNARkUce0Q

  4. #4
    Join Date
    Aug 2012
    Location
    Charleston, SC
    Posts
    1,099
    Post Thanks / Like

    Default Re: esp32 and Shelby's e131 test.ino

    I've yet to attempt doing any pixels on an esp32. I just added support for the library and verified the test sketch worked. Someone did submit an issue with it on the ESP32, but they never verified what exactly the issue was or if it was with their code so I closed it. Please add some details here if you experience anything similar and let us know how it goes! https://github.com/forkineye/ESPAsyncE131/issues/8
    -shelby
    [url=http://www.youtube.com/playlist?list=PLY6l3Fd1SM8viL-Q76DVHtjltwR6XbOc7]2014 Christmas Videos[/url] - [url=http://diychristmas.org/vb1/showthread.php?3261-Candlewick-Lights-2014-video-and-details]Write Up[/url]
    [url=http://www.youtube.com/playlist?list=PLY6l3Fd1SM8sTEvf6hIhPJX9rWgfbSmRX]2013 Halloween Videos[/url]

    [URL="http://diychristmas.org/vb1/showthread.php?1255-Generic-Dongle-HSXP-2108G&p=15008&viewfull=1#post15008"][COLOR="#FF0000"]Warning on cheap USB RS485 dongles - You get what you pay for...[/COLOR][/URL]

    [URL="https://github.com/forkineye"]My GitHub Stuff[/URL] | [URL="http://kw4fb.com"]My Ham Radio Stuff[/URL] | [url]http://forkineye.com[/url]

  5. #5
    Join Date
    Dec 2011
    Posts
    6,226
    Post Thanks / Like

    Default Re: esp32 and Shelby's e131 test.ino

    Thanks Martin for the explanation .

    From what little I have been able to source in regards to the esp32 and e1.31 it appears that folks are not using the espAsynce131 lib..

    I have noted this being done as a work around , though I have not figured out how to get it to work yet !



    Code:
    #ifndef E131_H_
    #define E131_H_
    
    #include "Arduino.h"
    
    /* Network interface detection.  WiFi for ESP8266 and Ethernet for AVR */
    
    #if defined (ESP32) || defined (ESP8266)
    #ifdef defined (ESP32)
    #include <WiFi.h>
    #elif defined (ESP8266)
    #include <ESP8266WiFi.h>
    #include <ESP8266WiFiMulti.h>
    #endif

  6. #6
    Join Date
    Dec 2011
    Posts
    6,226
    Post Thanks / Like

    Default Re: esp32 and Shelby's e131 test.ino

    after quite a bit of testing the ESP32 and Wled which is running a version of your e131 code , Multicast is terrible and only works with a single universe sporadically .

    Unicast works perfectly @ 25msec with 800 pixels, @ 50msec I see random lag !

    I cannot add the esp32 to any pre -configured/existing sequences without it totally lagging out . "(

    I am going to for now , assume this is an issue with the Wled firmware .

    Tested with both Artnet Lite and Hls .

    The esp32 is definitely fun to test with .

  7. #7
    Join Date
    Dec 2011
    Posts
    6,226
    Post Thanks / Like

    Default Re: esp32 and Shelby's e131 test.ino

    Just a little update on this Wled firmware for esp8266 or esp32 . This firmware is amazingly powerful and overloaded with options .

    The latest build enables rgb, rgbw or rgbww control . The nice part of this is, is that common anode rgb are easily controlled as if they are a ws28** pixel .

    If rgb is enabled the first pixel is mirrored onto the user selectable gpio .
    With a multitude of builtin effects , this is an excellent firmware for general year round usage and then e131 for show time .

    One short fall is there is still only 1 data pin available for pixels .
    With the new ESPixelstick being a Wemos , I would hope to see more output pins enabled for users to configure rather than all pixels on 1 pin .

  8. #8
    Join Date
    Nov 2011
    Location
    Chicago - Southwest Suburbs
    Posts
    7,958
    Post Thanks / Like

    Default Re: esp32 and Shelby's e131 test.ino

    If you want to get rid of the lag, you need to get rid of the unicast. However, since you were having very little luck with even one universe of multicast, it's entirely possible that there's something going on with the code on the ESP32. In general, you should be able to get at least a couple of universes working with multicast with minimal network optimization. Usually going beyond a few universes, you'll need to make sure you're using good WiFi hardware and optimize for the multicast traffic.
    For reference: https://www.diychristmas.org/wiki/in..._ACN_over_WiFi

  9. #9
    Join Date
    Dec 2011
    Posts
    6,226
    Post Thanks / Like

    Default Re: esp32 and Shelby's e131 test.ino

    Quote Originally Posted by jchuchla View Post
    If you want to get rid of the lag, you need to get rid of the unicast. However, since you were having very little luck with even one universe of multicast, it's entirely possible that there's something going on with the code on the ESP32. In general, you should be able to get at least a couple of universes working with multicast with minimal network optimization. Usually going beyond a few universes, you'll need to make sure you're using good WiFi hardware and optimize for the multicast traffic.
    For reference: https://www.diychristmas.org/wiki/in..._ACN_over_WiFi
    This is great information thank you . However with this particular firmware and the Esp32 I have found that multicast is a no go .
    Unicast is dead accurate sending 4-8 universes .
    With multicast 1 universe with any accuracy is all it can muster .
    I think Shelby's code would be great for the ESP32 if there was a sketch showing how to break out universes and channels like was enabled in his neopixel sketch for the esp8266 .

    Looking through the Wled firmware , it appears the e131 code is very thin with an edited version of Shelby's ESPAsyncE131 lib.
    This is the bulk of the code and is stored in A notification lib . Other than this there is a few calls in the main .ino

    Code:
    void arlsLock(uint32_t timeoutMs)
    {
      if (!realtimeActive){
        for (uint16_t i = 0; i < ledCount; i++)
        {
          strip.setPixelColor(i,0,0,0,0);
        }
        realtimeActive = true;
      }
      realtimeTimeout = millis() + timeoutMs;
      if (timeoutMs == 255001 || timeoutMs == 65000) realtimeTimeout = UINT32_MAX;
      if (arlsForceMaxBri) strip.setBrightness(255);
    }
    
    
    void handleE131Packet(e131_packet_t* p, IPAddress clientIP){
      //E1.31 protocol support
      uint16_t uni = htons(p->universe);
      if (uni < e131Universe || uni >= e131Universe + E131_MAX_UNIVERSE_COUNT) return;
      
      uint16_t len = htons(p->property_value_count) -1;
      len /= 3; //one LED is 3 DMX channels
      
      uint16_t multipacketOffset = (uni - e131Universe)*170; //if more than 170 LEDs (510 channels), client will send in next higher universe 
      if (ledCount <= multipacketOffset) return;
    
      arlsLock(realtimeTimeoutMs);
      if (len + multipacketOffset > ledCount) len = ledCount - multipacketOffset;
      
      for (uint16_t i = 0; i < len; i++) {
        int j = i * 3 +1;
        setRealtimePixel(i + multipacketOffset, p->property_values[j], p->property_values[j+1], p->property_values[j+2], 0);

  10. #10
    Join Date
    Nov 2011
    Location
    Chicago - Southwest Suburbs
    Posts
    7,958
    Post Thanks / Like

    Default Re: esp32 and Shelby's e131 test.ino

    Shelby did some workarounds in his project to explicitly send the required IGMP messages for multicast to work properly. I have no idea if that's present or not in the other code. I would doubt it. Without that, multicast likely won't work on much hardware.

    But do heed the unicast warnings though in my writeup. Things may look to work well in early testing, but when you go to scale it up to the full universe counts, and put it outside where all the interference is, then you'll start to get the intermittent lag issues.

Page 1 of 2 12 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •