Go Down

Topic: FINISHED PROJECT: ATTiny13A DMX Receiver, to WS2813 LED controller in 962 bytes (Read 19565 times) previous topic - next topic


There is a far better solution to serial reception than the above, it relies on counting cycles between leading edges of the received bits, and when a bit changes state within a 'window' the syncronisation is reset. With this application is it very useful as I have found that temperature and differences in ATTiny13's effect the clock somewhat and sometimes get data errors.

So either a resync on each bit is good (but tricky to implement) or a sync on the startbit of each byte only may be better

I have only written this approach in spec form and not coded yet, but it is on my list, and I am hoping it will still fit into the <1k bytes

This current application works by this method
1. lock onto start of DMX stream
2. read just enough bits/bytes that we need, then and stop reading
3. write serial data to the serial LEDs
4. the current DMX frame will still be streaming here but ignore it go back to (1)

I am not a big fan of coding like this, I prefer interrupts, but sometimes you have to break the rules, especially when you are trying to sniff data at 250kbps and write to LEDs at 800KHz !!


To be honest the whole code would be better written in assembler rather than dodging in and out of C all the time, it would probably run more accurate and efficient too

this would be one C-code file with the assembler embedded in, and would happily run in the Arduino environment, so nothing special to do apart from write using USBISP


I have rewritten this code to efficiently decode DMX512, all in assembler
using the internal 9.6MHz resonator, and accurate sample points, start/stop bit detection, Break and MAB detection, and error detection.

Currently using this to try and write to a much larger string of WS2812 LEDs, but the limitation is RAM (60bytes). I tried to slow the WS writes down so that they fell in-line with RX speed of the DMX bytes, but this is too slow for the WS chips and they seem to do their own thing !!

Nevertheless, I have a good solid DMX receiver

Just wondering what projects I can use this simple/cheap/small device on

DMX switch/relay ?

Any suggestions ??


Nice job for this, but asm is not in my chords (yet) unfortunately :)

I've seen lots of cinese commercial products like rgb pars (many watts) using overpowered stm8 mcus, similar in power to the 328p.

Open source tiny code is state of art for receivers, i'm trying myself to make custom pars or scene lights  with cheaper and smaller avr.

kudos to you


Hello imayoda

I am working on a much better DMX RX to WS controller, there were flaws in this design, which now I understand them I will be improving, most of the code is written, about 95% in AVR assembler

This will shortly be an "ATTiny85 to WS2801/11/12 NRZ & SPI converter", using the full 512 bytes (170 Pixels) and should be fully compliant with DMX512 (but not RDM)

Thanks for your comments



with this project, you are able to send DMX and change the led lights?

I would like to control these leds via an existing DMX controller. red green and blue faders.
Where in the code does it tell the LEDs what color to be?


with this project, you are able to send DMX and change the led lights?
Yes, that is the idea

I would like to control these leds via an existing DMX controller. red green and blue faders.
Where in the code does it tell the LEDs what color to be?
if you are using WS2812 leds then following would occur:
DMX chan 1 = Pixel 1 Green
DMX chan 2 = Pixel 1 Red
DMX chan 3 = Pixel 1 Blue
DMX chan 4 = Pixel 2 Green
DMX chan 5 = Pixel 2 Red
DMX chan 6 = Pixel 2 Blue


This project really needs a bit more thought and improvement
The ones I made work fine, but some controllers may cause this to go screwy.. on reflection it really needs an overhaul, perhaps all written in asm


thank you for your reply. That would take up a lot of channels if I planned on using several strips.


The ATTiny13A has only a very small amount of RAM, 60 bytes from memory, therefore I only used 12 channels (4 RGB Pixels) to allow me left over bytes to run my program, it is very tight !!


Hi Bob, Have been reading several posts around DMX on Arduino.

I can confirm an answer to a question you asked sometime ago... DUE doesnt work with TinkerKit DMX Shield...

I have a project that I can get two halves to work, but need to interface them together.

Environment: Start lights and track signals for a Slot Car setup (havenwoodraceway.co.uk)

Objective: To control 2 x Banks of 5 x PAR CANs to simulate the start sequence of races
(Imagine PAR CANS doing the job of the LED's in this video

Current Situation:
I have a PC running an application RCS 64 (rcs64.com) which controls a UNO for the lighting of individual LEDs'. The developers of this application are not prepared to open their source as they want to control the installation of their application from a single exe (understandable as they have a lot of development stuff going on that they are trying to support).

My current thought was to implement an UNO driven by RCS64 and for it to connect to a DUE with Tinkerkit DMX Shield on, which would sniff the PWM output and then translate to DMX signals to the PAR CANS.

Cant get DUE to work with DMX Shield. So thinking of getting another UNO to do the DMX job.

But having seen your work I wonder if you have some other suggestions on how to achieve the objective? Grateful for any thoughts...

Best regards


Hi Paul

Google "MAX485 DMX"

The Max485 is a single chip solution to convert the serial data into differential data required for DMX.
I make these little convertor boards for next to nothing as you can buy MAX485 very cheaply, and you only need 0v/5v supply and the serial connection to TX from the Arduino



Thank you very much Bob. Chip has been ordered...
Suspect I might be coming back to you at a later stage to sanity check my thoughts on next steps.

Best regards for now


And a general question...

In my logic the 5 DMX cans, hooked together in a serial fashion with XLR (3 pin), should each be addressed with their own first channel... i.e. 1st can (master) is channel 1 - red, can 2 - Channel 16 - red, Can 3 - Channel 24 etc

When using the DMX Shield I can only get action on the first can and first channel. My send strings from "Serial Monitor" have no effect on the subsequent cans....

Any suggestions?

Go Up