Electronics notes/Localish communication notes
| 📃 These are primarily notes, intended to be a collection of useful fragments, that will probably never be complete in any sense. |
DMX
Functionality you can expect
DMX is a shared serial bus used for lighting control.
Basically, two wires (plus shield) that each devices taps off.
Up to 512 distinct channels listening, one thing sending up to 512 distinct, one for each.
Most devices only listen, but there are variants that communicate both ways (RDM, and some proprietary stuff).
Speed
Data-size, 512 channels times a 8-bit value (0-255), at the given fixed communication rate, means that we can update a full universe up to 44 times per second
Stability
There is no error correction.
It's fairly robust, but glitches can happen when e.g. signals get induced onto that data cable, when its own signal gets weak due to cable length, etc. (and e.g. nightclubs can be electronically noisy as as hell, in ways you can't easily resolve).
In fixed installations you can often resolve that with a bunch of some thought put into design, and usually relatively minimal cost. Thinking about cable length, shielding, isolation, terminators, segmenting into parts with ~32 devices with repeaters inbetween (it is in the end a RS485 bus).
Control
Each device will listen to one or more preconfigured addresses.
- Initially made for dimmers, with each channel dimming a light.
- Most modern devices have multiple parameters so listen to a set of multiple channels
- ...typically a base address and the next few channels
- For example, RGB-mixing LED spots commonly use four or five
- (up to eight or so happens, for things like direction-motorized colored gobo'd lighting)
You will have to manually tell your controller about all the devices, and what channels they're on.
Physical
DMX is a single shared RS485 bus (so differential signalling) clocked at 250kHz.
Everything's wired to the same cable (not isolating like e.g. serial MIDI does),
so a driver sees the combined load current from all devices.
Typical receiver impedances mean you can put approximately 32 devices on a string (which is roughly just RS-485 specs). For more you may want a splitter/repeater to, effectively, drive the next segment.
There are reasons it may be better than 32, and reasons it may be worse, so it's still a good rough guideline.
Being RS-485, you only really needs two wires, and in practice you'd prefer to also have shield.
Differential voltage should be something between 2 to 6V, and often seems to be 5V.
Specs also say devices should deal with it being as low as 0.2V, but don't expect this from all devices.
(The absolute voltages, compared to ground, may apparently be anywhere between -7V and +12V(verify), but this isn't generally something you need to worry about)
http://www.opendmx.net/index.php/DMX512-A#Voltages_and_power_dissipation
The standard is USITT DMX-512,
- developed in 1986 to control stage-light dimmers,
- revised in 1990 (DMX512/1990),
- revised in 1998 (DMX512-A),
- revised in 2008(verify).
Cabling
Balanced cabling, because RS485 is differential signalling.
Given the speed, it must have low capacitance, and a characteristic impedance around 120 Ohm.
(Microphone cable may be tempting since they're also XLR3 -- but doesn't meet either of those requirements: it's higher capacitance and and has a less-than-deal characteristic impedance at the speed DMX uses. It will work on your test bench with a few devices and a few meters of cable, but will do unpredictable things in a large installation. For similar reasons, don't try to cheat one section with a bit of mic cable, it causes impedance mismatch and similar issues)
If you're not a star at electronics, then you may want to buy pre-made DMX cables, purely because a glitchy system that you can't really troubleshoot yourself probably isn't worth the couple dozen bucks you saved.
While there is noticeable variation in quality (and some really pricy nonsense, because of course there is),
most of these pre-made cables are decent enough.
If you like to DIY your own, then note that shielded twisted pair network cable is a good choice - it's balanced pair, ~100 ohms characteristic impedance, tends to be 24AWG or 22AWG (and you shouldn't go thinner than that on longer runs).
Since it's differential on balanced lines, a little interference is not a huge problem, yet shieded cable is wise. Both because they're used in electrically noisy environments, not lest of which because these cables will not be alone in conduits.
XLR3 versus XLR5
Pinout
The standard mentions XLR5 plugs:
- pin 1: shield
- pin 2: data-
- pin 3: data+
- pin 4: data- (spare)
- pin 5: data+ (spare)
Those last two pins were intended as spare/duplicate data lines, and some consider them future-feature things.
But chances are good they they will never be used for anything standardized
...so many devices use XLR3 instead:
- pin 1: shield
- pin 2: data-
- pin 3: data+
Controllers may have just a XLR3 plug. Some will have a XLR5-XLR3 adapter to allow both XLR3 and XLR5.
Devices and cables are often XLR3. You can use adapters for the occasional XLR5-only device. However, they will often just be using three pins of that socket. And it seems decent set of XLR5 cables only use three wires.
Repeaters and splitters might have either socket, or both - or be bare wire or a simpler connector, which fine in a fixed setup. This seems to vary mostly by brand.
Some like to use XLR5 cables in non-standard way,
- e.g. to have a controller put out two universes on just one XLR5 cable, split off later, to reduce clutter next to your main controller.
- some manufacturers/devices use these two pins for completely different things
- ...sometimes in ways that might damage real XLR5 DMX devices.
- ...so while XLR3 is technically a spec violation, pragmatically it is now the safer variant, just because you won't deal with any unknowns.
Termination and topology
DMX needs termination on the last device in a segment.
A terminator is a ~120 Ohm resistor (apparently specced to be 120 Ohm +5%/-10%, which is 108 to 126 Ohm) between the two data pins.
It helps to label the cable/plug you do this in as a terminator so people won't chuck it.
If a device
- has only a "DMX in" and no "DMX out", it's very likely to terminate the line itself.
- has a "DMX in", a "DMX out", and a switch that seems to relate to termination, it probably switches in a terminating resistor, and you can use that instead of plugging in a physical terminator
- (note it will be a bother if you plug something in and forget to disable it).
- has a "DMX in", a "DMX out", no such switch, (this is the most common case)
- ...and it's the last in line, you need to plug in a terminator.
A few devices may try to be smart about terminating automatically -- though that's not necessarily a good thing, because in cases that doesn't work you may be in for a lot of debugging fun. (also, they often only do this only when powered on, which can mean when powered off they may leave the segment in an usable state)
Non-trivial layouts: Using Y-splitters is not recommended, because on longer segments you'll run into issues with signal reflection and too much load.
Repeaters and splitters (which are more or less the same thing with different amounts of separate output drivers) are recommended for wires longer than 100 meters. The specs have a higher number for that length, but it's good practice to assume the real world has noisier and poorer-quality cables than lab conditions.
There are better and worse ways to make a repeater. If they opto-isolate between input and output
they also effectively clean up the signal, removing would-be-cumulative effects of load, noise, and such.
Better implementations more fully isolate both ends (even the power supply), which avoids trouble introduced by fixtures on different power phases and different ground levels. This can be necessary in larger installations - and possibly irrelevant in smaller ones.
Link
As the speed of 250000 (8us baud length), and given its fairly simple framing, it can update an full 512-channel 8-bit-valued universe approximately 44 times per second. (If you have fewer devices and put them all on lower addresses, you can go faster)
DMX mostly does standard UART-style startbit-databits-stopbits stuff.
The exception is the way it signals the start of a new frame, with a long break and mark.
The spec allows for pauses before and between slot values, so for the most part, the timing isn't very critical and buffering relatively unnecessary (but sometimes very handy - see below).
A frame is, roughly:
- Break, Mark to signal a new frame starting
- break is at least 88us but commonly about twice that
- mark is at least ~8us but also typically longer
- Start code (a.k.a. slot 0)
- 0 for most real use. Other values are extensions
- up to 512 slot values
RDM
RDM is an expansion that allows bi-directional communication, letting you detect what's on the line, configure, and monitor devices.
Shoudn't bother classical DMX devices, because RDM requests and responses uses a different start code.
Splitters/repeaters need to be designed with RDM in mind, though.
See also:
Laser channels
When you may wish to control lasers, it may be easier to adhere to ISP-DMX, which has predefined laser functions on 32 channels (1-32), and some (33-66) reserved for (future?) ILDA standarization.
...in other words, configure your other devices on channels above 67.
DIY
There are Arduino shields and comparable, which are often little more than the bus translation and an XLR socket or two.
For example, the CTC-DRA-10-1 is basically a MAX485 plus four jumpers:
- EN: basically EN in real use, not-EN while you're updating the 'duino (because by default it uses the hardware serial lines)
- TX-UART / TX-io and RX-UART / TX-io: Connect to Arduino USART pins (Digital 0 and 1), or to Digital 3 and 4
- Slave / DE: Use DE (Digital Enable) if you need r/w control (via Digital 2) (can be useful for testing, required for RDM). Slave if you do not need to switch between R and W.
You can use it as a DMX Master (controls devices), DMX Slave (e.g. listens and controls a lamp or such), and RDM transponder (see above).
There is no explicit protection against ground loops, ESD, and such, which are things you do might want to pay attention to.
Library: http://sourceforge.net/projects/dmxlibraryforar/files/ (DMX and RDM code)
When building DMX senders or receivers yourself:
You'll probably like an XLR socket.
The least you need is a serial port.
- most microcontroller serial ports will do
On senders: Since not all computers have physical serial ports anymore (and if they do you may not be able to run them at 250000 baud), it's common to see USB-to-serial devices.
Since most of those are RS-232, you'll also need translation to between RS232 to RS485.
- There are various ready-made ICs that translate between RS-232 and RS-485
- See voltage level details. You will probably need an op amp (verify)
- Opto-isolation between DMX line and your device logic is a good idea.
- Capacitive coupling to ground (e.g 10 nF) will lessen some RF interference.
Microcontroller libaries
Conceptronics
DMXSimple
TeensyDMX
DMXSerial
DMXSerial2 (extends DMXserial with RDM)
Software
RDM notes
Physical
Uses the RS485 bus, but instead of only the master talking and the lights being slaves, all devices can both send and receive.
RDM controllers are terminated at this side -- because the controller is no longer always driving.
You can mix in legacy DMX, which will of course stay receive-only.
...but any splitter/buffer type devices need to be RDM-aware, as many classical devices assume you would only be sending one way.
Transport
RDM packets use a different start code (0xcc), so can be sent between regular DMX commands (0x00).
- most of why they should not affect classic DMX at all.
RDM devices speak only when spoken to, and the controller addresses individual devices, so can easily avoid collisions on this shared bus.
Most sends will be unicast, through broadcast also has uses.
https://wiki.openlighting.org/index.php/RDM_Discovery
http://www.mathertel.de/Arduino/DMXSerial2.aspx
DMX over ethernet
DMX over Ethernet means DMX masters that you communicate to via Ethernet (not to be confused with serial DMX over 8P8C-plugged network cables, which also exists).
This can make sense on larger setups, as you have certified-correct data transmission up to the DMX hardware, and the DMX cables can be shorter.
However, there is no real standard, so you can't mix brands, drivers, etc. A little planning can avoid most trouble here.
Art-Net
Art-Net can be seen as an implementation of DMX512-A over UDP/IP, often over Ethernet, or WiFi.
See also:
- https://en.wikipedia.org/wiki/Art-Net
- http://art-net.org.uk
- http://www.artisticlicence.com/WebSiteMaster/User%20Guides/art-net.pdf
ACN
Architecture for Control Networks
https://en.wikipedia.org/wiki/Architecture_for_Control_Networks
sACN
Streaming ACN, sACN, E1.31, is an extension o ACN that intends to transfer DMX512 data over IP networks (or, in theory, any ACN compatible transport).
KiNET
https://opendmx.net/index.php/KiNET
DALI
https://en.wikipedia.org/wiki/Digital_Addressable_Lighting_Interface
TPM2
TPM2 (sometimes TPM2.net)
https://gist.github.com/jblang/89e24e2655be6c463c56
X10 and variants
http://en.wikipedia.org/wiki/X10_%28industry_standard%29
http://wiki.linuxmce.org/index.php/X10
OSC
OSC, Open Sound Control
tl;dr:
- Decent latency (because it's a fairly minimal protocol, and UDP)
- can decode complex data without pre-set knowledge (because self-described packets)
- Usually over UDP/IP (sometimes TCP/IP), often over Ethernet.
- often unicast at a specific host (is practical enough), at multiple hosts if necessary
- you could broadcast (for simplicity)
- you could multicast (to be nice to the network)
No specific port, you can choose one for each applications (and receiver programs tend to have choose one, but still be configurable).
Used e.g.
- as an alternative to MIDI that is not tied to using a physical plug,
- When used over ethernet you have significantly more throughput than MIDI.
- to connect applications (including fairly easy DIY) into your music setup
- things that receive it include these, things that send it there are a lot more of
- Also used in DIY projects as e.g. "to anyone who is listening, this thing happened"
Address model
You address what are probably specific components, and can do so in a pattern-matching way (so you can do a sort of passive form of pub-sub).
That is, you can do:
/synth1/oscillator/[1-2] /synth1/lfo/*
The last part will refer to a Method, the rest to Containers
On order
Wildcard-matched Methods can be called in any order.
Parts of Bundles are called in the order they appear.
Data model
Basic data types:
- 32-bit signed ints
- 32-bit IEEE floats
- null-terminated bytestrings. (Padded to 32-bit alignment)
- arbitrary bytestring preceded by its size (Padded to 32-bit alignment)
OSC packets are either messages or bundles
Messages are (address, data)
- address can be specified with wildcards
Bundles are (BundleID, timestamp, messages)
- meant for things that co-occur at a specific time.
- bundles have no address; the messages do
- can be nested(verify)
See also: