DMXing WS2812 13*13 pixel display from Nano (as an openEnttec device) [editted]

I am working on a new and exciting project using WS2812 RGB LEDs

I have done several but this one in my most ambitious..

I want to drive a matrix of 13*13 RGB WS2812 Leds using DMX data that I am receiving from a source, and I want to run this on a standard 16MHz Arduino UNO-type board

DMX data comes in over UART @ 250kbps WS2812 LEDs need to be driven at about 800KHz

Sounds easy at first, but when you look into it you find there are problems

1) DMX can arrive at a rate of 44 frames per second, one 512 byte frame can take 23ms to receive 2) DMX frames can run almost end-to-end 3) Sending 507bytes of RGB data to WS2812s takes 5ms and cannot be done between DMX frames 4) Interrupts cant be used to collect UART data as this might innterupt the WS2812 data flow 5) UART framing error must be continually monitored to stop rogue data packets getting through

13*13 pixel matrix has been chosen as this is the neatest, squarest and largest solution possible using 507 bytes out of a maximum of 512 DMX bytes, with 3 bytes required per WS2812 LED

With all this in mind I have started writing some fast assembler code which does the timing required for running the WS2812 leds (20 cycles per bit), to get the right timing (800KHz) the code has a few NOPs in it. I am going to use these NOPs to interleave the RX DMX assembler task in with the WS one.

To send each WS2812 byte at 800KHz bit rate, I need to send one byte every 10us (8 x 1.25us) One byte of DMX data will arrive every 44us (11 x 4us)

If I stretched out the sending of the WS2812 data by 10% I could send one byte every 11us. Therefore for every 4 bytes of WS2812 data I send, I could recieve ONE DMX byte (4 x 11us = 44us)

I could follow this idea through all the bytes I need to send until I finish reading byte 507, then I can carry on receiving DMX bytes until a further 55us passes by which time I can set the WriteLatch of the WS2812 devices

The data will be arriving slower than I will be outputting, so from the outset I will be writing OLD data to the WS devices, as the new data wont have arrived in time, but this is ok, I will only be ONE frame behind, and that wont be noticable

So, how am I going to drive this with DMX ?

I have found this cracking FREE program called JINX, I can create any size of LED array and send graphic animations, text, video, etc etc out of the USB port, all I need is a cheap and simple USB-DMX dongle (cheap Entec device) to convert this to DMX for my board

JINX WEBSITE

As usual, I will be posting updates, info and ideoa as I proceed, ultimately releasing the code when it is in a workable state

Quite a challenge!

Did you consider a two-chip solution? One Arduino could receive the dmx frames over serial, then transfer them over spi bus to the second Arduino. The spi transfer might only take 1~2 milliseconds. The second Arduino would them have plenty of time to send data to the ws2812 leds.

Paul

Yes I did, but I always love to push whatever devices I have to the absolute MAX, if it can be done then I WILL do it !!

I love a good challenge :)

The idea started from taking a basic Arduino, and not adding anything apart from a single connection to the WS2812 devices

I even think the UNO's USB->Serial convertor could be used to grab the DMX data as it comes through the UART from the JINX software... although this method is unproven, but essentially all the interface really needs is an FTDI as we dont really need to go to differential RS485 just for this test...

so why go the route :

[PC:JINX]--->USB--->USB/DMXconvert--->DMX/SerialConvert--->[UNO]

when we could go :

[PC:JINX]--->USB--->[UNO]

I looked into the USB->Serial interfaces that come with UNOs and NANOs

Apparently newer UNO's have a different type of USB interface chip (ATmega16U2 or 8U2) which wont work like an FTDI device

OpenDMX for Arduinos

At least the Nano's will still work, which is fine for me as this project does not need the complexity of a UNO at all, something really simple like the NANO is perfect

I don't think a Nano is any less complicated than Uno, just smaller.

What about a Leonardo/Pro Micro? USB on-chip. Don't know if that would overcome any baud rate issues?

I thought before I proceeded writing any intricate software for this nuts project I would test the hardware and PC application I have…

So, I tested a plain (super cheap £1.50) Nano board (with CH340 USB->Serial driver on board) with the JINX software… It wouldnt recognise the Nano as an openEntec device, but I then selected the device as a MiniDMX device and it showed the correct port and when I started streaming on the JINX software the RX LED started flashing like mad, so my guess it… it works… a slightly unusual Hack, but nethertheless a VERY cheap working one

On now with the software…

PaulRB:
I don’t think a Nano is any less complicated than Uno, just smaller.

What about a Leonardo/Pro Micro? USB on-chip. Don’t know if that would overcome any baud rate issues?

Hi Paul,

not sure if you saw where I was going with this… the only problem is the Newer UNOs have a different interface chip on them, I havent tested a new UNO with the JINX software yet, so I cant tell you if it works directly as a DMX interface

I have tested a UNO now, my one has ATmega16U2 as a USB interface chip

I cant get this to run in JINX, the program keeps reporting that it cant find the device, even though windows device manager happily sees the UNO

Just as I thought

