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

From Embedded Systems Learning Academy
Jump to: navigation, search
(Two nodes CAN configuration)
(LED Cube interface with SJ-One Board)
Line 227: Line 227:
 
|[[File:Circuit design.png|600px|thumb|right|Cube anode & plane connections]]
 
|[[File:Circuit design.png|600px|thumb|right|Cube anode & plane connections]]
 
|}
 
|}
 +
 +
*'''Cube's naming conventions:'''
 +
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.
 +
 
{|
 
{|
 
|[[File:Implemented hardware.png|500px|thumb|left|Final LED Cube Top View]]
 
|[[File:Implemented hardware.png|500px|thumb|left|Final LED Cube Top View]]

Revision as of 23:11, 22 May 2015

Grading Criteria

  • How well is Software & Hardware Design described?
  • How well can this report be used to reproduce this project?
  • Code Quality
  • Overall Report Quality:
    • Software Block Diagrams
    • Hardware Block Diagrams
      Schematic Quality
    • Quality of technical challenges and solutions adopted.

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.

File:Basic Block Diagram.png
Project Block Diagram

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

Week# Start Date Task Status Completion Date
1 3/15 Finalizing & ordering components

-Going through the requirements of the project

-Order hardware components based on the final list

Completed 3/17
2 3/27 3x3x2 LED cube testing with SPI interfacing

-Studying the SC74HC595 shift register datasheet

-Constructing a 3x3x2 LED cube for testing purpose -Interfacing of shift register using SSP1 with LPC1758

-Cascading of 4 shift registers using SSP1 to control anodes & RGB cathodes

Completed 4/10
3 4/8 Bluetooth Interface with SJone board through Android APK

-Testing the AT commands of Bluetooth HS-06 V1.06 module using hyperterminal(Completed)

-Testing interfacing of bluetooth using UART2(Completed)

Completed 4/17
4 4/8 Android application

-Communication between bluetooth module and an android application(Completed)

Completed 4/25
5 4/16 4x4x4 LED cube construction

-Building 2 LED cubes

-Interfacing & cascading of the shift registers with SJone boards to

control 16 anodes and 12 cathodes using SIPO configuration of shift register

-Interfacing of LED cubes with shift registers

Completed 4/26
6 4/20 CAN protocol programming

-Studying the CAN protocol datasheet(Completed)

-Setting up the interface of CAN transceiver and SJone boards(Completed)

-Initially making two-nodes CAN configuration(Completed)

-Three nodes CAN configuration(Completed)

Completed 4/30
7 4/27 Generating patterns on LED cubes

-Building libraries for generating Alphabets & numbers on the LED cubes

Completed 5/7
8 5/1 Implementing FreeRTOS for the system

-Implementing queue RTOS feature to connect the bluetooth interface and the CAN interface of the LPC1758 board

Completed 5/10
9 5/10 Final Debugging & testing Completed 5/15

Parts List & Cost

# Components Quantity Price($)/component
1 RGB LEDs pack of 100 2 9.95
2 CAN transceivers 15 Free
3 Shift registers, SC74HC595 10 1.49
4 SJone boards 3 80
5 Bluetooth module 1 20
6 Steel wire 1 8
7 Soldering kit 1 ~40
8 Jumper wires(each type) 1 25

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 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
File:Test cube.png
Test 3X3X2 Cube
File:Shift register cascading.png
Shift Register Cascading Logic
  • 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.

File:Cube's anode and plane connections.png
Cube anode & plane connections
File:Circuit design.png
Cube anode & plane connections
  • Cube's naming conventions:

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.

File:Implemented hardware.png
Final LED Cube Top View
File:Alphabet print.png
Printed Alphabet 'N' from Side View

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

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.
  • Android API 21 platform.

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 APIs setup available in the android bluetooth package:

  • 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.


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


Android provides BluetoothAdapter class to communicate with Bluetooth. Create an object of this calling by calling the static method getDefaultAdapter(). Its syntax is given below.

private BluetoothAdapter BA;
BA = BluetoothAdapter.getDefaultAdapter();


In order to enable the Bluetooth of your device, call the intent with the following Bluetooth constant ACTION_REQUEST_ENABLE. Its syntax is

Intent turnOn = new Intent(BluetoothAdapter.ACTION_REQUEST_ENABLE);
startActivityForResult(turnOn, 0);      


Apart from this constant, there are other constants provided the API , that supports different tasks. They are listed below.

Constant & description:

1        ACTION_REQUEST_DISCOVERABLE: This constant is used for turn on discovering of bluetooth
2        ACTION_STATE_CHANGED: This constant will notify that Bluetooth state has been changed
3        ACTION_FOUND: This constant is used for recieving information about each device that is discovered


Once you enable the Bluetooth , you can get a list of paired devices by calling getBondedDevices() method. It returns a set of bluetooth devices. Its syntax is.

private Set<BluetoothDevice>pairedDevices;
pairedDevices = BA.getBondedDevices();


Apart form the pariredDevices , there are other methods in the API that gives more control over Blueetooth. They are listed below.

Sr.No Method & description

1 enable(): This method enables the adapter if not enabled

2 isEnabled(): This method returns true if adapter is enabled

3 disable(): This method disables the adapter

4 getName(): This method returns the name of the Bluetooth adapter

5 setName(String name): This method changes the Bluetooth name

6 getState(): This method returns the current state of the Bluetooth Adapter.

7 startDiscovery(): This method starts the discovery process of the Bluetooth for 120 seconds.

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 due to loose soldering, patterns were not generated.

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

References

Acknowledgement

Any acknowledgement that you may wish to provide can be included here.

References Used

List any references used in project.

Appendix

You can list the references you used.