LED screen controller over Ethernet... among others ! It's a Wiznet IP controller with a A3P250 FPGA and I/Os.

Similar projects worth following
The WizYasep transmits and transcodes data flows through Ethernet, at high speed, low latency and low jitter. Its first purpose is the control of networked LED screens (made of asynchronous RBG LED)

The simplicity, performance and versatility surpass the PixelPusher and make it ideal for many industrial, embedded and real-time applications. Its extension connectors provide additional flexible functions, for example up to 24 LED channels withouht external logic !

WizYasep is created and developed in France by YGDES, reusing tools from the project, and custom versions may be built on demand ;-) An even more powerful controller is planned for 2016.

1. Feature in the british press
2. SPI Flasher sub-project spin-off
3. Extension boards
4. Expecting
5. Todo list
6. Notes about the WizYasep protocol
7. How many LEDs ? How fast ?
8. Delivery
9. Typical use
10. Speed tuning

  • 1 × A3P250-TQ100 Actel Flash FPGA
  • 1 × WIZ830MJ Wiz5300 TCP/IP Hardware controller
  • 1 × M25P40 512KB SPI Flash

  • Speed tuning

    Yann Guidon / YGDES09/24/2016 at 13:34 0 comments

    The WizYasep accomodates varying channel counts with the help of a variable frequency generator. The less channels to drive, the longer the period and the higher the value that is loaded in the digital predivider.

    This predivider value (and other paramaters) are stored in a precomputed table, which is hardwired in the FPGA. A change in the channel count will also update the clock frequency accordingly.

    There are cases where the frequency must be tuned. For example, when using the WS2811 in slow mode (400kbps) so the predivider value should be updatable. A prediv register should be written from the Flash contents or the network. This is one of the planned updates to the firmware.

  • Typical use

    Yann Guidon / YGDES12/27/2015 at 20:37 0 comments

    The WizYasep was initially designed to fit in the waterproof boxes mounted on the screens built by Fred Sapey Triomphe.

    The reconfigurable logic and IO allow many extensions, so it can be adapted to most projects and requirements.

    More applications are in preparation !

  • Delivery

    Yann Guidon / YGDES12/20/2015 at 19:49 0 comments

    The newboards are here ;-)

    After a professional oven reflow, they will undergo thorough testing and configuration in my workshop.

  • How many LEDs ? How fast ?

    Yann Guidon / YGDES12/19/2015 at 22:52 0 comments

    I often get these questions :

    • How many LED can the WizYasep drive ?

    The answer is : a lot !

    The W5300 network chip has a 128KB FIFO, that's roughly 40KLED. Is that enough ?

    Actually I have reduced the receive FIFO depth to 56KB, or about 19K LED. My largest screen #Mons2015 LED Screen ElectroSuper has 16800 LEDs, and they are spread over 6 WizYasep (2800 LED per sector) so it was easier to keep the size inside a 16 bits word.

    Later, on-the-fly picture compression (with #Recursive Range Reduction (3R) HW&SW CODEC ) will increase the LED capacity even more.But I don't think I'll use the whole 128K FIFO because so many LEDs create incredible technical problems at every level and it's easier to just plop another WizYasep (or more).
    • How fast can it refresh the display ?

    The answer is : very fast !

    Actually the two limiting factors are :

    1. The network speed
    2. The LED string length

    The usual asynchronous LEDs (WS2811, WS2812 and similar) are limited to about 30K LED/s. This means a 30K LED string can be refreshed once a second. If you want to refresh at 30Hz, that limits the string to 1000 LEDs. If you want 60Hz, limit your strings to 500 LEDs. With 24 channels, that's 12K LED, well withing the FIFO size.

    I have easily run the WizYasep with 20 channels up to about 120Hz with 140 LED per string but the difficulty becomes the generation/storage of all these images (hence my current development of a compression algorithm).

    The WizYasep can handle up to 24 channels (and there is provision for 40, and even more) so the next limitation is the network : can you continuously pump 9MB/s over your network link ? That is about 80 strings in parallel at full bandwidth...

    So in essence, the WizYasep is "adequate" for most medium and large scale projects, it's easy to use, and the price/performance is above the pack.

  • Notes about the WizYasep protocol

    Yann Guidon / YGDES12/19/2015 at 21:22 0 comments

    The WizYasep (currently) implements an application-specific network protocol that is simple (hence cheap and easy to use) yet efficient and flexible. Unlike other widely used protocols, WizYasep synchronises the displays very finely to prevent "tear/shear" of moving pictures. Software can display data through the network without a complex library.


    If this was not obvious before, this system uses UDP, IP and other Internet Protocols but it is not meant or designed to be connected to the WWW. It is reserved for isolated LANs to keep latency low and prevent anything from messing with it. 'K ?

    Protocol design and safety considerations

    The WizYasep uses a Wiznet hardware IP stack, please consult the W5300 datasheet for more details.

    ARP (MAC resolution) and PING are provided in hardware by default, they are active to provide the most basic network management ("is the board alive and properly configured ?"). This is the only case where the WizYasep board emits data, the rest of the protocol over UDP does only receive data (there is no ACK to keep things simple, fast and more resilient).

    The protocol is also implemented with resiliency in mind: the network stack is automatically reset if unusual conditions are detected (for example buffer overflows). At the same time it is not very restrictive and accepts certain malformed data. The worst that can happen is:

    • missing data or packet -> image is warped/shifted
    • altered data -> image changes color
    • too many data -> extra data are not shown

    This is not a "safety critical" device, no checksum or authentication is provided. It is designed for resilience, ease of use and performance. TCP is not used because of the ACK packets overhead, particularly for the synchronisation: anti-congestion algorithms are not good for real time.

    Protocol overview

    For every picture/frame, all data is sent in advance to one UDP socket. Hubs and router often "store and forward" data so this transmission might be delayed and the uncertainty increases if there is other kind of traffic on the links.

    The W5300 stores all the frame's data in its FIFO. 128KB is available but for practical reasons, only 56K are currently used. I haven't yet had to drive 19K LED with a single WizYasep board and if the FIFO is filled so much, something wrong is going on (buffer overflow) and the whole protocol is reset.

    Note: in my tests, the W5300 does not seem to handle well UDP packets that are larger than 1200 bytes. Check the packet sizes if you don't see any output...

    Pixel data are expected to be received in the right packet order. Normally, a simple LAN with a central hub should NOT reorder the packets. For this reason, packet sequence numbers are not used in the payload.

    After all the data are delivered to all the WizYasep, the data source sends a small broadcast packet (2 bytes over UDP) over the control/sync port. This triggers the simultaneous display refresh for all the receiving WizYasep boards of the network. The contents of their FIFO is read and reframed to feed the attached LED strings.

    The Ethernet network is the only cause of delay between screens, which is a fraction of a millisecond and no image deformation is visible.


    The Ethernet link is designed for 100Mbps operation and supports 10Mbps for backward compatibility. 1000BaseT is not supported but it can be connected to a Gigabit hub/router (which will downgrade the link to 100Mbps). This can be useful if the main system controller has to drive many Wiznet boards.

    The IP address/mask/port and the MAC address are configurable. Their value are stored in the onboard SPI Flash memory, which can be updated with #SPI Flasher. They can also be configured on demand, during fabrication. The usual parameters are

    • IP :
    • MAC address : please provide one
    • Network mask :
    • UDP data port: 60001d
    • UDP sync port: 60000d


    Any computer with a TCP/IP network stack can send data to the WizYasep.

    The main display loop works this way:

    1. Set a timer (can be 20ms for 50Hz refresh)...
    Read more »

  • Todo list

    Yann Guidon / YGDES12/18/2015 at 21:09 0 comments

    A detailed documentation is of course necessary (and I'll write many notes here), but there are other things and features to add to the system, to make it more configurable.

    First, make a better "internal bus" so any data (from the external SPI console or the onboard SPI memory) can be written to the Wiznet chip or the internal configuration registers.

    Those registers control :

    - RGB order: currently it's wired for RGB, but all other permutations are possible, GRB, GBR, RBG, BRG, BGR)

    - number of channels (must be even)

    - total number of LED [counted in pixels/2, or bytes/6]

    - "Almost full" level of the internal FIFO [counted in pixels/2, or bytes/6], which must be LESS than the total number of pixels (Could be computed from the total number of LEDs but it's better to do it in SW, logic gates are precious) [to be verified, it seems i took care of that corner case already in the design)

    I'll allocate addresses for these internal registers and the SPI flash will be able to configure them during the reset sequence.

    For a minimal configuration (8 channels implemented only) only 1/5 of the FPGA is used so there is some room for new features. Only 2 DP-SRAM blocks are left (1KB) though. The Actel chips are (most often) memory-bound...

    It might be possible to store pictures in the onboard SPI Flash memory, that are displayed during the first seconds after startup, or when the network is down.

  • Expecting

    Yann Guidon / YGDES12/13/2015 at 22:08 0 comments

    New boards are being expected ;-)

    And here are the Wiznet modules to populate them.

  • Extension boards

    Yann Guidon / YGDES12/09/2015 at 04:03 0 comments

    The WizYasep is a very flexible board and it was designed to allow extensions. Here is one that was designed for #Mons2015 LED Screen ElectroSuper

    Characteristics :

    • 20 buffered asynch LED outputs
    • 4 solid state relay outputs that distribute 16A to 4× 4A for power sequencing
    • integrated 5V power supply
    • console breakout connector (for live reprogramming/reconfiguration)

    Another different board is being designed to provide 64 LED outputs !

  • SPI Flasher sub-project spin-off

    Yann Guidon / YGDES09/23/2015 at 18:34 0 comments

    The #WizYasep board uses many tools designed to build the #YASEP project's framework. One of these tools is the #SPI Flasher which now has its own project page here !

    In the current revision, this programming tool is required to (re)configure the network parameters (IP address, MAC address, stuff like that) but the next revisions will provide more features such as reconfigurable channel count, or even a "screensaver picture". End users should be able to modifiy these parameters so it's important that they have all the necessary tools and informations.

    Of course I can provide the configuration service to inexperienced users but this spin-off lets the tech-savvy customers benefit more from the #WizYasep and adapt it to their own needs easily. The system I use is compact and battery-powered which is desirable and handy for field updates in the wild, it's not just "yet another SPI flasher" but a work tool.

    Later generations of the WizYasep will include more and more intelligence, including an embedded web server to remotely change the settings from the comfort of your favorite web browser. But there will always be the need to configure the board's address in the beginning, or "un-brick" in the unlikely event of a mistake.

  • Feature in the british press

    Yann Guidon / YGDES09/19/2015 at 03:09 0 comments

    Thank you Gavin for the very nice interview !

View all 10 project logs

  • 1
    Step 1

    Test your board with the following code:

    while true
      sleep 0.04
      dd if=/dev/urandom bs=1200 count=1|nc -u $IP 60001         
      echo -n 'La'|nc -u $IP 60000

    All the available channels should now blink with pretty colors !

    If you have several boards, send the data to each board in turn then broadcast the 'La' sync packet to the x.x.x.255 address so they all receive the signal at the same time.

  • 2
    Step 2

    You can check the order of the strips and verify the pixel mapping with this slightly more elaborate script :

    [ "$IP" ] || IP=
    while true
      WHITE=$(printf "\377\377\377")
      for i in $(seq 0 399)
        sleep 0.1
        echo -n $HEAD|nc -u $IP 60001
        echo -n 'La'|nc -u $IP 60000
    It should be recoded in C or Python because it only tests the first 400 pixels (due to packet size limitations).

    Note that the physical and logical order of the inputs are reversed. It's a litlle idiosynchrasy of the variable-output logic, it must be reversed in software but it makes the hardware faster and smaller.

View all instructions

Enjoy this project?



scott wrote 01/03/2023 at 07:38 point

hi. It's a cool project. Are you thinking of doing other projects using the W5300?

  Are you sure? yes | no

Yann Guidon / YGDES wrote 02/14/2024 at 08:14 point

If a client needs it, sure.

However it's getting harder to source the Wiznet modules these days, they might get obsoleted, which is a shame since it's such a great chip.

  Are you sure? yes | no

hammi_saif wrote 12/02/2017 at 08:13 point

which transmission layer protocol has been used for ethernet data. what is the data rate ??

  Are you sure? yes | no

Yann Guidon / YGDES wrote 02/14/2024 at 08:19 point

The W5300 can sustain almost full bandwidth of 100BaseT. The large buffer prevents data losses and the 16-bit wide bus allows the host controller to read data from the buffer as it arrives, unlike the smaller chips in the series.
In comparison, WS5100 or ENC28J are toys.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates