Dmx Slots Speed Chip

1. Dmx Slots Speed Chip Quick
2. Dmx Slots Speed Chip Game

From wiki.openlighting.org

DMX communication chip used in many ETC products (and retrofit to replace the Z216-F) including CEM, CEM+, CEM3, Smartpack, Smartswitch, Smartbar2 Paradigm, Echo ACP, Smartlink ACP, Eos Family consoles, Congo Family consoles, Cobalt family consoles, and Smartfade. Appears on packing slip as: IC 75LBC182 RS485 XCVR ESD DIP8.

• DMX Racer Next Generation Slot Cars Racing.
• DMX racer is a next generation of slot car racing. With the rotating-pin technology, the race cars can change lanes at anytime and anywhere on the track. This exciting new racing platform makes you feel like real auto-racing. 1:32 scale cars with head lights for night mode. Speed pattern chip installed for 5 speed levels with booster.
• Slot/address number is known by counting slots from the long packet break in the beginning of each packet. The maximum packet rate is 44 updates/s if all 513 slots are transmitted (start code + 512 values), but can be higher if fewer slots are transmitted. If only packets only consists of a start code + 24 values, up to 830 updates/s can be made.

The last version of the standard is called USITT DMX512-A and it is maintained by ESTA since 1998. In 2004 it was made an ANSI standard too, named 'E1.11, USITT DMX512-A' or 'ANSI E1.11-2004'. In 2008 it was revised [1] .

IF you are looking for info about connecting DMX equipment and setting addresses, look at this video tutorial from Martin.So far, the rest of this article is about technicalities.

DMX is characterized by its simplicity in how data are transferred from a controller to receiving equipment.

• 1Electrical

Electrical

DMX is based on the balanced serial connection standard EIA-485-A (a.k.a RS485).Only 5-pin XLR meets the standard (and products may meet the requirement by supplying adapters).Since the revision in 1998 the cables itself are not specified in DMX512-A (so it can be specified in separate standards?)In general the cable must fulfill the EIA-485 requirements of 120 Ohms (around 250 kHz) shielded twisted pair. One transmitter must be connected to maximum 32 receivers.

• Termination resistor tolerance is 120 Ohm +5 % / -10 % (108 – 126 Ohm).
• Each receiver must not load the differential line with more than 125 pF.

Use of category 5 UTP or STP

Other cable types have been examined to determine how well they are for DMX usage (as loose cables or in fixed building installations). The last report more or less concludes that for fixed installations, unshielded twisted pair in CAT 5 is good enough, even when it is mixed with 120 Ohm cable meant for EIA-485. The pulses from reflections and general degradation is not significant and harmless. See the three parts at http://www.esta.org/tsp/working_groups/CP/DMXoverCat5.htm .

See also this point in USITT's DMX faq:http://www.usitt.org/DMX512FAQ.aspx#a9(old link is [2]).

The cabling for DMX512-A should be described in the document called 'BSR E1.27-1 -- Portable Control Cables for Use with USITT DMX512/1990 and E1.11 [DMX512-A]'

The 8-position modular connector is allowed in the DMX512-A as an alternate connector if there is not space enough for XLR5 or for fixed installations in 'controlled access areas'.Pin-out:

Both common wires are mandatory, and must have same potential in equipment sockets.

Voltages and power dissipation

The power dissipation in the 120 Ohm terminating resistors depends on the differential voltage between the two data wires.If the transmitter only makes a 5 V differential voltage (which is common), the power dissipation is P= U*U/R= 5*5/120 = 208 mW.

According to [3] and the DMX512-A standard, the maximum absolute differential voltage allowed by the EIA485 standard is 6 V.This gives the maximum power dissipation is P= U*U/R= 6*6/120 = 300 mW. So it is best to use 1/2 W resistors, to keep them cool enough not to damage itself or weakening the solderings.

Transceiver chips made for 5 V (they seem to be widely used):

Transmitter/receiver topologies

To avoid ground loops between equipment and improve reception performance, the transmitters and receivers for the DMX line must use a good combination of transmitter/receiver topologies. Some are not allowed, some are accepted with warning labels and some are preferred. See http://www.usitt.org/standards/DMX512_FAQ.html#FAQ_15 .

Salt river casino arizona. Transmitters should use 'earth ground' as a reference for the positive/negative voltages that is put on the two data lines.Receivers should be 'isolated'.

The protocol

A Universe contains 512 addresses and a single DMX line (cable) can only transmit one universe. I.e. a controller with two universes need two DMX lines (daisy chains including splitters). A universe is normally thought of as an address space (in the controller), the cables that transmits it and the equipment that receives it.

• The DMX signal is made up of a sequence - called a packet - which is sent over and over again (to increase robustness).
• It is up to the controller/transmitter to decide how many of the 512 values is sent. A shorter packet means faster cycles.
• A receiver must be set or programmed to an address it listens to. If a receiver listens to multiple addresses, the set one is the first. (It depends on implementation.)
• Multiple receiver can listen to the same address - the DMX system does not care.

A packet has the following sequence:

• Break
• Mark After Break (MAB)
• The 'start code' frame (Sometimes called address 0) Alternate start codes
• 1-512 slots/frames with the values of the channels. The first value is for address '1', the next for address 2 etc.

(Note: A packet must have a minimum length in time)

• A slot/frame contains the value for one address, has one start bit and two stop bits.
• The address number is not sent over the lines, so the receiver must count the received slots from the start of the sequence to find the wanted value.
• The start code is used to alter the meaning of the data bytes in the rest of the packet. The default is 0, and the remaining 255 values is rarely used (by definition 0 means dimmers, but is used for intelligent light as well).

Note that some people and texts use the words frame and packet in the opposite sense than stated here.

Timings

The clock rate is 250 kHz so each symbol bit on the wire is 4 microseconds long (period time).

Symbol length is 4 +/- 0.08us for 245 - 255 k baud/s, with non-return-zero between symbol bits. To transmit 8 data bits it take 11 symbols because the use of one start bit and two stop bits around each data byte. Slot/address number is known by counting slots from the long packet break in the beginning of each packet.

The maximum packet rate is 44 updates/s if all 513 slots are transmitted (start code + 512 values), but can be higher if fewer slots are transmitted. If only packets only consists of a start code + 24 values, up to 830 updates/s can be made.

The Rx req. column shows what a receiver must be able to handle of valid timings.

Note that the minimum length of 'Mark after break' was doubled from 4 to 8 us in 1990, and receivers can be backward compatible by accepting the shortest time.

The slot time must be precise, or else the receiver should discard the whole packet, e.g. if the second stop bit is missing.

There must be at least one packet with start code=0 per second, and a receiving product must specify what happens when this time is exceeded.

Here is a nice overview of the different parts of a DMX packet with timings etc.: http://www.erwinrol.com/index.php?stagecraft/dmx.php.These timing values matches the ones in the DMX standard from 2004.

Idle must be high level (mark level, 'Mark before break').

As a receiver must handle varying 'mark time between slots', it needs to synchronize to each start bit in each slot.

Sources and additional reading

• Thorough DMX description and a long list of good references to other sites and projects. Much better than a Google search!

• ePanorama (thorough descriptions of most details, lots of links)

• Ujjal's DMX512 Pages (down-to-earth walk-through, also a good historical overview from before DMX )
• The anatomy of DMX512 (a nice, short overview)

• History from mechanical dimming over analog lines, multiplexing, DMX and to ACN in three pages.

See also

From wiki.openlighting.org

Since March 2013, OLA contains an SPI plugin, which allows you to drive strings of LEDs pixels provided your platform has an SPI interface. Using embedded Linux platforms like the Raspberry Pi, this allows one to build Pixel strings controllable via any of the supported protocols (ArtNet, E1.31, OSC & more) for less than $100.

Alternatively if you don't want network control, you can send DMX512 to the LEDs using the Python, C++ or Java client library running on the host itself.

Dmx Slots Speed Chip Quick

This page is focused on the Raspberry Pi, but may be applicable to other hardware such as the BeagleBone. If you're using a Raspberry Pi you can save yourself a lot of time by using the pre-built images, see OLA on the Raspberry Pi for details.

• 3Hardware Setup
• 4OLA SPI Plugin
• 7Example Configs

Host Hardware

The Raspberry Pi contains three SPI interfaces, but only one of these is wired to the 26-pin connector. The interface comes with 3 chip-enable (CE) lines but again only two are connected (pins 24 & 26). With the default mode, pin 24 is pulled low when the /dev/spi0.0 device is used and pin 26 is pulled low when /dev/spi0.1 is used.

