Digital Thermometer Interfaced with Android

The main aim of the project is to build a digital thermometer which can calculate temperature and send it to an android phone via a bluetooth module

Major Components

8051 Microcontroller board, LM35, ADC 0804, 16x2 LCD, Bluetooth Module, Serial board to board connector, Android phone

Block Diagram

Block Diagram showing Digital Thermometer Interface with Android

Circuit

Circuit showing Digital Thermometer Interface with android

Working

1. Temperature Sensor

LM35 is used as temperature sensor. It has a output Voltage proportional to Celsius temperature. The sensitivity is 10mV/C which means a temperature of 30 ℃ will produce a output voltage of 0.3V

2. Analog to Digital Converter

ADC0804 IC is used as ADC. It is a single channel ADC i.e can take only one analog signal as input. It has 8 bits which means it can produce a digital output between 0 to 255. It uses successive approximation technique to convert the analog input to digital output.

The step size can be adjusted by V_ref/2 pin. If there is no voltage set at Vref/2 pin, the ADC considers Vcc as the reference voltage. So, for a 5V input the step size is 5/256 = 19.53mV. In case we provide 1.28V at Vref/2 pin, the reference voltage will be 2.56V so that step size is 2.56/256 = 10mV. This means for every 10mV increase in the analog input the digital output is incremented by 1 bit.

3. Micro controller

The digital output of ADC is interfaced to a 8051 microcontroller. The 8051 sets the start of conversion (SOC) on ADC and reads the digital values at the end of conversion (EOC). The digital values are in HEX, it is converted to BCD and displayed on LCD as char. Here is the code to interface 8051 with LCD

• CS (pin 1 in the circuit) is always grounded which means ADC is always enabled
• For SOC, provide a edge trigger from 0 to 1 to the WR pin (pin 3 in the circuit)
• The ADC will take finite amount of time for conversion, after which INTR pin is indicates low (pin 5 in the circuit). This indicates EOC
• After EOC, we can read the digital output by providing an edge trigger from 0 to 1 at RD pin (pin 2 in the circuit)

The micro controller is also interfaced to a serial profile Bluetooth module at a baud rate of 9600. Once the Bluetooth handshake is finished, a message packet constructed with temperature is also sent continuously to the Bluetooth via serial port

4. Android app

A custom built android app discovers the nearby Bluetooth devices and connects to the one with serial port profile. The message packet sent from 8051 is decoded and the temperature is displayed on the mobile screen

Fire Fighting Robot

The main aim of the project is to build an autonomous vehicle (robot) that can detect a fire source, move towards it and extinguish the fire.

Major Components:

 

Arduino Uno, H-bridge circuit (L293D) – 2 nos. , IR photo diodes – 2nos. for detection, Fire sensor – 1 No (Can be another IR photodiode) and a Fan

Principle:

Fire sensors:

The spectral characteristics of the fire source depends on the source (or the burning material) of the fire. Most common fire sources emit radiations in the IR region of the spectrum and sensors that can sense radiations in this region can serve ideally for the purpose of detecting them.

Typical IR photodiodes have their sensitivity to be very high in the region from 870nm to 950nm wavelength, with daylight blocking filters to prevent any false triggers due to sunlight. These serve us ideally for fire detection purpose.

In this project, we intend to use three IR sensors –

Two on either sides in the front of the vehicle (Detectors) – This is for the initial fire detection and also for the purpose of guiding the vehicle in the direction of the fire source.

One in the centre with a high threshold (Activator) – This acts as a trigger for detecting the proximity of the fire and to take action (in our case switch on the fan) to extinguish it.

Controller:

An Arduino Uno is used here for controlling the robot. The main functions of the controller would be:

1. Initially be in scanning mode until any of the Detectors sense radiation.

2. Guide the vehicle by controlling the Left and Right motors based on the analog voltage levels from the Detectors.

3. When the fire source is close by, align the vehicle such that the fan faces the source (i.e the Activator is aligned to the fire). The Activator output is connected as an interrupt source to the Controller. Hence the extinguishing of fire takes place as part of the Interrupt Service routine (ISR)

4. Switch on the fan until fire is extinguished. H-bridge circuits are used for the purpose of motor and fan controls.

5. Return to scan mode

Circuit Diagram

Sensor Circuit:

1. The Value of R1 and R2 can be tuned based on the sensitivity requirement.

2.The 5V and GND can be derived from Arduino Uno board pins for convenience.

3. ANALOG_INPUT_LEFT, and ANALOG_INPUT_RIGHT can be any two analog pins on Arduino, say Analog 0, and Analog 1.

Fire Detection Circuit using Infrared Sensors

Flow Chart:

Algorithm for the Main Program

Interrupt Service Routine on detecting the Fire

 

Parsing GPS NMEA navigation message

A GPS receiver communicates its navigation solutions to the external world through a standard protocol. This protocol is a subset of the NMEA-0183 standard for interfacing marine electronic devices as defined by National Marine Electronics Association (NMEA). The NMEA reference manual provided along with each GPS receiver provides the details of the standard messages sent out by the particular receiver. Here we give an extract of a few basic messages that are essential for reading the PVT (Position, Velocity, and Time) solution.

Click Here for Introduction to GPS and How does a GPS Receiver Calculate Range from Satellites

The following table lists the entire set of NMEA messages related to GPS receiver and the information that they convey – 

Message Name	Information Contained
GGA	Time, Position, and Fix type
GLL	Latitude, Longitude, and UTC time of fix with status
GSA	Receiver operating mode, satellites used, and DOP
GSV	Number of satellites, elevation, azimuth, and SNR
RMC	Time, Date, Position, course, and speed
VTG	Course, and speed relative to ground
ZDA	PPS timing

