dissertation outline ss

8/9/2019 Dissertation Outline SS

1/12

5

CHAPTER 3

HARDWARE DESIGN AND TESTING

3.1: Design Goals

3.2: Technology Choices

3.3: Design and Test of Components

The hardware design part of this project involved phased design of various

components of the monitoring system. The complete system design had to be

divided into manageable sub-functions, each of which were designed and tested in

isolation. The most crucial element of this project is the sensor network node,

which includes several sub-components and sub-functions.

Firstly I needed a microprocessor/microcontroller to support the logic and

processing necessary on the nodes to allow sensor data capture, message creation,

transmission, and message routing. The processor has to play the role of forwarding message packets originating from other nodes, as well as transmitting

its own messages. Besides the processor, I need on these nodes multiple sensors,

and an RF module, and an antenna to handle the lower layers of communication.

The media access (MAC) and physical (PHY) layers of the communication are

handled by the radio module, whereas the processor has to host the upper layers of

the protocol stack.

Section 3.2 states and explains the technology choices made for these components.

In this section I describe how I started piecing together the components while

testing them individually. The good thing about testing components individually is

that it reduces the complexity of the test yet giving the confidence that these fairly

independent components would function correctly when they are combined

together. The following circuits were assembled towards the design and testing.


2/12

6

1. Functioning of sensors: This was the simplest step and merely involved

making a minimal connection with the sensor and taking the readings using

a data acquisition card and using a multi-meter.

2. Communication between a PC and Microcontroller: This is a key functionalcomponent for two reasons. Firstly it would serve as the gateway

communication After all, the sensor messages would be routed all the way

to a central receiving station where one or more computers would

aggregate the data. A gateway node is a node that on one hand receives

the data on radio, and on the other hand sends the data. Secondly it is

immensely important for debugging the firmware that is going into the

microcontroller. Debugging requires feedback from the system, which is

provided by readable/visible outputs. In the previous coursework projects

(motor controller, traffic light simulator) I have used LEDs to provide me that

feedback, but this time the programming task appears too complex for LEDs

to help in debugging. So textual output to a computer screen would be ideal.

3. Using the microcontroller A/D converters with sensors: The sensors typically

(the inexpensive ones anyway) show the measured quantity in terms of an

analog voltage change, or as resistance change which can then be translated

into a voltage change in potentiometer or Wheatstone bridge circuit. Either

way I need to convert sensor signal into digital form (i.e. a string of zeroes an

ones encoding the voltage level) to process in computers. Thankfully

microcontrollers come with built in A/D converters that can be multiplexed

on several channels. Our chosen microcontroller PIC16F877A has eight A/D

channels that can be used by the internal A/D converter.

4. Wireless communication between two nodes: This is the most crucial

component of the system that allows local readings to be communicated

across the network mesh.

Following is a brief account of the hardware tests carried out on each of the

aforementioned functions.


3/12

7

Testing of Sensors

Since it was practically impossible to have access to laboratory facilities for the

project I had to set up everything at my home and bootstrapped it from the basics.Since the project would involve taking measurements and tracking signals the first

thing that appeared important was data acquisition (DAQ) device that I could use as

(1) a for digital measurements from sensors and (2) as a low frequency scope since I

could not afford a real scope. This was a 20kSamples/Sec 20 channel, 10-bit

acquisition system. I tested it by connecting it to my computer and taking readings

from a potentiometer. The card came with software that would show the readings

from any of its 20 channels. This worked as the multi-meter readings and thesoftware readings agreed (as shown in figure 3.1).

Figure 3.1: Verifying the DAQ system

Next was the task of reading from the sensors using the DAQ. The thermal sensor

LM35DZ was connected with the DAq card and the voltage was measured. The

initial reading was 0.234V. This corresponds to 23.4 oC which agrees with the

thermometer in the room. Next I placed a hot soldering iron very close to the

temperature sensor and the reading slowly went up to 0.39V which corresponds to

39 oC. I made a similar measurement with the piezoelectric sensor and noted a large

increase with increase in vibration. I am yet to understand the quantitative