The Pi uses 3.3V logic. You can usually get away with connecting the pins directly to the pixel hardware which uses 5V for testing, but for reliable operation it's best to use a driver circuit to convert the voltage levels from 3.3v to 5v especially if you have a cable run between the Pi and the Pixel string. There is a schematic available or you can buy a kit.

Dmx Slots Speed Chip Game

Here are some timings stats collected from the Pi:

It also takes somewhere between 3.6 and 4.6 ms to toggle a GPIO pin using the /sys/class/gpio interface. The importance of these numbers will be clear in a minute.

Beyond the Pi, any SPI hardware supported by the Linux kernel should work modulo the timing restrictions. By default OLA looks for devices that match the /dev/spi* .

Pixel Hardware

On the pixel side the following is supported:

• LPD8806, e.g. https://www.adafruit.com/products/306. since 0.8.27
• WS2801, e.g. https://www.adafruit.com/products/738, since 0.8.28

Each of these uses 3 DMX slots per pixel, so you can drive up to 170 pixels from a universe of DMX data.

Hardware Setup

The simplest setup is to connect SCLK (pin 23) to the pixel string's clock line and MOSI (pin 19) to the pixel string's DATA line. You'll need a separate power supply for the pixel string, check the pixel specifications but 1A per m is a good rule of thumb. Don't forget to connect the ground on the power supply to a ground pin (e.g. 25) on the Pi.Do not connect the 5V rail of the pixel power supply to the Pi.

Multiplexer

If you want to drive more than one string in parallel you'll need to use a de-multiplexer. For a two-line multiplexer one can use the CE0 and CE1 lines to select the output string. To run more than 2 strings you'll need to use some of the GPIO pins as chip-enables. However these pins are slow (~4ms) which limits the update rate.

There is a 8 way demultiplexer schematic here.

OLA SPI Plugin

The OLA SPI plugin is pretty flexible, the primary limitation is how long it takes to write the data out the SPI interface, and this limits the overall refresh rate. Each SPI interface (/dev/spi*) is represented as an OLA Device. Devices can have multiple 'ports' since each port can consume at most one universe of DMX512 data (170 RGB pixels). Each port can be configured (via RDM) with a start address and personality (pixel type). This allows a combination of various strings lengths & pixel hardware types.

Each SPI device uses a backend to write the SPI data. Right now there are two types backends available: a software backend which merges the SPI data from one or more ports, and a hardware backend which uses the GPIO pins to control a hardware demultiplexer.

Timing

It all comes down to timing. Consider the following example:

• 170 LPD8806 pixels per string (results in 516 bytes written)
• Two strings using the built in CE lines to drive a hardware demultipliexer.
• SPI speed of 2Mhz

Using timing table above, we can see this will take 40.2 ms x 2 = 80ms to update all pixels. That means you'll only be able to do 12 updates per second. Most DMX systems run at 40 updates per second so we'll end up dropping updates.

If we tried to use GPIO pins rather than the CE ones it gets worse. Consider a second example:

• 32 WS2801 pixels per string (results in 75 bytes written)
• Four strings using two GPIO lines to drive a hardware demultipliexer.
• SPI speed of 2Mhz

Now each write requires setting GPIO pins. Worse case both pins will need to change which adds 8ms. The write itself takes 8.1 ms, so that's 16.1 ms per string or 64.4 ms to update all strings. That gives you an update rate of 15 updates per second. Still not close to DMX's 40 updates per second.

Software Setup

You'll need a suitable udev config, so that OLA has permission to talk to your SPI port. There is also some Raspberry Pi specific config (enabling a kernel module) on the same page.

If you're using the GPIO pins to drive an hardware demultiplexer, you'll need to run the following as root prior to starting olad.

Once you have OLA running it's a matter of patching an SPI Output port to a universe and then patching the desired input port. Free poker tracking software download. This can be done from the OLA web UI or by using ola_patch.

Configuration

The type of LED drivers, operating mode and DMX Start Address are configurable via RDM. Click on the RDM tab and you'll see the options.

The number of LEDs and SPI speed is set using the ola-spi.conf file.

Example Configs

Single Pixel String

For a simple single-string output we can use the software backend and ignore the CE lines. This config is for 25 WS2801 pixels running at 1Mhz on /dev/spi0.0. From the timing information above this should support about 75 updates / second.

Two Pixel Strings, using the CE lines

This example is for 25 WS2801 pixels and 32 LPD8806 pixels. Both strings run at 2Mhz and are connected to the spi bus, and we're using the CE chips to de-multiplex. We want to CE lines to be active-high.

