Electronics notes/Localish communication notes

From Helpful
Revision as of 12:43, 8 October 2024 by Helpful (talk | contribs) (→‎DMX over ethernet)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
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 and video 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 · Common terms, useful basics, soldering · landline phones · pulse modulation · PLL · Multimeter notes · signal reflection · Project boxes · resource metering · Radio and SDR · vacuum tubes · Unsorted stuff · 'E-fuse'

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

See also Category:Electronics.

📃 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. 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
(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, 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.


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

(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 — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

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

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

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



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 — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

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

ZigBee Light Link

Philips Hue

Philips ColorKinetics

Yeelight

LIFX