Improved DMX Shield Version for Arduino

The last version of the shield with it’s features and internals can be found on http://www.mathertel.de/Arduino/DMXShield.aspx .

This new version of the shield has no functional additions, so it works exactly like the shield in version v03 that is in use in multiple installations. But there are some improvements by adjusting some values and make its use more flexible when using it on top of an Arduino MEGA and other shields.

The most obvious features of the new (V04) version of the DMX Shield are the better placements of some of the components and the addition of all the shield connectors from the current Arduino boards.

Fixes to resistor values

The values from the optocoupler OK3 transferring the receiving signal in version v03 are adapted to the other optocouplers.

The 3 resistors (R4, R5, R6) are used to limit the current for the internal LEDs of the optocouplers. They had 300 or 470 Ohm in the first layout. These values are now made equal to 470 Ohm which is sufficient.

The 3 resistors (R7, R8, R9) are used to pull the output value of the optocoupler to HIGH also had different values of 470 or 4,7k Ohm. These values are now also made equal to 4,7k Ohm which is also sufficient. The downside of it is that the resistors are hard to distinguish.

I use both adjustments in some installations and they run fine.

The error in the naming of R1 and R2 is fixed.

Here is a picture of the shield with some assembly hints:

Flexibility for Arduino MEGA

The signals RX, TX and D2 are now brought to the pins d0, d1, d2 via a solder jumper. These 3 jumpers should be closed by dropping a small part of solder upon them for normal operation with Arduino Uno or Leonardo Boards.

If you like to use other serial ports or signals like on the Arduino MEGA you can leave these jumpers open and connect the signals the way you like.

The ICSP header of the Arduino board can now be brought to the next shield above the DMX shield by soldering a stackable header.

All the 4 holes from the Arduino Uno Board are now also available to the shield for building permanent robust stacks.

ICSP header and more pins.

All of these extensions are not needed by the DMX shield but it is a good practice to have connection pads and holes at these positions so the signals can be passed through.

Some Arduino shields are using the ICSP header to access the SPI signals from the ATmega chip. The Ethernet shield is a good example for that and there are good reasons to do so.

Not the new version of the DMX shield has 6 contacts right where a ICSP connector can be soldered to pass through the signals to a shield above.

Also 2 of the Arduino header pins have been expanded since some versions. The POWER connector is now 8 pins long and includes IOREF signal. The upper digital connector is now 10 pins long and include the SDA and SCL signals.

Because the DMX shield does not need these signals you can leave these pins without soldering a header or use the (old) shorter headers if you like.

Partlist DMX Shield

Here are the parts you need for a full assembly. It’s also a good order of soldering them.

Part name	Value	Description
Starting with the low parts...
R4, R5, R6	470 Ω	Bands: (yellow, purple, black, brown, brown*) or (yellow, purple, brown, silver*)
R7, R8, R9	4,7 kΩ	Bands: (yellow, purple, black, black, brown*) or (yellow, purple, red, silver*)
The resistors R1 - R3 should be adjusted for the role of the DMX board in your DMX setup. This configuration is for a DMX / RDM Controller. Don't use them when implementing a DMX or RDM Slave.
R1, R3	562 Ω	Bands: (green, blue, red, black, brown*)
R2	133 Ω	Bands: (brown, orange, orange, black, brown*)
Now the capacitators...
C1,C2,C3,C4	100n	Capacitors stabilizing the power. Label: 104
The dc-dc converter...
DC1	NME 0505	A dc-dc-converter. The chip that provides another 5 v source for the DMX signal converter.
Now you can check if the secondary 5v power is existing. Put it on top of an Arduino and measure the voltage at the capacitor C4. It should be near by 5V.
The optocouplers and the driver chips...
IC1	MAX481CPA	A MAX481CPA or MAX485 CPA from Maxim or another supplier used to convert the differential DMX signal into a logical signal. The 8 pin chip can be soldered directly or put on a socket. Be sure to place it in the right direction.
OK1, OK2, OK3	6N137	The optocouplers. The 8 pin chip can be soldered directly or put on a socket. Be sure to place it in the right direction.
...and the connectors
DMX		1X03 pinhead. I cut it from a longer (20 pin) one.
RGB		1X04 pinhead
stackable headers		You can solder the usual stackable headers or if you use the shield at the uppermost shield on the Arduino you can solder simple pinheads too.
ICSP		There is no need caused by this shield to solder a ICSP. You can solder one if you like to use the shield with another shield above that needs these connections.
solder jumpers		Don’t forget to close the jumpers when using a standard Arduino.

I will update the article on the web during the next days and will attach some pictures too.

I ordered more than I need for my projects so if you are interested in the PCB – let me know.

DMXBridge, a wireless DMX sender and receiver

There are situations where DMX cables are unwanted or just not practical. This project implements a wireless transfer of a DMX signal in the 2.4 GHz band using the Arduino platform and the popular transceiver module nRF24L01+ from nordic semiconductor.

The DMX protocol

Receiving and sending the DMX protocol from the ATmega chip is done by using the DMXSerial library and the built-in serial port. This implementation is using interrupts and is a good base for implementing a second protocol on the same chip.

The DMX Serial library has a built-in 512 byte buffer for a DMX universe that is accessible using the functions provided by the library. After initializing the library and starting the communication the interrupts ensure the communication in the background.

You can find a lot of details in the article about the DMXSerial library.

The Wireless protocol

The 2.4GHz RF Transceiver is connected to the Arduino board or ATmega processor by using the SPI interface. The library for driving this chip I used is the library from Greg Copeland that you can find at https://github.com/gcopeland/RF24. After initializing the library it is possible to send and receive data by using the provided functions of the library. The library transfers all the commands and data to the nRF24L01+ chip will also handle all the transfer details in the background.

Implementation

Because the libraries handle most of the communication details the implementation of this project only has to close the gap between the 2 protocols. The main differences between them are

Frame size: DMX is using a max. 512 byte long frame for sending all the values of all channels at once. The Transceiver uses a much shorter protocol that can transfer up to 32 bytes in one frame. I have seen controllers that do not send all the 512 bytes when only some channels are used in the setup.

Transfer speed: DMX is constantly using a 250 kBaud serial transfer speed on the DMX wire. There may be longer gaps between the frames and also between the individual bytes of a frame but it is common to use the maximum possible transfer speed. The Transceiver is supporting 3 different transfer modes

The solution I found and implemented here is to break up the 512 channels of the DMX information into smaller packages.

The sender

There are 2 buffers of DMX values. One contains the values I have received lately from the DMX protocol. The DMXSerial library is used to listen to the DMX protocol and fill this buffer.

The second buffer contains the values that have been sent over the wireless.

The values of both buffers are compared to find the recent changes and to send them with priority. If there is no difference between the 2 buffers no priority data will be sent.

To enable the addition of new receivers and to heal dropped packages all the DMX data is sent from time to time regardless whether there are changes on not.

The package transferred wirelessly contains a start-address and the actual 8 values starting at this address. The sender just sends the package without requesting any handshake from the receiver. This is called the broadcast mode of the nRF24L01+ modules that enables to use multiple receivers.

The receivers

The receiver only needs a single DMX buffer. All data from the incoming packages is directly taken into this buffer.

The DMXSerial library is used to send this information using the DMX protocol.

Setup the hardware

Both, the sender and the receivers need the DMX interface hardware attached to the serial interface and a nRF24L01+ module attached to the SPI bus. A prototype for this setup I used is the DMX Shield I published and a hand-soldered nRF24L01 adapter. The DMX shield is not forwarding the ICSP pins yet so this will only work on the Arduino UNO and older boards. (See discussion in Arduino Shield for NRF24L01+ post).

You need 2 of these at minimum.

Setup the software

• Install Arduino development environment.
• Add DMXSerial Library from http://www.mathertel.de/Arduino/DMXSerial.aspx
• Add the RF24 library by Greg Copeland from https://github.com/gcopeland/RF24.

Now you should be able to open and compile the provided sketches and upload them to the Arduino hardware.

The sketches I can provide for now are working in my environment and are not yet optimal for rough environments like stages. There are still some optimizations to do like sending smaller or larger packages and testing different transfer speeds. I like to get feedback from you.

Links

• The sketches can be downloaded from
  http://www.mathertel.de/Arduino/DMXBridgeStart.aspx
• nRF24L01+ specifications
  http://www.nordicsemi.com/eng/Products/2.4GHz-RF/nRF24L01P
• DMXSerial Library
  http://www.mathertel.de/Arduino/DMXSerial.aspx
• nRF24 Library by Greg Copeland
  https://github.com/gcopeland/RF24.

Hints on using NRF24L01+ with Arduino

I like to share some liks to the ressources on the internet that I found helpful for implementing projects using the Ultra low power 2.4GHz RF Transceiver NRF24L01+ with the Arduino platform.

The chip specifications

The NRF24L01 (no + at the end) was replaced by the NRF24L01+ (or sometimes called NRF24L01P). Be sure to get the new chip when buying an breakout board.

The nRF24L01+ is drop-in compatible with nRF24L01 and on-air compatible with nRF2401A, nRF2402, nRF24E1 and nRF24E2. Intermodulation and wideband blocking values in nRF24L01+ are much improved in comparison to the nRF24L01 and the addition of internal filtering to nRF24L01+ has improved the margins for meeting RF regulatory standards.

The old chip: http://www.nordicsemi.com/eng/Products/2.4GHz-RF/nRF24L01

The new chip: http://www.nordicsemi.com/eng/Products/2.4GHz-RF/nRF24L01P

You should read the nRF24L01+DataSheet, even if it is long and with many details – but that’s what you will need: http://www.nordicsemi.com/eng/content/download/2726/34069/file/nRF24L01P_Product_Specification_1_0.pdf

About ShockBurst^TM

This is a nice to read whitepaper with a description of the ShockBurst^TM transfer features of the chip:

http://www.semiconductorstore.com/pdf/NewSite/nordic/WP_nRF240x_ShockBurst.pdf

Arduino compatible Libraries for NRF24L01

There is no official “Arduino” library that is maintained by the core Arduino team so you have to look for the available libraries on the internet.

The  web site http://www.tinkerer.eu/ from Stefan Engelke in 2009 provides a native NRF20L01 library, the original MiRF library (not Arduino specific) and a native SPI library See http://www.tinkerer.eu/AVRLib/nRF24L01, and http://www.tinkerer.eu/AVRLib/SPI . I mention this library because it uses interrupts that most Arduino samples don’t.

The MiRF library was ported to the Arduino platform and is using the Arduino SPI library and is described on the arduino playground article: See http://playground.arduino.cc/InterfacingWithHardware/Nrf24L01

J. Coliz (a.k.a. maniacbug) implemented a ARDUINO specific library often called the RF24 library. Its available at https://github.com/maniacbug/RF24/ and was used as the base for implementing other libraries (see below) the last commit to this projects was last on 2012/06/23.

Greg Copeland forked (copied over) the library from maniacbug and added some useful stuff including a scanner sample application. He is currently (2013.04.09) supporting his work. See https://github.com/gcopeland/RF24.

Arco van Geest (a.k.a. gnulnulf) also forked the library from maniacbug is currently adding support for the Raspberry Pi. See https://github.com/gnulnulf/RF24

Stanley Seow forked the version gnulnulf https://github.com/stanleyseow/RF24 also working on upport for the Raspberry Pi.

Critics

There are too much libraries out there for my opinion and those starting from J. Coliz are using the GNU General Public License (not LGPL) and therefore are not compatible with the Arduino license policy.

J. Coliz also used the stdio.h printf() functionality ??? causing more usage of the program memory

For my personal projects I used the library from Greg Copeland for my first steps to discover the functionality of the chip.

 

 

 

Samples and Projects

Poor Man's 2.4 GHz Scanner:
http://arduino.cc/forum/index.php/topic,54795.0.html

Home Automation – Designing a remote module:
http://geekboy.it/projects/home_automation/home-automation-design

Sample without using a library:
http://blog.iteadstudio.com/nrf24l01-wireless-module-with-arduino/

A sample using the MiRF library:
http://www.bajdi.com/playing-with-nrf24l01-modules/

Step-by-Step introduction using the RF24 library:
http://arduino-info.wikispaces.com/Nrf24L01-2.4GHz-HowTo

Network Layer for RF24 Radios:
http://maniacbug.github.io/RF24Network/index.html

A very detailed tutorial in German:
http://www.mikrocontroller.net/articles/NRF24L01_Tutorial

Other Stuff

These links are not related to Arduino itself but when reading you may also find some interesting information.

• This web site contains several tutorials from 2011 that still apply: http://blog.diyembedded.com/
• http://nrqm.ca/nrf24l01/
• http://wiibrew.org/wiki/Logitech_USB_steering_wheel

...

Using the SPI bus with Ethernet, SD-card and NRF24L01 and other slave devices together

I currently work on an project using the popular NRF24L01 module where I came across the question how to avoid conflicts of new designs and existing Arduino boards.
The problem when using the W5100 based Ethernet shield including the  SD Card adapter and the NRF24L01 Modules together with a Arduino UNO board is that all of them are using the same SPI bus for the data transfer to the chips. Here is an overview of how to make them work all together.
Here the master is always the same ATMEGA328 chip on the Arduino board and the 3 chips are slave devices.

The SPI bus concept

A brief explanation of the SPI bus can be found on wikipedia. See http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus
The SPI bus needs 4 signals to work:
SCK or SCLK (serial clock) The clock signal that sets the tempo for any data transfer. This signal is generated by the master chip.
On the Arduino Uno this signal is available on pin 13 and ICSP 3.
MISO (master input, slave output) This signal line transfers the data from a slave device to the master chip.
On the Arduino Uno this signal is available on pin 12 and ICSP 1.
MOSI (master output, slave input) This signal line transfers the data from the master to the slave devices.
On the Arduino Uno this signal is available on pin 11 and ICSP 4.
SS or CSN (Slave Select) This signal makes a slave active by selecting it with a low signal.
On the Arduino Uno this signal has to be discussed…
Remark: The signal lines SCK, MOSI and MISO are also available on the ICSP header, see below.
The signal lines SCK, MOSI and MISO can permanently remain connected to all participating chips. However the Slave Select signal has to be different for every device.

Advantages in using the ICSP header

The SPI signals on an Arduino Mega board are not available on the pins 10, 11, 12 and 13 because this board uses another processor. But because programming an ATMEGA chip through the ICSP is internally also using the SPI interface, the signals are available on the ICSP header too. With the Arduino Ethernet Shield Version 06 the design has changed so that the SPI signals are not taken from the pins 11, 12 and 13 but from the pins ISP 4, 1 and 3. If you use an Arduino UNO or 2009 however these pins are connected on the main board.  When designing new shields for Standard and MEGA boards with SPI usage I recommended using the ICSP header like the Ethernet Shield does.

Pin 10

The Arduino pin 10, also labeled SS, also known as PB2 for ATMEGA328, is used by ATMEL to indicate whether the processor is used as an SPI master or slaver device. That pin 10 must remain an output or the SPI hardware will go into 'slave' mode.
Using this pin 10 for example on the Ethernet Shield is fine, but if you use other SPI slave devices, keep in mind to no use this pin for input purpose – better don’t use it to avoid conflicts.

Using multiple SPI bus slave devices

When using multiple slave devices on the same SPI bus there is no principle problem with the lines SCK, MOSI and MISO. Because every slave device needs its own slave select signal there are conflicts using the available Arduino pins. When you stack multiple ARDUINO shields on a single Arduino board you may also have conflicts with other pins the shield uses so you have to take care of other conflicts too. Here are some common pin usages:

Arduino Shield	Salve device	Arduino Pin
Ethernet version 01	W5100 chip Slave Select	10
Ethernet version 06	W5100 chip Slave Select	10
Ethernet version 06	SD card Slave Select	4

Using a NRF24L01 radio module

In different samples where the NRF24L01 radio is using the Arduino pin 9 for SS and using pin 8 for the Chip Enable signal but also 8 and 7 is used in same samples. There is no standard definition right now and therefore you have to tell the NRF24L01 library what signals to use for Slave Select and Chip Enable.
I personally recommend using 7 for Chip Enable and 8 for Slave Select because the pin 9 is one of the possible PWM output pins. When designing new Shields these pins assignments should be changeable in any way, just to be friendly to other shields… and having the chance to settle conflicts.

More Readings:

Design of the Arduino Ethernet Shield: http://arduino.cc/en/Main/ArduinoEthernetShield

Using the SD-Slot on the EthernetShield with Hardware SPI: http://playground.arduino.cc//Main/EthernetShieldSDHardwareSPIMod General tutorial: http://tronixstuff.wordpress.com/  About the NRF24L01: http://playground.arduino.cc/InterfacingWithHardware/Nrf24L01