Electronics notes/Localish communication notes

From Helpful
Jump to navigation Jump to search
This is for beginners and very much by a beginner / hobbyist.

It's intended to get an intuitive overview for hobbyist needs. It may get you started, but to be able to do anything remotely clever, follow a proper course or read a good book.


Some basics and reference: Volts, amps, energy, power · batteries · resistors · transistors · fuses · diodes · capacitors · inductors and transformers · ground

Slightly less basic: amplifier notes · varistors · changing voltage · baluns · frequency generation · Transmission lines · skin effect


And some more applied stuff:

IO: Input and output pins · wired local IO · wired local-ish IO · ·  Various wireless · 802.11 (WiFi) · cell phone

Sensors: General sensor notes, voltage and current sensing · Knobs and dials · Pressure sensing · Temperature sensing · humidity sensing · Light sensing · Movement sensing · Capacitive sensing · Touch screen notes

Actuators: General actuator notes, circuit protection · Motors and servos · Solenoids

Noise stuff: Stray signals and noise · sound-related noise names · electronic non-coupled noise names · electronic coupled noise · ground loop · strategies to avoid coupled noise · Sampling, reproduction, and transmission distortions

Audio notes: See avnotes


Platform specific

Arduino and AVR notes · (Ethernet)
Microcontroller and computer platforms ··· ESP series notes · STM32 series notes


Less sorted: Ground · device voltage and impedance (+ audio-specific) · electricity and humans · power supply considerations · Common terms, useful basics, soldering · landline phones · pulse modulation · signal reflection · Project boxes · resource metering · SDR · PLL · vacuum tubes · Multimeter notes Unsorted stuff

Some stuff I've messed with: Avrusb500v2 · GPS · Hilo GPRS · JY-MCU · DMX · Thermal printer ·

See also Category:Electronics.

These are primarily notes
It won't be complete in any sense.
It exists to contain fragments of useful information.

DMX

Functionality you can expect

DMX is a shared serial bus used for lighting control.


You can connect a bunch of listening devices, each of which 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)


There are up to 512 distinct channels in a universe, each of which have a 8-bits value (0-255).

The communication speed means it can update a full universe up to 44 times per second.


You will have to manually tell your controller about all the devices, and what channels they're on.


Most devices only listen, but there are variants that communicate both ways (RDM, and some proprietary stuff).


There is no error correction.

You want to set up your wiring decently to avoid glitches, considering cable length, shielding, isolation, and a terminator.

Also, because it's a RS485 bus, you want to consider repeaters when you have more than 32 devices on a single segment.

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




Microcontroller libaries

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)

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


Software

RDM notes

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:

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

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)

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:

Smart lights

Philips Hue

Philips ColorKinetics

Yeelight

LIFX