Software and hardware tools for our electrical engineering final year project are described on this page, as well as hardware components and critical software interfacing methods. Debugging, engineering, and test procedures can be found on this page.
ECE Final Year Project Tools
The sections below will cover all the hardware and software tools we used in our engineering senior design. The sections provide a high level look over the material, as well as an in depth look at all the circuits and components used to build the project.
Senior Project Software Tools
Microchip’s MPLAB IDE version 8.20 with the C18 Compiler were used create and compile the source code for this project.
AbsoluteTelnet 7.18 was used for AT command set communication with the GSM module. AT commands will be discussed in detail later in the next chapter.
Senior Project Hardware Tools
The PICkit2 Development Programmer/Debugger made by Microchip was used in the project for in-circuit debugging initially. The PICkit2 started giving us problems and would not debug our software, so we switched to the Microchip MPLAB ICD 2 debugger.
Electrical Engineering Final Project Hardware block diagram
A block diagram of our hardware for our PIC-GSM final project is shown in the figure below.
Figure 4 - Block Diagram of Hardware
Olimex PIC-GSM Cellular Development
The main hardware component of our project is the PIC-GSM Cellular Development board made by Olimex. The development board is pictured in Figure 3 of chapter 2. Before going into too much detail about each component a general overview of some of the board’s features will be presented. The PIC-GSM board contains a PIC18F97J60 microcontroller and a 3-band GSM GPRS module that can operate on 900/1800/1900Mhz. These two components on the board are the heart of our system. The board also contains two relays which are essential to our system. The specifications of these relays will be presented later in this report. The PIC-GSM also has an ICSP/ICD connector for programming with our PIC-ICD2 debugger. A list of the board features is presented below.
- ICSP/ICD connector for programming and debugging
- USB 2.0 type B connector to allow board to be interfaced to PC host
- GSM/GPRS module 900/1800/1900Mhz
- Li-ion backup battery
- PIC18F97J60-I/PT
- Ethernet RJ45 isolated connector
- GSM Audio In and Out
- RS232 connector
- Quartz crystal 20Mhz
- Two relays 10A/250VAC
- Two digital inputs
- Analog input
- Temperature sensor
- 5V voltage regulator
- EXT connector for available GPIO
- Four mounting holes 3.3 mm (0.13″)
- Dimensions 124×90 mm (4880 x 3540 mils)
The board requires a 12VDC power supply. The power supply uses 12VDC to power the relays, which is then regulated to 5VDC to charge the Li-ion battery backup. The battery is used to power the PIC18F97J60 and the GSM/GPRS module. Power consumption on the board in normal operation is between 90mA and 300mA. The relays add 60mA to this current when operating. The board can draw up to about 500mA when all modules are activated and communicating.
PIC18F97J60 Microcontroller
The PIC18F97J60 is the microcontroller our electrical engineering final year project uses. The chip has 100 pins, a relatively massive 128Kb memory, USART communication peripheral, and a wide operating voltage range of 2-3.6VDC. Figure 5 shows the chip and a table with some of the chip’s parameters. Figure 6 shows the pin diagram of the chip.
Figure 5 - PIC18F97J60 Parameters(From the user manual)
Figure 6 - PIC18F97J60 Pin Diagram(From the user manual)
GSM/GPRS Module
The GSM/GPRS module used on this development board is the SIM300D made by SIMCOM. The GSM module uses the AT Command set to communicate with the microcontroller. AT commands will be discussed later in this chapter. The SIM300D’s purpose is to communicate with the cell phone tower and microcontroller. The unit accepts power ranging from 3.4-4.5V and is supplied by our on board battery backup. The unit needs a 50 ohm antenna, which is conveniently built into our board. The figure below shows the pin diagram of the SIM300D module and what it looks like.
Figure 7 - SIMCOM SIM300D GSM Module(From the user manual)
The SIM300D module has two serial communication ports to help develop applications, but only one serial port can be used at a time. On our development board serial port one is multiplexed with the microcontroller and a FT232RL module to allow us to connect to the GSM module with USB for testing purposes via a terminal program (we used AbsolueTelnet). Since serial port 1 is multiplexed, serial port 2 cannot be used. The GSM module will connect to the microcontroller unless the memory is cleared, in this case the GSM module will connect to the USB through the FT232RL. The table below is a pin interface for serial port 1.
Figure 8 - SIM300D Serial 1 Interface
The figure below is a table describing the interface with the SIM-Card holder and SIM-Card.
Figure 9 - SIM300D SIM-Card Interface
Figure 10 shows how the GSM module is connected to the microcontroller in our ECE final year project.
Figure 10 - SIM300D connection to PIC18F97J60
SIM Card Holder
The SIM Card holder connects directly to the GSM module and houses the SIM card that will be used in the project. The SIM card holder used on our board is the Amphenol C707-10M006 512 2. This is a 6 pin SIM card holder and the figure below shows the interface between the SIM card holder and the SIM300D.
Figure 11 - SIM interface reference circuit with 6 pin SIM card
The SIM card holder requires 3VDC or 1.8VDC depending on the SIM card inserted and about 10mA. The SIM300D will supply the appropriate power automatically. Figure 12 shows the pin diagram of the SIM card holder, what it looks like, and how it operates.
Figure 12 - SIM Card Holder and Pin Diagram
ICSP Debugging/Programming Connector
The PIC-GSM board came equipped with an ICSP connection for debugging and programming the microcontroller. The figure below has the pin diagram and schematic of how it connects to the microcontroller.
Figure 13 - ICSP connector
FT232RL Module
The FT232RL module made by FTDI allows the SIM300D to communicate via serial UART to the computer through a USB cable. The use of this chip is only for testing purposes. It is very beneficial to an application developer because you can use a terminal program to communicate with the SIM300D to test AT commands. Information can be read from or sent to the SIM card, as well as deleted. The terminal program will allow you to see exactly what responses you can expect to receive from the GSM modem with particular AT commands. A schematic of the FT232RL module and its connections are in the Figure 14.
Figure 14 - FT232RL Pin diagram and schematic(From the user manual)
Relays
The PIC-GSM development board contains two Sun Hold RAS-1215 relays. The relays have a 12VDC coil voltage. The table below provides specifications of the relays.
| Rated Carrying Current | AC 120V 15A |
| AC 250V 10A | |
| DC 24V 15A | |
| Max Allowable Current | 20A |
| Max Allowable Voltage | AC 240V |
| DC 110V | |
| Max Current (continuous) | 15A |
| Contact Material | Ag alloy |
Table 1- Sun Hold RAS-1215 Relay Specifications
A schematic of the relays is provided below along with a picture of what they look like.
Figure 15 - Sun Hold RAS-1215 Relay Schematic(From the user manual)
Power
Power is supplied to the PIC-GSM Development Board with the RHINO PST-1800M AC/DC adapter. The adapter takes an input voltage of 100-240VAC and outputs either 3, 4.5, 6, 7.5, 9, or 12VDC. For our project the power supply is set to output 12VDC. At 12VDC output, this power supply can supply 1800mA maximum. This should be plenty of current to meet our board’s typical requirement of under 1A.
SIM Card
The SIM card used in our project is an AT&T SmartChip. It is a standard size SIM card made to be used for an AT&T GoPhone. It is required that the card not have a PIN security enabled, so we made sure not to enable a PIN security. This SIM card is inserted into the PIC-GSM Development Board’s SIM card holder.
Software
The following subsections will describe the MPLAB software environment, the AbsoluteTelnet software environment, AT commands, and the flow chart of our program as well as how the functions work.
Programming Environment
MPLAB environment
“MPLAB Integrated Development Environment (IDE) is a free, integrated toolset for the development of embedded applications employing Microchip’s PIC® and dsPIC® microcontrollers. MPLAB IDE runs as a 32-bit application on MS Windows®, is easy to use and includes a host of free software components for fast application development and super-charged debugging. MPLAB IDE also serves as a single, unified graphical user interface for additional Microchip and third party software and hardware development tools. Moving between tools is a snap, and upgrading from the free software simulator to hardware debug and programming tools is done in a flash because MPLAB IDE has the same user interface for all tools”.[1]
AT Commands
In order to communicate with the PIC-GSM board, we have to be familiar with the AT Commands. AT commands are commonly used for the GSM modem and cell phone. If someone wants to communicate between a cell phone and a computer, HyperTerminal works for the AT commands. For this project, the main idea is to program the board and make the board do the tasks. The PIC-GSM board is basically like a cell phone, in which the AT commands are used as well. Therefore, our communication between the MPLAB and the PIC-GSM is to use the Standard C Language to give the PIC-GSM Board an order to perform the tasks, such as reading the text message stored in the SIM card or make a phone call.
However, we were not using HyperTerminal to try out the communications in our project process, because we used Matt’s laptop to program. The operating system of his laptop is Windows Vista, which does not come with a free version of HyperTerminal. Fortunately, we found software which works similar to the HyperTerminal and compatible with Windows Vista. The Program is called Absolute Telnet. Although the software we used is a trial version, the functionality is enough for our project.
Before actually using Absolute Telnet to communicate with the board, some of the settings need to be confirmed. Under the “Option” in the menu bar, go to the properties. Under the “Connection” tab in the pop up window, the port in the “Direct to COM” sub-tab must be COM18, this is specific to Matt’s laptop that we used for this purpose. The screenshot of the property window is shown below:
Figure 16 – Absolute Telnet Properties
Then, we are able to use AbsoluteTelnet to communicate with the board. The command window of AbsoluteTelnet is shown below:
Figure 17 – AbsoluteTelnet Command Window
As shown in the figure above, in the beginning of communicating by AT commands, the first command we need to use is “AT”, which is to check the connections. If the set up for the communication between computer and the PIC-GSM Board is ready to go, an “OK” message would be returned.
The “AT+CMGR=1” is the AT command to read, which is reading the text message stored in the location identified by the number following “=”; in this case, the board reads the first message. The line following “AT+CMGR=1” is the response for the read command by the board. The next line is the message string of the text message read.
For this project, only a few AT commands are used, such as the read and send command. The AT commands we used are listed below:
- AT: Used to check the connection between GSM / GPRS modem and the computer
- AT+CMGF=1: Used to instruct the GSM / GPRS modem to operate in SMS text mode
- AT+CMGR=1: Used to read an SMS message at a certain storage location, which is the SIM card for this project
- AT+CMGS=1: Used to send SMS messages from a computer
- AT+CMGD=1: Used to delete text message stored in index 1
In the demo program, there are some other AT Commands used; however, we did not use them in our project.
Computer Engineering Project Program Flow
A software flow chart is an excellent way to demonstrate how our project works. The figure below is a flow chart of our project’s source code.
Figure 18 - Program Flow Chart
There are a few major functions in our program, each of which is listed below:
- main()
- read_txt()
- send_txt()
- delete_txt()
main Function
The main() function serves several purposes. First it calls a function that initializes the board. This function was included with demo software that was available for the PIC-GSM Development Board. Next, the main() function sends several AT commands via USART to the GSM module to prepare the board to receive text messages. After the initialization procedures are finished the main() function executes an infinite “while” loop with the read_txt() function contained in it. The purpose of this is to have the program constantly waiting to receive a new text message.
read_txt Function
The read_txt() function will be described in the following paragraph. The first thing the read_txt function does is send the AT command “AT+CMGR=1”. This AT command will read the text message stored in index 1 of the SIM card. Whatever is stored in index 1 of the SIM card is then stored into an array named “sms”. If there is a text message stored in index 1 the array will read in something like the message below.
+CMGR: “REC UNREAD”,”13173617945″,,”09/04/03,13:45:35-16″
Turn lamp on
OK
The first line starting with +CMGR contains information about the status of the message, the sender of the message, and a date and time stamp of when the message was received. The second line that contains the text “Turn lamp on” is the actual text message that was sent to the SIM card and is stored in index 1. The third line that says “OK” is a command the GSM modem returns when the AT command executed successfully. If the command does not execute successfully the GSM modem will respond with “ERROR”. At this point in the read_txt function the sms[] array is now filled with all of the information returned from the GSM modem in the lines above.
Now the read_txt() function actually starts to do things other than just read in text messages. The next thing this function does is compare the first five characters in the sms[] array. As you can see in the example above, the first five characters are “+CMGR”. This means it has read a text message in from index 1 of the SIM card, so index 1 is not empty. If index 1 of the SIM card was empty it would simply reply “OK” to the AT+CMGR=1 command. So the next thing the function does is check to see if the first 5 characters of the string are “+CMGR”, and if they are it knows there is a new text message and the program needs to further examine the sms[] array. If it is not “+CMGR” the function will continue to loop until the first five characters indicate a new message has been received.
At this point the first five characters in the sms[] array are “+CMGR”. Now the function will examine the phone number the text message is coming from. The phone number is stored starting at sms[21] and ending at sms[32]. This portion of the string is compared to see if the message is coming from an authorized phone number. Without this security feature any cell phone user would be able to operate our system. If the phone number is not authorized the function will jump to the delete_txt() function and simply delete the text message and begin looking for a new text message. We contemplated sending a text message to the unauthorized phone number letting the unauthorized user know they are not allowed to operate the system, but we decided we didn’t want them to know they were talking to an automated machine. There is potential someone could try to tamper with the system by sending mass amounts of messages to the system and cause our system in turn to respond with mass amounts of text messages. This could potentially lock up the system or cause errors.
Now that the system knows if that the phone number is authorized it can finally examine the text message the user actually sent. Currently, there are four different messages the system can receive, each is listed below:
- Turn lamp on
- Turn lamp off
- Turn fan on
- Turn fan off
Each message does exactly what it says it will do. There are a few conditions it checks for though. If a message is received telling the lamp to turn on it will first check to see if the lamp is already on. If the lamp is already on it will jump to send_txt() function that will tell the tell the sender that the lamp was already on. If the lamp was not already on the lamp will turn on and respond to the sender informing them the lamp has been turned on. If the lamp is off and you tell it to turn off a send_txt() function will inform you the lamp was already off, similar to the way it will tell you if it was already on. The fan works the same way the lamp does. This provides you the ability to check if an appliance was left on or off if you are not near it and want to check it’s status.
send_txt Function
While there is not any single function named send_txt(), there are several functions that perform essentially the same thing. We have had some problems passing arrays containing strings into our send_txt() function, and ended up making many functions that use the same code but don’t pass parameters into the function to avoid the issues we have had. We plan on optimizing the code before the final version of the project is completed, but for the sake of this report the current state of the functions will be discussed. Currently, there are eight functions that all do the same thing, except each sends a different message depending on the current state of the relays, and the state the relay is to be switched to. At the top of the send function the message that is to be sent to the operator of the system is stored into an array. Next, the state of the relay is changed according to what the operator requested. The following line of code is sent to the GSM modem via USART.
AT+CMGS=”+12197429365″
The program then must wait for the character “>” to be returned by the GSM modem. After this character is received the actual message we want to send to the system operator will be sent to the GSM modem. The modem responds with “+CMGR:” followed by some numbers that are not important to us and the expected “OK” response letting us know the command was executed successfully. The conversation between the microcontroller and GSM modem will look like the following lines of code.
AT+CMGS=”+12197429365″
> Light is now on!
+CMGS: 111
OK
This is the end of the send function. The program will now jump back to the place it was in the read_txt() function and continue running. Immediately after the send function is called the delete_txt() function is always called. This will always leave index 1 clear to receive a new text message. Since we only look at what the contents of SIM card index 1 are it is very important to keep it clear for new text messages after we are done using one. If index one is not cleared, the next message received will be placed into the following index, in this case it would be index 2.
delete_txt Function
The delete function is the simplest function we have in our program. It sends the command AT+CMGD=1 to the GSM modem through USART the same way the send function works. This command simply instructs the GSM modem to delete the text message stored in index 1 of the SIM card. After this function is executed, the program jumps back to where it was previously. Since there is now nothing stored in the SIM card index 1 the program will continue looping, waiting for a new text message to be received.