Jordan Guest 20747896Supervised by Ahmet Sekercioglu

Table of Contents1 - Introduction......................................................................................................................................3

2 - Development....................................................................................................................................3

2.1 – Hardware..................................................................................................................................3

2.1.1 - Atmel AT90USB1286 Microcontroller..................................................................................3

2.1.2 - Hope RFM22B Wireless Transceiver....................................................................................3

2.1.3 - DS18B20 Temperature Sensor.............................................................................................3

2.2 – Software....................................................................................................................................3

2.2.1 – LUFA...................................................................................................................................3

2.2.2 – Initialisation........................................................................................................................4

2.2.3 – Sending..............................................................................................................................5

2.2.4 – Receiving............................................................................................................................7

2.2.5 – Miscellaneous....................................................................................................................9

3 - User Guide......................................................................................................................................10

3.1 – Linux........................................................................................................................................10

3.1.1 - Programming the Microcontroller....................................................................................10

3.1.3 - Using the Smart Packet Radio...........................................................................................11

3.2 – Windows.................................................................................................................................12

3.2.1 - Programming the Microcontroller....................................................................................12

3.2.3 - Using the Smart Packet Radio...........................................................................................13

3.3 – Altering the RFM22B Settings..................................................................................................13

Interrupts.....................................................................................................................................14

Operating Function and Control...................................................................................................14

Packet Format..............................................................................................................................14

Transmitting and Receiving Settings.............................................................................................14

4 – Applications...................................................................................................................................15

4.1 - A Learning Tool........................................................................................................................15

4.2 - Beaconless Routing Protocols..................................................................................................15

3.2 - Beacon-Less Routing (BLR)[1]...............................................................................................15

3.3 - Implicit Geographic Forwarding (IGF)[2]..............................................................................17

3.4 - BLR and IGF Combination (Based on BOSS protocol)[3].......................................................18

5 – Conclusion......................................................................................................................................18

6 – Appendices....................................................................................................................................20

Appendix A.......................................................................................................................................20

Appendix B.......................................................................................................................................20

Appendix C.......................................................................................................................................21

Appendix D......................................................................................................................................22

Works Cited.........................................................................................................................................52

1 - IntroductionThe Smart Packet Radio has been developed for design and testing of wireless routing algorithms. The layout of the board had been completed previously and this document describes the development of the board from a freshly soldered printed circuit board, to a wireless device. Each main component is described a long with its function. The firmware used is also detailed, to give the user an idea of how the device operates without having to trawl through the code and scrutinise the comments.

As the device is to be used by future students a user guide has been included in the report, which details how to use the board step by step and is divided into 2 sections, one for the Windows operating system and one for the Linux operating system.

As the initial purpose of this board was to provide an environment to test beaconless routing protocols, research was conducted to find some example protocols which can be implemented in the future. A section detailing three of these protocols is also included.

A conclusion detailing the testing results and also problems encountered is at the end, followed by photos of the board, the PCB layout and the firmware which are included in the appendices for further reference.

2 - Development

2.1 – HardwareThis section contains a short description of each major piece of hardware that facilitates the operation of the Smart Packet Radio.

2.1.1 - Atmel AT90USB1286 MicrocontrollerThe Atmel Microcontroller serves many purposes. Firstly it allows communication between the user and the RFM22B transceiver module. It is responsible for the passing of commands and information to and from the module. This is achieved using the SPI interface available on the chip. It is also used to format and decode packets that have been sent and received at a very basic level, requiring a destination address and packet length in order to transmit data in its current mode of operation.

Once programmed, the microcontroller acts as an interface through which information can be wirelessly sent and received. Utilising the LUFA library, the microcontroller is recognised by the host as a communications port which makes it easily accessible across multiple platforms. As the device is so easily configurable, the way in which this information is sent including the format, transmission rate, carrier frequency etcetera, is completely up to the user. Using the current firmware, information can be sent byte by byte (as long as it’s in the required packet format). Alternatively the packet handling in the firmware can be removed entirely and the user can have this operation taken care of by implementing the desired transmission algorithm at a higher level. This can be achieved by using a script and accessing the device for the sole purpose of sending and receiving information.

Both port A and D are connected to external headers which can be used as general inputs and outputs depending on what the desired operation is. Port B is used for the SPI interface and also for LEDs which can be used to indicate whether the device is sending or receiving and also a health light to ensure the microcontroller is functioning as expecting.

2.1.2 - Hope RFM22B Wireless TransceiverThe Hope transceiver module is what provides the Smart Packet Radio with its wireless capabilities. The microcontroller communicates with it using a SPI interface. The mode of operation used in the firmware provided is called FIFO mode. It operates by receiving the data intended for wireless transmission to be sent from the microcontroller and storing it in a FIFO buffer located on the transceiver module. Once the full packet has been stored in the buffer and the transceiver has been notified of the packet length, the microcontroller puts the transceiver into transmit mode. Once in transmit mode, the transceiver uses its internal packet handler to format the packet (the firmware formats it as shown in Figure 1) using the data in the FIFO as the payload.

Figure - Packet Format

The preamble length is configurable though in testing it was found that with a preamble of less than 2 bytes, the device would regularly receive a valid preamble erroneously. In FIFO mode the transceiver must have a sync word of at least one byte in length, so in testing the minimum was used. The destination address can either be specified to a board or can be set to 0xFF which means the broadcast is read by all devices. The source address of a board is coded in the firmware and can be easily altered.

2.1.3 - DS18B20 Temperature SensorThe temperature sensor is used to detect the temperature of the Smart Packet Radio’s immediate environment. This is accomplished using a ‘one-wire’ protocol for requesting and reading data from the chip. In the firmware, the temperature is read and the information sent to the host in a string format. This only occurs when a jumper is placed across PA6 (Pin 6 on Port A) and ground.

After testing, it was determined that the device reads the temperature accurately, though as the transceiver and microcontroller both heat up during operation, the temperature read was higher than room temperature.

2.2 – SoftwareThis section contains a description of the code written.

2.2.1 – LUFAThe LUFA library is what allows the host to communicate with the Smart Packet Radio via USB. The USB to Serial demo project was used as a base to form the firmware. The purpose of this project was to allow communications between the USB input and a serial output. The serial component of the code was deleted as only the USB communication was required. The main functions used are:

void CDC_Device_SendByte (&VirtualSerial_CDC_Interface, const uint8_t Data)

This function sends a single byte of data to the host via USB.

void CDC_Device_ReceiveByte (&VirtualSerial_CDC_Interface, const uint8_t Data)

This function receives a single byte of data from the host via USB.

Although these are the only functions actively used in the firmware, the remainder of the LUFA project takes care of fundamental USB tasks and events required to make communication possible.

2.2.2 – InitialisationWhen the firmware is executed, a function called SetupHardware() is called. As the name suggests, this function initialises the hardware and makes it ready for use. There are three initialisation functions that are called. The first is USB_Init() which is located in the LUFA library and is required to allow the USB to function properly. The next two functions are AVR_Init() and RFM22_Init() which initialise the microcontroller and transceiver module respectively.

