Electronics notes/Localish communication notes

From Helpful
Jump to: navigation, search
This is for beginners and very much by a beginner. It's meant to try to cover hobbyist needs, and as a starting point to find out which may be the relevant details for you, not for definitive information.

Some basics and reference: Volts, amps, energy, power · Ground · batteries · resistors · changing voltage · transistors · fuses · diodes · varistors · capacitors · inductors · transformers · baluns · amplifier notes · frequency generation · skin effect


And some more applied stuff:

IO: IO and wired communication · localish communication · wireless (ISM RF, GSM, RFID, more) · 802.11 (WiFi) · 802.15 (including zigbee)


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

Some stuff I've messed with: Avrusb500v2 · GPS · Hilo GPRS · Bluetooth serial · JY-MCU · DMX · ESC/POS notes

Audio notes: basic audio hacks · microphones · amps and speakers · device voltage and impedance, audio and otherwise ·

Less sorted: Common terms, useful basics, soldering · Microcontroller and computer platforms · Arduino and AVR notes · ESP series notes · Electronics notes/Phase Locked Loop notes · mounts, chip carriers, packages, connectors · signal reflection · pulse modulation · electricity and humans · Unsorted stuff


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

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


What you can expect

It's a serial bus that you connect a bunch of listening devices to.

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

The speed it runs at means it can update a universe up to 44 times per second.


First made for dimmers, but applicable to anything you can usefully express with one or more parameters in a 0-255 value range.


Most modern devices have multiple parameters and 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. Eight or so can happen for things like motorized, colored, gobo'd lighting.

You can alter this base address, often using using DIP switches or a pushbutton/7seg interface or such, sometimes via software.


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


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


There is no error correction. So you probably want err on the careful side when considering shielding, isolation, cable length, and e.g. repeaters to not have too many devices on a single segment.

Physical

DMX is a single shared RS485 bus clocked at 250kHz.

Everything's wired to the same cable (not isolating and repeating like e.g. serial MIDI does), so a typical driver sees the combined load current from all devices.


Typical impedances mean you can put approximately 32 devices on a string (this seems to be implied from RS485 specs), after which you should use a splitter/repeater to, effectively, power the next segment.

There are reasons it may be better and that it may be worse than 32, but it's a good guideline.



Voltage

Electrically this is RS-485, differential signalling, so only really needs two wires, and in practice also shield.


Max differential voltage is 6V. Typical is 5V.

Specs say devices should deal with it being as low as 0.2V, but don't expect this from all devices.

http://www.opendmx.net/index.php/DMX512-A#Voltages_and_power_dissipation



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 (tempting since they're also XLR3) is neither of that, and has has an ill-fitting characteristic impedance at the speeds DMX uses. It'll work on your test bench with a few meters of cable, but will spectacuraly fail to work in a large installation. For very similar reasons, don't try to cheat one section with a bit of mic cable, it causes impedance mismatch)


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 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 run your own, then shielded twisted pair network cable is a good choice - it's balanced pair, ~100 ohms, tends to be 24AWG or 22AWG (and you shouldn't go thinner than that on longer runs).

Since these are differential on balanced lines, a little interference is not a huge problem, yet shieded cable is wise because they're rarely 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.

Chances are they'll 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, possibly XLR5 with an adapter to XLR3, sometimes both XLR3 and XLR5.

Repeaters and such tend to have both.

Devices and cables are often XLR3. You can use adapters for the occasional XLR5-only device.


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 the(/each) 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. Specs say ≥0.5 Watt to be safe, but the more ubiquitous 0.25W sort is likely fine. (Note you if you have two 220 ohms lying around, those in parallel is more in-spec)


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 a resistor on its DMX out, and you can use that instead of plugging in a physical terminator (it will also 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.

Some 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 so when powered on; powered off they may not leave the line in a usable state)


Non-trivial layouts: If you Y-split just by connecting wires it may work, since it's a shared bus anyway, but electronically you will more easily run into issues with signal reflection and, if these strings are longer, too much load.

Repeaters and splitters (which are more or less the same thing with different amounts of serarate 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.

(It can be faster if it stops early(verify) - which you can only do when there's no useful devices on high addresses)


DMX largely 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 (which ), so for the most part, the timing isn't very critical and buffering not really necessary (but 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

The least you need is translation between RS232 to RS485, and an XLR socket.


Since not quite all built-in PC serial ports could be run at 250000 baud, and not all computers have physical serial ports anymore, it's common to see USB devices.


You can use an Arduino's USART, 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.

FIFO buffering and 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



When building DMX receivers yourself:

  • There are various ready-made ICs that convert between differential voltages you want (look for references to RS-422 and RS-485) and computer/uC serial ports (TTL RS232, sometimes 15V RS232). Look for things like SN75176A, MAX490(verify), and various 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.


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)



Microcontroller libaries

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, 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.


See also:


sACN

Specifically sACN/E1.31

https://en.wikipedia.org/wiki/Architecture_for_Control_Networks


KiNET

https://opendmx.net/index.php/KiNET


DALI

https://en.wikipedia.org/wiki/Digital_Addressable_Lighting_Interface


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, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

OSC, Open Sound Control

tl;dr:

  • Decent latency
  • can decode complex data without pre-set knowledge (because self-described packets)


  • Usually over UDP/IP, often over Ethernet.
    • often aimed at a specific host (is practical enough)
    • you could broadcast (for simplicity)
    • OSC itself can talk to multiple hosts
    • 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 choses 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.
used as such in these and more
  • 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.

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: