Difference between revisions of "S15: CAN controlled RGB LED cubes"

Revision as of 06:20, 23 May 2015

Grading Criteria

Project Title

CAN controlled RGB LED cubes

Abstract

In this project, data(8 byte or less) sent from an android application will be displayed in a 3D form on a LED cube. Two LED cubes will be connected to two different SJone boards, these SJone boards are connected to a third SJone board using CAN bus. One LED board will be displaying some patters based upon the input from User and other LED cube will display characters one by one. The LED cubes will be connected to their respective SJ boards through shift registers. The boards will implement SSP protocol to communicate with the shift registers. A bluetooth module is connected to third SJone board. Android application sends data to be displayed along with the information about the SJone board(one of the LED cube) to be selected.

Objectives & Introduction

The main objective is to understand and implement CAN bus interface between 3 nodes. CAN Master node sends data with specific message id and Slave Nodes listen to their message id's and reads the data from CAN bus. The Secondary objective was to design two LED cubes and transmit data to LED cube via SSP interface.

Team Members & Responsibilities

• Chitrang Talaviya
  • LED cube design
  • Implementing CAN protocol
  • Bluetooth module interfacing
• Navjot Singh
  • Implementing CAN protocol
  • Bluetooth module interfacing
  • FreeRTOS environment
• Anuj Korat
  • LED cube design
  • Generating dynamic patterns
  • Implementing SSP with the shift registers
• Daamanmeet Paul
  • Android application development

Schedule

Parts List & Cost

Design & Implementation

Hardware Design & Interface

In our project, we are using CAN bus, LED cude interface with SPI using shift registers, Bluetooth interface with UART2. All of these interfaces are described below in detail.

LED Cube interface with SJ-One Board

• Shift registers have been used to communicate between the SJone board and the LED cubes. As the dimension of the cue is 4 x 4 x 4, it needs a total of 28 pins to control it, 16 pins to control 16 groups of 4 LED anodes and 12 pins to control 4 planes of the RGB lines. As we do not have that many pins on SJone board, we will be using 4 Serial- input-parallel-output shift registers to drive the LED terminals. This eases our job as only 5 pins are used from the board to drive 28 LED terminals.

File:1234.png SC74HC595 Shift Register Pin Diagram

Shift Register Timing Diagram

• The communication bus used between the LPC1758 board and the shift registers is SSP-Synchronous Serial Port. The driver written for the communication is as shown in Fig.All the shift registers are cascaded, meaning the serial output of one, connected to the serial input of the other. This way a total of 32 bits of serial data from the board can be converted into parallel outouts which are given to its respective LED terminals.

• Shift Register pin connections with the board:

*We are using 8 bits from the shift register as parallel output data. 
*The VCC and ground connections are made with the board
*The SRCLK is shifting clock which comes from the SSP1 clock
*The SRCLR is an active low pin and is being driven high along with the Output Enable permanently to never reset the storage register 
in the shift register and to enable the shift register respectively.
*The RCLK is the latching clock. It is connected with a GPIO pin on the board. When this pin is low the output of the shift register 
is in the floating state. No matter where the bit is reached in the storage register. When this pin becomes high, the storage register data latches with the output pins.  
*The SER is the serial input data which comes from the board as the MOSI input.
*The OUT pin is the output serial data. This is the same incoming data into the register. But, it has been shifted 8 times first and then only given out. This is used for cascading

• Cascading of the Shift Register and its testing:

A sample LED cube of dimension 3x3x2 was made in order to plan for the delicate construction of the actual LED cubes. This sample cube was interfaced with 3 cascaded shift register. This was simply done by connecting the serial output pin of 1st register with serial input pin of the second one. After one clock a bit output of a shift register shifts to the immediate next bit output of the register. In this way as shown in the figure, after 16 clock cycles a total of two bytes can be represented parallely at the shift register output. Note - In SPI communication the MSB of the byte always goes first.

• Cube's naming conventions & working logic:

So after the testing was successful, an actual LED cube was constructed with the pin and plane naming conventions as shown in the diagram above. a single plane of 16 LEDs have 1 common connection for Red, 1 common connection for Green, 1 common connection for Blue. The planes are horizontally constructed and the anodes are vertically connected. A single vertical line of anodes requires 1 pin. Likewise, there are a total of 16 anode line connections. In the circuit diagram, the shift registers has the SRCLR and OE, permanently pulled high for enabling the logic. The SRCLK and the RCLK are also commonly connected to the other shift registers SRCLK and RCLK pins respectively. Now, the RCLK is used to latch the data to the output pins. We do not want the data to appear at the output just when we are shifting the bits. Otherwise, due to the perception of vision, we will see some garbage output. Hence, just when we are done shifting a total of 32 output bit (4 bytes), we will latch the data to the output pins by pulling the RCLK pin high using software(GPIO) and then again lowering it later.

• Final Hardware and its testing:

One LED cube was made of dimension 4x4x4 that can display any color and another cube was made of dimension 5x5x4 (Blue) to display the letters more accurately. To turn ON and led ,only that particular anode line should be given logic 1 by the shift registers and every other anode line should be given logic 0. At the cathode side, only that particular planes, cathode must be pulled low and every other cathode lines high. This will apply a forward voltage across the LED and it will glow. In case of multicolor LED cube, a particular cathode should be selected to turn ON a specific color. Every color can be made using RGB. So as to make a color, a combination of RGB can be used. This can be achieved by giving red color to an LED for some specific time, then blue color for some time and then green color for some time. This way, due to very high frequency of this switching, human eyes would not see three different colors, but one color which is a mixture of these three colors. The resultant color depends on the right mix of the RGB colors. If we want to see orange color, we will have to incresing the delay time of the Red color first and then increase the Yellow color in equal proportion. Blue is not needed here. VOILA! we have an orange color LED. In the above diagram, a letter N is shown on the cube. It seems that each LED of this 'N' is glowing at the same time, while it truely is not. Only one plane of LEDs is working at once. This is the magic of 'perception of vision'.

Two nodes CAN configuration

Hardware setup

• The below diagram is for Two nodes CAN configuration. CAN1 is used on SJBoard with CAN transceiver MCP 2551. The interfacing with MCP2551 and SJBoard is shown below with the pin diagram. This setup is for communication between two SJBoards using CAN protocol. Here, Termination resisters value between CANH and CANL is 120 Ohms. The RS pin is used to select High-speed, Slope-control or Standby modes via an external biasing resistor and is connected to the ground directly. External 5V power supplier is used to power up both MCP 2551 CAN transceiver ICs. P0.0 and P0.1 on SJBoard are for RXD1 and TXD1 respectively for CAN1.

• This below 2 nodes CAN configuration is for the testing of the CAN protocol. In this project, 3 nodes CAN configuration is used. Third CAN node can be inserted to this network easily. CANH of the third node is connected to the CANH channel of the network and CANL is connected to CANL channel of netwrork.

File:CANdia.png

Bluetooth module Interface

• Data from Android application is sent over Bluetooth to 'Bluetooth receiver (HC-06)'. Bluetooth receiver is connected to UART 2 as per below diagram.
• Bluetooth module is connected with UART2 on SJSU-One board. HC-06 needs 5V, which is being provided externally. Tx Pin of HC-06 is connected with P2.9 (Rx of Uart2), Rx pin is connected with P2.8 of Sjsu-One board, GND is made common and Vcc is connected with 3.3V (took from SJSU one board). Below is the pin diagram from Bluetooth-Uart connections.

File:Team19 bluetooth.png

Software Design

SSP Communication

int buffer(char out1, char out2,char out3,char out4)
{while(!(LPC_SSP1->SR & 0x2)); 
       LPC_SSP1->DR = out1;        // sending a total of 4 bytes for 4 shift registers
while(!(LPC_SSP1->SR & (1<<4)));   // waiting for a byte to be sent succesfully
       LPC_SSP1->DR = out2;
while(!(LPC_SSP1->SR & (1<<4)));
       LPC_SSP1->DR = out3;
while(!(LPC_SSP1->SR & (1<<4)));
       LPC_SSP1->DR = out4;
while(!(LPC_SSP1->SR & (1<<4)));
       LPC_GPIO0->FIOSET = (1<<1); // setting the storage register clock pin high after sending 32 bits so
       delay_us(1);                // that the it latches the shift register output to the output pins
       LPC_GPIO0->FIOCLR = (1<<1);
while(!(LPC_SSP1->SR & 0x4));
       return LPC_SSP1->DR;
   }

CAN Communication

• A task is created for CAN transmission at transmission side and this task checks for the signal from the UART Interrupt handler; on receiving the signal, data on a requested board will be sent using CAN protocol.
• Receiver side listens only to the messages from specific message id and on receiving the message, it updates the data buffer.

Bluetooth module Interface

• Protocol used to send data from application: 8-byte data (or less ) send over Bluetooth will be displayed on the one of the LED cubes. If we need to display characters ‘SJSU’ on LED cube connected to Sj-One board 1. Then user should transmit < 1SJSU$>; where first field is board on which data is to be displayed followed by words to display, ‘$’ sign is must be added at the end to indicate the end of string(data). If the data to be displayed is 8 bytes long, then ’$’ is not required.
• The first flied should be either 1 or 2 (to select from one of 2 LED cubes).
• In our project, we are using UART2 connection with Bluetooth module. Baud rate is set at 9600 bps.Once the data is sent over mobile to Bluetooth device, Receive interrupt will occur and interrupt handler will be called. Interrupt handler sends signal to respective task(CAN Transmitter task) and task which is waiting on signal then reads the FIFO. The first character read by task will be ‘board number’ followed by words to be printed and ‘$’ sign. On reading the whole message the task sends message to CAN transmitter to send data over CAN bus.

Android Application Development

Tools used to Develop Android Application:

• Android Studio based on IntelliJ IDEA.
• Java Development kit 7 by Oracle.
• Android ADB interface.

Application Features:

• Bluetooth pairing up to 6 devices at a time.
• Facility to change Transmission Protocol within the Application.
• Send Data serially to any serial Bluetooth Device.
• Receive Data serially from any Bluetooth device using same protocol.

