Difference between revisions of "PIC32MX: XBee Wireless Round-trip Latency"

From Mech
Jump to navigationJump to search
Line 7: Line 7:
<br clear=all>
<br clear=all>
[[Image:George Randolph.Team15.2010.jpeg|thumb|200px|George Randolph|right]]
[[Image:George Randolph.Team15.2010.jpeg|thumb|200px|George Randolph|right]]
The experiments that make up this lab were done by Team 15 who are composed of Nathan Hirsch and George Randolph. George Randolph can be seen in the image to the right. Man, he's awesome.
The experiments that make up this lab were done by Team 15 who are composed of Nathan Hirsch and George Randolph. George Randolph can be seen in the image to the right. Man, he's awesome. Some of George's interests include severe weather and progressive rock. If you have no idea what progressive rock is, you should check out this [http://www.progarchives.com website]. It's a very comprehensive database that explains why progressive rock is awesome and why everyone should listen to it. By far, it's the most sophisticated genre to hit the music scene since Johann Sebastian Bach in the late 17th century.
<br clear=all>
<br clear=all>



Revision as of 01:41, 14 February 2010

Original Assignment

Your assignment is to set up one PIC32 to send data to another using XBees for wireless RS-232 comm. One PIC will send a series of numbers; the other PIC will receive them and echo them back; and the first PIC will time the total time to send and receive back. To time, the first PIC can set a digital pin high, then set it low again when the original sent data is correctly received. It could also keep track of the count of a counter-timer. You can time how long it takes for the round-trip using an oscilloscope or by reading the counter-timer. You should try this for different baud rates and a couple of different sizes (in bytes) of the message. How low can you get the total round-trip time while guaranteeing low data loss?

Overview


George Randolph

The experiments that make up this lab were done by Team 15 who are composed of Nathan Hirsch and George Randolph. George Randolph can be seen in the image to the right. Man, he's awesome. Some of George's interests include severe weather and progressive rock. If you have no idea what progressive rock is, you should check out this website. It's a very comprehensive database that explains why progressive rock is awesome and why everyone should listen to it. By far, it's the most sophisticated genre to hit the music scene since Johann Sebastian Bach in the late 17th century.

Circuit

The following diagram depicts the circuit we used for our experiments. The theory behind the circuit is simple. The transmitter PIC TX pin is connected to the XBee RX pin. The XBee broadcasts the signal. The receiver XBee's RX pin is connected to the PIC's TX pin. The receiver PIC's RX pin is then connected to the XBee's TX pin.

The arrows symbolize an elementary view of the signal flow during the timing process and Pin D1 was used for clocking the trip time by setting it high and low.

Lab5.2010.Circuit.png

XBee chip

The pinout of the XBee chip can be seen in the image to the right. Note the RTS and CTS pins on the XBees were not used during the experiment. Notice how the XBee chip is constructed so that it can be stuck into a solderless protoboard or plugged directly into a RS232 cable.

X-CTU

We conducted the experiments at various BaudRates and this involved reprogramming the XBee chips. This was easy to do, but required the use of special software. Digikey's X-CTU is hyperterminal-like softwares which allows for easy interface between a computer and the XBee chips. After downloading it and installing it, the chips can be reprogrammed. The steps to reprogram the chips with different BaudRates are as follows:

  • Connect the end of the RS232 cable to the XBee chip. (Make sure the black wire connection on the RS232 cable plugs into the GND pin of XBee chip).
  • X-CTU should automatically detect the chip. Click on the terminal tab in X-CTU
  • Type "+++" (without the quotation marks) and the chip should reply with "OK." This means that you are connected and talking with the chip. After ten seconds of inactivity in this mode, the chip will automatically disconnect itself and you'll have to type "+++" again.
  • In order to change the baud rate type the following command: ATBD followed by 0-7 depending on the BaudRate you want
    • 0 = 1200 bps
    • 1 = 2400 bps
    • 2 = 4800 bps
    • 3 = 9600 bps
    • 4 = 19200 bps
    • 5 = 38400 bps
    • 6 = 57600 bps
    • 7 = 115200 bps
  • After typing the command and the number, press enter and they type ATWR to write the command to memory. Type ATCN to exit command mode. The chip should be reprogrammed.

Note that after reprogramming the chip, in order to interface with it and the terminal, you'll have to change the BaudRate settings in X-CTU on the computer tab. You can select various standard BaudRates from the dropdown menu. If you want to make sure the chip has been correctly reprogrammed, you can change the BaudRate in X-CTU and then try to reconnect with the XBee chip by typing "+++" in the terminal. If you get an "OK" response then the chip has been correctly reprogrammed.

Code

Transmitter Code

The code below is for the transmitter XBee chip. Note that the message string sent included only one period and was placed at the end. The program scans the message it receives looking for that period, so it knows that the whole message was received.

/********************************************************************** 

     Transmitter Code
     Lab 5: High Speed XBee Latency
     George Randolph
     Nathan Hirsch
     10 February 2010

This code is for the TRANSMITTER XBee chip.  It takes a string of characters and 
sends them from the PIC to the XBee and broadcasts it out into the world.  The 
reciever chip should receive the message and echo it back to the transmitter.  At
the point when the transmitter first broadcasts the message, a pin on the PIC is 
set to high.  When the message is successfully echoed back, that pin is set low 
so the whole process can be timed using an oscilloscope.

**********************************************************************/


// ****** Includes 
#include "HardwareProfile.h"

// ****** Constants
#define DESIRED_BAUDRATE    	    (115200)	      // The desired BaudRate Note: This must be changed when changing the XBee chip BaudRate
#define PIN_D1			LATDbits.LATD1        // These commands format pins D1-D4 as digital outputs.
#define PIN_D2			LATDbits.LATD2
#define PIN_D3			LATDbits.LATD3
#define PIN_D4			LATDbits.LATD4

// ****** Variables
unsigned int Time;
char RS232_Out_Buffer[64];  			      // The buffer may be changed if lots of data is being sent at a high BaudRate
char message;


// ****** Function Declarations
void initInterruptController();

// ****** Main Function
int main(void)
{
	int	pbClk;
	//initUART2(pbClk);
	
	// Configure the system performance
	pbClk = SYSTEMConfigPerformance(SYS_FREQ); 
	
	mInitAllLEDs();
		
		// define setup Configuration 2 for OpenUARTx
		// IrDA encoded UxTX idle state is '0'
		// Enable UxRX pin
		// Enable UxTX pin
		// Interrupt on transfer of every character to TSR 
		// Interrupt on every char received
		// Disable 9-bit address detect
		// Rx Buffer Over run status bit clear

	#define config2		UART_TX_PIN_LOW | UART_RX_ENABLE | UART_TX_ENABLE | UART_INT_TX | UART_INT_RX_CHAR | UART_ADR_DETECT_DIS | UART_RX_OVERRUN_CLEAR
	
	// Open UART2 with config1 and config2
	OpenUART2(config1, config2, pbClk/16/DESIRED_BAUDRATE-1);	// calculate actual BAUD generate value.

	// Configure UART2 RX Interrupt with priority 7
	ConfigIntUART2(UART_INT_PR7 | UART_RX_INT_EN);

	// Must enable glocal interrupts - in this case, we are using multi-vector mode
        INTEnableSystemMultiVectoredInt();
 	
	//Set D1, D2, D3, and D4 as a digital output
	LATD |= 0x001E; TRISD &= 0xFFE1;


	while(1) //let interrupt handle the UART
	{ 
		if (swUser) // swUser NOT pressed
		{
		// Turn off all the lights to show that the message has not been sent 
		mLED_0_Off();
		mLED_1_Off();
		mLED_2_Off();
		mLED_3_Off();
		PIN_D1 = 0;
		}
		else
		{
		// Turn on all the lights to show that the message was sent	
		mLED_0_On();
		mLED_1_On();
		mLED_2_On();
		mLED_3_On();
       	PIN_D1 = 1; 			    // Set the pin high to begin the clocking 
		putsUART2("1234.\r\n");     // This is where the message goes.  Note the period at the end of the message
		break; 			    // Code only sends the stuff in UART2 ONE time.  
		}
		
	}
   return 0;
 }
 
 
// **** Interrupts

// UART 2 interrupt handler and is set at priority 7
void __ISR(_UART2_VECTOR, ipl7) IntUart2Handler(void)
{ 
	// Is this an RX interrupt?
	if(mU2RXGetIntFlag())
	{
		// Clear the RX interrupt Flag
	    mU2RXClearIntFlag();

		message = ReadUART2();
		mLED_3_On();

		// Toggle LED to indicate UART activity
		if (message == '.') 			      // Note this is the last portion of the message we sent.  
		{
		     PIN_D1 = 0;		              // Put the Pin to low to finish the clocking
		     // Toggle some LEDs to show that the message was received correctly.  
		     mLED_0_Off();
		     mLED_1_Off();	
		}
	}

	// We don't care about TX interrupt
	if ( mU2TXGetIntFlag() )
	{
		mU2TXClearIntFlag();
	}
}

Receiver Code

The code below is for the receiver XBee. It takes the message sent by the transmitter and echoes it back to the transmitter.

/****************************************************
	Receiver Code
	Lab 5: High Speed XBee Latency
	George Randolph
	Nathan Hirsch
	10 February 2010
	
***************************************************/

//*** Includes
#include "HardwareProfile.h"

//*** Constants 
#define DESIRED_BAUDRATE    	(115200)      // The desired BaudRate.  Note this must change if the XBee chip's BaudRate is changed


//*** Main Program
int main(void) 
{
	int	pbClk;
	unsigned char data;						// The variable that will assing the things to when it reads the UART
		
	pbClk = SYSTEMConfigPerformance(SYS_FREQ);

	mInitAllLEDs();
	
	#define config1 UART_EN | UART_IDLE_CON | UART_RX_TX | UART_DIS_WAKE | UART_DIS_LOOPBACK | UART_DIS_ABAUD | UART_NO_PAR_8BIT | UART_1STOPBIT | UART_IRDA_DIS |
                        UART_DIS_BCLK_CTS_RTS| UART_NORMAL_RX | UART_BRGH_SIXTEEN  
	#define config2	UART_TX_PIN_LOW | UART_RX_ENABLE | UART_TX_ENABLE | UART_INT_TX | UART_INT_RX_CHAR | UART_ADR_DETECT_DIS | UART_RX_OVERRUN_CLEAR
	//OpenUART1( config1, config2, pbClk/16/DESIRED_BAUDRATE-1);	// calculate actual BAUD generate value.
	OpenUART2( config1, config2, pbClk/16/DESIRED_BAUDRATE-1);	// calculate actual BAUD generate value.
		
	while (1) 
	{ 
		while(!DataRdyUART2());	     // Wait for data in the UARTRx
      	data = (char)ReadUART2();	     // Read data from Rx and assign it to "data"
		
		while(BusyUART2());	     // Wait till the UART transmitter is free
      	putcUART2(data);		     // Write data into Tx.

		if(data == '.')		     // If the data string matches what we sent, turn the lights on
		{	
			mLED_0_On();
			mLED_1_On();
			mLED_2_On();
			mLED_3_On();
		}
		else 
		{ // If the received data doesn't match what was actually sent, only turn on two lights to show that some data was received, just not the right kind
			mLED_0_On();
			mLED_1_On();
			mLED_2_Off();
			mLED_3_Off();
		}
   }
}

Notes

The message string that was sent ended in a period and there was only one period in the whole message string. We used this to assure that the entire string was read before assigning the digital pin that clocked the entire transfer process to low.

Results

The table below summarizes our results. We ran two experiments. The first involved varying the baud rate with the same size message sent. We sent a message of 90 bytes consisting of the phrase: "Would you like paper or plastic today, sir? Remember, plastic is bad for the environment." (without the quotation marks). Notice there is only one period in our message and that it is at the end. When the program sees the ASCII value for the period it knows that it has captured the entire message. We performed each test 3 times and averaged our measured time results using an oscilloscope hooked up to Pin D1.

BaudRate Latency Time (ms) Expected Time (ms) Errors?
1200 2360 2400 No
4800 600 600 No
9600 308 300 No
19200 160 150 No
57600 64 50 No
115200 40 25 No

In order to calculate the expected time, we multiplied 90 by 8 to get the number of bits we were sending, divided by the BaudRate to get the time and multiplied that by 4. The reason for the factor of 4 is that we assumed the time would, at a minimum, need to travel from the transmitting PIC to the transmitting XBee and from the receiving XBee to the receiving PIC and then back to the receiving XBee and then back to the transmitting XBee and finally to the transmitting PIC. That's a total of four loops. The schematic outlines the signal flow via arrows. We then multiplied that result by 1000 to get the result in ms.

We also conducted an experiment to see the absolute speed messages could be sent varying the byte size. We programmed the XBee chips to broadcast at the highest allowable BaudRate, 115200 bps, and then sent messages of varying lengths. The results can be seen in the table below.

Message Size (Bytes) Latency Time (ms) Expected Time (ms) Errors?
5 10 1.389 No
10 12 2.78 No
15 14 4.167 No
20 15 5.556 No
25 17 6.94 No
30 19 8.33 No
35 20.8 9.772 No
40 23 11.11 No
45 24.8 12.5 No
50 26.4 13.89 No
100 43 27.77 No
142 48 39.44 No

We discovered that at message sizes about about 150, the message would get truncated and not all of it would be echoed back. We reasoned that it had to do with the buffer size. Throughout all the tests, we kept the buffer at 64. The buffer on the XBee chip is elementarily analogous to the buffer for websites such as youtube.com. If the buffer isn't fast enough, then you have to wait while the video loads. We think that if the buffer size increases, you may be able to send longer message sizes without them getting truncated, however we were unable to perform these experiments due to time constraints.


Latency Time vs BaudRate

The graph at the right shows the relationship between varying the BaudRate and its effect on the latency time. The expected latency time and our experimentally obtained latency time were very close. It got less and less accurate, however, as the BaudRate increased. This makes sense because the factor of four added to simulated the total "distance" the message had to take played a much more substantial role. At very high BaudRates, the time for the PIC to communicate with the XBee can add to the lag time.


Byte Size vs Latency

The graph at the right shows the latency time vs byte size. Each test was done two times and the results averaged. The XBee chips were programmed at the highest BaudRates, 115200 bps and the byte size was increased by 5's up to about 50. We observed that at message sizes above about 150, the message would get truncated and not all of it was transmitted. As discussed above, we believe the buffer is the main culprit for this. The main behavior of the graph is mostly linear, which seems to make sense (up to the ~150 byte threshold). Because the XBee chips are operating at their highest allowable BaudRate, the time lag between PIC and XBee communication plays a much bigger role. Again if the buffer were increased, we believe the two lines would get closer to each other. However, considering the timesteps were are dealing with, the expected and measured times are only off by about 10 ms which is still very good.