AT90USB1286SPI_Init(SPI_SPEED_FCPU_DIV_2 | SPI_ORDER_MSB_FIRST | SPI_SCK_LEAD_RISING | SPI_SAMPLE_LEADING | SPI_MODE_MASTER);The SPI_Init function initialises parameters specific to the SPI required to send information and commands to the transceiver module. The speed is set to 4MHz (the CPU speed divided by 2). The order of information is the MSB first which is standard for SPI. The SPI clock leads on the rising edge, and the data is sampled on the leading edge of the clock. The microcontroller is the SPI master and is initialised as such.

DDRB |= 0xF1; //Enable SS as an outputPORTB |= 0x80; //Pull SS high Sets the SPI chip select pin as an output and initialises it high as chip select is active low. This will be used when conducting SPI reads and writes.

DDRE = 0x00;PORTE = 0x40; //Enable pull-up on PE6 to be used for interrupt Sets PE6 as an input and pulls it up. This pin is connected to the interrupt pin on the transceiver module and will be used to notify the microcontroller of certain events.

DDRC = 0x77; //RGB LED output pins LED1(PC4-R, PC5-G, PC6-B) LED2(PC0 - B) Used for USB StatusPORTC = 0x71; //Output High

DDRE |= 0x03; //RGB LED output pins LED2(PE0 - R, PE1 - G)PORTE |= 0x03; //Output high

Sets Port C and E (not include PE6) as outputs and pulls them up. These pins are used for the RGB LEDs on the board and are active low. These LEDs have no dedicated purpose and have been used to indicate the USB connection status as well as when an unrecognised interrupt has occurred.

DDRA = 0x00; //Port A used for inputPORTA = 0x40; Sets Port A to be used as inputs and pulls PA6 up. Although this port can be used as an input or output, in this case it’s set up as in input to allow the user to read the temperature when the pulled up pin is connected to ground.

RFM22BThe function initialising the transceiver module consists of a series of SPI writes to various registers of the module which determine how it will operate. Each register is mentioned in the code whether it was used in the firmware or not, to allow for the user to have a general understanding of what the registers do without having to refer to the relevant paperwork. The most important part of this function is right at the start.

_delay_ms(50);write(0x07, 0x81); //Reset register values on RFM22B_delay_ms(50);

There is a delay inserted which gives time for the transceiver module to ‘wake up’ before any information is written. Then a command is sent to clear all of the register before any of the settings are changed. This ensured that every desired register write is executed properly.

Although the settings on the transceiver module are fully customisable, the firmware uses the following settings:

Function / Description Default Firmware

Transmission Rate 40 kbps 200 kbps

Transmission Frequency 995 MHz 434 MHz

Peak Frequency Deviation 20 KHz 26 KHz

Transmission Power -1 dBm 2 dBm

Preamble Length 4 Bytes 2 Bytes

Modulation Type Unmodulated carrier Frequency Shift Keying

Mode Direct Mode FIFO Mode

Automatic Packet Handling Enabled Enabled

Before the main loop of the program is entered, the rx_mode function is called to ensure that the default state of the device is awaiting a packet. The rx_mode function is detailed in the ‘Receiving’ section.

2.2.3 – SendingTo send a packet using the firmware provided, the first step is sending the Smart Packet Radio the packet desired to be sent in the following format:

Figure - Packet format for microcontroller

The packet is stored in a buffer on the microcontroller and once the full packet has been received the tx_mode function is called:

