SMARTCRIB

1. What is Smartcrib?
2. Design principles
3. Hardware Architecture
4. Software Architecture
5. Installing the application
6. Cost estimate
7. Volunteer

1. What is Smartcrib?

Smartcrib is a project whose purpose is to offer a low-cost solution for house automatisation (lighting, multimedia and household items control), accessible via mobile devices. The idea of this project came after an exhtensive study of what similar solutions are currently available – most of them being expensive and the home-made ones lacking documentation. Our vision is that every person that would desire the automatisation of their home to the extent that would suit best their needs should be able to do so without spending a fortune and while being able to adapt and adjust the solution as much as possible.
Back to index »

2. Design principles

1. portability and platform-independence
2. usability
3. stability and robustness
4. extensibility
5. low-cost

3. Hardware Architecture

The overall hardware architecture is described in the image below.
The main components are :

• a Web and DataBase server – used for hosting the Web server, the DB and the application itself
• one or several DMX interfaces – used to communicate from the server to the DMX devices (dimmers or switches)
• one or several dimmer/switch packs – used in the actual control over the devices.
• wireless router – used in order to have an internal network
• smartphone – with the capability to connect to the internet

The flow of the application is the following:

The user connects to the wireless network using the smartphone and makes a request for the Smartcrib application homepage to the web server.

The web server will render the home page of the user according to the user’s permission and preferences.
The user will select the devices that should be controlled from the homepage and will select a particular command (dimm the lights or turn on the media player).
This command will be sent to the application on the server and from there it will be dispatched to the DMX interface and the dimmer/switch pack corresponding to the device (if it is targeting a DMX device) or to the media application.
The response will return to the application on the server and will be displayed on the user’s smartphone.

A more detailed description of each device involved, bellow.

The DMX interface is a control device used in the DMX communication between the server and the connected devices, playing the role of dispatching commands to devices and collecting responses from them .There are several models available, some of them connecting via USB, others using a serial port.
The one used for the initial implementation of Smartcrib can be purchased on http://www.usbdmx.com

• USB Bus powered - big advantage taking into consideration that while even the older computers have USB ports, most laptops do not have a serial one
• DMX lines galvanically opto-isolated from the USB bus
• DMX lines over voltage protected, and current limited
• Simultaneously send and receive up to 512 channels
• Minimal host computer resource needed
• Firmware up-datable over USB – another handy feature; serial devices sometimes require a special circuit to be build in order to re-write or update the firmware on the chip
• High quality resilient line drivers
• Heavy duty powder coated steel case
• Affordable and easy to build – another advantage that had a big weight in our choice of DMX interface taking into consideration that affordability is one of the primary objectives of this project
• Compatable with all major O/S – definitely a big plus

The USB DMX interface uses a FT245BM USB device from FTDI. They supply drivers for most O/S, available for download on the FTDI driver download page.
Communication with the USB DMX interface is asynchronous, meaning that it is not neccessary to wait for a command response before sending the next command, and an interface generated response (such as a change to a DMX channel value) may be received before the response to the previously sent command.
However command responses will always be in the order the commands were sent to the interface.
The protocol has been designed to be as efficient (fast) as possible, meaning that it is based around unsigned bytes and not ascii characters, therefore a lot less bytes need to be sent. There are a number of commands that can be written to the Interface, and a number of responses that can be read from the interface. Commands and Responses are grouped together into a number of sub groups : System, Global, TX, RX

There is one format that all commands and response headers are defined to. It is a single byte made of the following bits :
7 6 5 4 3 2 1 0
R G G C C C C H
R = 1 for Response, 0 for Command
GG = 00 System, 01 Global, 10 TX, 11 RX
CCCC The identifier
H Some Commands / Responses use this to identify the high address bit. If not used this must be set to 0.

Whenerver a command is issued, a response header matching the command intentifier (but with the response bit set) will be received. Optionaly (depending on the command) attitional information in following bytes might be received. When using commands that contain address / channel numbers, 0x000 = channel 1 and 0x1FF = channel 512