Most of the receivers provide an option to enable / disable each of these messages depending on the bandwidth and data rate limits.

A typical GPS logs read from the receiver would be similar to this –

............................................................

............................................................

$GPGSV,3,1,12,04,64,168,27,17,50,004,32,28,42,059,40,08,34,149,22*75

$GPGSV,3,2,12,02,28,202,18,27,27,320,22,26,25,235,16,15,13,273,*7B

$GPGSV,3,3,12,09,12,323,26,10,10,163,39,07,08,149,25,20,04,075,*78

$GPRMC,125535.281,A,1908.0906,N,07254.3485,E,000.0,000.0,290611,,,A*6C

$GPVTG,000.0,T,,M,000.0,N,000.0,K,A*0D

$GPGGA,125536.281,1908.0906,N,07254.3485,E,1,07,1.4,33.2,M,-65.1,M,,0000*4F

$GPGSA,A,3,28,17,07,10,09,27,04,,,,,,2.0,1.4,1.5*33

............................................................

............................................................

In the current discussion, we shall only consider RMC and VTG messages, since these two messages contain the PVT solution required.

RMC – Recommended Minimum Specific GNSS Data:
$GPRMC,125535.281,A,1908.0906,N,07254.3485,E,000.0,000.0,290611,,,A*6C

Name	Example	Unit	Description
Message ID	$GPRMC		RMC protocol header
UTC Time	125535.281		hhmmss.sss
Status	A		A = valid; V = Not Valid
Latitude	1908.0906		ddmm.mmmm
N/S Indicator	N		E = East; W = West
Longitude	07254.3485		dddmm.mmmm
E/W Indicator	E		E = East; W = West
Speed Over Ground	000.0	Knots
Course Over Ground	000.0	Degrees	True
Date	290611		ddmmyy
Magnetic Variation*	12.123	Degrees
E/W Indicator	E		E = East; W = West
Mode	A		A = Autonomous, D = DGPS; E = DR**
Checksum	*6C
<CR><LF>			End of message

VTG – Course Over Ground and Ground Speed

$GPVTG,000.0,T,,M,000.0,N,000.0,K,A*0D

Name	Example	Unit	Description
Message ID	$GPVTG		VTG  protocol header
Course	000.0	degrees	Measured Heading
Reference	T		True
Course	005.6	degrees	Measured Heading
Reference	M		Magnetic
Speed	00.1	knots	Measured Horizontal Speed
Units	N		Knots
Speed	00.2	km/hr	Measured Horizontal Speed
Units	K		Kilometers per hour
Mode	A		A = Autonomous, D = DGPS; E = DR**
Checksum	*0D
<CR><LF>			End of message

* Magnetic variation data may or may not be supported in all the receivers

** DR = Dead Reackoning

Reading NMEA messages and displaying on LCD:

Two approaches can be taken to read the NMEA message through serial port and displaying them on the LCD screen , each method having its own merits and demerits –

1.  Interrupt based architecture (Process function as a background process)

In this method, we keep filling a global circular buffer, say

Rx_buffer[MAX_GPS_BUFFER_SIZE]

in the ISR. As an example an ISR written for ARM 7 processor reading GPS from UART0 is given here -

void Uart0_ISR(void) __irq

{

     char read_byte = 0;

     read_byte = U0RBR;

     Rx_buffer[Rx_buffer_pntr++] = read_byte;

     if(Rx_buffer_pntr >= MAX_GPS_BUFFER_SIZE)

     {

           Rx_buffer_pntr = Rx_buffer_pntr - MAX_GPS_BUFFER_SIZE;

     }

     VICVectAddr = 0;

}

The value of MAX_GPS_BUFFER_SIZE depends on the processing time of the foreground processes i.e. how often is the Rx_buffer checked for received bytes.

This approach is best suited for environments where many processes need to run in parallel. But it requires relatively large memory space to store the received bytes.

2. Polling based architecture (Processing function as a foreground process)

In this method, no other background process can be run along with message parsing. Here the program keeps polling the interrupt bit after receiving each byte. As an example, let us look at a 8051 based implementation, where the program polls each byte and waits until a $ is received –

while (1)

{

while(RI != 1);RI = 0;

if(ASCII_DOLLAR != SBUF)

{

continue;

}

....

....

....

}

This approach is suitable for small projects where the memory available is very small (e.g. in case of 8051, only 128 bytes is available for data) and GPS message reading is the only process running.

Steps to Parse NMEA messages

i.              Identify “$GP” symbol, which signifies the start of the message

ii.             If the characters that follow $GP are “RMC”, then go to the parsing function for RMC. Similarly if it is “VTG” go to the processing function for VTG.

iii.            In each of the messages, use comma (,) as the separator for the values to be extracted.

iv.            The message delimiter is identified as an asterisk symbol (*) which is followed by the checksum. The checksum in the message is an exclusive-or of all the bytes received between $ and *, not including both.

The last two bytes received after * represent the two nibbles of the 1 byte check sum.

Consider the following message –

$GPVTG,054.7,T,034.4,M,005.5,N,010.2,K*48

Checksum = (ASCII_G) XOR (ASCII_P) XOR .... so on up to ... (ASCII_K)

If the message is received properly, the Checksum must read 0X48. Once the checksum passes, copy the values of Longitude, latitude, time and Velocity to corresponding buffers for display on LCD. 

Click here for C-code Interfacing 8051 with LCD and Geolocation Tracking with GPS and GSM project

GPS Interfaced with 8051 showing Latitude and Longitude



GPS Interfaced with 8051 showing Velocity and Time