Application development Procedure:-

Application is developed upon the sample code provided by http://developer.android.com/guide/topics/connectivity/bluetooth.html & http://bitfountain.io/courses/mini-android

Bluetooth API setup :

• BluetoothAdapter

Used for the local Bluetooth adapter (Bluetooth radio). The BluetoothAdapter is the entry-point for all Bluetooth interaction. It is used to discover other Bluetooth devices, query a list of bonded (paired) devices, instantiate a BluetoothDevice using a known MAC address, and create a BluetoothServerSocket to listen for communications from other devices.

• Connecting Bluetooth devices.

The Android has the Sjsu board connected Bluetooth module stored in a BluetoothDevice object. The next objective is to form the connection between the Android and the Sjsu Board. This work should take place in separate thread.

Code

private class ConnectThread extends Thread {

private final BluetoothSocket mmSocket;

private final BluetoothDevice mmDevice;

private static final UUID MY_UUID = UUID.fromString("00001101-0000-1000-8000-

00805f9b34fb");

public ConnectThread(BluetoothDevice device) {

BluetoothSocket tmp = null;

mmDevice = device;

try {

tmp = device.createRfcommSocketToServiceRecord(MY_UUID);

} catch (IOException e) { }

mmSocket = tmp; }

public void run() {

mBluetoothAdapter.cancelDiscovery();

try {

mmSocket.connect();

} catch (IOException connectException) {

try {

mSocket.close();

} catch (IOException closeException) { }

return;}}

public void cancel() {

try {

mmSocket.close();

} catch (IOException e) { }}}

Android platform includes support for the Bluetooth framework that allows a device to wirelessly exchange data with other Bluetooth devices. Android provides Bluetooth API to perform these different operations.

Steps

1. Scan for other Bluetooth devices

2. Get a list of paired devices

3. Connect to other devices through service discovery

Application BlueT19 GUI :-

• Home Screen of the Application

In this screen, the first button (Search for the paired devices) is used to search for the paired Bluetooth devices which are already paired with the device and from this list of devices we can choose whichever device to communicate data. Then, the second button located in the bottom is used to finally establish the connection. If the device you are selecting is not a serial data compatible then an error message is also generated. Figure is sown below.

File:Home Screen.png

• Main Application screen

In this screen, there are two options provided that are we can send and receive serial data simultaneously. In the upper part of the screen the buttons are provided to disconnect with the device and clear the input received from the other connected device. The serial data received is displayed right under the above two button. In the lower part the screen, we have the option of sending serial data to the connected device. We can directly enter data by clicking Enter Command screen option by using onscreen keyboard. After entering the desired data we can send it by clicking the Send button. But, in this project we are only using the serial data transmitting facility of the application. Figures are shown below.

File:Main Application Screen.png File:Application working.png

Implementation

Below are the flow charts for 'Data' transfer from 'Android Device' via CAN bus to 'LED Cube'.

Transmitter Flow Chart

File:Receiverflowchart T19.png Receiver Flow Chart

Testing & Technical Challenges

My Issue #0

• Due to connection of Rs pin of CAN transceiver to ground via 1K resistor, CAN transmission was not working.So after directly connecting this pin to ground we resolved this issue.

My Issue #1

• Sending a long string of data from Application: This issue was mainly because we were not using Interrupts hence FIFO was overflowing which results into loss of data.
• Getting garbage value during read from UART2: This was because of baud rate, on using baud rate 9600 with precision ±3 %, this issue got resolved.

My Issue #2

• While generating patterns on LED cubes, we were getting problem of different intensity of LEDs on same LED cube. To resolve this problem we removed IC- ULM 2003 and we connected the cathodes of LED to shift register via resistors instead of using ULM.
• Also, we used 22 ohm resistor according to the electrical characteristics, but we found out prcatically, that even a 10 ohm resistor will work. The 10 ohm resistor is properly sinking the cathode current and also we are getting optimal brightness of the LEDS.
• Also due to loose soldering, patterns were not generated.
• Because of the clock signal given to many shift registers at once, the capacitance of the line decreased, hence we needed to find a particular SPI frequency.

Conclusion

Conclude your project here. You can recap your testing and problems. You should address the "so what" part here to indicate what you ultimately learnt from this project. How has this project increased your knowledge?

Project Video

Upload a video of your project and post the link here.

Project Source Code

• Sourceforge Source Code Link

References

Acknowledgement

We would like to thank Preet for teaching the concepts in a very practical sense in the class. It really helped us in the implementation of the project. We would also like to thank Shashank who was always ready to help and who also gave many ideas of what we can do in the project.

References Used

• Preetpal Kang's lecture notes of CMPE 244, Computer Engineering, San Jose State University, Jan-May 2015.
• http://www.nxp.com/documents/user_manual/UM10360.pdf
• http://gemlit.com/howto/
• http://www.nxp.com/documents/data_sheet/74HC_HCT595.pdf
• http://www.ti.com/lit/ds/symlink/uln2003a.pdf

Appendix

You can list the references you used.