calibration of the vibration sensor readings (TODO).

The outcomes of this test are as follows


4/12

8

(1) The DAQ board is working fine.

(2) The sensors are working fine.

(3) I understand the connection for the sensors.

Testing of Communication between PC and Microcontroller

The communication between PC and microcontroller is done using a protocol called

RS232 which predates USB by several decades and was designed for industrial

automation in the early days of digital computers. The RS232 is a serial protocol

supported by a hardware card present in most desktop PCs but is relatively rare in

modern laptop PCs. However it is easy to support that protocol by tunnellingthrough USB. The key electrical feature of this protocol is that the voltage levels in

the RS232 range between +/- 10 volts or above, which is way above the TTL voltage

level used in microcontrollers. So there I need to use what is called a voltage level

converter to convert TTL voltage levels into RS232. I have used the MAX202 chip

(from MAXIM) for this purpose. Thankfully our microcontroller (PIC16F877A) has

internal hardware (called universal asynchronous receiver transmitter or UART) for

this communication which reduces the programming task to simply reading and

writing to the UART registers. Initially I started using assembly instructions for

writing to these registers using the following subroutine:

ConsolePut

banksel TXSTA

btfss TXSTA , TRMT ; verify the buffer is empty

goto ConsolePut ; if not loop back

banksel TXREG

movwf TXREG ; copy the data in WREG to the transmit buffer

return

However, it was a pain to use such a routine in assembly. For example, in order to

send a character string to the computer one would have to call this function once

for each character. I have not yet figured out a way of specifying character strings

in assembly. Thankfully the PIC C compilers support the printf function which

makes output very easy.


5/12

9

Figure 3.2 shows the circuit diagram that I assembled for initially testing the

microcontroller PC communication.

RA0/AN02

RA1/AN13

RA2/AN2/VREF-4

RA4/T0CKI6

RA5/AN4/SS7

RE0/AN5/RD8

RE1/AN6/WR9

RE2/AN7/CS10

OSC1/CLKIN13

OSC2/CLKOUT14

RC1/T1OSI/CCP2 16

RC2/CCP1 17

RC3/SCK/SCL 18

RD0/PSP0 19

RD1/PSP1 20

RB7/PGD 40RB6/PGC 39

RB5 38RB4 37

RB3/PGM 36RB2 35RB1 34

RB0/INT 33

RD7/PSP7 30RD6/PSP6 29RD5/PSP5 28RD4/PSP4 27RD3/PSP3 22RD2/PSP2 21

RC7/RX/DT 26RC6/TX/CK 25

RC5/SDO 24RC4/SDI/SDA 23

RA3/AN3/VREF+5

RC0/T1OSO/T1CKI 15

MCLR/Vpp/THV1

U1

PIC16F877A

X120 Mhz

C1

20pF

C2

20pF

B15V

R1

3.3k

Reset Switch

T1IN11

R1OUT12

T2IN10

R2OUT9

T1OUT 14

R1IN 13

T2OUT 7

R2IN 8

C2+

4

C2-

5

C1+

1

C1-

3

VS+ 2

VS- 6

U2

MAX202

RS232 Connection

Shikha Sarkar

C3

1uF

C4

1uF

162738495

J1

CONN-D9F

C71uF

C81uF

C5

1uF

Figure 3.2: Circuit for verifying Microcontroller to PC communication

The first test was simply a hello world program that sends the string hello

world! to the PC. This did work then I tried a program to keep sending a counter

value. Here are a few points about the communication firmware.

The baud rate has to be set in the firmware. This was done using the following

directives in the C program.

#use delay(clock=20000000)

#use rs232(baud=9600, UART1A)

On the PC side I used the hyper-terminal software that comes bundled with every

windows installation. It can be started using the menu Start All Programs

Accessories Communications Hyperterminal on my Windows XP box. The

hyper-terminal software prompts for configuration details such as port name, baud

rate etc. using the dialog boxes as shown in Figure 3.3. Once it is set up, I can see

the data (characters) sent by the microcontroller on the hyper-terminal screen.


6/12

10

