View source for Electronics notes/Localish communication notes

{{#addbodyclass:tag_tech}}
{{electronics notes}}
{{notes}}

==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
<!-- can be faster with some creativity - if you put all devices at low addresses and you send incomplete universes.
Few people really need or want this.  

As such, latency is nearly zero for the first address and ~20ms for the last.
-->



'''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. nightclub ceiling 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 
:: {{comment|(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. 
<!--
So no, there's no electrical difference between IN and OUT sockets.
-->

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, essentially, drive the next segment.

There are reasons it may be better than 32, and reasons it may be worse, so it's a 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 at the source, lessening over a long wire.

Specs also say devices should deal with it being as low as 0.2V, but don't all devices to deal with that.


{{comment|(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),
: In 2004 the same standard was adopted as "ANSI E1.11-2004" as well
: revised in 2008{{verify}} - ANSI E1.11-2008 ?



====Cabling====

[[Balanced cabling]], because RS485 is [[differential signalling]].

Given the speed, it must have low capacitance, and a characteristic impedance around 120 Ohm.

{{comment|(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 [https://en.wikipedia.org/wiki/Characteristic_impedance 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.

<!--
The following is ESTA's (and the typical{{verify}}) way to connect using network cable: {{comment|(there are others, apparently rarer options)}}
 pin , Brown:     Common (for Data2, but usually the two browns are the same thing) 
 pin , Br/wht:    Common (for Data1, but usually the two browns are the same thing)
 pin , Green:     Data2-
 pin , Green/wht: Data2+
 pin , Or:        Data1-
 pin , Or/wht:    Data1+
 pin , blue:      unused
 pin , blue/wht:  unused
-->
<!--
DMX512-A gives a suggested wiring for [[8P8C]] connectors, though people suggest you avoid these connectors, or at least label things clearly:
* While the unconnected blue wires avoid US phone pins, this wiring doesn't play nice with Ethernet.
* You can argue that using the blue for extra Common cables can be useful. 
* ''Don't'' double the data lines, though (you're more likely to create signal reflection than to decrease noise?{{verify}})
-->


<!--
See also:
* http://www.bigclive.com/dmxtest.htm
* http://www.dmx512.com/web/light/dmx512/term.htm
* https://erg.abdn.ac.uk/users/gorry/eg3576/DMX-phy.html
-->

====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 {{comment|(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.

<!--
Specs say &ge;0.5 Watt to be safe. DIYing:
* If you have standard values, then a 120 ohm (probably 0.25W in simple sets) is likely fine
* if you like specs and safety:
** it's easiest to buy a 120 (or 110) Ohm, 0.5W resistor.
** If you have a set of common-values resistors, then two 220s in parallel make for 110 Ohm at ~0.5W.

Some people like building debuggers with LEDs. A ~220 Ohm series resistor makes sense.
Note that LEDs light up only above ~2V, so are a little more pessimistic than necessary.
-->


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.

<!--
https://newsandviews.dataton.com/how-to-understand-dmx-and-avoid-potential-pitfalls
-->

===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. {{comment|(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


<!--
https://www.freestylersupport.com/wiki/dmx_basics:dmx_timing
https://www.etcconnect.com/Support/Articles/DMX-Speed.aspx
https://www.nxp.com/docs/en/application-note/AN3315.pdf
-->



====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:
* http://en.wikipedia.org/wiki/RDM_(lighting)


====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.
<!--
{{comment|(...or use ILDA instead, a standard more tuned to laser use, using a DB25 connector)}}
-->

===DIY===

<!--
Computer control can be a little finicky, because it's a moderately high baud rate with slightly interesting framing. 

A lot of circuits are nothing more than unbuffered transation between serial/USB to RS485.

Unbuffered, meaning that the computer has to get the timing right or the DMX devices will misbehave. 

Better devices might receive and remember the state, because their transmission is more dedicated and timing is easier.
-->



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 {{search|MAX485 pdf|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) {{comment|(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
:: check whether they are for modern TTL-voltage RS232, or older ~15V [[RS232]]
:: Look for things like MAX485, SP485{{verify}}, 
:: Note that translation for RS422 will also work (e.g. SN75176A, MAX490{{verify}}, others)
: 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.



<!--
FIFO buffering is only really important if you want to function as a repeater, and/or dealing with RDM.
If you do so in a microcontroller, you may want one with multiple hardware serial ports

, though because of the slightly unusual timing you need to address the port more directly than using Serial. There are good DMX libraries, use them
-->


<!--
===Multiple controllers===

Putting two controllers on the same wire probably won't damage anything, but there ''should'' be a good reason they are not talking at the same time - because that'll make receivers go haywire.
For example for RDM, that's part of the protocol.


It's more relevant when you have multiple lighting desks.

These will need a merger - a device which reads and buffers both,
has some logic that decides which values are used,
then sends its results.



It's also relevant if you sometimes want PC control, 
but want some basic things happening when it's not on.

You could put something inbetween to listen for the PC's master,
and whenever it isn't, does sends its own thing.

This is a little cheaty, because both sending makes things go haywire.
As such, you should be able to back off quickly enough for that not to be bothersome,
and stay backed off until it goes silent.

Ideally, give up some time between every frame to listen for anything that isn't you


You can avoid that by creating a (USB) master that has has such an idle mode,
but this is a little more involved.



https://arduino.stackexchange.com/questions/24523/rs485-multimaster-communication-with-collision-avoidance

https://github.com/MichaelJonker/HardwareSerialRS485/wiki

-->

===Microcontroller libaries===
{{stub}}

Conceptronics


DMXSimple
: https://github.com/PaulStoffregen/DmxSimple

TeensyDMX
: https://github.com/ssilverman/TeensyDMX


DMXSerial
: https://github.com/mathertel/DMXSerial

DMXSerial2 (extends DMXserial with RDM)
: http://www.mathertel.de/Arduino/DMXSerial2.aspx
: https://github.com/mathertel/DmxSerial2


<!--
http://playground.arduino.cc/Learning/DMX

-->

===Software===
<!--
https://dmxking.com/control-software


http://www.lifact.com



-->

===RDM notes===
{{stub}}

'''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
: {{comment|(...not to be confused with serial DMX over 8P8C-plugged network cables, which also exists and ''is'' in the standard)}}


DMX over Ethernet 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 don't expect to 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.

<!--
An Art-Net controller outputs DMX, meaning you can put it where it's physically handiest, and the controllers can be anywhere that there is ethernet or wifi - and support Art-Net (DIYers can note that the protocol is fairly easy).

-->


<!--
Art-Net 
Art-Net II 
Art-Net III (2011)
Artnet IV (2016)

-->

<!--
Has a pub/sub feature
-->
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==
{{stub}}
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 [https://en.wikipedia.org/wiki/Open_Sound_Control#Applications 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:
* http://en.wikipedia.org/wiki/Open_Sound_Control
* http://opensoundcontrol.org/spec-1_0

==Smart lights==
===ZigBee Light Link===

===Philips Hue===
<!--


Concepts: 
* Lights 
: themselves form a ZigBee-based mesh network (see ZigBee Light Link)

* Bridge
: functionally, a hardware device that embodies/mediates most of the API
: technically, translates Ethernet(/wifi) to Zigbee

* Portal - web based API that lets you talk to your bridge (and thereby your lights) from the 'net.

* App - something that can talk the API, basically via the bridge or portal{{verify}}



Ease of DIY interfacing: pretty easy

https://www.developers.meethue.com/documentation/how-hue-works

-->

===Philips ColorKinetics===
<!--

-->
===Yeelight===
<!--

-->
===LIFX===
<!--

https://eu.lifx.com/

-->