The DMX channel controlling devices can be split in 2 categories (according to functionality):

• DMX Dimmer packs used in dimming lights
• DMX Switch packs used in switching on/off various devices

The DMX channel controlling devices are connected to the DMX control interface in a multi-drop bus topology commonly called a "daisy chain".
Each device has a DMX512 in and generally a DMX512 out connector - sometimes marked as DMX512 thru. The DMX512 out on the controller is linked via a DMX512 cable to the DMX512 in on the first fixture. A second cable then links the DMX512 out on the first fixture to the next device, and so on. In general, the final, empty, DMX512 out connector should have a DMX512 terminating plug attached into it, which is simply a resistor that matches the impedance of the cabling used (usually 120 ohms) joining pins 2 and 3 of the connector.
Many modern devices negate this requirement as they are capable of auto-terminating the link.

The DMX Dimmer packs are used for dimming the lights and are connected both to the USBDMX interface (in a daisy chain) and to the lighting devices (light bulbs) .

The DMX Switch packs are used for switching DMX devices on/off and are connected both to the USBDMX interface (in a daisy chain) and to the DMX devices. These packs can be bought (most available devices also both the capabilities to switch and dim at the same time) or, provided you have some electrical skills and knowledge, can be home-made.

DMX512 cables are usually use five-pin XLR connector, although only three pins of the five are always used. Some manufacturers have used three-pin XLR connectors and it has even been known for light fixtures to be produced with a TRS connector jack for DMX connectivity, this is a violation of the Standard, although the trend in professional equipment is towards compliance with DMX512-A. DMX512-A prohibits use of any connector other than a 5-pin XLR unless there is not physical space on the device for that connector, in which case an adaptor must be supplied.
Cabling for DMX512 was removed from the Standard and made a separate standards project in 2004. Two Cabling standards have been developed, one for Portable DMX512 cables and one for Permanent installations. This resolved previous issues arising from the differing needs of cables used in touring shows vs. cables used for permanent infrastructure. In addition, cable performance is now specified with regard to nominal impedance and capacitance to provide guidance as to what constitutes an acceptable cable. Microphone and line level audio cables do not have the correct characteristics, and should never be used for DMX512. The significantly lower nominal impedance and significantly higher capacitance of these cables distort the DMX512 data which can cause irregular operation or intermittent errors that are difficult to identify and correct.
For this project, the cabling has been home-made using 3 pin XLR connectors and 2 wire shielded audio cable. Imagery below and a handy how-to guide



                       

4. Software Architecture

When accesing the application web interface which will be displayed in a browser window (either using a computer or a mobile device), this will connect to the Apache Tomcat webserver and to the MySQL backend database to display the original state of the system.Any change in the state due to the user’s commands will be sent to the Java application and depending on the request mapping, will be forwarded either to MPlayer (which is functioning in slave mode) either to the USBDMX command interface (using a .dll ) and from there, to the requested DMX channel. Any change in a device state will be updated in the database.

5. Installing the application

For the hardware installation one would need to buy or build a USBDMX control interface, the various channel control devices necessary and the necessary XLR cables used for connecting the daisy chain network. The installation process of the interface requires the download of the FT245BM USB driver (D2XX Direct drivers).

From a software perspective, one would need to install the following applications :

• JVM 5.x-6.x http://www.java.com/en/download/index.jsp
• Apache Tomcat 5.5 http://tomcat.apache.org/
• MySQL (or any other SQL databse system) http://dev.mysql.com/downloads/mysql/5.0.html#downloads
• Microsoft Visual C++ 2008 Redistributable Package (x64) http://www.microsoft.com/downloads/details.aspx?familyid=bd2a6171-e2d6-4230-b809-9a8d7548c1b6&displaylang=en
• FT245BM USB driver (>D2XX Direct drivers) http://www.ftdichip.com/Drivers/D2XX.htm
• Mplayer http://www.mplayerhq.hu/design7/dload.html

6. Cost estimate

7. Volunteering