void tx_mode(void){ write(0x07, 0x01); //To ready mode cbi(PORTC, RXANT); //Clears RXANT sbi(PORTC, TXANT); //Sets TXANT

write(0x08, 0x03); // FIFO reset write(0x08, 0x00); // Clear FIFO }

This function sets the antenna to be used for transmission and clears the FIFO on the transceiver. This is done to ensure that the correct data is sent. Once this has been done, the transmit function is called:

void transmit(unsigned char *tx_packet){ write(0x3A, tx_packet[0]);

write(0x3E, (tx_packet[2]+3));

for (int i=0; i<(tx_packet[2]+3); i++) { write(0x7F, tx_packet[i]); //Send payload to the FIFO }

write(0x05, 0x04); // Enable packet sent interrupt write(0x06, 0x00); tx_mode_enabled = true; //Flag used to identify source of interrupt

write(0x07, 0x09); // Start TX }

The transmit function takes the buffer of characters sent from the host as an input. It writes the destination address to be used as Header Byte 3 which will be checked when other radios receive the packet and also sets the packet length. The packet is then written to the transceiver modules FIFO. An interrupt is enabled on the transceiver which is used to notify the microcontroller when the packet has been completely sent and a flag is set which prevents another packet from being read on the USB input before the current pack is sent. Another flag is set and checked in the ISR to determine what the interrupt was for. The microcontroller then sends the command for the transceiver to begin transmission.

Once the transmission is complete, an interrupt is sent to the microcontroller. When this happens, the ISR sets a flag high and reads the interrupt status registers located on the transceiver. The actual response to the interrupt takes place in the main loop of code. The interrupt status registers and relevant flags are checked and once it is determined that the interrupt was due to a valid packet being sent the following events occur:

The transceiver is taken out of transmission mode and placed into ready mode

The TX LED is turned on and a timer is started which will turn it off after an arbitrary amount of time.

The relevant transmission flags are cleared.

The rx_mode function is called, placing the transceiver into a state awaiting a packet.

2.2.4 – ReceivingUnless the Smart Packet Radio is sending a packet, the firmware ensures that it is in a state waiting to receive a packet from another device. There are two functions which facilitate the reception of a packet, the first being rx_mode:

void rx_mode(void){ write(0x07, 0x01); //To ready mode cbi(PORTC, TXANT); //Clears TXANT sbi(PORTC, RXANT); //Sets RXANT

write(0x07, 0x01); //To ready mode

write(0x08, 0x03); //Clears FIFO write(0x08, 0x00); //Resets FIFO

write(0x05, 0x02); //Enables packet received interrupt write(0x06, 0x00); rx_mode_enabled = true; //Flag used to identify source of interrupt

write(0x07, 0x05); //Places RFM22B in RX mode}

Firstly, the above function sets the antenna to be used for receiving and resets the FIFO on the transceiver module. It then enables an interrupt that will notify the microcontroller when a valid packet has been received and also sets a flag which will help the ISR identify which interrupt has caused the interrupt service routine to be initiated. The microcontroller then sends the command that places the transceiver into receive mode.

When the device receives a valid packet, and interrupt is triggered and the interrupt service routine is initiated which sets the IRQ flag and reads the interrupt status registers. Once the microcontroller determines that the interrupt was triggered due to a valid packet being received, the following events occur:

The transceiver is taken out of receive mode.

The RX LED is turned on and a timer is started which will turn it off after an arbitrary amount of time.

The receive function is called.

The received packet is sent to the host byte by byte via USB.

The rx_mode function is called and the device waits for another valid packet.

The following code is the receive function:

int receive(unsigned char *rx_buffer){ unsigned char i;

int receive_packet_length = read(0x4B);

for(i=0; i<receive_packet_length; i++) { rx_buffer[i] = read(0x7F); }

return receive_packet_length;}

The receive function first reads the packet length from the transceiver module and then proceeds to read the received packet from the FIFO on board the module and returns the length of the packet received.

2.2.5 – MiscellaneousApart from the interrupt generated by the transceiver module, there are three timer overflow interrupts which are used. Two of them are used to operate the RX and TX LEDs. The LEDs are switched on right before the timer is started. When the timer overflows an interrupt occurs, and the interrupts service routine switches the respective LED off. The third interrupt is used for two purposes. Firstly it toggles a blue LED intermittently as long as the firmware is running. This is used to ensure that the microcontroller is still running. If PA7 is pulled to ground and the interrupt is serviced, the temperature is read and sent to the host via USB in a string format.

The function idle_mode is not implemented in the firmware though was used for testing and debugging. Although the function isn’t called, it has been left as it may be necessary for future projects using the board. As the name suggests, the function places the transceiver module in an idle state where it won’t send or receive any information.

The function read_all_registers isn’t used in the firmware either but is another tool which can be used in future projects. The function simply sends the register number followed by the contents of that register to the host via USB. It can be used to ensure the registers are set as required.

3 - User Guide

3.1 – LinuxMost of the development of the Smart Packet Radio was performed using the Windows operating system. This was mainly due to the software available, as AVR Studio was preferable when programming the microcontroller and since the software used has a GUI which is generally easier to use. Once the microcontroller was setup as desired however, Linux provides a much easier method for communicating with the device.

3.1.1 - Programming the Microcontroller

Installation of required software:1. GCC-AVR is required to compile the code, this can be obtained by opening the terminal and

typing:

sudo apt-get install gcc-avr

2. A program called dfu-programmer is required to flash the code in .hex format onto the microcontroller. This can be installed by opening the terminal and typing:

sudo apt-get install dfu-programmer

Compiling the code:1. Extract the SPR Project to a directory of your choice.

2. Use your favourite text editor to edit the project as desired.

3. If any new files have been added, be sure to update the makefile included in the project.

4. Navigate to the projects directory in terminal and make the project.

Programming the microcontrollerAfter making the project, the .hex file should have been generated and saved to the project directory. Now it needs to be flashed to the microcontroller, which is accomplished using dfu-programmer and following the steps provided:

1. Hold the reset button on the Smart Packet Radio. Whilst the reset button is held down, hold the HWB button simultaneously. Let go of the reset button, followed by the HWB. This places the microcontroller into DFU mode and allows it to be programmed via USB.NOTE: No fuses on the microcontroller can be changed via USB.

2. Once in DFU mode, open the terminal and type:

sudo dfu-programmer at90usb1286 erase

3. As long as the previous operation was performed successfully, the microcontroller can now be programmed by typing:

sudo dfu-programmer at90usb1286 flash SPR.hex

4. After this has been done the device needs to be reset. This can be accomplished by pressing the reset button or by using the dfu-programmer by typing:

sudo dfu-programmer at90usb1286 reset

3.1.3 - Using the Smart Packet RadioAfter the device has been programmed and reset the operating system should recognise it as a communications port. In order to find what port it has been assigned to, open the terminal and type:

ls /dev/ttyACM*The following should show on the screen:

Figure - Ports listed in terminal

In the example above the port is located at “/dev/ttyACM0”. Depending on what is connected to the computer, more than one port may be displayed. Simple testing is required to determine which one the Smart Packet Radio is connected to. Once the port is determined it can simply be written to using the appropriate packet format and the data will be sent. It should also receive data but will only display it on the screen when the serial read command is used.

Example Python ScriptAs Python was the language intended to be used with the boards, an example script for transmitting and a separate script for receiving have been written. In order to use the script, it is required that the ‘serial’ header file is downloaded. This can be acquired by typing:

sudo apt-get install python-serialOnce it has been downloaded, the sample code for transmission is as follows:Note: The port must be edited depending on which port the device is connected.

#!/usr/bin/env pythonimport serialimport sysimport timedevice=serial.Serial('/dev/ttyACM'+sys.argv[1],115200)

for i in range(500):    device.write(chr(0xff)+chr(0xaa)+chr(0x07)+'1234567')    print 'Sending packet %d'%i

The port determined in the previous step is used as an input argument when running the code. The above code sends the 500 packets which are 10 bytes long, and returns the total time taken to send the packets. Note that the format used is ‘Destination address’, ‘Don’t care’ (as the source address is inserted by the firmware), ‘Payload length’, followed by the payload which is 7 bytes in length.

The sample code for receiving is as follows:

#!/usr/bin/env pythonimport serialimport sysimport timedevice=serial.Serial('/dev/ttyACM'+sys.argv[1],115200)

device.read(20)start=time.time()device.read(1020)print time.time()-start

The above code reads 1000 bytes and prints the time taken to receive the data. This was useful for determining the practical transmission rate of the device.

This is how the Smart Packet Radio is used. Obviously the Python script can be expanded on greatly to include packet handling and can be used to implement any desired routing algorithm

3.2 – WindowsWindows was chiefly used when developing the device. This was due to the fact that the testing software and hardware used was more easily compatible with Windows. As expressed in the final section though, communication with the Smart Packet Radio as a communications port is limited.

3.2.1 - Programming the Microcontroller

Installation of required softwareAVR Studio is used to write and compile the code that will be flashed onto the microcontroller. It is recommended that AVR Studio 4 is used. This can be downloaded for free though is included with the project.

Win AVR is also required to compile the code. This can be downloaded for free.

Flip is the program that is used to flash the compiled .hex file onto the microcontroller. This can also be downloaded for free and is included with the project.

Programming the microcontrollerAfter the software is downloaded and installed, the desired code can be flashed onto the device by following these steps:

1. Open project in AVR Studio.

2. Edit the project as desired.

3. If any new files have been added, be sure to update the makefile included in the project.

4. Select “Build -> Rebuild All”.

5. The SPR.hex file should be generated and saved in the project directory.

Now that the code has been compiled successfully, it can be flashed onto the microcontroller using Flip. After the program is open:

1. Hold the reset button on the Smart Packet Radio. Whilst the reset button is held down, hold the HWB button simultaneously. Let go of the reset button, followed by the HWB. This places the microcontroller into DFU mode and allows it to be programmed via USB.NOTE: No fuses on the microcontroller can be changed via USB.

2. From the toolbar “Device -> Select” and choose AT90USB1286 from the list.

3. Select the “Load hex file” button and navigate to the .hex file generated previously.

Figure - Flip Toolbar

4. Select the “Open communications medium” button and click USB. Then click “Open”. If this doesn’t work reset the device and repeat from step 1.

5. Click “Run” in the bottom left hand corner and once the device is programmed click “Start Application” in the bottom right.

The software should now be loaded on to the device.

3.2.3 - Using the Smart Packet RadioWhen the device is programmed and connected, Windows 7 should recognise the Smart Packet Radio as a communications port and subsequently install the required drivers.

The program used in testing to access the communications port was “Terminal by Brady”. This can also be downloaded for free. One of the limitations using the Smart Packet Radio with Windows is that a script can’t be written which handles reading and writing to the communications port. As such the only intelligence on the user end is writing the packet that wishes to be sent, and choosing a rate of transmitting those packets (to a maximum of 100 times a second). The programs interface is as follows:

Figure - Toolbar of Terminal Program

After the device has been programmed and reset, select “ReScan” and it should show up in the dropdown menu to the right as one of the COM ports. The baud rate can also be chosen. The data bits must be set to 8, with no parity and 1 stop bits. There’s also no handshaking. The other important selection is whether you want the data to be displayed in HEX or ASCII.

Once the desired settings have been chosen, select “Connect” from the top left hand corner. If the output is selected to be displayed in hex, any information received from another device should automatically show up on the screen. If the temperature sensor is enabled, ASCII display should be selected as the temperature will be printed approximately twice a second.

To send information, select “Set Macros” located at the bottom. The following screen will be presented:

Figure - Macro Settings Menu (Terminal Program)

The information to be sent should be entered in HEX using the format $AA for a HEX value of 0xAA. It’s important to note that spaces shouldn’t be placed between bytes, and that if using the firmware the appropriate packet format is used (i.e. Destination address, don’t care, payload length, payload). If the checkbox at the end of the macro is checked, that macro will be sent to the relevant port every 1000 ms. This number can be changed to a minimum of 10 ms.

3.3 – Altering the RFM22B SettingsAltering the settings used to transmit data on the transceiver module can easily be changed by altering the contents of the registers using simple SPI writes. In the firmware code, these have been listed in sequential order with a brief description of their function. Although specific details of their implementation can be found in the attached information, a general overview of the registers mainly utilised in the firmware is given below.

Not all registers and settings are used in the firmware. The main ones used are:

InterruptsRegister Function

0x03 & 0x04 Interrupt status registers. Information in these registers can be used to determine what the reason for a triggered interrupt was. They must also be read in order to reset the signal on the interrupt pin. Note: If an event occurs, the interrupt status bit will be asserted whether the interrupt enable bit is set or not. Though the interrupt enable bit must be set for an interrupt to physically occur.

0x05 & 0x06 Interrupt enable registers. By setting the bits in these registers, the microcontroller will be notified when the relevant event occurs via a signal on the interrupt pin. The only two interrupts used in the firmware are valid packet sent and valid packet received interrupts.

Operating Function and ControlRegister Function

0x07 & 0x08 Used to control the operation of the transceiver module. In the firmware, these registers are used to initialise the transceiver to a ready state and also to place it into send and receive modes. They are also used to clear the send and receive FIFOs to ensure that the correct data is read from the module.

Packet FormatRegister Function

0x30 Data access control. Is used to enable the used of the packet handler on board the transceiver module for both sending and receiving. Also used to implement a CRC on the packet sent. The mentioned features are all taken advantage of in the firmware.

0x32 & 0x33 Header control. Used to set the desired length of both the sync word and header. Also enables the use of a broadcast byte, which means if the header is set to a hex value of 0xFF the receive header check is disregarded. This feature is implemented in the firmware.

0x34 Used to set the preamble length. Through testing, it was determined that 2 bytes length resulted in few erroneous valid preambles being detected though this can obviously be alter depending on the application desired.

0x36 – 0x39 Sync word 3-0. These registers are used to set the sync word which consists of 4 bytes of data. When using the automatic packet handler offered by the transceiver module, the sync word must be at least 1 byte in length. In the firmware only 1 byte is used and it’s set to the default value.

0x3A – 0x3D Transmit header 3-0. These registers are used to set the value of the header bytes used. In the firmware, only 1 header byte is used and the destination address is written to the relevant register in the transmit function.

0x3E Packet length. The length of the payload is written to this register and notifies the transceiver of how many bytes it needs to send. In the firmware, this is written inside the transmit function.

0x3F – 0x42 Check header 3-0. The head bytes received are checked against the values held inside these registers. In the firmware, the source address of the board is written to check header byte 3 at start up.

Transmitting and Receiving SettingsRegister Function

0x1C – 0x25 FSK settings. These registers are used when utilizing frequency shift keying which is implemented in the firmware.

0x6E – 0x70 Data rate settings. Used to set the transmission rate of the transceiver, is set to the maximum of 200 kbps in the firmware.

0x75 – 0x77 RX/TX carrier frequency settings. Used to determine the carrier frequency used. Is set to 434 MHz in the firmware.

0x71 & 0x72 Frequency deviation settings. In the firmware this is set to 26 MHz.

Note: When changing these settings, the suggested method is to open the spreadsheet “Si443x-Register-Settings” and put in the desired settings. The spreadsheet should update the relevant register information and this can be used to program the transceiver.

4 – Applications

4.1 - A Learning ToolThe Smart Packet Radio is intended to replace the current packet radios being used in the wireless communication labs. The Smart Packet Radio can be used to introduce students to telecommunications, and can be used as a tool to learn and implement simple protocols to observe how they work in practice. At a more advanced level, the device can be used as a platform to develop and test various routing protocols. Due to its configurability, a wider variety of avenues can be explored. These features include frequency hopping, varying transmission frequencies, different types of modulation (or no modulation); different transmission rates and a direct mode which bypasses the packet handler on board the transceiver (which may be desirable for certain applications)

4.2 - Beaconless Routing ProtocolsThe Smart Packet Radio was initially developed to provide an opportunity to research beaconless routing protocols. In the design specification for this project, three different beaconless routing protocols were researched for implementation in a wireless network of Smart Packet Radios. This section will detail each protocol, as they may still serve as a base for development in the future.

3.2 - Beacon-Less Routing (BLR)[1]

Process1. The full data packet is sent by the initial sender.

2. Any nodes that provide progress towards the destination consider themselves appropriate as a next hop and begin a countdown timer.

3. When the countdown is complete, the data is resent either to the next hop or destination.

4. Any node that overhears the packet being resent cancels their own timer whilst the sender interprets this as an acknowledgement and assumes the first hop has received the packet successfully.

If the initial sender doesn’t overhear the data packet being forwarded within the time Tmax, it will attempt to send the packet another 5 times before discarding the data packet.

AdvantagesThere has been a study regarding packet length and how it affects the reliability of transmission. It has been shown that smaller packets are more likely to be delivered than larger ones [3]. Because this algorithm sends the full data packet straight away, this means it will choose a next hop with a stable connection every time.

The BLR protocol uses the full data packet as its initial broadcast and also uses subsequent broadcasts of the data packet as passive acknowledgements. This reduces the amount of control packets required and this is a highly desirable characteristic as one of the major goals of research in this area is to minimize the amount messages required to transfer information, both to save power and reduce the chances of collisions.

DisadvantagesAlthough the use of subsequent broadcasts of the data packet as a passive acknowledgement may be advantages in some respects, it also results in multiple neighbours forwarding the message. This occurs when both nodes are within range of the initial sender, but not within range of each other. The following diagram illustrates this scenario:

Although the sender has detected 2 potential next hops, because A can’t overhear B forwarding the packet and vice versa, a duplicate message will be produced.

3.3 - Implicit Geographic Forwarding (IGF)[2]

Process1. A Request to Send (RTS) message is sent by initial sender.

2. Any nodes that provide progress towards the destination begin a countdown timer.

3. The timer is calculated using the same equation described previously.

4. When the countdown is complete, a Clear to Send (CTS) message is broadcast.

5. Any potential hops that overhear this CTS will cancel their own timers.

6. The node that provides the most progress should respond with a CTS frame first, when this is received by the initial sender the data packet is sent to that particular node.

7. After the full data packet is received and acknowledgement is sent back to the initial sender.

8. The selected node then begins the process again.

If the initial sender does not receive a CTS in response to its first RTS message by time Tmax, it will broadcast another 5 RTS frames before discarding the data packet.

After a next hop is selected via the RTS to CTS handshake and the full data packet is sent, if an acknowledgement isn’t received by time , the node will attempt to send the data packet up to a maximum of 3 times until it will retransmit a RTS frame, ignoring any CTS messages sent by the initial next hop selected.

AdvantagesThe use of RTS and CTS control messages means that the initial sender will unicast the data packet to the first hop. As the next hop is decided by the sender there is virtually no chance of multiple forwarders being selected.

DisadvantagesUsing control messages in the algorithm means that the number of messages sent per transfer is increased. This is undesirable as the purpose of beacon less routing is to minimise the total number of messages being sent to provide a more efficient communications protocol.

Generally the RTS and CTS packets being sent are relatively small. This means that although control messages can be exchanged between the initial forwarder and a potential next hop, when the full data packet is transmitted there’s a chance that it may not be able to traverse the link. This will result in redundant messages being sent as well as a delay in the transfer as the initial sender will have to begin the process all over again, selecting a different node as the first hop.

3.4 - BLR and IGF Combination (Based on BOSS protocol)[3]

Process1. An initial packet is sent. This contains the full data message, the position of the initial sender

and the position of the destination.

2. Any node that provides progress towards the destination stores the message.

3. A timer is then started, with the time being calculated as with the previous protocols.

4. A response message containing the nodes position is broadcasted.

5. Any neighbours that overhear the broadcast cancel their own timer and delete the stored packet.

6. When the initial sender receives the response, it broadcasts a selection frame notifying neighbouring nodes of which will be selected to forward the message.

7. Any nodes that overhear the selection message and haven’t already cancelled their timers will do so.

8. The selected node then forwards an initial packet as mentioned in step 1, beginning the process again.

During the forwarding process, when the selected node forwards an initial packet the initial sender will over hear this and interpret it as an acknowledgement. As with BLR, this reduces the number of control messages required. The only drawback is when the packet reaches the destination. As the destination doesn’t forward the message, the node that passed it on will assume the packet wasn’t received. Therefore an acknowledgement needs to be sent when the message arrives at the destination.

AdvantagesThis protocol aims to combine the advantages of the previously mentioned protocols. By including the full data message in the first packet being sent, this will prevent the initial sender from choosing a next hop that may have an unstable connection. This results in less retransmissions and a lower end to end delay.

As with the IGF protocol, this protocol relies on control messages sent between nodes. This ensures that the forwarding of the packet is done by a single node and prevents multiple packets arriving at the destination.

DisadvantagesIn theory this protocol should outperform both of the previously mentioned protocols; though by combining their strengths it will also inherit minor comparative weaknesses.

Although it will produce fewer duplicates than the BLR protocol, it requires more control messages to do so. And although it will utilise more stable links than the IGF protocol, it must also send larger messages when transferring data from source to destination.

Algorithm

Problem IGF BLR BOSS

Unreachability High Low Low

Unreliability Med Med Low

Duplicates Low High Low

Contention Med Med Low

5 – ConclusionIn conclusion, the Smart Packet Radio has been developed and tested, and is in basic working order. It is set to transmit at the maximum data rate allowable for the modulation being used which is 200 kbps. The maximum transmission distance was found to be 300m, though for its intended purpose this distance is not required.

Disregarding the internal settings for transmission power, the size of the antenna had a great impact on the reliable transmission distance. Using an antenna with a length of ƛ/4 gave the greatest results, though because multiple hops would be required over the length of the communications labs, the antenna size was reduced to around half of that. Coupled with minimum transmission power this reduced the reliable transmission distance to about 10 metres.

The internal packet handler is also used successfully, implementing a preamble, sync byte, header byte and CRC. These features result in a great reliability of transmission though these features may wish to be disabled in future applications.

The user guide written in this report was also a core component of this project. As the Smart Packet Radio is intended to be used for future project of various natures, it’s essential that whoever uses them has a quick and easy method of implementing the device whether on the Windows operating system, or Linux.

Although most of the final tests were successful, an error was encountered when attempting to write packets continuously to one board using the Python code mentioned earlier. The tests were successful up to about 4000 packets. For an unknown reason if an amount greater than this was selected, after a few seconds the radio would start transmitting at around one packet a second. As most of the testing was performed using the terminal program in Windows this problem wasn’t encountered until the end of the project and there wasn’t enough time to look into it thoroughly. It may have something to do with the asymmetrical nature of the speed at which data is being read in to the device compared to how quickly it is sent. As the ability to send this amount of packets one after the other may not be necessary in the future, it can be investigated at a later time if this feature is desired.

The direct mode offered by the transceiver which bypasses the internal packet handler was also attempted. Unfortunately it was difficult to get working and the idea was scrapped as the FIFO mode offered by the module seemed like a more reliable route. If the user wishes all of the packet handling to be done at a higher level and the device to have no intelligence (i.e. only used to send and receive information) direct mode may be desirable. The hardware is set up allows this mode to be possible though more testing is needed to develop it properly.

The firmware has been attached as an appendix if further analysis is required though for practical application the whole project is required for the board to operate, as parameters set by the LUFA code is not included in the main c file.

6 – Appendices

Appendix A

Appendix B

Appendix C

Appendix D/* LUFA Library Copyright (C) Dean Camera, 2011.

dean [at] fourwalledcubicle [dot] com www.lufa-lib.org*/

/* Copyright 2011 Dean Camera (dean [at] fourwalledcubicle [dt] com)

Permission to use, copy, modify, distribute, and sell this software and its documentation for any purpose is hereby granted without fee, provided that the above copyright notice appear in all copies and that both that the copyright notice and this permission notice and warranty disclaimer appear in supporting documentation, and that the name of the author not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission.

The author disclaim all warranties with regard to this software, including all implied warranties of merchantability and fitness. In no event shall the author be liable for any special, indirect or consequential damages or any damages whatsoever resulting from loss of use, data or profits, whether in an action of contract, negligence or other tortious action, arising out of or in connection with the use or performance of this software.*/

/** \file * * Main source file for the USBtoSerial project. This file contains the main tasks of * the project and is responsible for the initial application hardware configuration. */

#include <avr/io.h>#include <avr/interrupt.h>#include <stdio.h>#include <stdbool.h>#include <util/delay.h>#include "ds18b20.h"

//===============================////Set bit and clear bit functions////===============================//

#define sbi(var, mask) ((var) |= (uint8_t)(1 << mask)) //Set bit function#define cbi(var, mask) ((var) &= (uint8_t)~(1 << mask)) //Clear bit function

//=================////RFM22 Pin Defines////=================//

#define CS 0 //PB0 - Chip select pin for RFM22B#define TXANT 1 //PC1 - Sets the antenna to be used for transmission#define RXANT 2 //PC2 - Sets the antenna to be used for receiving

//==========//

//Prototypes////==========//

void AVR_Init(void); //Initialises pins on the microcontrollervoid RFM22_Init(void); //Initialises RFM22B transceiverchar read(uint8_t); //SPI read functionvoid write(uint8_t, char); //SPI write functionvoid tx_mode(void); //Readies RFM22B for transmissionvoid transmit(unsigned char*); //Writes data to FIFO on RFM22B and sends transmit commandvoid rx_mode(void); //Readies RFM22 for receivingint receive(unsigned char*); //Reads received data from RFM22Bvoid idle_mode(void); //Places RFM22B in an idle statevoid read_all_registers(void); //Reads all the registers on the RFM22B

//================////Global Variables////================//

volatile bool IRQTriggered; //Flag indicating when an IRQ has occureduint8_t intrs = 0;bool tx_mode_enabled; //Flag used to show the board has just sent a packetbool rx_mode_enabled; //Flag used to show the board is waiting to receive a packetunsigned char source_address = 0x0B; //Source address of boardchar temperature_buffer[12];unsigned char int1;unsigned char int2;

//================================================//

#include "USBtoSerial.h"

/** LUFA CDC Class driver interface configuration and state information. This structure is * passed to all CDC Class driver functions, so that multiple instances of the same class * within a device can be differentiated from one another. */USB_ClassInfo_CDC_Device_t VirtualSerial_CDC_Interface = { .Config = { .ControlInterfaceNumber = 0,

.DataINEndpointNumber = CDC_TX_EPNUM, .DataINEndpointSize = CDC_TXRX_EPSIZE, .DataINEndpointDoubleBank = false,

.DataOUTEndpointNumber = CDC_RX_EPNUM, .DataOUTEndpointSize = CDC_TXRX_EPSIZE, .DataOUTEndpointDoubleBank = false,

.NotificationEndpointNumber = CDC_NOTIFICATION_EPNUM, .NotificationEndpointSize = CDC_NOTIFICATION_EPSIZE, .NotificationEndpointDoubleBank = false, }, };

/** Main program entry point. This routine contains the overall program flow, including initial * setup of all components and the main program loop. */

int main(void){ // Local variables unsigned char tx_buffer[255];

unsigned char rx_buffer[255];int tx_count = 0;int receive_packet_length; //Variable used to

store the length of the packet that's been receivedbool transmitting = false;

IRQTriggered = false; SetupHardware();

sei();

rx_mode();

for (;;) {

//ISR if (IRQTriggered) {

//Packet sent interrupt if((int1 & (1 << 2)) && tx_mode_enabled) { write(0x07, 0x01); //Set to ready mode

PORTB ^= (1 << 6); //Toggle TX LED

TCCR1B = 0x02;tx_mode_enabled = false; //Disable

tx_mode flagtransmitting = false;

rx_mode(); //Sets chip back to rx_mode }

//Valid packet received interrupt else if(int1 & (1 << 1) && rx_mode_enabled)

{write(0x07, 0x01); //Set to ready mode

PORTB ^= (1 << 5); //Toggle RX LEDTCCR3B = 0x02;receive_packet_length = receive(rx_buffer);

//Reads received packet and places bits in rx_bufferfor(int i = 0; i < (receive_packet_length);

i++){

//Prints contents of rx_buffer to comms port

CDC_Device_SendByte(&VirtualSerial_CDC_Interface, rx_buffer[i]);}rx_mode(); //Sets chip back to

rx_mode }

//Unexpected interrupt else {

PORTE ^= (1 << 0); //Causes RGB LED to go red representing an unrecognised interrupt }

// Reset flag IRQTriggered = false; }

if(!transmitting){

int16_t ReceivedByte = CDC_Device_ReceiveByte(&VirtualSerial_CDC_Interface); if (!(ReceivedByte < 0)) {

switch(tx_count){

//write(0x07, 0x01); //Puts RFM22 into ready mode

//First byte of the packet contains the destination address

case 0:tx_buffer[tx_count] = ReceivedByte;tx_count += 1;break;

//Second byte of the packet will contain the source address provided by the board

case 1:tx_buffer[tx_count] = source_address;tx_count += 1;break;

//Third byte of the packet contains the length of the payload

case 2:tx_buffer[tx_count] = ReceivedByte;

CDC_Device_SendByte(&VirtualSerial_CDC_Interface, tx_buffer[tx_count]);

tx_count += 1;break;

//The rest of the data contained is the payload and will be read into the tx_buffer

default:if (tx_count < (tx_buffer[2]+2)){

tx_buffer[tx_count] = ReceivedByte;tx_count += 1;

}//When the last byte of the payload is read in, the

transceiver is put into transmit mode//and the packet is then transmitted

else{

tx_buffer[tx_count] = ReceivedByte;tx_count = 0;transmitting = true;tx_mode();transmit(tx_buffer);

}break;

}}

} CDC_Device_USBTask(&VirtualSerial_CDC_Interface);

USB_USBTask(); }}

/** Configures the board hardware and chip peripherals for the functionality. */void SetupHardware(void){ /* Disable watchdog if enabled by bootloader/fuses */ MCUSR &= ~(1 << WDRF); wdt_disable();

/* Disable clock division */ clock_prescale_set(clock_div_1);

/* Hardware Initialization */ USB_Init(); AVR_Init(); RFM22_Init();}

/** Event handler for the library USB Connection event. */void EVENT_USB_Device_Connect(void){ cbi(PORTC, 6); //Set RGB LED1 Blue - USB Enumerating}

/** Event handler for the library USB Disconnection event. */void EVENT_USB_Device_Disconnect(void){ cbi(PORTC, 4); //Set RGB LED1 Red - USB Disconnected}

/** Event handler for the library USB Configuration Changed event. */void EVENT_USB_Device_ConfigurationChanged(void){ bool ConfigSuccess = true;

ConfigSuccess &= CDC_Device_ConfigureEndpoints(&VirtualSerial_CDC_Interface); if (ConfigSuccess) {

sbi(PORTC, 6); cbi(PORTC, 5); //Set RGB LED1 Green - USB Ready } else { cbi(PORTC, 4); //Set RGB LED1 Red - USB Error }}

/** Event handler for the library USB Control Request reception event. */void EVENT_USB_Device_ControlRequest(void){ CDC_Device_ProcessControlRequest(&VirtualSerial_CDC_Interface);}

/** Event handler for the CDC Class driver Line Encoding Changed event. * * \param[in] CDCInterfaceInfo Pointer to the CDC class interface configuration structure being referenced */

void EVENT_CDC_Device_LineEncodingChanged(USB_ClassInfo_CDC_Device_t* const CDCInterfaceInfo){}

void AVR_Init(void){ //Initialises SPI for communication with RFM22B module SPI_Init(SPI_SPEED_FCPU_DIV_2 | SPI_ORDER_MSB_FIRST | SPI_SCK_LEAD_RISING | SPI_SAMPLE_LEADING | SPI_MODE_MASTER);

DDRB |= 0xF1; //Enable SS as an output PORTB |= 0x80; //Pull SS high// PORTB |= 0x10; //Shut down RFM22 DDRE = 0x00; PORTE = 0x40; //Enable pull-up on PE6 to be used for intererr DDRC = 0x77; //RGB LED output pins LED1(PC4-R, PC5-G, PC6-B) LED2(PC0 - B) Used for USB Status PORTC = 0x71; //Output High

DDRA = 0x00; //Port A used for inputPORTA = 0x40;

DDRE |= 0x03; //RGB LED output pins LED2(PE0 - R, PE1 - G) PORTE |= 0x03; //Output high

// External Interrupt(s) initialization // INT6 Mode: Falling Edge //Sets pin PE6 to receive neg edge interrupt from RFM22B module EICRA=0x00; EICRB=0x20; EIMSK=0x40; EIFR=0x40;

//Enable timers and timer overflow interruptsTCCR0B = 0x04;TCCR1B = 0x00;TCCR3B = 0x00;

TIMSK0 |= _BV(TOIE0);TIMSK1 = 0x01;TIMSK3 = 0x01;TCNT0 = 0;

}

// Initialize the RFM22 for transmittingvoid RFM22_Init(void){/*//=======================////Register initialisation////=======================// Address Read/Write - Function*/

_delay_ms(50); write(0x07, 0x81); //Reset register values on RFM22B

_delay_ms(50);

//0x00 R - Device type//0x01 R - Device version//0x02 R - Device status

//0x03 R - Interrupt status 1//0x04 R - Interrupt status 2//0x05 R/W - Interrupt Enable 1 write(0x05, 0x00); //Disable all interrupts//0x06 R/W - Interrupt Enable 2 write(0x06, 0x00); // Disable all interrupts//0x07 R/W - Operating function and control 2 write(0x07, 0x01); // Set READY mode//0x08 R/W - Operating function and control 2//0x09 R/W - Crystal oscillator load capacitance

write(0x09, 0x7F); // Cap = 12.5pF//0x0A R/W - Microcontroller output clock write(0x0A, 0x05); // Clk output is 2MHz//0x0B R/W - GPIO_0 configuration write(0x0B, 0xF4); // GPIO0 is for RX data output//0x0C R/W - GPIO_1 configuration write(0x0C, 0xEF); // GPIO1 is TX/RX data CLK output//0x0D R/W - GPIO_2 configuration

write(0x0D, 0x00); //0x0E R/W - I/O port configuration write(0x0E, 0x00); //0x0F R/W - ADC configuration write(0x0F, 0x70); //0x10 R/W - ADC sensor amplifier offset write(0x10, 0x00); //0x11 R - ADC value//0x12 R/W - Temperature sensor control write(0x12, 0x00); //0x13 R/W - Temperature offset value write(0x13, 0x00); //0x14 R/W - Wake-up timer period 1 //0x15 R/W - Wake-up timer period 2//0x16 R/W - Wake-up timer period 3//0x17 R - Wake-up timer value 1//0x18 R - Wake-up timer value 2//0x19 R/W - Low-duty cycle mode duration//0x1A R/W - Low battery detector threshold//0x1B R - Battery voltage level//0x1C R/W - IF filter bandwidth

write(0x1C, 0x88); //200kbps // write(0x1C, 0x83); //150kbps// write(0x1C, 0x9A); //100kbps //0x1D R/W - AFC loop gearshift override write(0x1D, 0x3C); //200kbps & 150kbps & 100kbps //0x1E R/W - AFC timing control

write(0x1E, 0x02); //200kbps & 150kbps & 100kbps //0x1F R/W - Clock recovery gearshift override write(0x1F, 0x03); //200kbps & 150kbps & 100kbps//0x20 R/W - Clock recovery oversampling ratio

write(0x20, 0x3C); //200kbps // write(0x20, 0x50); //150kbps// write(0x20, 0x3C); //100kbps //0x21 R/W Clock recovery offset 2 write(0x21, 0x02); //200kbps // write(0x21, 0x01); //150kbps// write(0x21, 0x02); //100kbps //0x22 R/W - Clock recovery offset 1 write(0x22, 0x22); //200kbps// write(0x22, 0x99); //150kbps// write(0x22, 0x22); //100kbps//0x23 R/W - Clock recovery offset 0 write(0x23, 0x22); //200kbps// write(0x23, 0x9A); //150kbps // write(0x23, 0x22); //100kbps

//0x24 R/W - Clock recovery timing loop gain 1 write(0x24, 0x07); //200kbps & 150 kbps & 100kbps //0x25 R/W - Clock recovery timing loop gain 0 write(0x25, 0xFF); //200kbps & 150 kbps & 100kbps //0x26 R - Received signal strength indicator//0x27 R/W - RSSI threshold for clear channel indicator//0x28 R - Antenna dicersity register 1 //0x29 R - Antenna dicersity register 2//0x2A R/W - AFC limiter

write(0x2A, 0xFF); //200kbps & 150 kbps & 100kbps//0x2B R - AFC correction read//0x2C R/W - OOK counter value 1 write(0x2C, 0x00);//0x2D R/W - OOK counter value 2 write(0x2D, 0x00);//0x2E R/W Slicer peak hold write(0x2E, 0x00);//0x2F - RESERVED//0x30 R/W - Data access control write(0x30, 0x8C); //0x31 R - EzMAC Status//0x32 R/W - Header control 1 write(0x32, 0x88); //Check header byte 3 and enable broadcast byte (0xFF) //0x33 R/W - Header control 2 write(0x33, 0x10); //Sets length of header to 1 byte //0x34 R/W - Preamble length write(0x34, 4); // 4 nibble = 2 byte preamble//0x35 R/W - Preamble detection control write(0x35, 0x20); //0x36 R/W - Sync word 3 write(0x36, 0x2D); //0x37 R/W - Sync word 2//0x38 R/W - Sync word 1//0x39 R/W - Sync word 0//0x3A R/W - Transmit header 3 //Transmit header set dynamically in transmit function //0x3B R/W - Transmit header 2//0x3C R/W - Transmit header 1//0x3D R/W - Transmit header 0//0x3E R/W - Packet length //Packet length is set dynamically in transmit function//0x3F R/W - Check header 3

write(0x3F, source_address);//0x40 R/W - Check header 2//0x41 R/W - Check header 1//0x42 R/W - Check header 0//0x43 R/W - Header enable 3 write(0x43, 0xFF); //Check all bits//0x44 R/W - Header enable 2//0x45 R/W - Header enable 1//0x46 R/W - Header enable 0//0x47 R - Received header 3//0x48 R - Received header 2//0x49 R - Received header 1//0x4A R - Received header 0 //0x4B R - Received packet length//0x4C to 0x4E - RESERVED//0x4F R/W - ADC8 control//0x50 to 0x5F - RESERVED//0x58 R/W - Changed whsen setting tx data rate

write(0x58, 0xED); //200kbps// write(0x58, 0xC0); //150kbps & 100kbps//0x60 R/W - Channel filter coefficient address

//0x61 - RESERVED//0x62 R/W - Crystal oscillator / Control test//0x63 to 0x68 - RESERVED//0x69 R/W - AGC Override 1

write(0x69, 0x60); //200kbps & 150kbps & 100kbps//0x6A to 0x6C - RESERVED//0x6D R/W - TX power write(0x6D, 0x01); // TX power to max//0x6E R/W - TX data rate 1 write(0x6E, 0x33); //200kbps// write(0x6E, 0x26); //150kbps// write(0x6E, 0x19); //100kbps //0x6F R/W - TX data rate 0 write(0x6F, 0x33); //200kbps// write(0x6F, 0x66); //150kbps// write(0x6F, 0x9A); //100kbps //0x70 R/W - Modulcation mode control 1

write(0x70, 0x0C); // No manchester code, no data whiting//0x71 R/W - Modulcation mode control 2 //write(0x71, 0x02); //Direct mode FSK

write(0x71, 0x22); // FSK, fd[8]=0, no invert for TX/RX data, FIFO mode//0x72 R/W - Frequency deviation write(0x72, 0x50); //200kbps // Frequency deviation setting to 45K=72*625//0x73 R/W - Frequency offset 1 write(0x73, 0x00); // No frequency offset//0x74 R/W - Frequency offset 2

write(0x74, 0x00); // No frequency offset//0x75 R/W - Frequency band select write(0x75, 0x53); // frequency set to 434MHz//0x76 R/W - Nominal carrier frequency 1 write(0x76, 0x64); // frequency set to 434MHz//0x77 R/W - Nominal carrier frequency 0 write(0x77, 0x00); // frequency set to 434Mhz//0x78 - RESERVED//0x79 R/W - Frequency hopping channel select write(0x79, 0x00); // no frequency hopping//0x7A R/W - Frequency hopping step size write(0x7A, 0x00); // no frequency hopping//0x7B - RESERVED//0x7C R/W - TX FIFO control 1//0x7D R/W - TX FIFO control 2//0x7E R/W - RX FIFO control//0x7F R/W - FIFO access

cbi(PORTC, TXANT); //Clears TXANT cbi(PORTC, RXANT); //Clears RXANT}

//=============================================================////Function that reads all of the registers in the RFM22B module////=============================================================//void read_all_registers(void){

unsigned char value;unsigned char i;for(i = 0; i<0x80; i++){

value = read(i);CDC_Device_SendByte(&VirtualSerial_CDC_Interface, i);CDC_Device_SendByte(&VirtualSerial_CDC_Interface, value);

}

PORTE ^= (1 << 0);}

//=================================================================////Function that readies the RFM22B module for wireless transmission////=================================================================//void tx_mode(void){ write(0x07, 0x01); //To ready mode cbi(PORTC, RXANT); //Clears RXANT sbi(PORTC, TXANT); //Sets TXANT

write(0x08, 0x03); // FIFO reset write(0x08, 0x00); // Clear FIFO }

//=============================================////Function to Transmit Packet via RFM22B Module////=============================================//void transmit(unsigned char *tx_packet){

write(0x3A, tx_packet[0]);

write(0x3E, (tx_packet[2]+3));

for (int i=0; i<(tx_packet[2]+3); i++) {// CDC_Device_SendByte(&VirtualSerial_CDC_Interface, tx_packet[i]); write(0x7F, tx_packet[i]); //Send payload to the FIFO }

write(0x05, 0x04); // Enable packet sent interrupt write(0x06, 0x00);

tx_mode_enabled = true; //Sets tx_mode flag

write(0x07, 0x09); // Start TX }

//=============================================================////Puts RFM22B into an Idle state, neither sending nor receiving////=============================================================//void idle_mode(void){ write(0x07, 0x01); //To ready mode

write(0x08, 0x03); //Clears FIFO write(0x08, 0x00); //Reset FIFO

cbi(PORTC, TXANT); //Clears TXANT cbi(PORTC, RXANT); //Clears RXANT}//===============================================////Function to place RFM22B module to receive mode////===============================================//void rx_mode(void){ write(0x07, 0x01); //To ready mode cbi(PORTC, TXANT); //Clears TXANT sbi(PORTC, RXANT); //Sets RXANT

write(0x07, 0x01); //To ready mode

write(0x08, 0x03); //Clears FIFO write(0x08, 0x00); //Resets FIFO

write(0x05, 0x02); //Enables packet received interruptwrite(0x06, 0x00);rx_mode_enabled = true;

write(0x07, 0x05); //Places RFM22B in RX mode}

//=================================================////Function reads data from RX FIFO on RFM22B module////=================================================//int receive(unsigned char *rx_buffer){ unsigned char i;

int receive_packet_length = read(0x4B);

for(i=0; i<receive_packet_length; i++) { rx_buffer[i] = read(0x7F); }

return receive_packet_length;}

//==============================================////Reads from specified register on RFM22B module////==============================================//char read(uint8_t address){ address &= 0x7F; //Sets MSB to 0 for read cbi(PORTB, CS); //Selects RFM22B module SPI_SendByte (address); //Sends address to read from char rx = SPI_ReceiveByte(); //Reads char sbi(PORTB, CS); //Deselects module return rx;}

//=================================================////Writes specified data to address on RFM22B module////=================================================//void write(uint8_t address, char data){ address |= 0x80; //Sets MSB to 1 for write cbi(PORTB, CS); //Selects RFM22B module SPI_SendByte (address); //Sends address to write to SPI_SendByte (data); //Writes data to selected address sbi(PORTB, CS); //Deselects module}

//======================================================////Raises flag when interrupt received from RFM22B module////======================================================//ISR(INT6_vect){ IRQTriggered = true; // Read interrupt status registers int1 = read(0x03); int2 = read(0x04);

}

//=============================================////Timer overflow interrupts used to control LEDs////=============================================//ISR(TIMER0_OVF_vect){

//Timer1 overflow used to toggle the MCU health LEDintrs++;if (intrs >= 30){

PORTB ^= (1 << 7);// read_all_registers();

if(bit_is_clear(PINA, PA6)) {

therm_read_temperature(temperature_buffer);

for(int i = 0; i < 10; i++){

//Prints contents of temperature_buffer to comms port

CDC_Device_SendByte(&VirtualSerial_CDC_Interface, temperature_buffer[i]);

}}intrs = 0;

}}

ISR(TIMER1_OVF_vect){

//Timer 1 overflow used to toggle TX LEDPORTB ^= (1 << 6);TCCR1B = 0x00;

}

ISR(TIMER3_OVF_vect){

//Timer 3 overflow used to toggle RX LEDPORTB ^= (1 << 5);TCCR3B = 0x00;

}

Works CitedMarc Heissenbuttel, T. B. � BLR: Beacon-Less Routing Algorithm for Mobile Ad-Hoc Networks. University of Bern, Switzerland: Institute of Computer Science and Applied Mathematics.

Z.M. Hanapi, M. I. (2009). Dynamic Window Secured Implicit Geographic. World Academy of Science, Engineering and Technology.

Juan A. Sanchez, R. M.-P. BOSS: Beacon-less On Demand Strategy for Geographic Routing inWireless. Fac. Informatica, Univ. of Murcia: Dept. of Information and Communications Engineering.

Atmel. (2008). USBAT9082/162 Datasheet.

HopeRF Electronic. RFM22 ISM Transceiver Module Datasheet.