Ultimately the PC side of the communication will be handled by application

software that aggregates data from the gateway hardware. There are C/C++ and

Java libraries for high level handling

Figure 3.3: Hyper-terminal configuration dialog boxes

There is a potential pitfall in making the RS232 connection. One important piece of

connector hardware I need for it is a D9/DB9 female connector to connect from the

microcontroller side with the RS232 cable. I could not find it anywhere in Maplin or

RS components. So I made a temporary makeshift one from a spare RS232 cable.

I cut the cable and opened up the back of the male connector to see the colours

corresponding to the pin numbers and made the connections from the female part

onto the prototyping board accordingly. However, it turned out that I had inferred

the pin-numbers as the mirror image of what it actually is (I numbered by looking at

it from the back whilst I should have looked from the front). This misconnection

caused overheating and complete brown-out of the microcontrollers and destroyed

two of them. One should be very careful about RS232 connections, as we are

playing with voltages above TTL levels. Figure 3.4 shows the colour code used by

the RS232 cable and the connection I made to the prototyping board.

Figure 3.5 shows the test circuit as assembled on the prototyping board.

The outcomes of this test are as follows-

(1) The generic PIC programmer is working fine.

(2) RS232 communication is working fine.


7/12

11

(3) The voltage converter is working fine.

(4) I know the connections required for the RS232 communication.

Figure 3.4: Colour-code of RS232 cable wires

Figure 3.5: Prototype board setup for the circuit shown in Figure 3.1

Test of Reading Sensors by the Microcontroller

The microcontroller 16F877A provides 8 analog input channels, which I could use to

connect up to eight sensors in each node. I needed to understand how this works


8/12

12

and what the connections are. With the temperature sensor LM35 I made the

circuit as shown in figure 3.6.

RA0/AN02

RA1/AN13

RA2/AN2/VREF-4

RA4/T0CKI6

RA5/AN4/SS7

RE0/AN5/RD8

RE1/AN6/WR9

RE2/AN7/CS10

OSC1/CLKIN13

OSC2/CLKOUT14

RC1/T1OSI/CCP2 16

RC2/CCP1 17

RC3/SCK/SCL 18

RD0/PSP0 19RD1/PSP1 20


RB5 38RB4 37

RB3/PGM 36RB2 35RB1 34

RB0/INT 33




RA3/AN3/VREF+5

RC0/T1OSO/T1CKI 15

MCLR/Vpp/THV1

U1

PIC16F877A

X120 Mhz

C1

20pF

C2

20pF

B15V

R1

3.3k

Reset Switch

T1IN11

R1OUT12

T2IN10

R2OUT9

T1OUT 14

R1IN 13

T2OUT 7

R2IN 8

C2+

4

C2-

5

C1+

1

C1-

3

VS+ 2

VS- 6

U2

MAX202

Temperature Sensor Connection

Shikha Sarkar

C3

1uF

C4

1uF

162738495

J1

CONN-D9F

C71uF

C81uF

C5

1uF

V -

3

V +

2

ADJ 1

U3

LM135

Figure 3.6: Circuit to test the microcontrollers A/D converter.

The test circuits as they look on the prototyping board are shown in Figure 3.7.

I wrote a simple program as shown in Figure 3.8 to send the sampled sensor

readings to the PC. Figure 3.9 shows how the firmwares output shown on the PC

hyper-terminal screen.

Figure 3.7: Testing of the sensor connection to the micro-controller.


9/12

13

1 #include 2 #fuses HS,NOWDT,NOPROTECT,NOLVP3 #use rs232(baud= 9600 , xmit=PIN_C6, rcv=PIN_C7)4 #use delay(clock= 20000000 )567 void main ()8 {9 unsigned int8 i, value, min, max;

10 printf ( "Sampling:" );11 setup_adc_ports (AN0);12 setup_adc (ADC_CLOCK_INTERNAL);13 set_adc_channel ( 0 );1415 do 16 {17 min = 255 ;18 max = 0 ;19 for (i = 0 ; i max)26 max = value;27 }28 printf( " \r\n Min: 1000*( %d/255) degrees Max: 1000*( %d/255) degrees \n\r " ,29 min, max);30 }31 while (TRUE);32 }

Figure 3.8: Test code to read the temperature and send it to the PC

Figure 3.9: Sensor readings as seen on the hyper-terminal screen.

The second screenshot in figure 3.9 is for the readings from the vibration sensor

(with some minor changes to the above program). I could see that the values were

changing according to disturbance I subjected the piezoelectric-film to, but have not

yet figured out what the values mean in absolute terms.


10/12

14

Testing of Wireless Communication between Network Nodes

The test circuit was assembled as two units of the structure shown in Figure 3.10.

RA0/AN02

RA1/AN13

RA2/AN2/VREF-4

RA4/T0CKI6

RA5/AN4/SS7

RE0/AN5/RD8

RE1/AN6/WR9

RE2/AN7/CS10

OSC1/CLKIN13

OSC2/CLKOUT14

RC1/T1OSI/CCP2 16

RC2/CCP1 17

RC3/SCK/SCL 18

RD0/PSP0 19

RD1/PSP1 20


RB5 38RB4 37

RB3/PGM 36RB2 35RB1

34RB0/INT33




RA3/AN3/VREF+5

RC0/T1OSO/T1CKI 15

MCLR/Vpp/THV1

U1

PIC16F877A

RXD

RTS

TXD

CTS

VT1

VTERM

X120 Mhz

C1

20pF

C2

20pF

SPIDINDOUTSCKSSTRIG

D1LED-RED

D2LED-RED

R1

10k

R2

10k

SW1

SW-SPST

R3

10k

SW2

SW-SPST

R4

10k

B15V

Ground this to Reset

PIC16F877 Gateway (Circuit As Inferred from the MiWi Stack Code for PIC16)

Figure 3.10: Connection of each Zigbee node according to the Zigbee code

comments. The RF module MRF24J40MA is shown as a generic SPI device.

The website of the Zigbee manufacturer provides a sample application code written

in PIC16 assembly language to test Zigbee communication with the MRF24J40 RF

module. This code is quite large (a few thousand lines of assembly instructions), and

I have not fully understood it but I have identifies the key areas where I should

modify to customize according to our needs. The key areas are:

1. The part that creates the data packet to transmit to the RF module using SPI

(serial peripheral interface).


11/12

15

2. The part where the board-registers are set up. This par could be modified to

set up the port settings.

The provided sample application has code to send a toggle LED message to whichthe recipient module is expected to respond by toggling an LED. The relevant

section of the code is as follows:

445 xorlw 0x55

446 btfss STATUS , Z ; if the data byte was 0x55 then toggle

PORTA0

447 goto _ApplicationLoopPacketDiscard

448 _ApplicationLoopToggleLight 449 movlw 0x01

450 xorwf PORTA , F

451 ; fall through to the discard section

I am not 100% sure of its functioning, but I did see LEDs getting toggled (I have

uploaded the video in http://www.youtube.com/watch?v=wo5arl5a_Uk ). This

most likely confirms that the sample code did work, but I am yet to fully get on the

top of what is going on. I followed the circuit blindly and did not connect the RS232

to log this operation, which is a thing I plan to do next. Figure 3.12 is a picture of

the wireless toggle LED test assembly. It became very overly complicated when I

tried to add the RS232 connection. In fact this was the first assembly I tested, after

the initial sensor tests, and before the isolated RS232 tests, and this was when the

microcontrollers got burnt due to wrong RS232 connection. I need to do a full

integration testing with better planning so that the prototype circuit does not get

too complicated. Ideally I should design a PCB for the final design if time permits.

In figure 3.10 I have drawn the ZigBee module as a generic SPI device. Figure 3.11

shows the actual connections between the Zigbee module and the microcontroller.


12/12

16

Figure 3.11: Connection diagram for the RF module MRF24J40MA

Figure 3.12: Wireless toggle LED test. Video is available in the URL:

http://www.youtube.com/watch?v=wo5arl5a_Uk

dissertation outline ss

Documents