It is not "Newer UNOs", it is all UNOs.

The bogus boards sold in profusion on eBay as "UNO"s (which they are not as the definition of a UNO is containing a mega16U2, otherwise it is actually a Duemilanove) generally have a CH340. But a Nano clone - yes also containing a CH340 - is a far more useful format for serious projects.

Paul__B: It is not "Newer UNOs", it is all UNOs.

Ah, ok, my information was based on something I read on the internet that older UNOs had a FD before they changed to the 16U2

Further testing revealed that the NANO/CH340 (although can see data from the PC app) is not working in the same way as a FD interface device, JINX can see the port, but the data is incorrect for it to run.

I will investigate more, in the meantime I have emailed the designer of JINX asking if he knows a reason why CH340 cant be used as an openEntec device

I found I had a NANO that had an FD232 on board
I managed to get it configured in as an openEntec device within JINX

So far I can see reception of the DMX data via the interface directly on the NANO

tonight I shall play some more and see if I am actually getting what I think I am getting !!


These FD232 Nano’s are hard to come by as far as I can see
Many ebay suppliers say the device has an FD part on it, but actually its the CH340

I found one supplier that offers a “100% ORIGINAL FTDI FT232RL” on the Nano board

the cost is a little more than the hi volume ch340 nano (£2.72, instead of £152) but we shall see…

http://www.ebay.co.uk/itm/221930229715

Last night I tried a slightly more extensive test on my 'FD232' Nano reading DMX directly over USB as an openEntec device

  1. I set the board LED to firstly detect 'break' via monitoring the framing error UART flag
  2. I then set the LED to detect the first byte as zero (start byte)
  3. I then set the LED to show the value of the first usable DMX byte
  4. I then set the LED to show that 512 bytes had been recieved

In all cases I was able to detect the correct values when running JINX software

my next stage is to properly translate the DMX values into a WS2812 stream to drive a string of LEDs

more to come :)

If this doesn't work with the CH340, then clearly either the CH340 driver is non-standard, or the JINX code does not interact correctly with a standard driver.

The question is - which?

The interface should be standard.

For full DMX refresh rate, the assembler is going to be a little tricky to get right with the timing of DMX reception and streaming of the WS2812.

The stream needs to be sent WITHOUT any breaks to ensure the data gets through to the LED correctly

At the same time as I am doing this I must also receive and process DMX bytes at full chat

I cant use interrupts, but my plan is good, and carefully based on processor cycle times to do a bit of each task interleaved together in the same unbroken code stream

I dont think the code will be particularly long, just perhaps hard to understand for those who dont use AVR assembler, therefore its not really an Arduino project, but i will make it Arduino compatible

--

One last thing, I successfully managed to have both the JINX application and Arduino IDE open at the same time (even though they were using the same USB/UART port), I could make changes on the Nano code, then start the DMX stream, see my results, stop the DMX stream, and make more changes.. without having to shut either JINX or the Arduino IDE down to release the USB/COM port

Paul__B: If this doesn't work with the CH340, then clearly either the CH340 driver is non-standard, or the JINX code does not interact correctly with a standard driver.

The question is - which?

The interface should be standard.

I believe the CH340 works in a way that does not comply with the openEntec standard, which is what is expected from JINX. JINX specifically looks for an openEntec device to connect to, there are other options (ethernet and other serial-types) but I specifically wanted to work on a level playing field using DMX

If i tried to connect to the CH340 it couldnt find it.. When JINX connected to the FD232 on the Nano it showed up in the connection window as a string of numbers/hex, which could be some value coming from the device via the driver (not sure)

All I know is the FD232/FTDI Nano works where the CH340 doesnt, although I hope to look into this more and find a solution

I have emailed the developers of JINX to see if they have a solution, but I guess I am at the bottom of the list as a 'fun' user :)

mcnobby: One last thing, I successfully managed to have both the JINX application and Arduino IDE open at the same time (even though they were using the same USB/UART port), I could make changes on the Nano code, then start the DMX stream, see my results, stop the DMX stream, and make more changes.. without having to shut either JINX or the Arduino IDE down to release the USB/COM port

Nor should you.

The IDE only opens the port in order either to download, or implement the serial monitor. The port should be closed - as far as it concerns the IDE - outside of those times.

Looking further into JINX last night I also discovered that you can 'patch' parts of your on-screen design to a particular USB/UART port

Although I will be designing for a 13*13 pixel (507 DMX channel) display panel, I realised I could make several panels, each one being driven from a different NANO

So in theory, In JINX I could have a 26*26 pixel design and patch 4 separate '13*13' Nano displays together, or more if I so wished... the only limitation is current being drawn over the USB, but I sure wont be driving the LEDs from USB, so it will be just whatever each AtMega328 takes, plus a little for each FTDI chip

I have written all the software for this JINX(openEntec DMX) to WS2812 convertor into a NANO and shall be testing it this weekend, after which I will be pleased to publish my code

It has been quite a struggle getting the timing of DMX RX and WS2812 data interleaved down to an atomic level, but I think I have got it now

It works !!
I shall be posting video link soon