PIC32MX: XBee Wireless Round-trip Latency
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
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.
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.
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.
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.