Two Pixel Strings, using a single output

• A slot/frame contains the value for one address, has one start bit and two stop bits.
• The address number is not sent over the lines, so the receiver must count the received slots from the start of the sequence to find the wanted value.
• The start code is used to alter the meaning of the data bytes in the rest of the packet. The default is 0, and the remaining 255 values is rarely used (by definition 0 means dimmers, but is used for intelligent light as well).

Note that some people and texts use the words frame and packet in the opposite sense than stated here.

Timings

The clock rate is 250 kHz so each symbol bit on the wire is 4 microseconds long (period time).

Symbol length is 4 +/- 0.08us for 245 - 255 k baud/s, with non-return-zero between symbol bits. To transmit 8 data bits it take 11 symbols because the use of one start bit and two stop bits around each data byte. Slot/address number is known by counting slots from the long packet break in the beginning of each packet.

The maximum packet rate is 44 updates/s if all 513 slots are transmitted (start code + 512 values), but can be higher if fewer slots are transmitted. If only packets only consists of a start code + 24 values, up to 830 updates/s can be made.

The Rx req. column shows what a receiver must be able to handle of valid timings.

Note that the minimum length of 'Mark after break' was doubled from 4 to 8 us in 1990, and receivers can be backward compatible by accepting the shortest time.

The slot time must be precise, or else the receiver should discard the whole packet, e.g. if the second stop bit is missing.

There must be at least one packet with start code=0 per second, and a receiving product must specify what happens when this time is exceeded.

Here is a nice overview of the different parts of a DMX packet with timings etc.: http://www.erwinrol.com/index.php?stagecraft/dmx.php.These timing values matches the ones in the DMX standard from 2004.

Idle must be high level (mark level, 'Mark before break').

As a receiver must handle varying 'mark time between slots', it needs to synchronize to each start bit in each slot.

Sources and additional reading

• Thorough DMX description and a long list of good references to other sites and projects. Much better than a Google search!

• ePanorama (thorough descriptions of most details, lots of links)

• Ujjal's DMX512 Pages (down-to-earth walk-through, also a good historical overview from before DMX )
• The anatomy of DMX512 (a nice, short overview)

• History from mechanical dimming over analog lines, multiplexing, DMX and to ACN in three pages.

See also

From wiki.openlighting.org

Since March 2013, OLA contains an SPI plugin, which allows you to drive strings of LEDs pixels provided your platform has an SPI interface. Using embedded Linux platforms like the Raspberry Pi, this allows one to build Pixel strings controllable via any of the supported protocols (ArtNet, E1.31, OSC & more) for less than $100.

Alternatively if you don't want network control, you can send DMX512 to the LEDs using the Python, C++ or Java client library running on the host itself.

Dmx Slots Speed Chip Quick

This page is focused on the Raspberry Pi, but may be applicable to other hardware such as the BeagleBone. If you're using a Raspberry Pi you can save yourself a lot of time by using the pre-built images, see OLA on the Raspberry Pi for details.

• 3Hardware Setup
• 4OLA SPI Plugin
• 7Example Configs

Host Hardware

The Raspberry Pi contains three SPI interfaces, but only one of these is wired to the 26-pin connector. The interface comes with 3 chip-enable (CE) lines but again only two are connected (pins 24 & 26). With the default mode, pin 24 is pulled low when the /dev/spi0.0 device is used and pin 26 is pulled low when /dev/spi0.1 is used.

The Pi uses 3.3V logic. You can usually get away with connecting the pins directly to the pixel hardware which uses 5V for testing, but for reliable operation it's best to use a driver circuit to convert the voltage levels from 3.3v to 5v especially if you have a cable run between the Pi and the Pixel string. There is a schematic available or you can buy a kit.

Dmx Slots Speed Chip Game

Here are some timings stats collected from the Pi:

It also takes somewhere between 3.6 and 4.6 ms to toggle a GPIO pin using the /sys/class/gpio interface. The importance of these numbers will be clear in a minute.

Beyond the Pi, any SPI hardware supported by the Linux kernel should work modulo the timing restrictions. By default OLA looks for devices that match the /dev/spi* .

Pixel Hardware

On the pixel side the following is supported:

• LPD8806, e.g. https://www.adafruit.com/products/306. since 0.8.27
• WS2801, e.g. https://www.adafruit.com/products/738, since 0.8.28

Each of these uses 3 DMX slots per pixel, so you can drive up to 170 pixels from a universe of DMX data.

Hardware Setup

The simplest setup is to connect SCLK (pin 23) to the pixel string's clock line and MOSI (pin 19) to the pixel string's DATA line. You'll need a separate power supply for the pixel string, check the pixel specifications but 1A per m is a good rule of thumb. Don't forget to connect the ground on the power supply to a ground pin (e.g. 25) on the Pi.Do not connect the 5V rail of the pixel power supply to the Pi.

Multiplexer

If you want to drive more than one string in parallel you'll need to use a de-multiplexer. For a two-line multiplexer one can use the CE0 and CE1 lines to select the output string. To run more than 2 strings you'll need to use some of the GPIO pins as chip-enables. However these pins are slow (~4ms) which limits the update rate.

There is a 8 way demultiplexer schematic here.

OLA SPI Plugin

The OLA SPI plugin is pretty flexible, the primary limitation is how long it takes to write the data out the SPI interface, and this limits the overall refresh rate. Each SPI interface (/dev/spi*) is represented as an OLA Device. Devices can have multiple 'ports' since each port can consume at most one universe of DMX512 data (170 RGB pixels). Each port can be configured (via RDM) with a start address and personality (pixel type). This allows a combination of various strings lengths & pixel hardware types.

Each SPI device uses a backend to write the SPI data. Right now there are two types backends available: a software backend which merges the SPI data from one or more ports, and a hardware backend which uses the GPIO pins to control a hardware demultiplexer.

Timing

It all comes down to timing. Consider the following example:

• 170 LPD8806 pixels per string (results in 516 bytes written)
• Two strings using the built in CE lines to drive a hardware demultipliexer.
• SPI speed of 2Mhz

Using timing table above, we can see this will take 40.2 ms x 2 = 80ms to update all pixels. That means you'll only be able to do 12 updates per second. Most DMX systems run at 40 updates per second so we'll end up dropping updates.

If we tried to use GPIO pins rather than the CE ones it gets worse. Consider a second example:

• 32 WS2801 pixels per string (results in 75 bytes written)
• Four strings using two GPIO lines to drive a hardware demultipliexer.
• SPI speed of 2Mhz

Now each write requires setting GPIO pins. Worse case both pins will need to change which adds 8ms. The write itself takes 8.1 ms, so that's 16.1 ms per string or 64.4 ms to update all strings. That gives you an update rate of 15 updates per second. Still not close to DMX's 40 updates per second.

Software Setup

You'll need a suitable udev config, so that OLA has permission to talk to your SPI port. There is also some Raspberry Pi specific config (enabling a kernel module) on the same page.

If you're using the GPIO pins to drive an hardware demultiplexer, you'll need to run the following as root prior to starting olad.

Once you have OLA running it's a matter of patching an SPI Output port to a universe and then patching the desired input port. Free poker tracking software download. This can be done from the OLA web UI or by using ola_patch.

Configuration

The type of LED drivers, operating mode and DMX Start Address are configurable via RDM. Click on the RDM tab and you'll see the options.

The number of LEDs and SPI speed is set using the ola-spi.conf file.

Example Configs

Single Pixel String

For a simple single-string output we can use the software backend and ignore the CE lines. This config is for 25 WS2801 pixels running at 1Mhz on /dev/spi0.0. From the timing information above this should support about 75 updates / second.

Two Pixel Strings, using the CE lines

This example is for 25 WS2801 pixels and 32 LPD8806 pixels. Both strings run at 2Mhz and are connected to the spi bus, and we're using the CE chips to de-multiplex. We want to CE lines to be active-high.

Two Pixel Strings, using a single output

This example is a string of 300 WS2801 pixels. Since this is more than one universe of data, we need to use multiple ports.

SPI data is written when data arrives on the second port (sync-port = -2). See the plugin description for more info.

Exported Variables

The SPI plugin exports a number of useful variables. These can be found at http://:9090/debug. Each is indexed by the device name e.g. /dev/spi0.0 .

spi-writes

Number of writes to each SPI device

spi-write-errors

Number of writes that resulted in an error

spi-drops

Number of DMX updates that were skipped. The happens if DMX data is arriving faster than it can be written to the SPI bus.

Related Links

http://www.solderlab.de/index.php/software/glediator (Pixel Control Software that outputs ArtNet)