WizYasep

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.

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 !

The newboards are here ;-)

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

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.

• 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.

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.

Settings

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 : 192.168.41.1xx
• MAC address : please provide one
• Network mask : 192.168.41.00
• UDP data port: 60001d
• UDP sync port: 60000d

Algorithm

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)
2. Read and process the image data (it usually takes a little time) to assemble the UDP packets
3. Send the data
   for all the packets in a sub-frame,
   for all the receiving Wizyasep
   send the packet
   The loop organises the packets so the first packet is sent to each Wizyasep, then the second... It is better than sending all the data to one WizYasep, then all the data to the other, because it reduces congestion in the hub/router, prevents packet loss due tu buffer overflows (particularly in a Gigabit network)
4. Wait for timer expiration
5. Send the Sync packet to the control port

   struct {
     char signature;
     char sequence;
   } sync_payload= { 'L', 'a' };
   // 0x4C6x, only the 4 LSB of "sequence" vary,
   // so this shows in ASCII as "La" "Lb" "Lc" "Ld"..."Lp"

   (beware of Endian ;-) )
6. goto 1

Note: Step 2 could be moved to step 4 but a tiny delay (a µs ?) is required after the sync packet is sent. This is lets the WizYasep assert how much data is contained in its FIFO. Otherwise, data from one frame could appear on another (though it's unlikely but it's not absolutely impossible, so it's safer/simpler to move the processing step just after the sync).

This delay can be removed if frame sequence numbers were contained in the data packets. The WizYasep would just stop reading when the sequence number does not match the number sent in the sync packet (yes, this one is implemented). However, due to a technical limitation of the WZ5300 FIFO, it's not possible to "unread" already read data (the W5100 is not FIFO based so the "random access" memory makes it possible, but the bus is only 8 bits wide and the capacity is too low, the W5100 can't contain enough data for a medium screen).

It's a hack but it works very well. I reserve the right to restore the sequence number once I get over a few technicalities.

Packet format

• Data socket :

Raw LED data are sent in order, in UDP packets to port 60001. The packet size shall be even, not 0 (otherwise the stack is reset). The source can send 1200 bytes or less at a time.

A frame sequence number was added as a header (identical to the sync packet) but it was removed (this simplifies coding, just sendto() a location in memory, no need to memcpy to shift data and add the header...). This header will be restored one day.

A packet sequence number was also developed but

1. Link/data errors are highly unlikely in practice
2. This adds code and bugs

The protocol is reset if more than 56K bytes are received on this port.

• Control socket

A pair of bytes is sent to port 60000.

struct {
  char signature;
  char sequence;
} sync_payload= { 'L', 'a' };
// 0x4C6x, only the 4 LSB of "sequence" vary,
// so this shows in ASCII as "La" "Lb" "Lc"..."Lp"

BTW : beware of byte ordering ;-)

Of course, only send one per complete frame. The protocol is reset if more than 512 bytes are received on this port.

Data formatting and pixel ordering

Pixels are transmitted as RGB byte triplets.

By default, the byte ordering is preserved but the hardware can reorder (RGB, GRB, RBG, GBR, BGR, BRG)

The data for one string (output) is sent in the same order, as well. Control software must reorganise data according to the display's geometry (zig-zag etc.)

The first triplet is displayed by the first LED of the string (closest to the WizYasep or data input).

There is one channel per physical output.

Channels only work in pairs : one channel will be unused / disconnected if the display has an odd number of LED strings. This will obviously waste a bit of bandwidth but this is marginal in practical cases.

Currently the number of channels is set at fabrication time but it should be user-configurable in the future.

All channels have the same pixel count or length : if one output has less pixels, then the missing data must still be sent. Usually, displays have a balanced number of outputs so this is not a drawback.

Pixels are sent with channel interleaving: all the first pixels of the channels are sent first. Then come all the second pixels of all channels, etc. For 4 channels, the pixels are in this order:

C1 C2 C3 C4 C1 C2 C3 C4 C1 C2 C3 C4 C1 C2 C3 C4...

The WizYasep can't know how many LEDs are actually connected so more or less could be actually sent, with the obvious side effects of truncated or partial display.

Offline behaviour

The WizYasep can detect when the network is down. However, a simple timeout (after the last valid packet) also works well so the display turns black one second after the last update.

The internal configuration of the number of pixels is useful for this blanking. There is no check of the number of pixels received from the network. A higher number of pixels will not be seen, while a lower number will only blank one part of the screen.

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.

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.

New boards are being expected ;-)

And here are the Wiznet modules to populate them.

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 !

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.

Thank you Gavin for the very nice interview !

http://www.linuxuser.co.uk/raspberry-pi/electrosuper-led-tunnel