Projects - User contributions [en]

Projects:2015s1-40 Flexible ad-hoc Network A: Physical Layer

2015-10-24T11:23:06Z

A1627539:

== Introduction ==

=== Overview ===

==== Project Team ====

Cong Nguyen

Duncan Lawry

==== Supervisors ====

Michael Liebelt

Braden Phillips

=== Significance ===

Ad-hoc wireless networks are self-configurable networks with high node mobility, allowing them to function without reliance on any fixed infrastructure. This makes wireless ad-hoc networks useful for quick communication channel deployment suitable for all applications.

While there are already many existing commercial solutions with ad-hoc capability such as [http://www.zigbee.org/ ZigBee], [https://developer.bluetooth.org/TechnologyOverview/Pages/PAN.aspx Bluetooth Personal Area Network (PAN)] and Wi-Fi based ad-hoc configurations ([http://windows.microsoft.com/en-au/windows/set-computer-to-computer-adhoc-network Windows], [https://support.apple.com/kb/PH13796?locale=en_US MacOS], [https://wiki.debian.org/WiFi/AdHoc Linux (Debian)]) these solutions are generally costly in terms of processing power, memory requirement due to reliance on existing protocol stack or costly in terms of royalty. Furthermore, they are commonly reliant on the ISM 2.4GHz band, making them unsuitable for high-range applications without having to invest on a larger antenna which can increase power requirement and a product's physical size.

This project aims to develop an ad-hoc network stack with low processing power and low memory requirement by developing customized protocol layers operating in ISM sub-1GHz frequency for long communication distance and free usage, while provide high reliability and robustness.

=== Objectives and Deliverables ===

This project involves the development of the hardware abstraction layer (HAL), physical layer, link layer and network layer of a wireless ad-hoc network. In usage, data can be provided to the protocols via systems attaching to the protocol stacks or through an application on the microcontroller running the network stack itself.

At the end of this project, the developed ad-network will be flexible in configuration, providing reliable and modest data transfer rate over 100 metres. This means:

1. The network will be self-configuring, independent of external networking infrastructure

2. The network must scale efficiently from 2 to 50 or more nodes

3. The network must work well in both dense and sparse clusters

4. Packet delay should be as low as possible

5. There must be error-checking on multiple levels at the node

6. Node antennas must have a range of over 100 metres.

7. The network must support unicast and if time permits, multicast operation.

8. Each node should consume as little power as possible

== High Level Overview ==

=== Background ===

'''Ad-hoc Topology'''

An ad-hoc network can be classified into various classifications based on the communication type, topology and node configurations. Depending on the communication type, a network can be classified as single-hop or multi-hop ad-hoc network. In a single-hop network, all nodes are in range of each other and can communicate directly. In a multi-hop network, not all nodes are in reach of each others and need to communicate via a node in between - thus hops.

An ad-hoc network can also be classified by topology. The two major classifications are flat and hierarchical. In a flat ad-hoc nework, all nodes carry the same responsibilities. This means there are no admin nodes and that each nodes performs the same functionality. On the contrary, hierarchical ad-hoc networks consist of clusters of nodes representing individual networks but are all linked together. In a hierarchical network, master nodes exists and area responsible for passing data between clusters.

Lastly, an ad-hoc network can be classified based on its node configuration: homogeneous or heterogeneous. In homogeneous newtorks, all nodes have the same hardware and characteristics (processor, memory, peripheral devices, etc.). Wireless sensor network is a typical example of a homogeneous network. In a heterogeneous network, nodes differ in hardware configurations and thus cannot provide the same services.

This project is focused on implementing a flat, multi-hop and homogeneous network.

'''Addressing schemes'''

The focus of this project is to provide a robust and reliable unicast and broadcast routing ([https://en.wikipedia.org/wiki/Unicast#Addressing_methodologies Addressing methodologies]). If time permits or for future project groups, multicast can be added.

=== Layers ===

When it comes to code organization, we employs the [https://en.wikipedia.org/wiki/OSI_model OSI model]. In this project, the lower three layers are implemented: physical layer, link layer and network layer.

While implementing individual layers may lead to increased memory use due to duplicated buffers on various layers, it was chosen to specifically not to use cross-layer implementation as we wanted to:

* Use abstraction to simplify the development process
* Allow higher layers to be ported to other platforms as technology improves
* Allow lower layers to be used easily without higher layers as to customized to use in smaller microcontrollers, projects that does not require extra complexity of higher layers, etc.

====Hardware Abstraction Layer====

The hardware abstraction layer (HAL) implements functions that set up the MSP430 core hardware such as clocks, GPIO, UART, etc. This layer allows higher layers in the stack to have access to the hardware through a simple and portable abstraction API regardless of the underlying hardware. By default, the HAL initializes the MSP430 modules to the following settings:

* GPIO - All pins defaults to outputs with an output value of 0, with the exception of:
** P1.0: red LED on-board
** P1.1: input button with internal pull-up resistor (active low)
** P1.5, P1.6: UART Tx and Rx
** P5.0, P5.1: low-frequency watch crystal ACLK source

* Clocks
** MCLK: 25 MHz
** SMCLK: 25 MHz
** ACLK: 32768 Hz (external watch crystal frequency)

* UART
** Baud: 115200 (configurable with predefined symbols, ranging from 115200 to 921600)
** Data: 8 bits
** Parity: none
** Stop: 1 bit
** Flow control: none
** Hardware Rx interrupt disabled by default

* Timers
** Timer0_A0 is reserved for Link Layer operation

The HAL layer also includes ''fputs()'' and ''fputc()'' functions that overrides default ''stdio.h'' functions, allowing developers to use ''printf()'' seamlessly through UART in their applications.

====Physical Layer====

The Physical Layer deals with the physical connectivity between nodes. It set up the CC430 RF module's configuration registers, PA table, node address, as well as include some abstraction functions used in transmitting and enabling/disabling various settings of the RF module.

Various RF configurations are included with Olimex's examples that could be used readily with the physical layer implemented, allowing the physical layer's transfer rate to vary between 38.4k baud and 250k baud, as well as being able to transmit with output power settings from -30dBm to +8dBm.

These settings are configurable using predefined symbols.

====Link Layer====

With the wireless medium being tightly controlled, most wireless ad-hoc network applications operates in the ISM band, which is free from licensing. This means that there is limited channel bandwidth, much less than that of a wired network. Additionally, being wireless, there are many factors that can degrade the quality of the signal, such as noise and interference from other sources.

The Link Layer, sometimes referred to as a MAC layer, involves the functions and procedures to transfer data between two or more nodes in-range of the network. Its primary responsibility is to ensure that data is correct before the user application has access to them and discard incorrect data as it receives.

Furthermore, for data transmission utilizing multi-hop, a link layer must also facilitates safe-guards against [https://en.wikipedia.org/wiki/Hidden_node_problem hidden-] and [https://en.wikipedia.org/wiki/Exposed_node_problem exposed-] terminal problems.

Link Layer protocols commonly used in embedded systems belongs to the ''contention-based'' classification. This means that they are aware of the risks of collisions of transmitted data, while ''contention-free'' protocols commonly used in mobile phone networks, are more applicable to static networks with centralized control.

Utilizing a single channel with limited hardware processing power and aimed to be low power, two implementations of the link layer exists in the project: pure CSMA and FAMA-NCS.

* '''CSMA'''

CSMA protocol is classified as a contention-based protocol categorized in the ''random-access'' scheme. In this protocol, a node may transmit as soon as it is ready. It is suitable for low-load systems with a large number of potential senders.

As the CC430 chip used supporting Automatic Clear Channel Assessment on-chip [http://www.ti.com/product/cc430f5137 CC430F5137] (Listen-before-talk), the pure CSMA implementation is basically the physical layer implementation with extra address checking and buffers, ensuring that it conforms with the Link Layer interface.

* '''FAMA-NCS'''

FAMA-NCS stands for ''Floor Acquisition Multiple Access'' with ''Non-persistent carrier sensing'' ([http://link.springer.com/article/10.1023%2FA%3A1019146831447 Specification]), where ''floor'' stands for ''channel''. It is a MACA-based scheme that makes announcements before it sends data to inform other nodes to be silent. Unlike MACA protocols, FAMA protocols require collision avoidance to be performed at both the sender and receiver nodes.

To acquire the floor (channel), the sending node sends out a ''Request-to-Send (RTS)''. The receiver responds with a ''Clear-to-Send (CTS)'' back to the transmitter. Any nodes overhearing this CTS packet knows the station has acquired the floor. CTS packets are repeated long enough for the benefit of any hidden sender did not register another node's RTS.

With CC430 chip including Automatic Clear Channel Assessment that uses carrier sensing, it is arbitrary that the non-persistent carrier sensing should be used.

====Network Layer====

- Description

- Significance

=== Packet Format ===

[[File:Packet_Format.png]]

== Results ==

'''Maximum stable transfer speed'''

* Physical Layer: 215 packets/second
* CSMA-based Link Layer: 169 packets/second
* FAMA-based Link Layer: 22 packets/second

== Development Tools ==

=== Hardware ===

* CC430 development boards from Olimex were used as development targets throughout this project ([http://au.element14.com/olimex/msp430-ccrf/cc430f5137-transceiver-dev-board/dp/2061336 MSP430-CCRF])
* Various MSP430 LaunchPads were utilized as debugger and programmer, including:
** [http://www.ti.com/ww/en/launchpad/launchpads-msp430-msp-exp430g2.html#tabs MSP430G2553 LaunchPad]: hardware not recognized in Mac OS.
** [http://www.ti.com/ww/en/launchpad/launchpads-msp430-msp-exp430fr4133.html#tabs MSP430FR4133 LaunchPad]: added feature of power measurement, compatible with both Windows and Mac OS.
** [http://www.ti.com/ww/en/launchpad/launchpads-msp430-msp-exp430f5529lp.html#tabs MSP430F5529 LaunchPad]: compatible with both Windows and Mac OS.

=== Software ===

==== Code Composer Studio ====

* Version: 6.1.1
* Compiler version: 4.4.4

==== SmartRF Studio ====

* Used in RX/TX dBM measurement and RF configuration register generation
* Provide a quick description of how to use this tool for readers

Projects:2015s1-40 Flexible ad-hoc Network A: Physical Layer

2015-10-24T11:09:13Z

A1627539: /* Project Overview in Songs */

== Introduction ==

=== Overview ===

==== Project Team ====

Cong Nguyen

Duncan Lawry

==== Supervisors ====

Michael Liebelt

Braden Phillips

=== Significance ===

Ad-hoc wireless networks are self-configurable networks with high node mobility, allowing them to function without reliance on any fixed infrastructure. This makes wireless ad-hoc networks useful for quick communication channel deployment suitable for all applications.

While there are already many existing commercial solutions with ad-hoc capability such as [http://www.zigbee.org/ ZigBee], [https://developer.bluetooth.org/TechnologyOverview/Pages/PAN.aspx Bluetooth Personal Area Network (PAN)] and Wi-Fi based ad-hoc configurations ([http://windows.microsoft.com/en-au/windows/set-computer-to-computer-adhoc-network Windows], [https://support.apple.com/kb/PH13796?locale=en_US MacOS], [https://wiki.debian.org/WiFi/AdHoc Linux (Debian)]) these solutions are generally costly in terms of processing power, memory requirement due to reliance on existing protocol stack or costly in terms of royalty. Furthermore, they are commonly reliant on the ISM 2.4GHz band, making them unsuitable for high-range applications without having to invest on a larger antenna which can increase power requirement and a product's physical size.

This project aims to develop an ad-hoc network stack with low processing power and low memory requirement by developing customized protocol layers operating in ISM sub-1GHz frequency for long communication distance and free usage, while provide high reliability and robustness.

=== Objectives and Deliverables ===

This project involves the development of the hardware abstraction layer (HAL), physical layer, link layer and network layer of a wireless ad-hoc network. In usage, data can be provided to the protocols via systems attaching to the protocol stacks or through an application on the microcontroller running the network stack itself.

At the end of this project, the developed ad-network will be flexible in configuration, providing reliable and modest data transfer rate over 100 metres. This means:

1. The network will be self-configuring, independent of external networking infrastructure

2. The network must scale efficiently from 2 to 50 or more nodes

3. The network must work well in both dense and sparse clusters

4. Packet delay should be as low as possible

5. There must be error-checking on multiple levels at the node

6. Node antennas must have a range of over 100 metres.

7. The network must support unicast and if time permits, multicast operation.

8. Each node should consume as little power as possible

=== Project Overview in our Original Songs ===

[https://www.youtube.com/watch?v=97gdJu1JrVI Ad-hoc Networks, Physical Layer, Link Layer Intro] (Make sure to enable subtitles)

[https://youtu.be/gOzrWcktKQ4 Network Layer Intro]

== High Level Overview ==

=== Background ===

'''Ad-hoc Topology'''

An ad-hoc network can be classified into various classifications based on the communication type, topology and node configurations. Depending on the communication type, a network can be classified as single-hop or multi-hop ad-hoc network. In a single-hop network, all nodes are in range of each other and can communicate directly. In a multi-hop network, not all nodes are in reach of each others and need to communicate via a node in between - thus hops.

An ad-hoc network can also be classified by topology. The two major classifications are flat and hierarchical. In a flat ad-hoc nework, all nodes carry the same responsibilities. This means there are no admin nodes and that each nodes performs the same functionality. On the contrary, hierarchical ad-hoc networks consist of clusters of nodes representing individual networks but are all linked together. In a hierarchical network, master nodes exists and area responsible for passing data between clusters.

Lastly, an ad-hoc network can be classified based on its node configuration: homogeneous or heterogeneous. In homogeneous newtorks, all nodes have the same hardware and characteristics (processor, memory, peripheral devices, etc.). Wireless sensor network is a typical example of a homogeneous network. In a heterogeneous network, nodes differ in hardware configurations and thus cannot provide the same services.

This project is focused on implementing a flat, multi-hop and homogeneous network.

'''Addressing schemes'''

The focus of this project is to provide a robust and reliable unicast and broadcast routing ([https://en.wikipedia.org/wiki/Unicast#Addressing_methodologies Addressing methodologies]). If time permits or for future project groups, multicast can be added.

=== Layers ===

When it comes to code organization, we employs the [https://en.wikipedia.org/wiki/OSI_model OSI model]. In this project, the lower three layers are implemented: physical layer, link layer and network layer.

While implementing individual layers may lead to increased memory use due to duplicated buffers on various layers, it was chosen to specifically not to use cross-layer implementation as we wanted to:

* Use abstraction to simplify the development process
* Allow higher layers to be ported to other platforms as technology improves
* Allow lower layers to be used easily without higher layers as to customized to use in smaller microcontrollers, projects that does not require extra complexity of higher layers, etc.

====Hardware Abstraction Layer====

The hardware abstraction layer (HAL) implements functions that set up the MSP430 core hardware such as clocks, GPIO, UART, etc. This layer allows higher layers in the stack to have access to the hardware through a simple and portable abstraction API regardless of the underlying hardware. By default, the HAL initializes the MSP430 modules to the following settings:

* GPIO - All pins defaults to outputs with an output value of 0, with the exception of:
** P1.0: red LED on-board
** P1.1: input button with internal pull-up resistor (active low)
** P1.5, P1.6: UART Tx and Rx
** P5.0, P5.1: low-frequency watch crystal ACLK source

* Clocks
** MCLK: 25 MHz
** SMCLK: 25 MHz
** ACLK: 32768 Hz (external watch crystal frequency)

* UART
** Baud: 115200 (configurable with predefined symbols, ranging from 115200 to 921600)
** Data: 8 bits
** Parity: none
** Stop: 1 bit
** Flow control: none
** Hardware Rx interrupt disabled by default

* Timers
** Timer0_A0 is reserved for Link Layer operation

The HAL layer also includes ''fputs()'' and ''fputc()'' functions that overrides default ''stdio.h'' functions, allowing developers to use ''printf()'' seamlessly through UART in their applications.

====Physical Layer====

The Physical Layer deals with the physical connectivity between nodes. It set up the CC430 RF module's configuration registers, PA table, node address, as well as include some abstraction functions used in transmitting and enabling/disabling various settings of the RF module.

Various RF configurations are included with Olimex's examples that could be used readily with the physical layer implemented, allowing the physical layer's transfer rate to vary between 38.4k baud and 250k baud, as well as being able to transmit with output power settings from -30dBm to +8dBm.

These settings are configurable using predefined symbols.

====Link Layer====

With the wireless medium being tightly controlled, most wireless ad-hoc network applications operates in the ISM band, which is free from licensing. This means that there is limited channel bandwidth, much less than that of a wired network. Additionally, being wireless, there are many factors that can degrade the quality of the signal, such as noise and interference from other sources.

The Link Layer, sometimes referred to as a MAC layer, involves the functions and procedures to transfer data between two or more nodes in-range of the network. Its primary responsibility is to ensure that data is correct before the user application has access to them and discard incorrect data as it receives.

Furthermore, for data transmission utilizing multi-hop, a link layer must also facilitates safe-guards against [https://en.wikipedia.org/wiki/Hidden_node_problem hidden-] and [https://en.wikipedia.org/wiki/Exposed_node_problem exposed-] terminal problems.

Link Layer protocols commonly used in embedded systems belongs to the ''contention-based'' classification. This means that they are aware of the risks of collisions of transmitted data, while ''contention-free'' protocols commonly used in mobile phone networks, are more applicable to static networks with centralized control.

Utilizing a single channel with limited hardware processing power and aimed to be low power, two implementations of the link layer exists in the project: pure CSMA and FAMA-NCS.

* '''CSMA'''

CSMA protocol is classified as a contention-based protocol categorized in the ''random-access'' scheme. In this protocol, a node may transmit as soon as it is ready. It is suitable for low-load systems with a large number of potential senders.

As the CC430 chip used supporting Automatic Clear Channel Assessment on-chip [http://www.ti.com/product/cc430f5137 CC430F5137] (Listen-before-talk), the pure CSMA implementation is basically the physical layer implementation with extra address checking and buffers, ensuring that it conforms with the Link Layer interface.

* '''FAMA-NCS'''

FAMA-NCS stands for ''Floor Acquisition Multiple Access'' with ''Non-persistent carrier sensing'' ([http://link.springer.com/article/10.1023%2FA%3A1019146831447 Specification]), where ''floor'' stands for ''channel''. It is a MACA-based scheme that makes announcements before it sends data to inform other nodes to be silent. Unlike MACA protocols, FAMA protocols require collision avoidance to be performed at both the sender and receiver nodes.

To acquire the floor (channel), the sending node sends out a ''Request-to-Send (RTS)''. The receiver responds with a ''Clear-to-Send (CTS)'' back to the transmitter. Any nodes overhearing this CTS packet knows the station has acquired the floor. CTS packets are repeated long enough for the benefit of any hidden sender did not register another node's RTS.

With CC430 chip including Automatic Clear Channel Assessment that uses carrier sensing, it is arbitrary that the non-persistent carrier sensing should be used.

====Network Layer====

- Description

- Significance

=== Packet Format ===

[[File:Packet_Format.png]]

== Results ==

'''Maximum stable transfer speed'''

* Physical Layer: 215 packets/second
* CSMA-based Link Layer: 169 packets/second
* FAMA-based Link Layer: 22 packets/second

== Development Tools ==

=== Hardware ===

* CC430 development boards from Olimex were used as development targets throughout this project ([http://au.element14.com/olimex/msp430-ccrf/cc430f5137-transceiver-dev-board/dp/2061336 MSP430-CCRF])
* Various MSP430 LaunchPads were utilized as debugger and programmer, including:
** [http://www.ti.com/ww/en/launchpad/launchpads-msp430-msp-exp430g2.html#tabs MSP430G2553 LaunchPad]: hardware not recognized in Mac OS.
** [http://www.ti.com/ww/en/launchpad/launchpads-msp430-msp-exp430fr4133.html#tabs MSP430FR4133 LaunchPad]: added feature of power measurement, compatible with both Windows and Mac OS.
** [http://www.ti.com/ww/en/launchpad/launchpads-msp430-msp-exp430f5529lp.html#tabs MSP430F5529 LaunchPad]: compatible with both Windows and Mac OS.

=== Software ===

==== Code Composer Studio ====

* Version: 6.1.1
* Compiler version: 4.4.4

==== SmartRF Studio ====

* Used in RX/TX dBM measurement and RF configuration register generation
* Provide a quick description of how to use this tool for readers

Projects:2015s1-40 Flexible ad-hoc Network A: Physical Layer

2015-10-24T10:58:14Z

A1627539:

== Introduction ==

=== Overview ===

==== Project Team ====

Cong Nguyen

Duncan Lawry

==== Supervisors ====

Michael Liebelt

Braden Phillips

=== Significance ===

Ad-hoc wireless networks are self-configurable networks with high node mobility, allowing them to function without reliance on any fixed infrastructure. This makes wireless ad-hoc networks useful for quick communication channel deployment suitable for all applications.

While there are already many existing commercial solutions with ad-hoc capability such as [http://www.zigbee.org/ ZigBee], [https://developer.bluetooth.org/TechnologyOverview/Pages/PAN.aspx Bluetooth Personal Area Network (PAN)] and Wi-Fi based ad-hoc configurations ([http://windows.microsoft.com/en-au/windows/set-computer-to-computer-adhoc-network Windows], [https://support.apple.com/kb/PH13796?locale=en_US MacOS], [https://wiki.debian.org/WiFi/AdHoc Linux (Debian)]) these solutions are generally costly in terms of processing power, memory requirement due to reliance on existing protocol stack or costly in terms of royalty. Furthermore, they are commonly reliant on the ISM 2.4GHz band, making them unsuitable for high-range applications without having to invest on a larger antenna which can increase power requirement and a product's physical size.

This project aims to develop an ad-hoc network stack with low processing power and low memory requirement by developing customized protocol layers operating in ISM sub-1GHz frequency for long communication distance and free usage, while provide high reliability and robustness.

=== Objectives and Deliverables ===

This project involves the development of the hardware abstraction layer (HAL), physical layer, link layer and network layer of a wireless ad-hoc network. In usage, data can be provided to the protocols via systems attaching to the protocol stacks or through an application on the microcontroller running the network stack itself.

At the end of this project, the developed ad-network will be flexible in configuration, providing reliable and modest data transfer rate over 100 metres. This means:

1. The network will be self-configuring, independent of external networking infrastructure

2. The network must scale efficiently from 2 to 50 or more nodes

3. The network must work well in both dense and sparse clusters

4. Packet delay should be as low as possible

5. There must be error-checking on multiple levels at the node

6. Node antennas must have a range of over 100 metres.

7. The network must support unicast and if time permits, multicast operation.

8. Each node should consume as little power as possible

=== Project Overview in Songs ===

[https://www.youtube.com/watch?v=97gdJu1JrVI Ad-hoc Networks, Physical Layer, Link Layer Intro] (Make sure to enable subtitles)

[https://youtu.be/gOzrWcktKQ4 Network Layer Intro]

== High Level Overview ==

=== Background ===

'''Ad-hoc Topology'''

An ad-hoc network can be classified into various classifications based on the communication type, topology and node configurations. Depending on the communication type, a network can be classified as single-hop or multi-hop ad-hoc network. In a single-hop network, all nodes are in range of each other and can communicate directly. In a multi-hop network, not all nodes are in reach of each others and need to communicate via a node in between - thus hops.

An ad-hoc network can also be classified by topology. The two major classifications are flat and hierarchical. In a flat ad-hoc nework, all nodes carry the same responsibilities. This means there are no admin nodes and that each nodes performs the same functionality. On the contrary, hierarchical ad-hoc networks consist of clusters of nodes representing individual networks but are all linked together. In a hierarchical network, master nodes exists and area responsible for passing data between clusters.

Lastly, an ad-hoc network can be classified based on its node configuration: homogeneous or heterogeneous. In homogeneous newtorks, all nodes have the same hardware and characteristics (processor, memory, peripheral devices, etc.). Wireless sensor network is a typical example of a homogeneous network. In a heterogeneous network, nodes differ in hardware configurations and thus cannot provide the same services.

This project is focused on implementing a flat, multi-hop and homogeneous network.

'''Addressing schemes'''

The focus of this project is to provide a robust and reliable unicast and broadcast routing ([https://en.wikipedia.org/wiki/Unicast#Addressing_methodologies Addressing methodologies]). If time permits or for future project groups, multicast can be added.

=== Layers ===

When it comes to code organization, we employs the [https://en.wikipedia.org/wiki/OSI_model OSI model]. In this project, the lower three layers are implemented: physical layer, link layer and network layer.

While implementing individual layers may lead to increased memory use due to duplicated buffers on various layers, it was chosen to specifically not to use cross-layer implementation as we wanted to:

* Use abstraction to simplify the development process
* Allow higher layers to be ported to other platforms as technology improves
* Allow lower layers to be used easily without higher layers as to customized to use in smaller microcontrollers, projects that does not require extra complexity of higher layers, etc.

====Hardware Abstraction Layer====

The hardware abstraction layer (HAL) implements functions that set up the MSP430 core hardware such as clocks, GPIO, UART, etc. This layer allows higher layers in the stack to have access to the hardware through a simple and portable abstraction API regardless of the underlying hardware. By default, the HAL initializes the MSP430 modules to the following settings:

* GPIO - All pins defaults to outputs with an output value of 0, with the exception of:
** P1.0: red LED on-board
** P1.1: input button with internal pull-up resistor (active low)
** P1.5, P1.6: UART Tx and Rx
** P5.0, P5.1: low-frequency watch crystal ACLK source

* Clocks
** MCLK: 25 MHz
** SMCLK: 25 MHz
** ACLK: 32768 Hz (external watch crystal frequency)

* UART
** Baud: 115200 (configurable with predefined symbols, ranging from 115200 to 921600)
** Data: 8 bits
** Parity: none
** Stop: 1 bit
** Flow control: none
** Hardware Rx interrupt disabled by default

* Timers
** Timer0_A0 is reserved for Link Layer operation

The HAL layer also includes ''fputs()'' and ''fputc()'' functions that overrides default ''stdio.h'' functions, allowing developers to use ''printf()'' seamlessly through UART in their applications.

====Physical Layer====

The Physical Layer deals with the physical connectivity between nodes. It set up the CC430 RF module's configuration registers, PA table, node address, as well as include some abstraction functions used in transmitting and enabling/disabling various settings of the RF module.

Various RF configurations are included with Olimex's examples that could be used readily with the physical layer implemented, allowing the physical layer's transfer rate to vary between 38.4k baud and 250k baud, as well as being able to transmit with output power settings from -30dBm to +8dBm.

These settings are configurable using predefined symbols.

====Link Layer====

With the wireless medium being tightly controlled, most wireless ad-hoc network applications operates in the ISM band, which is free from licensing. This means that there is limited channel bandwidth, much less than that of a wired network. Additionally, being wireless, there are many factors that can degrade the quality of the signal, such as noise and interference from other sources.

The Link Layer, sometimes referred to as a MAC layer, involves the functions and procedures to transfer data between two or more nodes in-range of the network. Its primary responsibility is to ensure that data is correct before the user application has access to them and discard incorrect data as it receives.

Furthermore, for data transmission utilizing multi-hop, a link layer must also facilitates safe-guards against [https://en.wikipedia.org/wiki/Hidden_node_problem hidden-] and [https://en.wikipedia.org/wiki/Exposed_node_problem exposed-] terminal problems.

Link Layer protocols commonly used in embedded systems belongs to the ''contention-based'' classification. This means that they are aware of the risks of collisions of transmitted data, while ''contention-free'' protocols commonly used in mobile phone networks, are more applicable to static networks with centralized control.

Utilizing a single channel with limited hardware processing power and aimed to be low power, two implementations of the link layer exists in the project: pure CSMA and FAMA-NCS.

* '''CSMA'''

CSMA protocol is classified as a contention-based protocol categorized in the ''random-access'' scheme. In this protocol, a node may transmit as soon as it is ready. It is suitable for low-load systems with a large number of potential senders.

As the CC430 chip used supporting Automatic Clear Channel Assessment on-chip [http://www.ti.com/product/cc430f5137 CC430F5137] (Listen-before-talk), the pure CSMA implementation is basically the physical layer implementation with extra address checking and buffers, ensuring that it conforms with the Link Layer interface.

* '''FAMA-NCS'''

FAMA-NCS stands for ''Floor Acquisition Multiple Access'' with ''Non-persistent carrier sensing'' ([http://link.springer.com/article/10.1023%2FA%3A1019146831447 Specification]), where ''floor'' stands for ''channel''. It is a MACA-based scheme that makes announcements before it sends data to inform other nodes to be silent. Unlike MACA protocols, FAMA protocols require collision avoidance to be performed at both the sender and receiver nodes.

To acquire the floor (channel), the sending node sends out a ''Request-to-Send (RTS)''. The receiver responds with a ''Clear-to-Send (CTS)'' back to the transmitter. Any nodes overhearing this CTS packet knows the station has acquired the floor. CTS packets are repeated long enough for the benefit of any hidden sender did not register another node's RTS.

With CC430 chip including Automatic Clear Channel Assessment that uses carrier sensing, it is arbitrary that the non-persistent carrier sensing should be used.

====Network Layer====

- Description

- Significance

=== Packet Format ===

[[File:Packet_Format.png]]

== Results ==

'''Maximum stable transfer speed'''

* Physical Layer: 215 packets/second
* CSMA-based Link Layer: 169 packets/second
* FAMA-based Link Layer: 22 packets/second

== Development Tools ==

=== Hardware ===

* CC430 development boards from Olimex were used as development targets throughout this project ([http://au.element14.com/olimex/msp430-ccrf/cc430f5137-transceiver-dev-board/dp/2061336 MSP430-CCRF])
* Various MSP430 LaunchPads were utilized as debugger and programmer, including:
** [http://www.ti.com/ww/en/launchpad/launchpads-msp430-msp-exp430g2.html#tabs MSP430G2553 LaunchPad]: hardware not recognized in Mac OS.
** [http://www.ti.com/ww/en/launchpad/launchpads-msp430-msp-exp430fr4133.html#tabs MSP430FR4133 LaunchPad]: added feature of power measurement, compatible with both Windows and Mac OS.
** [http://www.ti.com/ww/en/launchpad/launchpads-msp430-msp-exp430f5529lp.html#tabs MSP430F5529 LaunchPad]: compatible with both Windows and Mac OS.

=== Software ===

==== Code Composer Studio ====

* Version: 6.1.1
* Compiler version: 4.4.4

==== SmartRF Studio ====

* Used in RX/TX dBM measurement and RF configuration register generation
* Provide a quick description of how to use this tool for readers

Projects:2015s1-40 Flexible ad-hoc Network A: Physical Layer

2015-10-21T12:40:34Z

A1627539: /* SmartRF Studio */

Projects:2015s1-40 Flexible ad-hoc Network A: Physical Layer

2015-10-21T12:40:17Z

A1627539:

== Introduction ==

=== Overview ===

==== Project Team ====

Cong Nguyen

Duncan Lawry

==== Supervisors ====

Michael Liebelt

Braden Phillips

=== Significance ===

Ad-hoc wireless networks are self-configurable networks with high node mobility, allowing them to function without reliance on any fixed infrastructure. This makes wireless ad-hoc networks useful for quick communication channel deployment suitable for all applications.

While there are already many existing commercial solutions with ad-hoc capability such as [http://www.zigbee.org/ ZigBee], [https://developer.bluetooth.org/TechnologyOverview/Pages/PAN.aspx Bluetooth Personal Area Network (PAN)] and Wi-Fi based ad-hoc configurations ([http://windows.microsoft.com/en-au/windows/set-computer-to-computer-adhoc-network Windows], [https://support.apple.com/kb/PH13796?locale=en_US MacOS], [https://wiki.debian.org/WiFi/AdHoc Linux (Debian)]) these solutions are generally costly in terms of processing power, memory requirement due to reliance on existing protocol stack or costly in terms of royalty. Furthermore, they are commonly reliant on the ISM 2.4GHz band, making them unsuitable for high-range applications without having to invest on a larger antenna which can increase power requirement and a product's physical size.

This project aims to develop an ad-hoc network stack with low processing power and low memory requirement by developing customized protocol layers operating in ISM sub-1GHz frequency for long communication distance and free usage, while provide high reliability and robustness.

=== Objectives and Deliverables ===

This project involves the development of the hardware abstraction layer (HAL), physical layer, link layer and network layer of a wireless ad-hoc network. In usage, data can be provided to the protocols via systems attaching to the protocol stacks or through an application on the microcontroller running the network stack itself.

At the end of this project, the developed ad-network will be flexible in configuration, providing reliable and modest data transfer rate over 100 metres. This means:

1. The network will be self-configuring, independent of external networking infrastructure

2. The network must scale efficiently from 2 to 50 or more nodes

3. The network must work well in both dense and sparse clusters

4. Packet delay should be as low as possible

5. There must be error-checking on multiple levels at the node

6. Node antennas must have a range of over 100 metres.

7. The network must support unicast and if time permits, multicast operation.

8. Each node should consume as little power as possible

== High Level Overview ==

=== Background ===

'''Ad-hoc Topology'''

An ad-hoc network can be classified into various classifications based on the communication type, topology and node configurations. Depending on the communication type, a network can be classified as single-hop or multi-hop ad-hoc network. In a single-hop network, all nodes are in range of each other and can communicate directly. In a multi-hop network, not all nodes are in reach of each others and need to communicate via a node in between - thus hops.

An ad-hoc network can also be classified by topology. The two major classifications are flat and hierarchical. In a flat ad-hoc nework, all nodes carry the same responsibilities. This means there are no admin nodes and that each nodes performs the same functionality. On the contrary, hierarchical ad-hoc networks consist of clusters of nodes representing individual networks but are all linked together. In a hierarchical network, master nodes exists and area responsible for passing data between clusters.

Lastly, an ad-hoc network can be classified based on its node configuration: homogeneous or heterogeneous. In homogeneous newtorks, all nodes have the same hardware and characteristics (processor, memory, peripheral devices, etc.). Wireless sensor network is a typical example of a homogeneous network. In a heterogeneous network, nodes differ in hardware configurations and thus cannot provide the same services.

This project is focused on implementing a flat, multi-hop and homogeneous network.

'''Addressing schemes'''

The focus of this project is to provide a robust and reliable unicast and broadcast routing ([https://en.wikipedia.org/wiki/Unicast#Addressing_methodologies Addressing methodologies]). If time permits or for future project groups, multicast can be added.

=== Layers ===

When it comes to code organization, we employs the [https://en.wikipedia.org/wiki/OSI_model OSI model]. In this project, the lower three layers are implemented: physical layer, link layer and network layer.

While implementing individual layers may lead to increased memory use due to duplicated buffers on various layers, it was chosen to specifically not to use cross-layer implementation as we wanted to:

* Use abstraction to simplify the development process
* Allow higher layers to be ported to other platforms as technology improves
* Allow lower layers to be used easily without higher layers as to customized to use in smaller microcontrollers, projects that does not require extra complexity of higher layers, etc.

====Hardware Abstraction Layer====

The hardware abstraction layer (HAL) implements functions that set up the MSP430 core hardware such as clocks, GPIO, UART, etc. This layer allows higher layers in the stack to have access to the hardware through a simple and portable abstraction API regardless of the underlying hardware. By default, the HAL initializes the MSP430 modules to the following settings:

* GPIO - All pins defaults to outputs with an output value of 0, with the exception of:
** P1.0: red LED on-board
** P1.1: input button with internal pull-up resistor (active low)
** P1.5, P1.6: UART Tx and Rx
** P5.0, P5.1: low-frequency watch crystal ACLK source

* Clocks
** MCLK: 25 MHz
** SMCLK: 25 MHz
** ACLK: 32768 Hz (external watch crystal frequency)

* UART
** Baud: 115200 (configurable with predefined symbols, ranging from 115200 to 921600)
** Data: 8 bits
** Parity: none
** Stop: 1 bit
** Flow control: none
** Hardware Rx interrupt disabled by default

* Timers
** Timer0_A0 is reserved for Link Layer operation

The HAL layer also includes ''fputs()'' and ''fputc()'' functions that overrides default ''stdio.h'' functions, allowing developers to use ''printf()'' seamlessly through UART in their applications.

====Physical Layer====

The Physical Layer deals with the physical connectivity between nodes. It set up the CC430 RF module's configuration registers, PA table, node address, as well as include some abstraction functions used in transmitting and enabling/disabling various settings of the RF module.

Various RF configurations are included with Olimex's examples that could be used readily with the physical layer implemented, allowing the physical layer's transfer rate to vary between 38.4k baud and 250k baud, as well as being able to transmit with output power settings from -30dBm to +8dBm.

These settings are configurable using predefined symbols.

====Link Layer====

With the wireless medium being tightly controlled, most wireless ad-hoc network applications operates in the ISM band, which is free from licensing. This means that there is limited channel bandwidth, much less than that of a wired network. Additionally, being wireless, there are many factors that can degrade the quality of the signal, such as noise and interference from other sources.

The Link Layer, sometimes referred to as a MAC layer, involves the functions and procedures to transfer data between two or more nodes in-range of the network. Its primary responsibility is to ensure that data is correct before the user application has access to them and discard incorrect data as it receives.

Furthermore, for data transmission utilizing multi-hop, a link layer must also facilitates safe-guards against [https://en.wikipedia.org/wiki/Hidden_node_problem hidden-] and [https://en.wikipedia.org/wiki/Exposed_node_problem exposed-] terminal problems.

Link Layer protocols commonly used in embedded systems belongs to the ''contention-based'' classification. This means that they are aware of the risks of collisions of transmitted data, while ''contention-free'' protocols commonly used in mobile phone networks, are more applicable to static networks with centralized control.

Utilizing a single channel with limited hardware processing power and aimed to be low power, two implementations of the link layer exists in the project: pure CSMA and FAMA-NCS.

* '''CSMA'''

CSMA protocol is classified as a contention-based protocol categorized in the ''random-access'' scheme. In this protocol, a node may transmit as soon as it is ready. It is suitable for low-load systems with a large number of potential senders.

As the CC430 chip used supporting Automatic Clear Channel Assessment on-chip [http://www.ti.com/product/cc430f5137 CC430F5137] (Listen-before-talk), the pure CSMA implementation is basically the physical layer implementation with extra address checking and buffers, ensuring that it conforms with the Link Layer interface.

* '''FAMA-NCS'''

FAMA-NCS stands for ''Floor Acquisition Multiple Access'' with ''Non-persistent carrier sensing'' ([http://link.springer.com/article/10.1023%2FA%3A1019146831447 Specification]), where ''floor'' stands for ''channel''. It is a MACA-based scheme that makes announcements before it sends data to inform other nodes to be silent. Unlike MACA protocols, FAMA protocols require collision avoidance to be performed at both the sender and receiver nodes.

To acquire the floor (channel), the sending node sends out a ''Request-to-Send (RTS)''. The receiver responds with a ''Clear-to-Send (CTS)'' back to the transmitter. Any nodes overhearing this CTS packet knows the station has acquired the floor. CTS packets are repeated long enough for the benefit of any hidden sender did not register another node's RTS.

With CC430 chip including Automatic Clear Channel Assessment that uses carrier sensing, it is arbitrary that the non-persistent carrier sensing should be used.

====Network Layer====

- Description

- Significance

=== Packet Format ===

[[File:Packet_Format.png]]

== Results ==

'''Maximum stable transfer speed'''

* Physical Layer: 215 packets/second
* CSMA-based Link Layer: 169 packets/second
* FAMA-based Link Layer: 22 packets/second

== Development Tools ==

=== Hardware ===

* CC430 development boards from Olimex were used as development targets throughout this project ([http://au.element14.com/olimex/msp430-ccrf/cc430f5137-transceiver-dev-board/dp/2061336 MSP430-CCRF])
* Various MSP430 LaunchPads were utilized as debugger and programmer, including:
** [http://www.ti.com/ww/en/launchpad/launchpads-msp430-msp-exp430g2.html#tabs MSP430G2553 LaunchPad]: hardware not recognized in Mac OS.
** [http://www.ti.com/ww/en/launchpad/launchpads-msp430-msp-exp430fr4133.html#tabs MSP430FR4133 LaunchPad]: added feature of power measurement, compatible with both Windows and Mac OS.
** [http://www.ti.com/ww/en/launchpad/launchpads-msp430-msp-exp430f5529lp.html#tabs MSP430F5529 LaunchPad]: compatible with both Windows and Mac OS.

=== Software ===

==== Code Composer Studio ====

* Version: 6.1.1
* Compiler version: 4.4.4

==== SmartRF Studio ====

- Used in RX/TX dBM measurement and RF configuration register generation

- Provide a quick description of how to use this tool for readers

Projects:2015s1-40 Flexible ad-hoc Network A: Physical Layer

2015-10-21T12:39:28Z

A1627539: /* Code Composer Studio */

== Introduction ==

=== Overview ===

==== Project Team ====

Cong Nguyen

Duncan Lawry

==== Supervisors ====

Michael Liebelt

Braden Phillips

=== Significance ===

Ad-hoc wireless networks are self-configurable networks with high node mobility, allowing them to function without reliance on any fixed infrastructure. This makes wireless ad-hoc networks useful for quick communication channel deployment suitable for all applications.

While there are already many existing commercial solutions with ad-hoc capability such as [http://www.zigbee.org/ ZigBee], [https://developer.bluetooth.org/TechnologyOverview/Pages/PAN.aspx Bluetooth Personal Area Network (PAN)] and Wi-Fi based ad-hoc configurations ([http://windows.microsoft.com/en-au/windows/set-computer-to-computer-adhoc-network Windows], [https://support.apple.com/kb/PH13796?locale=en_US MacOS], [https://wiki.debian.org/WiFi/AdHoc Linux (Debian)]) these solutions are generally costly in terms of processing power, memory requirement due to reliance on existing protocol stack or costly in terms of royalty. Furthermore, they are commonly reliant on the ISM 2.4GHz band, making them unsuitable for high-range applications without having to invest on a larger antenna which can increase power requirement and a product's physical size.

This project aims to develop an ad-hoc network stack with low processing power and low memory requirement by developing customized protocol layers operating in ISM sub-1GHz frequency for long communication distance and free usage, while provide high reliability and robustness.

=== Objectives and Deliverables ===

This project involves the development of the hardware abstraction layer (HAL), physical layer, link layer and network layer of a wireless ad-hoc network. In usage, data can be provided to the protocols via systems attaching to the protocol stacks or through an application on the microcontroller running the network stack itself.

At the end of this project, the developed ad-network will be flexible in configuration, providing reliable and modest data transfer rate over 100 metres. This means:

1. The network will be self-configuring, independent of external networking infrastructure

2. The network must scale efficiently from 2 to 50 or more nodes

3. The network must work well in both dense and sparse clusters

4. Packet delay should be as low as possible

5. There must be error-checking on multiple levels at the node

6. Node antennas must have a range of over 100 metres.

7. The network must support unicast and if time permits, multicast operation.

8. Each node should consume as little power as possible

== High Level Overview ==

=== Background ===

'''Ad-hoc Topology'''

An ad-hoc network can be classified into various classifications based on the communication type, topology and node configurations. Depending on the communication type, a network can be classified as single-hop or multi-hop ad-hoc network. In a single-hop network, all nodes are in range of each other and can communicate directly. In a multi-hop network, not all nodes are in reach of each others and need to communicate via a node in between - thus hops.

An ad-hoc network can also be classified by topology. The two major classifications are flat and hierarchical. In a flat ad-hoc nework, all nodes carry the same responsibilities. This means there are no admin nodes and that each nodes performs the same functionality. On the contrary, hierarchical ad-hoc networks consist of clusters of nodes representing individual networks but are all linked together. In a hierarchical network, master nodes exists and area responsible for passing data between clusters.

Lastly, an ad-hoc network can be classified based on its node configuration: homogeneous or heterogeneous. In homogeneous newtorks, all nodes have the same hardware and characteristics (processor, memory, peripheral devices, etc.). Wireless sensor network is a typical example of a homogeneous network. In a heterogeneous network, nodes differ in hardware configurations and thus cannot provide the same services.

This project is focused on implementing a flat, multi-hop and homogeneous network.

'''Addressing schemes'''

The focus of this project is to provide a robust and reliable unicast and broadcast routing ([https://en.wikipedia.org/wiki/Unicast#Addressing_methodologies Addressing methodologies]). If time permits or for future project groups, multicast can be added.

=== Layers ===

When it comes to code organization, we employs the [https://en.wikipedia.org/wiki/OSI_model OSI model]. In this project, the lower three layers are implemented: physical layer, link layer and network layer.

While implementing individual layers may lead to increased memory use due to duplicated buffers on various layers, it was chosen to specifically not to use cross-layer implementation as we wanted to:

* Use abstraction to simplify the development process
* Allow higher layers to be ported to other platforms as technology improves
* Allow lower layers to be used easily without higher layers as to customized to use in smaller microcontrollers, projects that does not require extra complexity of higher layers, etc.

====Hardware Abstraction Layer====

The hardware abstraction layer (HAL) implements functions that set up the MSP430 core hardware such as clocks, GPIO, UART, etc. This layer allows higher layers in the stack to have access to the hardware through a simple and portable abstraction API regardless of the underlying hardware. By default, the HAL initializes the MSP430 modules to the following settings:

* GPIO - All pins defaults to outputs with an output value of 0, with the exception of:
** P1.0: red LED on-board
** P1.1: input button with internal pull-up resistor (active low)
** P1.5, P1.6: UART Tx and Rx
** P5.0, P5.1: low-frequency watch crystal ACLK source

* Clocks
** MCLK: 25 MHz
** SMCLK: 25 MHz
** ACLK: 32768 Hz (external watch crystal frequency)

* UART
** Baud: 115200 (configurable with predefined symbols, ranging from 115200 to 921600)
** Data: 8 bits
** Parity: none
** Stop: 1 bit
** Flow control: none
** Hardware Rx interrupt disabled by default

* Timers
** Timer0_A0 is reserved for Link Layer operation

The HAL layer also includes ''fputs()'' and ''fputc()'' functions that overrides default ''stdio.h'' functions, allowing developers to use ''printf()'' seamlessly through UART in their applications.

====Physical Layer====

The Physical Layer deals with the physical connectivity between nodes. It set up the CC430 RF module's configuration registers, PA table, node address, as well as include some abstraction functions used in transmitting and enabling/disabling various settings of the RF module.

Various RF configurations are included with Olimex's examples that could be used readily with the physical layer implemented, allowing the physical layer's transfer rate to vary between 38.4k baud and 250k baud, as well as being able to transmit with output power settings from -30dBm to +8dBm.

These settings are configurable using predefined symbols.

====Link Layer====

With the wireless medium being tightly controlled, most wireless ad-hoc network applications operates in the ISM band, which is free from licensing. This means that there is limited channel bandwidth, much less than that of a wired network. Additionally, being wireless, there are many factors that can degrade the quality of the signal, such as noise and interference from other sources.

The Link Layer, sometimes referred to as a MAC layer, involves the functions and procedures to transfer data between two or more nodes in-range of the network. Its primary responsibility is to ensure that data is correct before the user application has access to them and discard incorrect data as it receives.

Furthermore, for data transmission utilizing multi-hop, a link layer must also facilitates safe-guards against [https://en.wikipedia.org/wiki/Hidden_node_problem hidden-] and [https://en.wikipedia.org/wiki/Exposed_node_problem exposed-] terminal problems.

Link Layer protocols commonly used in embedded systems belongs to the ''contention-based'' classification. This means that they are aware of the risks of collisions of transmitted data, while ''contention-free'' protocols commonly used in mobile phone networks, are more applicable to static networks with centralized control.

Utilizing a single channel with limited hardware processing power and aimed to be low power, two implementations of the link layer exists in the project: pure CSMA and FAMA-NCS.

* '''CSMA'''

CSMA protocol is classified as a contention-based protocol categorized in the ''random-access'' scheme. In this protocol, a node may transmit as soon as it is ready. It is suitable for low-load systems with a large number of potential senders.

As the CC430 chip used supporting Automatic Clear Channel Assessment on-chip [http://www.ti.com/product/cc430f5137 CC430F5137] (Listen-before-talk), the pure CSMA implementation is basically the physical layer implementation with extra address checking and buffers, ensuring that it conforms with the Link Layer interface.

* '''FAMA-NCS'''

FAMA-NCS stands for ''Floor Acquisition Multiple Access'' with ''Non-persistent carrier sensing'' ([http://link.springer.com/article/10.1023%2FA%3A1019146831447 Specification]), where ''floor'' stands for ''channel''. It is a MACA-based scheme that makes announcements before it sends data to inform other nodes to be silent. Unlike MACA protocols, FAMA protocols require collision avoidance to be performed at both the sender and receiver nodes.

To acquire the floor (channel), the sending node sends out a ''Request-to-Send (RTS)''. The receiver responds with a ''Clear-to-Send (CTS)'' back to the transmitter. Any nodes overhearing this CTS packet knows the station has acquired the floor. CTS packets are repeated long enough for the benefit of any hidden sender did not register another node's RTS.

With CC430 chip including Automatic Clear Channel Assessment that uses carrier sensing, it is arbitrary that the non-persistent carrier sensing should be used.

====Network Layer====

- Description

- Significance

=== Packet Format ===

[[File:Packet_Format.png]]

== Results ==

'''Maximum stable transfer speed'''

* Physical Layer: 215 packets/second
* CSMA-based Link Layer: 169 packets/second
* FAMA-based Link Layer: 22 packets/second

== Development Tools ==

=== Hardware ===

* CC430 development boards from Olimex were used as development targets throughout this project ([http://au.element14.com/olimex/msp430-ccrf/cc430f5137-transceiver-dev-board/dp/2061336 MSP430-CCRF])
* Various MSP430 LaunchPads were utilized as debugger and programmer, including:
** [http://www.ti.com/ww/en/launchpad/launchpads-msp430-msp-exp430g2.html#tabs MSP430G2553 LaunchPad]: hardware not recognized in Mac OS.
** [http://www.ti.com/ww/en/launchpad/launchpads-msp430-msp-exp430fr4133.html#tabs MSP430FR4133 LaunchPad]: added feature of power measurement, compatible with both Windows and Mac OS.
** [http://www.ti.com/ww/en/launchpad/launchpads-msp430-msp-exp430f5529lp.html#tabs MSP430F5529 LaunchPad]: compatible with both Windows and Mac OS.

=== Software ===

==== Code Composer Studio ====

* Version: 6.1.1
* Compiler version: 4.4.4

==== SmartRF Studio ====

- Used in RX/TX dBM measurement and RF configuration register generation

- Provide a quick description of how to use this tool for readers

=== Related documentation ===

== Application Development Guide ==

=== Typical Program Flow ===

=== Code Explanation ===

'''Code walk-through for various layers'''

=== Predefined Definitions ===

''' What they are for, why they exist, when to use them'''

=== Usage Scenarios ===

=== Migration Advice ===

- How to port code from this project to other MCU architectures

== Reflection and Improvement ==

== Reference ==

Projects:2015s1-40 Flexible ad-hoc Network A: Physical Layer

2015-10-21T12:38:33Z

A1627539: /* Field Results */

== Introduction ==

=== Overview ===

==== Project Team ====

Cong Nguyen

Duncan Lawry

==== Supervisors ====

Michael Liebelt

Braden Phillips

=== Significance ===

Ad-hoc wireless networks are self-configurable networks with high node mobility, allowing them to function without reliance on any fixed infrastructure. This makes wireless ad-hoc networks useful for quick communication channel deployment suitable for all applications.

While there are already many existing commercial solutions with ad-hoc capability such as [http://www.zigbee.org/ ZigBee], [https://developer.bluetooth.org/TechnologyOverview/Pages/PAN.aspx Bluetooth Personal Area Network (PAN)] and Wi-Fi based ad-hoc configurations ([http://windows.microsoft.com/en-au/windows/set-computer-to-computer-adhoc-network Windows], [https://support.apple.com/kb/PH13796?locale=en_US MacOS], [https://wiki.debian.org/WiFi/AdHoc Linux (Debian)]) these solutions are generally costly in terms of processing power, memory requirement due to reliance on existing protocol stack or costly in terms of royalty. Furthermore, they are commonly reliant on the ISM 2.4GHz band, making them unsuitable for high-range applications without having to invest on a larger antenna which can increase power requirement and a product's physical size.

This project aims to develop an ad-hoc network stack with low processing power and low memory requirement by developing customized protocol layers operating in ISM sub-1GHz frequency for long communication distance and free usage, while provide high reliability and robustness.

=== Objectives and Deliverables ===

This project involves the development of the hardware abstraction layer (HAL), physical layer, link layer and network layer of a wireless ad-hoc network. In usage, data can be provided to the protocols via systems attaching to the protocol stacks or through an application on the microcontroller running the network stack itself.

At the end of this project, the developed ad-network will be flexible in configuration, providing reliable and modest data transfer rate over 100 metres. This means:

1. The network will be self-configuring, independent of external networking infrastructure

2. The network must scale efficiently from 2 to 50 or more nodes

3. The network must work well in both dense and sparse clusters

4. Packet delay should be as low as possible

5. There must be error-checking on multiple levels at the node

6. Node antennas must have a range of over 100 metres.

7. The network must support unicast and if time permits, multicast operation.

8. Each node should consume as little power as possible

== High Level Overview ==

=== Background ===

'''Ad-hoc Topology'''

An ad-hoc network can be classified into various classifications based on the communication type, topology and node configurations. Depending on the communication type, a network can be classified as single-hop or multi-hop ad-hoc network. In a single-hop network, all nodes are in range of each other and can communicate directly. In a multi-hop network, not all nodes are in reach of each others and need to communicate via a node in between - thus hops.

An ad-hoc network can also be classified by topology. The two major classifications are flat and hierarchical. In a flat ad-hoc nework, all nodes carry the same responsibilities. This means there are no admin nodes and that each nodes performs the same functionality. On the contrary, hierarchical ad-hoc networks consist of clusters of nodes representing individual networks but are all linked together. In a hierarchical network, master nodes exists and area responsible for passing data between clusters.

Lastly, an ad-hoc network can be classified based on its node configuration: homogeneous or heterogeneous. In homogeneous newtorks, all nodes have the same hardware and characteristics (processor, memory, peripheral devices, etc.). Wireless sensor network is a typical example of a homogeneous network. In a heterogeneous network, nodes differ in hardware configurations and thus cannot provide the same services.

This project is focused on implementing a flat, multi-hop and homogeneous network.

'''Addressing schemes'''

The focus of this project is to provide a robust and reliable unicast and broadcast routing ([https://en.wikipedia.org/wiki/Unicast#Addressing_methodologies Addressing methodologies]). If time permits or for future project groups, multicast can be added.

=== Layers ===

When it comes to code organization, we employs the [https://en.wikipedia.org/wiki/OSI_model OSI model]. In this project, the lower three layers are implemented: physical layer, link layer and network layer.

While implementing individual layers may lead to increased memory use due to duplicated buffers on various layers, it was chosen to specifically not to use cross-layer implementation as we wanted to:

* Use abstraction to simplify the development process
* Allow higher layers to be ported to other platforms as technology improves
* Allow lower layers to be used easily without higher layers as to customized to use in smaller microcontrollers, projects that does not require extra complexity of higher layers, etc.

====Hardware Abstraction Layer====

The hardware abstraction layer (HAL) implements functions that set up the MSP430 core hardware such as clocks, GPIO, UART, etc. This layer allows higher layers in the stack to have access to the hardware through a simple and portable abstraction API regardless of the underlying hardware. By default, the HAL initializes the MSP430 modules to the following settings:

* GPIO - All pins defaults to outputs with an output value of 0, with the exception of:
** P1.0: red LED on-board
** P1.1: input button with internal pull-up resistor (active low)
** P1.5, P1.6: UART Tx and Rx
** P5.0, P5.1: low-frequency watch crystal ACLK source

* Clocks
** MCLK: 25 MHz
** SMCLK: 25 MHz
** ACLK: 32768 Hz (external watch crystal frequency)

* UART
** Baud: 115200 (configurable with predefined symbols, ranging from 115200 to 921600)
** Data: 8 bits
** Parity: none
** Stop: 1 bit
** Flow control: none
** Hardware Rx interrupt disabled by default

* Timers
** Timer0_A0 is reserved for Link Layer operation

The HAL layer also includes ''fputs()'' and ''fputc()'' functions that overrides default ''stdio.h'' functions, allowing developers to use ''printf()'' seamlessly through UART in their applications.

====Physical Layer====

The Physical Layer deals with the physical connectivity between nodes. It set up the CC430 RF module's configuration registers, PA table, node address, as well as include some abstraction functions used in transmitting and enabling/disabling various settings of the RF module.

Various RF configurations are included with Olimex's examples that could be used readily with the physical layer implemented, allowing the physical layer's transfer rate to vary between 38.4k baud and 250k baud, as well as being able to transmit with output power settings from -30dBm to +8dBm.

These settings are configurable using predefined symbols.

====Link Layer====

With the wireless medium being tightly controlled, most wireless ad-hoc network applications operates in the ISM band, which is free from licensing. This means that there is limited channel bandwidth, much less than that of a wired network. Additionally, being wireless, there are many factors that can degrade the quality of the signal, such as noise and interference from other sources.

The Link Layer, sometimes referred to as a MAC layer, involves the functions and procedures to transfer data between two or more nodes in-range of the network. Its primary responsibility is to ensure that data is correct before the user application has access to them and discard incorrect data as it receives.

Furthermore, for data transmission utilizing multi-hop, a link layer must also facilitates safe-guards against [https://en.wikipedia.org/wiki/Hidden_node_problem hidden-] and [https://en.wikipedia.org/wiki/Exposed_node_problem exposed-] terminal problems.

Link Layer protocols commonly used in embedded systems belongs to the ''contention-based'' classification. This means that they are aware of the risks of collisions of transmitted data, while ''contention-free'' protocols commonly used in mobile phone networks, are more applicable to static networks with centralized control.

Utilizing a single channel with limited hardware processing power and aimed to be low power, two implementations of the link layer exists in the project: pure CSMA and FAMA-NCS.

* '''CSMA'''

CSMA protocol is classified as a contention-based protocol categorized in the ''random-access'' scheme. In this protocol, a node may transmit as soon as it is ready. It is suitable for low-load systems with a large number of potential senders.

As the CC430 chip used supporting Automatic Clear Channel Assessment on-chip [http://www.ti.com/product/cc430f5137 CC430F5137] (Listen-before-talk), the pure CSMA implementation is basically the physical layer implementation with extra address checking and buffers, ensuring that it conforms with the Link Layer interface.

* '''FAMA-NCS'''

FAMA-NCS stands for ''Floor Acquisition Multiple Access'' with ''Non-persistent carrier sensing'' ([http://link.springer.com/article/10.1023%2FA%3A1019146831447 Specification]), where ''floor'' stands for ''channel''. It is a MACA-based scheme that makes announcements before it sends data to inform other nodes to be silent. Unlike MACA protocols, FAMA protocols require collision avoidance to be performed at both the sender and receiver nodes.

To acquire the floor (channel), the sending node sends out a ''Request-to-Send (RTS)''. The receiver responds with a ''Clear-to-Send (CTS)'' back to the transmitter. Any nodes overhearing this CTS packet knows the station has acquired the floor. CTS packets are repeated long enough for the benefit of any hidden sender did not register another node's RTS.

With CC430 chip including Automatic Clear Channel Assessment that uses carrier sensing, it is arbitrary that the non-persistent carrier sensing should be used.

====Network Layer====

- Description

- Significance

=== Packet Format ===

[[File:Packet_Format.png]]

== Results ==

'''Maximum stable transfer speed'''

* Physical Layer: 215 packets/second
* CSMA-based Link Layer: 169 packets/second
* FAMA-based Link Layer: 22 packets/second

== Development Tools ==

=== Hardware ===

* CC430 development boards from Olimex were used as development targets throughout this project ([http://au.element14.com/olimex/msp430-ccrf/cc430f5137-transceiver-dev-board/dp/2061336 MSP430-CCRF])
* Various MSP430 LaunchPads were utilized as debugger and programmer, including:
** [http://www.ti.com/ww/en/launchpad/launchpads-msp430-msp-exp430g2.html#tabs MSP430G2553 LaunchPad]: hardware not recognized in Mac OS.
** [http://www.ti.com/ww/en/launchpad/launchpads-msp430-msp-exp430fr4133.html#tabs MSP430FR4133 LaunchPad]: added feature of power measurement, compatible with both Windows and Mac OS.
** [http://www.ti.com/ww/en/launchpad/launchpads-msp430-msp-exp430f5529lp.html#tabs MSP430F5529 LaunchPad]: compatible with both Windows and Mac OS.

=== Software ===

==== Code Composer Studio ====

- TI Compiler version

==== SmartRF Studio ====

- Used in RX/TX dBM measurement and RF configuration register generation

- Provide a quick description of how to use this tool for readers

=== Related documentation ===

== Application Development Guide ==

=== Typical Program Flow ===

=== Code Explanation ===

'''Code walk-through for various layers'''

=== Predefined Definitions ===

''' What they are for, why they exist, when to use them'''

=== Usage Scenarios ===

=== Migration Advice ===

- How to port code from this project to other MCU architectures

== Reflection and Improvement ==

== Reference ==

Projects:2015s1-40 Flexible ad-hoc Network A: Physical Layer

2015-10-21T12:35:44Z

A1627539: /* Packet Format */

== Introduction ==

=== Overview ===

==== Project Team ====

Cong Nguyen

Duncan Lawry

==== Supervisors ====

Michael Liebelt

Braden Phillips

=== Significance ===

Ad-hoc wireless networks are self-configurable networks with high node mobility, allowing them to function without reliance on any fixed infrastructure. This makes wireless ad-hoc networks useful for quick communication channel deployment suitable for all applications.

While there are already many existing commercial solutions with ad-hoc capability such as [http://www.zigbee.org/ ZigBee], [https://developer.bluetooth.org/TechnologyOverview/Pages/PAN.aspx Bluetooth Personal Area Network (PAN)] and Wi-Fi based ad-hoc configurations ([http://windows.microsoft.com/en-au/windows/set-computer-to-computer-adhoc-network Windows], [https://support.apple.com/kb/PH13796?locale=en_US MacOS], [https://wiki.debian.org/WiFi/AdHoc Linux (Debian)]) these solutions are generally costly in terms of processing power, memory requirement due to reliance on existing protocol stack or costly in terms of royalty. Furthermore, they are commonly reliant on the ISM 2.4GHz band, making them unsuitable for high-range applications without having to invest on a larger antenna which can increase power requirement and a product's physical size.

This project aims to develop an ad-hoc network stack with low processing power and low memory requirement by developing customized protocol layers operating in ISM sub-1GHz frequency for long communication distance and free usage, while provide high reliability and robustness.

=== Objectives and Deliverables ===

This project involves the development of the hardware abstraction layer (HAL), physical layer, link layer and network layer of a wireless ad-hoc network. In usage, data can be provided to the protocols via systems attaching to the protocol stacks or through an application on the microcontroller running the network stack itself.

At the end of this project, the developed ad-network will be flexible in configuration, providing reliable and modest data transfer rate over 100 metres. This means:

1. The network will be self-configuring, independent of external networking infrastructure

2. The network must scale efficiently from 2 to 50 or more nodes

3. The network must work well in both dense and sparse clusters

4. Packet delay should be as low as possible

5. There must be error-checking on multiple levels at the node

6. Node antennas must have a range of over 100 metres.

7. The network must support unicast and if time permits, multicast operation.

8. Each node should consume as little power as possible

== High Level Overview ==

=== Background ===

'''Ad-hoc Topology'''

An ad-hoc network can be classified into various classifications based on the communication type, topology and node configurations. Depending on the communication type, a network can be classified as single-hop or multi-hop ad-hoc network. In a single-hop network, all nodes are in range of each other and can communicate directly. In a multi-hop network, not all nodes are in reach of each others and need to communicate via a node in between - thus hops.

An ad-hoc network can also be classified by topology. The two major classifications are flat and hierarchical. In a flat ad-hoc nework, all nodes carry the same responsibilities. This means there are no admin nodes and that each nodes performs the same functionality. On the contrary, hierarchical ad-hoc networks consist of clusters of nodes representing individual networks but are all linked together. In a hierarchical network, master nodes exists and area responsible for passing data between clusters.

Lastly, an ad-hoc network can be classified based on its node configuration: homogeneous or heterogeneous. In homogeneous newtorks, all nodes have the same hardware and characteristics (processor, memory, peripheral devices, etc.). Wireless sensor network is a typical example of a homogeneous network. In a heterogeneous network, nodes differ in hardware configurations and thus cannot provide the same services.

This project is focused on implementing a flat, multi-hop and homogeneous network.

'''Addressing schemes'''

The focus of this project is to provide a robust and reliable unicast and broadcast routing ([https://en.wikipedia.org/wiki/Unicast#Addressing_methodologies Addressing methodologies]). If time permits or for future project groups, multicast can be added.

=== Layers ===

When it comes to code organization, we employs the [https://en.wikipedia.org/wiki/OSI_model OSI model]. In this project, the lower three layers are implemented: physical layer, link layer and network layer.

While implementing individual layers may lead to increased memory use due to duplicated buffers on various layers, it was chosen to specifically not to use cross-layer implementation as we wanted to:

* Use abstraction to simplify the development process
* Allow higher layers to be ported to other platforms as technology improves
* Allow lower layers to be used easily without higher layers as to customized to use in smaller microcontrollers, projects that does not require extra complexity of higher layers, etc.

====Hardware Abstraction Layer====

The hardware abstraction layer (HAL) implements functions that set up the MSP430 core hardware such as clocks, GPIO, UART, etc. This layer allows higher layers in the stack to have access to the hardware through a simple and portable abstraction API regardless of the underlying hardware. By default, the HAL initializes the MSP430 modules to the following settings:

* GPIO - All pins defaults to outputs with an output value of 0, with the exception of:
** P1.0: red LED on-board
** P1.1: input button with internal pull-up resistor (active low)
** P1.5, P1.6: UART Tx and Rx
** P5.0, P5.1: low-frequency watch crystal ACLK source

* Clocks
** MCLK: 25 MHz
** SMCLK: 25 MHz
** ACLK: 32768 Hz (external watch crystal frequency)

* UART
** Baud: 115200 (configurable with predefined symbols, ranging from 115200 to 921600)
** Data: 8 bits
** Parity: none
** Stop: 1 bit
** Flow control: none
** Hardware Rx interrupt disabled by default

* Timers
** Timer0_A0 is reserved for Link Layer operation

The HAL layer also includes ''fputs()'' and ''fputc()'' functions that overrides default ''stdio.h'' functions, allowing developers to use ''printf()'' seamlessly through UART in their applications.

====Physical Layer====

The Physical Layer deals with the physical connectivity between nodes. It set up the CC430 RF module's configuration registers, PA table, node address, as well as include some abstraction functions used in transmitting and enabling/disabling various settings of the RF module.

Various RF configurations are included with Olimex's examples that could be used readily with the physical layer implemented, allowing the physical layer's transfer rate to vary between 38.4k baud and 250k baud, as well as being able to transmit with output power settings from -30dBm to +8dBm.

These settings are configurable using predefined symbols.

====Link Layer====

With the wireless medium being tightly controlled, most wireless ad-hoc network applications operates in the ISM band, which is free from licensing. This means that there is limited channel bandwidth, much less than that of a wired network. Additionally, being wireless, there are many factors that can degrade the quality of the signal, such as noise and interference from other sources.

The Link Layer, sometimes referred to as a MAC layer, involves the functions and procedures to transfer data between two or more nodes in-range of the network. Its primary responsibility is to ensure that data is correct before the user application has access to them and discard incorrect data as it receives.

Furthermore, for data transmission utilizing multi-hop, a link layer must also facilitates safe-guards against [https://en.wikipedia.org/wiki/Hidden_node_problem hidden-] and [https://en.wikipedia.org/wiki/Exposed_node_problem exposed-] terminal problems.

Link Layer protocols commonly used in embedded systems belongs to the ''contention-based'' classification. This means that they are aware of the risks of collisions of transmitted data, while ''contention-free'' protocols commonly used in mobile phone networks, are more applicable to static networks with centralized control.

Utilizing a single channel with limited hardware processing power and aimed to be low power, two implementations of the link layer exists in the project: pure CSMA and FAMA-NCS.

* '''CSMA'''

CSMA protocol is classified as a contention-based protocol categorized in the ''random-access'' scheme. In this protocol, a node may transmit as soon as it is ready. It is suitable for low-load systems with a large number of potential senders.

As the CC430 chip used supporting Automatic Clear Channel Assessment on-chip [http://www.ti.com/product/cc430f5137 CC430F5137] (Listen-before-talk), the pure CSMA implementation is basically the physical layer implementation with extra address checking and buffers, ensuring that it conforms with the Link Layer interface.

* '''FAMA-NCS'''

FAMA-NCS stands for ''Floor Acquisition Multiple Access'' with ''Non-persistent carrier sensing'' ([http://link.springer.com/article/10.1023%2FA%3A1019146831447 Specification]), where ''floor'' stands for ''channel''. It is a MACA-based scheme that makes announcements before it sends data to inform other nodes to be silent. Unlike MACA protocols, FAMA protocols require collision avoidance to be performed at both the sender and receiver nodes.

To acquire the floor (channel), the sending node sends out a ''Request-to-Send (RTS)''. The receiver responds with a ''Clear-to-Send (CTS)'' back to the transmitter. Any nodes overhearing this CTS packet knows the station has acquired the floor. CTS packets are repeated long enough for the benefit of any hidden sender did not register another node's RTS.

With CC430 chip including Automatic Clear Channel Assessment that uses carrier sensing, it is arbitrary that the non-persistent carrier sensing should be used.

====Network Layer====

- Description

- Significance

=== Packet Format ===

[[File:Packet_Format.png]]

== Field Results ==

== Development Tools ==

=== Hardware ===

* CC430 development boards from Olimex were used as development targets throughout this project ([http://au.element14.com/olimex/msp430-ccrf/cc430f5137-transceiver-dev-board/dp/2061336 MSP430-CCRF])
* Various MSP430 LaunchPads were utilized as debugger and programmer, including:
** [http://www.ti.com/ww/en/launchpad/launchpads-msp430-msp-exp430g2.html#tabs MSP430G2553 LaunchPad]: hardware not recognized in Mac OS.
** [http://www.ti.com/ww/en/launchpad/launchpads-msp430-msp-exp430fr4133.html#tabs MSP430FR4133 LaunchPad]: added feature of power measurement, compatible with both Windows and Mac OS.
** [http://www.ti.com/ww/en/launchpad/launchpads-msp430-msp-exp430f5529lp.html#tabs MSP430F5529 LaunchPad]: compatible with both Windows and Mac OS.

=== Software ===

==== Code Composer Studio ====

- TI Compiler version

==== SmartRF Studio ====

- Used in RX/TX dBM measurement and RF configuration register generation

- Provide a quick description of how to use this tool for readers

=== Related documentation ===

== Application Development Guide ==

=== Typical Program Flow ===

=== Code Explanation ===

'''Code walk-through for various layers'''

=== Predefined Definitions ===

''' What they are for, why they exist, when to use them'''

=== Usage Scenarios ===

=== Migration Advice ===

- How to port code from this project to other MCU architectures

== Reflection and Improvement ==

== Reference ==

Projects:2015s1-40 Flexible ad-hoc Network A: Physical Layer

2015-10-21T12:35:22Z

A1627539: /* Link Layer */

== Introduction ==

=== Overview ===

==== Project Team ====

Cong Nguyen

Duncan Lawry

==== Supervisors ====

Michael Liebelt

Braden Phillips

=== Significance ===

Ad-hoc wireless networks are self-configurable networks with high node mobility, allowing them to function without reliance on any fixed infrastructure. This makes wireless ad-hoc networks useful for quick communication channel deployment suitable for all applications.

While there are already many existing commercial solutions with ad-hoc capability such as [http://www.zigbee.org/ ZigBee], [https://developer.bluetooth.org/TechnologyOverview/Pages/PAN.aspx Bluetooth Personal Area Network (PAN)] and Wi-Fi based ad-hoc configurations ([http://windows.microsoft.com/en-au/windows/set-computer-to-computer-adhoc-network Windows], [https://support.apple.com/kb/PH13796?locale=en_US MacOS], [https://wiki.debian.org/WiFi/AdHoc Linux (Debian)]) these solutions are generally costly in terms of processing power, memory requirement due to reliance on existing protocol stack or costly in terms of royalty. Furthermore, they are commonly reliant on the ISM 2.4GHz band, making them unsuitable for high-range applications without having to invest on a larger antenna which can increase power requirement and a product's physical size.

This project aims to develop an ad-hoc network stack with low processing power and low memory requirement by developing customized protocol layers operating in ISM sub-1GHz frequency for long communication distance and free usage, while provide high reliability and robustness.

=== Objectives and Deliverables ===

This project involves the development of the hardware abstraction layer (HAL), physical layer, link layer and network layer of a wireless ad-hoc network. In usage, data can be provided to the protocols via systems attaching to the protocol stacks or through an application on the microcontroller running the network stack itself.

At the end of this project, the developed ad-network will be flexible in configuration, providing reliable and modest data transfer rate over 100 metres. This means:

1. The network will be self-configuring, independent of external networking infrastructure

2. The network must scale efficiently from 2 to 50 or more nodes

3. The network must work well in both dense and sparse clusters

4. Packet delay should be as low as possible

5. There must be error-checking on multiple levels at the node

6. Node antennas must have a range of over 100 metres.

7. The network must support unicast and if time permits, multicast operation.

8. Each node should consume as little power as possible

== High Level Overview ==

=== Background ===

'''Ad-hoc Topology'''

An ad-hoc network can be classified into various classifications based on the communication type, topology and node configurations. Depending on the communication type, a network can be classified as single-hop or multi-hop ad-hoc network. In a single-hop network, all nodes are in range of each other and can communicate directly. In a multi-hop network, not all nodes are in reach of each others and need to communicate via a node in between - thus hops.

An ad-hoc network can also be classified by topology. The two major classifications are flat and hierarchical. In a flat ad-hoc nework, all nodes carry the same responsibilities. This means there are no admin nodes and that each nodes performs the same functionality. On the contrary, hierarchical ad-hoc networks consist of clusters of nodes representing individual networks but are all linked together. In a hierarchical network, master nodes exists and area responsible for passing data between clusters.

Lastly, an ad-hoc network can be classified based on its node configuration: homogeneous or heterogeneous. In homogeneous newtorks, all nodes have the same hardware and characteristics (processor, memory, peripheral devices, etc.). Wireless sensor network is a typical example of a homogeneous network. In a heterogeneous network, nodes differ in hardware configurations and thus cannot provide the same services.

This project is focused on implementing a flat, multi-hop and homogeneous network.

'''Addressing schemes'''

The focus of this project is to provide a robust and reliable unicast and broadcast routing ([https://en.wikipedia.org/wiki/Unicast#Addressing_methodologies Addressing methodologies]). If time permits or for future project groups, multicast can be added.

=== Layers ===

When it comes to code organization, we employs the [https://en.wikipedia.org/wiki/OSI_model OSI model]. In this project, the lower three layers are implemented: physical layer, link layer and network layer.

While implementing individual layers may lead to increased memory use due to duplicated buffers on various layers, it was chosen to specifically not to use cross-layer implementation as we wanted to:

* Use abstraction to simplify the development process
* Allow higher layers to be ported to other platforms as technology improves
* Allow lower layers to be used easily without higher layers as to customized to use in smaller microcontrollers, projects that does not require extra complexity of higher layers, etc.

====Hardware Abstraction Layer====

The hardware abstraction layer (HAL) implements functions that set up the MSP430 core hardware such as clocks, GPIO, UART, etc. This layer allows higher layers in the stack to have access to the hardware through a simple and portable abstraction API regardless of the underlying hardware. By default, the HAL initializes the MSP430 modules to the following settings:

* GPIO - All pins defaults to outputs with an output value of 0, with the exception of:
** P1.0: red LED on-board
** P1.1: input button with internal pull-up resistor (active low)
** P1.5, P1.6: UART Tx and Rx
** P5.0, P5.1: low-frequency watch crystal ACLK source

* Clocks
** MCLK: 25 MHz
** SMCLK: 25 MHz
** ACLK: 32768 Hz (external watch crystal frequency)

* UART
** Baud: 115200 (configurable with predefined symbols, ranging from 115200 to 921600)
** Data: 8 bits
** Parity: none
** Stop: 1 bit
** Flow control: none
** Hardware Rx interrupt disabled by default

* Timers
** Timer0_A0 is reserved for Link Layer operation

The HAL layer also includes ''fputs()'' and ''fputc()'' functions that overrides default ''stdio.h'' functions, allowing developers to use ''printf()'' seamlessly through UART in their applications.

====Physical Layer====

The Physical Layer deals with the physical connectivity between nodes. It set up the CC430 RF module's configuration registers, PA table, node address, as well as include some abstraction functions used in transmitting and enabling/disabling various settings of the RF module.

Various RF configurations are included with Olimex's examples that could be used readily with the physical layer implemented, allowing the physical layer's transfer rate to vary between 38.4k baud and 250k baud, as well as being able to transmit with output power settings from -30dBm to +8dBm.

These settings are configurable using predefined symbols.

====Link Layer====

With the wireless medium being tightly controlled, most wireless ad-hoc network applications operates in the ISM band, which is free from licensing. This means that there is limited channel bandwidth, much less than that of a wired network. Additionally, being wireless, there are many factors that can degrade the quality of the signal, such as noise and interference from other sources.

The Link Layer, sometimes referred to as a MAC layer, involves the functions and procedures to transfer data between two or more nodes in-range of the network. Its primary responsibility is to ensure that data is correct before the user application has access to them and discard incorrect data as it receives.

Furthermore, for data transmission utilizing multi-hop, a link layer must also facilitates safe-guards against [https://en.wikipedia.org/wiki/Hidden_node_problem hidden-] and [https://en.wikipedia.org/wiki/Exposed_node_problem exposed-] terminal problems.

Link Layer protocols commonly used in embedded systems belongs to the ''contention-based'' classification. This means that they are aware of the risks of collisions of transmitted data, while ''contention-free'' protocols commonly used in mobile phone networks, are more applicable to static networks with centralized control.

Utilizing a single channel with limited hardware processing power and aimed to be low power, two implementations of the link layer exists in the project: pure CSMA and FAMA-NCS.

* '''CSMA'''

CSMA protocol is classified as a contention-based protocol categorized in the ''random-access'' scheme. In this protocol, a node may transmit as soon as it is ready. It is suitable for low-load systems with a large number of potential senders.

As the CC430 chip used supporting Automatic Clear Channel Assessment on-chip [http://www.ti.com/product/cc430f5137 CC430F5137] (Listen-before-talk), the pure CSMA implementation is basically the physical layer implementation with extra address checking and buffers, ensuring that it conforms with the Link Layer interface.

* '''FAMA-NCS'''

FAMA-NCS stands for ''Floor Acquisition Multiple Access'' with ''Non-persistent carrier sensing'' ([http://link.springer.com/article/10.1023%2FA%3A1019146831447 Specification]), where ''floor'' stands for ''channel''. It is a MACA-based scheme that makes announcements before it sends data to inform other nodes to be silent. Unlike MACA protocols, FAMA protocols require collision avoidance to be performed at both the sender and receiver nodes.

To acquire the floor (channel), the sending node sends out a ''Request-to-Send (RTS)''. The receiver responds with a ''Clear-to-Send (CTS)'' back to the transmitter. Any nodes overhearing this CTS packet knows the station has acquired the floor. CTS packets are repeated long enough for the benefit of any hidden sender did not register another node's RTS.

With CC430 chip including Automatic Clear Channel Assessment that uses carrier sensing, it is arbitrary that the non-persistent carrier sensing should be used.

====Network Layer====

- Description

- Significance

=== Packet Format ===

[[File:Packet_Format.png]]

- Photo/Table of the packet

- Size and limitation of the packet

- Description of each byte in the packet

== Field Results ==

== Development Tools ==

=== Hardware ===

* CC430 development boards from Olimex were used as development targets throughout this project ([http://au.element14.com/olimex/msp430-ccrf/cc430f5137-transceiver-dev-board/dp/2061336 MSP430-CCRF])
* Various MSP430 LaunchPads were utilized as debugger and programmer, including:
** [http://www.ti.com/ww/en/launchpad/launchpads-msp430-msp-exp430g2.html#tabs MSP430G2553 LaunchPad]: hardware not recognized in Mac OS.
** [http://www.ti.com/ww/en/launchpad/launchpads-msp430-msp-exp430fr4133.html#tabs MSP430FR4133 LaunchPad]: added feature of power measurement, compatible with both Windows and Mac OS.
** [http://www.ti.com/ww/en/launchpad/launchpads-msp430-msp-exp430f5529lp.html#tabs MSP430F5529 LaunchPad]: compatible with both Windows and Mac OS.

=== Software ===

==== Code Composer Studio ====

- TI Compiler version

==== SmartRF Studio ====

- Used in RX/TX dBM measurement and RF configuration register generation

- Provide a quick description of how to use this tool for readers

=== Related documentation ===

== Application Development Guide ==

=== Typical Program Flow ===

=== Code Explanation ===

'''Code walk-through for various layers'''

=== Predefined Definitions ===

''' What they are for, why they exist, when to use them'''

=== Usage Scenarios ===

=== Migration Advice ===

- How to port code from this project to other MCU architectures

== Reflection and Improvement ==

== Reference ==

Projects:2015s1-40 Flexible ad-hoc Network A: Physical Layer

2015-10-07T09:09:37Z

A1627539: /* Development Tools */

== Introduction ==

=== Overview ===

==== Project Team ====

Cong Nguyen

Duncan Lawry

==== Supervisors ====

Michael Liebelt

Braden Phillips

=== Significance ===

Ad-hoc wireless networks are self-configurable networks with high node mobility, allowing them to function without reliance on any fixed infrastructure. This makes wireless ad-hoc networks useful for quick communication channel deployment suitable for all applications.

While there are already many existing commercial solutions with ad-hoc capability such as [http://www.zigbee.org/ ZigBee], [https://developer.bluetooth.org/TechnologyOverview/Pages/PAN.aspx Bluetooth Personal Area Network (PAN)] and Wi-Fi based ad-hoc configurations ([http://windows.microsoft.com/en-au/windows/set-computer-to-computer-adhoc-network Windows], [https://support.apple.com/kb/PH13796?locale=en_US MacOS], [https://wiki.debian.org/WiFi/AdHoc Linux (Debian)]) these solutions are generally costly in terms of processing power, memory requirement due to reliance on existing protocol stack or costly in terms of royalty. Furthermore, they are commonly reliant on the ISM 2.4GHz band, making them unsuitable for high-range applications without having to invest on a larger antenna which can increase power requirement and a product's physical size.

This project aims to develop an ad-hoc network stack with low processing power and low memory requirement by developing customized protocol layers operating in ISM sub-1GHz frequency for long communication distance and free usage, while provide high reliability and robustness.

=== Objectives and Deliverables ===

This project involves the development of the hardware abstraction layer (HAL), physical layer, link layer and network layer of a wireless ad-hoc network. In usage, data can be provided to the protocols via systems attaching to the protocol stacks or through an application on the microcontroller running the network stack itself.

At the end of this project, the developed ad-network will be flexible in configuration, providing reliable and modest data transfer rate over 100 metres. This means:

1. The network will be self-configuring, independent of external networking infrastructure

2. The network must scale efficiently from 2 to 50 or more nodes

3. The network must work well in both dense and sparse clusters

4. Packet delay should be as low as possible

5. There must be error-checking on multiple levels at the node

6. Node antennas must have a range of over 100 metres.

7. The network must support unicast and if time permits, multicast operation.

8. Each node should consume as little power as possible

== High Level Overview ==

=== Background ===

'''Ad-hoc Topology'''

An ad-hoc network can be classified into various classifications based on the communication type, topology and node configurations. Depending on the communication type, a network can be classified as single-hop or multi-hop ad-hoc network. In a single-hop network, all nodes are in range of each other and can communicate directly. In a multi-hop network, not all nodes are in reach of each others and need to communicate via a node in between - thus hops.

An ad-hoc network can also be classified by topology. The two major classifications are flat and hierarchical. In a flat ad-hoc nework, all nodes carry the same responsibilities. This means there are no admin nodes and that each nodes performs the same functionality. On the contrary, hierarchical ad-hoc networks consist of clusters of nodes representing individual networks but are all linked together. In a hierarchical network, master nodes exists and area responsible for passing data between clusters.

Lastly, an ad-hoc network can be classified based on its node configuration: homogeneous or heterogeneous. In homogeneous newtorks, all nodes have the same hardware and characteristics (processor, memory, peripheral devices, etc.). Wireless sensor network is a typical example of a homogeneous network. In a heterogeneous network, nodes differ in hardware configurations and thus cannot provide the same services.

This project is focused on implementing a flat, multi-hop and homogeneous network.

'''Addressing schemes'''

The focus of this project is to provide a robust and reliable unicast and broadcast routing ([https://en.wikipedia.org/wiki/Unicast#Addressing_methodologies Addressing methodologies]). If time permits or for future project groups, multicast can be added.

=== Layers ===

When it comes to code organization, we employs the [https://en.wikipedia.org/wiki/OSI_model OSI model]. In this project, the lower three layers are implemented: physical layer, link layer and network layer.

While implementing individual layers may lead to increased memory use due to duplicated buffers on various layers, it was chosen to specifically not to use cross-layer implementation as we wanted to:

* Use abstraction to simplify the development process
* Allow higher layers to be ported to other platforms as technology improves
* Allow lower layers to be used easily without higher layers as to customized to use in smaller microcontrollers, projects that does not require extra complexity of higher layers, etc.

====Hardware Abstraction Layer====

The hardware abstraction layer (HAL) implements functions that set up the MSP430 core hardware such as clocks, GPIO, UART, etc. This layer allows higher layers in the stack to have access to the hardware through a simple and portable abstraction API regardless of the underlying hardware. By default, the HAL initializes the MSP430 modules to the following settings:

* GPIO - All pins defaults to outputs with an output value of 0, with the exception of:
** P1.0: red LED on-board
** P1.1: input button with internal pull-up resistor (active low)
** P1.5, P1.6: UART Tx and Rx
** P5.0, P5.1: low-frequency watch crystal ACLK source

* Clocks
** MCLK: 25 MHz
** SMCLK: 25 MHz
** ACLK: 32768 Hz (external watch crystal frequency)

* UART
** Baud: 115200 (configurable with predefined symbols, ranging from 115200 to 921600)
** Data: 8 bits
** Parity: none
** Stop: 1 bit
** Flow control: none
** Hardware Rx interrupt disabled by default

* Timers
** Timer0_A0 is reserved for Link Layer operation

The HAL layer also includes ''fputs()'' and ''fputc()'' functions that overrides default ''stdio.h'' functions, allowing developers to use ''printf()'' seamlessly through UART in their applications.

====Physical Layer====

The Physical Layer deals with the physical connectivity between nodes. It set up the CC430 RF module's configuration registers, PA table, node address, as well as include some abstraction functions used in transmitting and enabling/disabling various settings of the RF module.

Various RF configurations are included with Olimex's examples that could be used readily with the physical layer implemented, allowing the physical layer's transfer rate to vary between 38.4k baud and 250k baud, as well as being able to transmit with output power settings from -30dBm to +8dBm.

These settings are configurable using predefined symbols.

====Link Layer====

With the wireless medium being tightly controlled, most wireless ad-hoc network applications operates in the ISM band, which is free from licensing. This means that there is limited channel bandwidth, much less than that of a wired network. Additionally, being wireless, there are many factors that can degrade the quality of the signal, such as noise and interference from other sources.

The Link Layer, sometimes referred to as a MAC layer, involves the functions and procedures to transfer data between two or more nodes in-range of the network. Its primary responsibility is to ensure that data is correct before the user application has access to them and discard incorrect data as it receives.

Furthermore, for data transmission utilizing multi-hop, a link layer must also facilitates safe-guards against [https://en.wikipedia.org/wiki/Hidden_node_problem hidden-] and [https://en.wikipedia.org/wiki/Exposed_node_problem exposed-] terminal problems.

Link Layer protocols commonly used in embedded systems belongs to the ''contention-based'' classification. This means that they are aware of the risks of collisions of transmitted data, while ''contention-free'' protocols commonly used in mobile phone networks, are more applicable to static networks with centralized control.

Utilizing a single channel with limited hardware processing power and aimed to be low power, two implementations of the link layer exists in the project: pure ALOHA and FAMA-NCS.

* '''Pure ALOHA'''

Pure ALOHA protocol is classified as a contention-based protocol categorized in the ''random-access'' scheme. In this protocol, a node may transmit as soon as it is ready. It is suitable for low-load systems with a large number of potential senders.

As the CC430 chip used supporting Automatic Clear Channel Assessment on-chip [http://www.ti.com/product/cc430f5137 CC430F5137] (Listen-before-talk), the pure ALOHA implementation is basically the physical layer implementation with extra address checking and buffers, ensuring that it conforms with the Link Layer interface.

* '''FAMA-NCS'''

FAMA-NCS stands for ''Floor Acquisition Multiple Access'' with ''Non-persistent carrier sensing'' ([http://link.springer.com/article/10.1023%2FA%3A1019146831447 Specification]), where ''floor'' stands for ''channel''. It is a MACA-based scheme that makes announcements before it sends data to inform other nodes to be silent. Unlike MACA protocols, FAMA protocols require collision avoidance to be performed at both the sender and receiver nodes.

To acquire the floor (channel), the sending node sends out a ''Request-to-Send (RTS)''. The receiver responds with a ''Clear-to-Send (CTS)'' back to the transmitter. Any nodes overhearing this CTS packet knows the station has acquired the floor. CTS packets are repeated long enough for the benefit of any hidden sender did not register another node's RTS.

With CC430 chip including Automatic Clear Channel Assessment that uses carrier sensing, it is arbitrary that the non-persistent carrier sensing should be used.

====Network Layer====

- Description

- Significance

=== Packet Format ===

[[File:Packet_Format.png]]

- Photo/Table of the packet

- Size and limitation of the packet

- Description of each byte in the packet

== Field Results ==

== Development Tools ==

=== Hardware ===

* CC430 development boards from Olimex were used as development targets throughout this project ([http://au.element14.com/olimex/msp430-ccrf/cc430f5137-transceiver-dev-board/dp/2061336 MSP430-CCRF])
* Various MSP430 LaunchPads were utilized as debugger and programmer, including:
** [http://www.ti.com/ww/en/launchpad/launchpads-msp430-msp-exp430g2.html#tabs MSP430G2553 LaunchPad]: hardware not recognized in Mac OS.
** [http://www.ti.com/ww/en/launchpad/launchpads-msp430-msp-exp430fr4133.html#tabs MSP430FR4133 LaunchPad]: added feature of power measurement, compatible with both Windows and Mac OS.
** [http://www.ti.com/ww/en/launchpad/launchpads-msp430-msp-exp430f5529lp.html#tabs MSP430F5529 LaunchPad]: compatible with both Windows and Mac OS.

=== Software ===

==== Code Composer Studio ====

- TI Compiler version

==== SmartRF Studio ====

- Used in RX/TX dBM measurement and RF configuration register generation

- Provide a quick description of how to use this tool for readers

=== Related documentation ===

== Application Development Guide ==

=== Typical Program Flow ===

=== Code Explanation ===

'''Code walk-through for various layers'''

=== Predefined Definitions ===

''' What they are for, why they exist, when to use them'''

=== Usage Scenarios ===

=== Migration Advice ===

- How to port code from this project to other MCU architectures

== Reflection and Improvement ==

== Reference ==

Projects:2015s1-40 Flexible ad-hoc Network A: Physical Layer

2015-10-07T08:52:15Z

A1627539: /* Packet Format */

== Introduction ==

=== Overview ===

==== Project Team ====

Cong Nguyen

Duncan Lawry

==== Supervisors ====

Michael Liebelt

Braden Phillips

=== Significance ===

Ad-hoc wireless networks are self-configurable networks with high node mobility, allowing them to function without reliance on any fixed infrastructure. This makes wireless ad-hoc networks useful for quick communication channel deployment suitable for all applications.

While there are already many existing commercial solutions with ad-hoc capability such as [http://www.zigbee.org/ ZigBee], [https://developer.bluetooth.org/TechnologyOverview/Pages/PAN.aspx Bluetooth Personal Area Network (PAN)] and Wi-Fi based ad-hoc configurations ([http://windows.microsoft.com/en-au/windows/set-computer-to-computer-adhoc-network Windows], [https://support.apple.com/kb/PH13796?locale=en_US MacOS], [https://wiki.debian.org/WiFi/AdHoc Linux (Debian)]) these solutions are generally costly in terms of processing power, memory requirement due to reliance on existing protocol stack or costly in terms of royalty. Furthermore, they are commonly reliant on the ISM 2.4GHz band, making them unsuitable for high-range applications without having to invest on a larger antenna which can increase power requirement and a product's physical size.

This project aims to develop an ad-hoc network stack with low processing power and low memory requirement by developing customized protocol layers operating in ISM sub-1GHz frequency for long communication distance and free usage, while provide high reliability and robustness.

=== Objectives and Deliverables ===

This project involves the development of the hardware abstraction layer (HAL), physical layer, link layer and network layer of a wireless ad-hoc network. In usage, data can be provided to the protocols via systems attaching to the protocol stacks or through an application on the microcontroller running the network stack itself.

At the end of this project, the developed ad-network will be flexible in configuration, providing reliable and modest data transfer rate over 100 metres. This means:

1. The network will be self-configuring, independent of external networking infrastructure

2. The network must scale efficiently from 2 to 50 or more nodes

3. The network must work well in both dense and sparse clusters

4. Packet delay should be as low as possible

5. There must be error-checking on multiple levels at the node

6. Node antennas must have a range of over 100 metres.

7. The network must support unicast and if time permits, multicast operation.

8. Each node should consume as little power as possible

== High Level Overview ==

=== Background ===

'''Ad-hoc Topology'''

An ad-hoc network can be classified into various classifications based on the communication type, topology and node configurations. Depending on the communication type, a network can be classified as single-hop or multi-hop ad-hoc network. In a single-hop network, all nodes are in range of each other and can communicate directly. In a multi-hop network, not all nodes are in reach of each others and need to communicate via a node in between - thus hops.

An ad-hoc network can also be classified by topology. The two major classifications are flat and hierarchical. In a flat ad-hoc nework, all nodes carry the same responsibilities. This means there are no admin nodes and that each nodes performs the same functionality. On the contrary, hierarchical ad-hoc networks consist of clusters of nodes representing individual networks but are all linked together. In a hierarchical network, master nodes exists and area responsible for passing data between clusters.

Lastly, an ad-hoc network can be classified based on its node configuration: homogeneous or heterogeneous. In homogeneous newtorks, all nodes have the same hardware and characteristics (processor, memory, peripheral devices, etc.). Wireless sensor network is a typical example of a homogeneous network. In a heterogeneous network, nodes differ in hardware configurations and thus cannot provide the same services.

This project is focused on implementing a flat, multi-hop and homogeneous network.

'''Addressing schemes'''

The focus of this project is to provide a robust and reliable unicast and broadcast routing ([https://en.wikipedia.org/wiki/Unicast#Addressing_methodologies Addressing methodologies]). If time permits or for future project groups, multicast can be added.

=== Layers ===

When it comes to code organization, we employs the [https://en.wikipedia.org/wiki/OSI_model OSI model]. In this project, the lower three layers are implemented: physical layer, link layer and network layer.

While implementing individual layers may lead to increased memory use due to duplicated buffers on various layers, it was chosen to specifically not to use cross-layer implementation as we wanted to:

* Use abstraction to simplify the development process
* Allow higher layers to be ported to other platforms as technology improves
* Allow lower layers to be used easily without higher layers as to customized to use in smaller microcontrollers, projects that does not require extra complexity of higher layers, etc.

====Hardware Abstraction Layer====

The hardware abstraction layer (HAL) implements functions that set up the MSP430 core hardware such as clocks, GPIO, UART, etc. This layer allows higher layers in the stack to have access to the hardware through a simple and portable abstraction API regardless of the underlying hardware. By default, the HAL initializes the MSP430 modules to the following settings:

* GPIO - All pins defaults to outputs with an output value of 0, with the exception of:
** P1.0: red LED on-board
** P1.1: input button with internal pull-up resistor (active low)
** P1.5, P1.6: UART Tx and Rx
** P5.0, P5.1: low-frequency watch crystal ACLK source

* Clocks
** MCLK: 25 MHz
** SMCLK: 25 MHz
** ACLK: 32768 Hz (external watch crystal frequency)

* UART
** Baud: 115200 (configurable with predefined symbols, ranging from 115200 to 921600)
** Data: 8 bits
** Parity: none
** Stop: 1 bit
** Flow control: none
** Hardware Rx interrupt disabled by default

* Timers
** Timer0_A0 is reserved for Link Layer operation

The HAL layer also includes ''fputs()'' and ''fputc()'' functions that overrides default ''stdio.h'' functions, allowing developers to use ''printf()'' seamlessly through UART in their applications.

====Physical Layer====

The Physical Layer deals with the physical connectivity between nodes. It set up the CC430 RF module's configuration registers, PA table, node address, as well as include some abstraction functions used in transmitting and enabling/disabling various settings of the RF module.

Various RF configurations are included with Olimex's examples that could be used readily with the physical layer implemented, allowing the physical layer's transfer rate to vary between 38.4k baud and 250k baud, as well as being able to transmit with output power settings from -30dBm to +8dBm.

These settings are configurable using predefined symbols.

====Link Layer====

With the wireless medium being tightly controlled, most wireless ad-hoc network applications operates in the ISM band, which is free from licensing. This means that there is limited channel bandwidth, much less than that of a wired network. Additionally, being wireless, there are many factors that can degrade the quality of the signal, such as noise and interference from other sources.

The Link Layer, sometimes referred to as a MAC layer, involves the functions and procedures to transfer data between two or more nodes in-range of the network. Its primary responsibility is to ensure that data is correct before the user application has access to them and discard incorrect data as it receives.

Furthermore, for data transmission utilizing multi-hop, a link layer must also facilitates safe-guards against [https://en.wikipedia.org/wiki/Hidden_node_problem hidden-] and [https://en.wikipedia.org/wiki/Exposed_node_problem exposed-] terminal problems.

Link Layer protocols commonly used in embedded systems belongs to the ''contention-based'' classification. This means that they are aware of the risks of collisions of transmitted data, while ''contention-free'' protocols commonly used in mobile phone networks, are more applicable to static networks with centralized control.

Utilizing a single channel with limited hardware processing power and aimed to be low power, two implementations of the link layer exists in the project: pure ALOHA and FAMA-NCS.

* '''Pure ALOHA'''

Pure ALOHA protocol is classified as a contention-based protocol categorized in the ''random-access'' scheme. In this protocol, a node may transmit as soon as it is ready. It is suitable for low-load systems with a large number of potential senders.

As the CC430 chip used supporting Automatic Clear Channel Assessment on-chip [http://www.ti.com/product/cc430f5137 CC430F5137] (Listen-before-talk), the pure ALOHA implementation is basically the physical layer implementation with extra address checking and buffers, ensuring that it conforms with the Link Layer interface.

* '''FAMA-NCS'''

FAMA-NCS stands for ''Floor Acquisition Multiple Access'' with ''Non-persistent carrier sensing'' ([http://link.springer.com/article/10.1023%2FA%3A1019146831447 Specification]), where ''floor'' stands for ''channel''. It is a MACA-based scheme that makes announcements before it sends data to inform other nodes to be silent. Unlike MACA protocols, FAMA protocols require collision avoidance to be performed at both the sender and receiver nodes.

To acquire the floor (channel), the sending node sends out a ''Request-to-Send (RTS)''. The receiver responds with a ''Clear-to-Send (CTS)'' back to the transmitter. Any nodes overhearing this CTS packet knows the station has acquired the floor. CTS packets are repeated long enough for the benefit of any hidden sender did not register another node's RTS.

With CC430 chip including Automatic Clear Channel Assessment that uses carrier sensing, it is arbitrary that the non-persistent carrier sensing should be used.

====Network Layer====

- Description

- Significance

=== Packet Format ===

[[File:Packet_Format.png]]

- Photo/Table of the packet

- Size and limitation of the packet

- Description of each byte in the packet

== Field Results ==

== Development Tools ==

=== Hardware ===

=== Software ===

==== Code Composer Studio ====

- TI Compiler version

==== SmartRF Studio ====

- Used in RX/TX dBM measurement and RF configuration register generation

- Provide a quick description of how to use this tool for readers

=== Related documentation ===

== Application Development Guide ==

=== Typical Program Flow ===

=== Code Explanation ===

'''Code walk-through for various layers'''

=== Predefined Definitions ===

''' What they are for, why they exist, when to use them'''

=== Usage Scenarios ===

=== Migration Advice ===

- How to port code from this project to other MCU architectures

== Reflection and Improvement ==

== Reference ==

File:Packet Format.png

2015-10-07T08:51:08Z

A1627539: Packet format for Project 40

Packet format for Project 40

Projects:2015s1-40 Flexible ad-hoc Network A: Physical Layer

2015-10-05T23:25:01Z

A1627539: /* Packet Format */

== Introduction ==

=== Overview ===

==== Project Team ====

Cong Nguyen

Duncan Lawry

==== Supervisors ====

Michael Liebelt

Braden Phillips

=== Significance ===

Ad-hoc wireless networks are self-configurable networks with high node mobility, allowing them to function without reliance on any fixed infrastructure. This makes wireless ad-hoc networks useful for quick communication channel deployment suitable for all applications.

While there are already many existing commercial solutions with ad-hoc capability such as [http://www.zigbee.org/ ZigBee], [https://developer.bluetooth.org/TechnologyOverview/Pages/PAN.aspx Bluetooth Personal Area Network (PAN)] and Wi-Fi based ad-hoc configurations ([http://windows.microsoft.com/en-au/windows/set-computer-to-computer-adhoc-network Windows], [https://support.apple.com/kb/PH13796?locale=en_US MacOS], [https://wiki.debian.org/WiFi/AdHoc Linux (Debian)]) these solutions are generally costly in terms of processing power, memory requirement due to reliance on existing protocol stack or costly in terms of royalty. Furthermore, they are commonly reliant on the ISM 2.4GHz band, making them unsuitable for high-range applications without having to invest on a larger antenna which can increase power requirement and a product's physical size.

This project aims to develop an ad-hoc network stack with low processing power and low memory requirement by developing customized protocol layers operating in ISM sub-1GHz frequency for long communication distance and free usage, while provide high reliability and robustness.

=== Objectives and Deliverables ===

This project involves the development of the hardware abstraction layer (HAL), physical layer, link layer and network layer of a wireless ad-hoc network. In usage, data can be provided to the protocols via systems attaching to the protocol stacks or through an application on the microcontroller running the network stack itself.

At the end of this project, the developed ad-network will be flexible in configuration, providing reliable and modest data transfer rate over 100 metres. This means:

1. The network will be self-configuring, independent of external networking infrastructure

2. The network must scale efficiently from 2 to 50 or more nodes

3. The network must work well in both dense and sparse clusters

4. Packet delay should be as low as possible

5. There must be error-checking on multiple levels at the node

6. Node antennas must have a range of over 100 metres.

7. The network must support unicast and if time permits, multicast operation.

8. Each node should consume as little power as possible

== High Level Overview ==

=== Background ===

'''Ad-hoc Topology'''

An ad-hoc network can be classified into various classifications based on the communication type, topology and node configurations. Depending on the communication type, a network can be classified as single-hop or multi-hop ad-hoc network. In a single-hop network, all nodes are in range of each other and can communicate directly. In a multi-hop network, not all nodes are in reach of each others and need to communicate via a node in between - thus hops.

An ad-hoc network can also be classified by topology. The two major classifications are flat and hierarchical. In a flat ad-hoc nework, all nodes carry the same responsibilities. This means there are no admin nodes and that each nodes performs the same functionality. On the contrary, hierarchical ad-hoc networks consist of clusters of nodes representing individual networks but are all linked together. In a hierarchical network, master nodes exists and area responsible for passing data between clusters.

Lastly, an ad-hoc network can be classified based on its node configuration: homogeneous or heterogeneous. In homogeneous newtorks, all nodes have the same hardware and characteristics (processor, memory, peripheral devices, etc.). Wireless sensor network is a typical example of a homogeneous network. In a heterogeneous network, nodes differ in hardware configurations and thus cannot provide the same services.

This project is focused on implementing a flat, multi-hop and homogeneous network.

'''Addressing schemes'''

The focus of this project is to provide a robust and reliable unicast and broadcast routing ([https://en.wikipedia.org/wiki/Unicast#Addressing_methodologies Addressing methodologies]). If time permits or for future project groups, multicast can be added.

=== Layers ===

When it comes to code organization, we employs the [https://en.wikipedia.org/wiki/OSI_model OSI model]. In this project, the lower three layers are implemented: physical layer, link layer and network layer.

While implementing individual layers may lead to increased memory use due to duplicated buffers on various layers, it was chosen to specifically not to use cross-layer implementation as we wanted to:

* Use abstraction to simplify the development process
* Allow higher layers to be ported to other platforms as technology improves
* Allow lower layers to be used easily without higher layers as to customized to use in smaller microcontrollers, projects that does not require extra complexity of higher layers, etc.

====Hardware Abstraction Layer====

The hardware abstraction layer (HAL) implements functions that set up the MSP430 core hardware such as clocks, GPIO, UART, etc. This layer allows higher layers in the stack to have access to the hardware through a simple and portable abstraction API regardless of the underlying hardware. By default, the HAL initializes the MSP430 modules to the following settings:

* GPIO - All pins defaults to outputs with an output value of 0, with the exception of:
** P1.0: red LED on-board
** P1.1: input button with internal pull-up resistor (active low)
** P1.5, P1.6: UART Tx and Rx
** P5.0, P5.1: low-frequency watch crystal ACLK source

* Clocks
** MCLK: 25 MHz
** SMCLK: 25 MHz
** ACLK: 32768 Hz (external watch crystal frequency)

* UART
** Baud: 115200 (configurable with predefined symbols, ranging from 115200 to 921600)
** Data: 8 bits
** Parity: none
** Stop: 1 bit
** Flow control: none
** Hardware Rx interrupt disabled by default

* Timers
** Timer0_A0 is reserved for Link Layer operation

The HAL layer also includes ''fputs()'' and ''fputc()'' functions that overrides default ''stdio.h'' functions, allowing developers to use ''printf()'' seamlessly through UART in their applications.

====Physical Layer====

The Physical Layer deals with the physical connectivity between nodes. It set up the CC430 RF module's configuration registers, PA table, node address, as well as include some abstraction functions used in transmitting and enabling/disabling various settings of the RF module.

Various RF configurations are included with Olimex's examples that could be used readily with the physical layer implemented, allowing the physical layer's transfer rate to vary between 38.4k baud and 250k baud, as well as being able to transmit with output power settings from -30dBm to +8dBm.

These settings are configurable using predefined symbols.

====Link Layer====

With the wireless medium being tightly controlled, most wireless ad-hoc network applications operates in the ISM band, which is free from licensing. This means that there is limited channel bandwidth, much less than that of a wired network. Additionally, being wireless, there are many factors that can degrade the quality of the signal, such as noise and interference from other sources.

The Link Layer, sometimes referred to as a MAC layer, involves the functions and procedures to transfer data between two or more nodes in-range of the network. Its primary responsibility is to ensure that data is correct before the user application has access to them and discard incorrect data as it receives.

Furthermore, for data transmission utilizing multi-hop, a link layer must also facilitates safe-guards against [https://en.wikipedia.org/wiki/Hidden_node_problem hidden-] and [https://en.wikipedia.org/wiki/Exposed_node_problem exposed-] terminal problems.

Link Layer protocols commonly used in embedded systems belongs to the ''contention-based'' classification. This means that they are aware of the risks of collisions of transmitted data, while ''contention-free'' protocols commonly used in mobile phone networks, are more applicable to static networks with centralized control.

Utilizing a single channel with limited hardware processing power and aimed to be low power, two implementations of the link layer exists in the project: pure ALOHA and FAMA-NCS.

* '''Pure ALOHA'''

Pure ALOHA protocol is classified as a contention-based protocol categorized in the ''random-access'' scheme. In this protocol, a node may transmit as soon as it is ready. It is suitable for low-load systems with a large number of potential senders.

As the CC430 chip used supporting Automatic Clear Channel Assessment on-chip [http://www.ti.com/product/cc430f5137 CC430F5137] (Listen-before-talk), the pure ALOHA implementation is basically the physical layer implementation with extra address checking and buffers, ensuring that it conforms with the Link Layer interface.

* '''FAMA-NCS'''

FAMA-NCS stands for ''Floor Acquisition Multiple Access'' with ''Non-persistent carrier sensing'' ([http://link.springer.com/article/10.1023%2FA%3A1019146831447 Specification]), where ''floor'' stands for ''channel''. It is a MACA-based scheme that makes announcements before it sends data to inform other nodes to be silent. Unlike MACA protocols, FAMA protocols require collision avoidance to be performed at both the sender and receiver nodes.

To acquire the floor (channel), the sending node sends out a ''Request-to-Send (RTS)''. The receiver responds with a ''Clear-to-Send (CTS)'' back to the transmitter. Any nodes overhearing this CTS packet knows the station has acquired the floor. CTS packets are repeated long enough for the benefit of any hidden sender did not register another node's RTS.

With CC430 chip including Automatic Clear Channel Assessment that uses carrier sensing, it is arbitrary that the non-persistent carrier sensing should be used.

====Network Layer====

- Description

- Significance

=== Packet Format ===

[[File:http://i62.tinypic.com/d8ehl.jpg]]
- Photo/Table of the packet

- Size and limitation of the packet

- Description of each byte in the packet

== Field Results ==

== Development Tools ==

=== Hardware ===

=== Software ===

==== Code Composer Studio ====

- TI Compiler version

==== SmartRF Studio ====

- Used in RX/TX dBM measurement and RF configuration register generation

- Provide a quick description of how to use this tool for readers

=== Related documentation ===

== Application Development Guide ==

=== Typical Program Flow ===

=== Code Explanation ===

'''Code walk-through for various layers'''

=== Predefined Definitions ===

''' What they are for, why they exist, when to use them'''

=== Usage Scenarios ===

=== Migration Advice ===

- How to port code from this project to other MCU architectures

== Reflection and Improvement ==

== Reference ==

Projects:2015s1-40 Flexible ad-hoc Network A: Physical Layer

2015-10-04T09:12:53Z

A1627539: /* Deliverable Test Results */

== Introduction ==

=== Overview ===

==== Project Team ====

Cong Nguyen

Duncan Lawry

==== Supervisors ====

Michael Liebelt

Braden Phillips

=== Significance ===

Ad-hoc wireless networks are self-configurable networks with high node mobility, allowing them to function without reliance on any fixed infrastructure. This makes wireless ad-hoc networks useful for quick communication channel deployment suitable for all applications.

While there are already many existing commercial solutions with ad-hoc capability such as [http://www.zigbee.org/ ZigBee], [https://developer.bluetooth.org/TechnologyOverview/Pages/PAN.aspx Bluetooth Personal Area Network (PAN)] and Wi-Fi based ad-hoc configurations ([http://windows.microsoft.com/en-au/windows/set-computer-to-computer-adhoc-network Windows], [https://support.apple.com/kb/PH13796?locale=en_US MacOS], [https://wiki.debian.org/WiFi/AdHoc Linux (Debian)]) these solutions are generally costly in terms of processing power, memory requirement due to reliance on existing protocol stack or costly in terms of royalty. Furthermore, they are commonly reliant on the ISM 2.4GHz band, making them unsuitable for high-range applications without having to invest on a larger antenna which can increase power requirement and a product's physical size.

This project aims to develop an ad-hoc network stack with low processing power and low memory requirement by developing customized protocol layers operating in ISM sub-1GHz frequency for long communication distance and free usage, while provide high reliability and robustness.

=== Objectives and Deliverables ===

This project involves the development of the hardware abstraction layer (HAL), physical layer, link layer and network layer of a wireless ad-hoc network. In usage, data can be provided to the protocols via systems attaching to the protocol stacks or through an application on the microcontroller running the network stack itself.

At the end of this project, the developed ad-network will be flexible in configuration, providing reliable and modest data transfer rate over 100 metres. This means:

1. The network will be self-configuring, independent of external networking infrastructure

2. The network must scale efficiently from 2 to 50 or more nodes

3. The network must work well in both dense and sparse clusters

4. Packet delay should be as low as possible

5. There must be error-checking on multiple levels at the node

6. Node antennas must have a range of over 100 metres.

7. The network must support unicast and if time permits, multicast operation.

8. Each node should consume as little power as possible

== High Level Overview ==

=== Background ===

'''Ad-hoc Topology'''

An ad-hoc network can be classified into various classifications based on the communication type, topology and node configurations. Depending on the communication type, a network can be classified as single-hop or multi-hop ad-hoc network. In a single-hop network, all nodes are in range of each other and can communicate directly. In a multi-hop network, not all nodes are in reach of each others and need to communicate via a node in between - thus hops.

An ad-hoc network can also be classified by topology. The two major classifications are flat and hierarchical. In a flat ad-hoc nework, all nodes carry the same responsibilities. This means there are no admin nodes and that each nodes performs the same functionality. On the contrary, hierarchical ad-hoc networks consist of clusters of nodes representing individual networks but are all linked together. In a hierarchical network, master nodes exists and area responsible for passing data between clusters.

Lastly, an ad-hoc network can be classified based on its node configuration: homogeneous or heterogeneous. In homogeneous newtorks, all nodes have the same hardware and characteristics (processor, memory, peripheral devices, etc.). Wireless sensor network is a typical example of a homogeneous network. In a heterogeneous network, nodes differ in hardware configurations and thus cannot provide the same services.

This project is focused on implementing a flat, multi-hop and homogeneous network.

'''Addressing schemes'''

The focus of this project is to provide a robust and reliable unicast and broadcast routing ([https://en.wikipedia.org/wiki/Unicast#Addressing_methodologies Addressing methodologies]). If time permits or for future project groups, multicast can be added.

=== Layers ===

When it comes to code organization, we employs the [https://en.wikipedia.org/wiki/OSI_model OSI model]. In this project, the lower three layers are implemented: physical layer, link layer and network layer.

While implementing individual layers may lead to increased memory use due to duplicated buffers on various layers, it was chosen to specifically not to use cross-layer implementation as we wanted to:

* Use abstraction to simplify the development process
* Allow higher layers to be ported to other platforms as technology improves
* Allow lower layers to be used easily without higher layers as to customized to use in smaller microcontrollers, projects that does not require extra complexity of higher layers, etc.

====Hardware Abstraction Layer====

The hardware abstraction layer (HAL) implements functions that set up the MSP430 core hardware such as clocks, GPIO, UART, etc. This layer allows higher layers in the stack to have access to the hardware through a simple and portable abstraction API regardless of the underlying hardware. By default, the HAL initializes the MSP430 modules to the following settings:

* GPIO - All pins defaults to outputs with an output value of 0, with the exception of:
** P1.0: red LED on-board
** P1.1: input button with internal pull-up resistor (active low)
** P1.5, P1.6: UART Tx and Rx
** P5.0, P5.1: low-frequency watch crystal ACLK source

* Clocks
** MCLK: 25 MHz
** SMCLK: 25 MHz
** ACLK: 32768 Hz (external watch crystal frequency)

* UART
** Baud: 115200 (configurable with predefined symbols, ranging from 115200 to 921600)
** Data: 8 bits
** Parity: none
** Stop: 1 bit
** Flow control: none
** Hardware Rx interrupt disabled by default

* Timers
** Timer0_A0 is reserved for Link Layer operation

The HAL layer also includes ''fputs()'' and ''fputc()'' functions that overrides default ''stdio.h'' functions, allowing developers to use ''printf()'' seamlessly through UART in their applications.

====Physical Layer====

The Physical Layer deals with the physical connectivity between nodes. It set up the CC430 RF module's configuration registers, PA table, node address, as well as include some abstraction functions used in transmitting and enabling/disabling various settings of the RF module.

Various RF configurations are included with Olimex's examples that could be used readily with the physical layer implemented, allowing the physical layer's transfer rate to vary between 38.4k baud and 250k baud, as well as being able to transmit with output power settings from -30dBm to +8dBm.

These settings are configurable using predefined symbols.

====Link Layer====

With the wireless medium being tightly controlled, most wireless ad-hoc network applications operates in the ISM band, which is free from licensing. This means that there is limited channel bandwidth, much less than that of a wired network. Additionally, being wireless, there are many factors that can degrade the quality of the signal, such as noise and interference from other sources.

The Link Layer, sometimes referred to as a MAC layer, involves the functions and procedures to transfer data between two or more nodes in-range of the network. Its primary responsibility is to ensure that data is correct before the user application has access to them and discard incorrect data as it receives.

Furthermore, for data transmission utilizing multi-hop, a link layer must also facilitates safe-guards against [https://en.wikipedia.org/wiki/Hidden_node_problem hidden-] and [https://en.wikipedia.org/wiki/Exposed_node_problem exposed-] terminal problems.

Link Layer protocols commonly used in embedded systems belongs to the ''contention-based'' classification. This means that they are aware of the risks of collisions of transmitted data, while ''contention-free'' protocols commonly used in mobile phone networks, are more applicable to static networks with centralized control.

Utilizing a single channel with limited hardware processing power and aimed to be low power, two implementations of the link layer exists in the project: pure ALOHA and FAMA-NCS.

* '''Pure ALOHA'''

Pure ALOHA protocol is classified as a contention-based protocol categorized in the ''random-access'' scheme. In this protocol, a node may transmit as soon as it is ready. It is suitable for low-load systems with a large number of potential senders.

As the CC430 chip used supporting Automatic Clear Channel Assessment on-chip [http://www.ti.com/product/cc430f5137 CC430F5137] (Listen-before-talk), the pure ALOHA implementation is basically the physical layer implementation with extra address checking and buffers, ensuring that it conforms with the Link Layer interface.

* '''FAMA-NCS'''

FAMA-NCS stands for ''Floor Acquisition Multiple Access'' with ''Non-persistent carrier sensing'' ([http://link.springer.com/article/10.1023%2FA%3A1019146831447 Specification]), where ''floor'' stands for ''channel''. It is a MACA-based scheme that makes announcements before it sends data to inform other nodes to be silent. Unlike MACA protocols, FAMA protocols require collision avoidance to be performed at both the sender and receiver nodes.

To acquire the floor (channel), the sending node sends out a ''Request-to-Send (RTS)''. The receiver responds with a ''Clear-to-Send (CTS)'' back to the transmitter. Any nodes overhearing this CTS packet knows the station has acquired the floor. CTS packets are repeated long enough for the benefit of any hidden sender did not register another node's RTS.

With CC430 chip including Automatic Clear Channel Assessment that uses carrier sensing, it is arbitrary that the non-persistent carrier sensing should be used.

====Network Layer====

- Description

- Significance

=== Packet Format ===

- Photo/Table of the packet

- Size and limitation of the packet

- Description of each byte in the packet

== Field Results ==

== Development Tools ==

=== Hardware ===

=== Software ===

==== Code Composer Studio ====

- TI Compiler version

==== SmartRF Studio ====

- Used in RX/TX dBM measurement and RF configuration register generation

- Provide a quick description of how to use this tool for readers

=== Related documentation ===

== Application Development Guide ==

=== Typical Program Flow ===

=== Code Explanation ===

'''Code walk-through for various layers'''

=== Predefined Definitions ===

''' What they are for, why they exist, when to use them'''

=== Usage Scenarios ===

=== Migration Advice ===

- How to port code from this project to other MCU architectures

== Reflection and Improvement ==

== Reference ==

Projects:2015s1-40 Flexible ad-hoc Network A: Physical Layer

2015-10-04T09:01:28Z

A1627539: /* Link Layer */

== Introduction ==

=== Overview ===

==== Project Team ====

Cong Nguyen

Duncan Lawry

==== Supervisors ====

Michael Liebelt

Braden Phillips

=== Significance ===

Ad-hoc wireless networks are self-configurable networks with high node mobility, allowing them to function without reliance on any fixed infrastructure. This makes wireless ad-hoc networks useful for quick communication channel deployment suitable for all applications.

While there are already many existing commercial solutions with ad-hoc capability such as [http://www.zigbee.org/ ZigBee], [https://developer.bluetooth.org/TechnologyOverview/Pages/PAN.aspx Bluetooth Personal Area Network (PAN)] and Wi-Fi based ad-hoc configurations ([http://windows.microsoft.com/en-au/windows/set-computer-to-computer-adhoc-network Windows], [https://support.apple.com/kb/PH13796?locale=en_US MacOS], [https://wiki.debian.org/WiFi/AdHoc Linux (Debian)]) these solutions are generally costly in terms of processing power, memory requirement due to reliance on existing protocol stack or costly in terms of royalty. Furthermore, they are commonly reliant on the ISM 2.4GHz band, making them unsuitable for high-range applications without having to invest on a larger antenna which can increase power requirement and a product's physical size.

This project aims to develop an ad-hoc network stack with low processing power and low memory requirement by developing customized protocol layers operating in ISM sub-1GHz frequency for long communication distance and free usage, while provide high reliability and robustness.

=== Objectives and Deliverables ===

This project involves the development of the hardware abstraction layer (HAL), physical layer, link layer and network layer of a wireless ad-hoc network. In usage, data can be provided to the protocols via systems attaching to the protocol stacks or through an application on the microcontroller running the network stack itself.

At the end of this project, the developed ad-network will be flexible in configuration, providing reliable and modest data transfer rate over 100 metres. This means:

1. The network will be self-configuring, independent of external networking infrastructure

2. The network must scale efficiently from 2 to 50 or more nodes

3. The network must work well in both dense and sparse clusters

4. Packet delay should be as low as possible

5. There must be error-checking on multiple levels at the node

6. Node antennas must have a range of over 100 metres.

7. The network must support unicast and if time permits, multicast operation.

8. Each node should consume as little power as possible

== High Level Overview ==

=== Background ===

'''Ad-hoc Topology'''

An ad-hoc network can be classified into various classifications based on the communication type, topology and node configurations. Depending on the communication type, a network can be classified as single-hop or multi-hop ad-hoc network. In a single-hop network, all nodes are in range of each other and can communicate directly. In a multi-hop network, not all nodes are in reach of each others and need to communicate via a node in between - thus hops.

An ad-hoc network can also be classified by topology. The two major classifications are flat and hierarchical. In a flat ad-hoc nework, all nodes carry the same responsibilities. This means there are no admin nodes and that each nodes performs the same functionality. On the contrary, hierarchical ad-hoc networks consist of clusters of nodes representing individual networks but are all linked together. In a hierarchical network, master nodes exists and area responsible for passing data between clusters.

Lastly, an ad-hoc network can be classified based on its node configuration: homogeneous or heterogeneous. In homogeneous newtorks, all nodes have the same hardware and characteristics (processor, memory, peripheral devices, etc.). Wireless sensor network is a typical example of a homogeneous network. In a heterogeneous network, nodes differ in hardware configurations and thus cannot provide the same services.

This project is focused on implementing a flat, multi-hop and homogeneous network.

'''Addressing schemes'''

The focus of this project is to provide a robust and reliable unicast and broadcast routing ([https://en.wikipedia.org/wiki/Unicast#Addressing_methodologies Addressing methodologies]). If time permits or for future project groups, multicast can be added.

=== Layers ===

When it comes to code organization, we employs the [https://en.wikipedia.org/wiki/OSI_model OSI model]. In this project, the lower three layers are implemented: physical layer, link layer and network layer.

While implementing individual layers may lead to increased memory use due to duplicated buffers on various layers, it was chosen to specifically not to use cross-layer implementation as we wanted to:

* Use abstraction to simplify the development process
* Allow higher layers to be ported to other platforms as technology improves
* Allow lower layers to be used easily without higher layers as to customized to use in smaller microcontrollers, projects that does not require extra complexity of higher layers, etc.

====Hardware Abstraction Layer====

The hardware abstraction layer (HAL) implements functions that set up the MSP430 core hardware such as clocks, GPIO, UART, etc. This layer allows higher layers in the stack to have access to the hardware through a simple and portable abstraction API regardless of the underlying hardware. By default, the HAL initializes the MSP430 modules to the following settings:

* GPIO - All pins defaults to outputs with an output value of 0, with the exception of:
** P1.0: red LED on-board
** P1.1: input button with internal pull-up resistor (active low)
** P1.5, P1.6: UART Tx and Rx
** P5.0, P5.1: low-frequency watch crystal ACLK source

* Clocks
** MCLK: 25 MHz
** SMCLK: 25 MHz
** ACLK: 32768 Hz (external watch crystal frequency)

* UART
** Baud: 115200 (configurable with predefined symbols, ranging from 115200 to 921600)
** Data: 8 bits
** Parity: none
** Stop: 1 bit
** Flow control: none
** Hardware Rx interrupt disabled by default

* Timers
** Timer0_A0 is reserved for Link Layer operation

The HAL layer also includes ''fputs()'' and ''fputc()'' functions that overrides default ''stdio.h'' functions, allowing developers to use ''printf()'' seamlessly through UART in their applications.

====Physical Layer====

The Physical Layer deals with the physical connectivity between nodes. It set up the CC430 RF module's configuration registers, PA table, node address, as well as include some abstraction functions used in transmitting and enabling/disabling various settings of the RF module.

Various RF configurations are included with Olimex's examples that could be used readily with the physical layer implemented, allowing the physical layer's transfer rate to vary between 38.4k baud and 250k baud, as well as being able to transmit with output power settings from -30dBm to +8dBm.

These settings are configurable using predefined symbols.

====Link Layer====

With the wireless medium being tightly controlled, most wireless ad-hoc network applications operates in the ISM band, which is free from licensing. This means that there is limited channel bandwidth, much less than that of a wired network. Additionally, being wireless, there are many factors that can degrade the quality of the signal, such as noise and interference from other sources.

The Link Layer, sometimes referred to as a MAC layer, involves the functions and procedures to transfer data between two or more nodes in-range of the network. Its primary responsibility is to ensure that data is correct before the user application has access to them and discard incorrect data as it receives.

Furthermore, for data transmission utilizing multi-hop, a link layer must also facilitates safe-guards against [https://en.wikipedia.org/wiki/Hidden_node_problem hidden-] and [https://en.wikipedia.org/wiki/Exposed_node_problem exposed-] terminal problems.

Link Layer protocols commonly used in embedded systems belongs to the ''contention-based'' classification. This means that they are aware of the risks of collisions of transmitted data, while ''contention-free'' protocols commonly used in mobile phone networks, are more applicable to static networks with centralized control.

Utilizing a single channel with limited hardware processing power and aimed to be low power, two implementations of the link layer exists in the project: pure ALOHA and FAMA-NCS.

* '''Pure ALOHA'''

Pure ALOHA protocol is classified as a contention-based protocol categorized in the ''random-access'' scheme. In this protocol, a node may transmit as soon as it is ready. It is suitable for low-load systems with a large number of potential senders.

As the CC430 chip used supporting Automatic Clear Channel Assessment on-chip [http://www.ti.com/product/cc430f5137 CC430F5137] (Listen-before-talk), the pure ALOHA implementation is basically the physical layer implementation with extra address checking and buffers, ensuring that it conforms with the Link Layer interface.

* '''FAMA-NCS'''

FAMA-NCS stands for ''Floor Acquisition Multiple Access'' with ''Non-persistent carrier sensing'' ([http://link.springer.com/article/10.1023%2FA%3A1019146831447 Specification]), where ''floor'' stands for ''channel''. It is a MACA-based scheme that makes announcements before it sends data to inform other nodes to be silent. Unlike MACA protocols, FAMA protocols require collision avoidance to be performed at both the sender and receiver nodes.

To acquire the floor (channel), the sending node sends out a ''Request-to-Send (RTS)''. The receiver responds with a ''Clear-to-Send (CTS)'' back to the transmitter. Any nodes overhearing this CTS packet knows the station has acquired the floor. CTS packets are repeated long enough for the benefit of any hidden sender did not register another node's RTS.

With CC430 chip including Automatic Clear Channel Assessment that uses carrier sensing, it is arbitrary that the non-persistent carrier sensing should be used.

====Network Layer====

- Description

- Significance

=== Packet Format ===

- Photo/Table of the packet

- Size and limitation of the packet

- Description of each byte in the packet

== Deliverable Test Results ==

== Development Tools ==

=== Hardware ===

=== Software ===

==== Code Composer Studio ====

- TI Compiler version

==== SmartRF Studio ====

- Used in RX/TX dBM measurement and RF configuration register generation

- Provide a quick description of how to use this tool for readers

=== Related documentation ===

== Application Development Guide ==

=== Typical Program Flow ===

=== Code Explanation ===

'''Code walk-through for various layers'''

=== Predefined Definitions ===

''' What they are for, why they exist, when to use them'''

=== Usage Scenarios ===

=== Migration Advice ===

- How to port code from this project to other MCU architectures

== Reflection and Improvement ==

== Reference ==

Projects:2015s1-40 Flexible ad-hoc Network A: Physical Layer

2015-10-04T08:12:28Z

A1627539: /* Link Layer */

== Introduction ==

=== Overview ===

==== Project Team ====

Cong Nguyen

Duncan Lawry

==== Supervisors ====

Michael Liebelt

Braden Phillips

=== Significance ===

Ad-hoc wireless networks are self-configurable networks with high node mobility, allowing them to function without reliance on any fixed infrastructure. This makes wireless ad-hoc networks useful for quick communication channel deployment suitable for all applications.

While there are already many existing commercial solutions with ad-hoc capability such as [http://www.zigbee.org/ ZigBee], [https://developer.bluetooth.org/TechnologyOverview/Pages/PAN.aspx Bluetooth Personal Area Network (PAN)] and Wi-Fi based ad-hoc configurations ([http://windows.microsoft.com/en-au/windows/set-computer-to-computer-adhoc-network Windows], [https://support.apple.com/kb/PH13796?locale=en_US MacOS], [https://wiki.debian.org/WiFi/AdHoc Linux (Debian)]) these solutions are generally costly in terms of processing power, memory requirement due to reliance on existing protocol stack or costly in terms of royalty. Furthermore, they are commonly reliant on the ISM 2.4GHz band, making them unsuitable for high-range applications without having to invest on a larger antenna which can increase power requirement and a product's physical size.

This project aims to develop an ad-hoc network stack with low processing power and low memory requirement by developing customized protocol layers operating in ISM sub-1GHz frequency for long communication distance and free usage, while provide high reliability and robustness.

=== Objectives and Deliverables ===

This project involves the development of the hardware abstraction layer (HAL), physical layer, link layer and network layer of a wireless ad-hoc network. In usage, data can be provided to the protocols via systems attaching to the protocol stacks or through an application on the microcontroller running the network stack itself.

At the end of this project, the developed ad-network will be flexible in configuration, providing reliable and modest data transfer rate over 100 metres. This means:

1. The network will be self-configuring, independent of external networking infrastructure

2. The network must scale efficiently from 2 to 50 or more nodes

3. The network must work well in both dense and sparse clusters

4. Packet delay should be as low as possible

5. There must be error-checking on multiple levels at the node

6. Node antennas must have a range of over 100 metres.

7. The network must support unicast and if time permits, multicast operation.

8. Each node should consume as little power as possible

== High Level Overview ==

=== Background ===

'''Ad-hoc Topology'''

An ad-hoc network can be classified into various classifications based on the communication type, topology and node configurations. Depending on the communication type, a network can be classified as single-hop or multi-hop ad-hoc network. In a single-hop network, all nodes are in range of each other and can communicate directly. In a multi-hop network, not all nodes are in reach of each others and need to communicate via a node in between - thus hops.

An ad-hoc network can also be classified by topology. The two major classifications are flat and hierarchical. In a flat ad-hoc nework, all nodes carry the same responsibilities. This means there are no admin nodes and that each nodes performs the same functionality. On the contrary, hierarchical ad-hoc networks consist of clusters of nodes representing individual networks but are all linked together. In a hierarchical network, master nodes exists and area responsible for passing data between clusters.

Lastly, an ad-hoc network can be classified based on its node configuration: homogeneous or heterogeneous. In homogeneous newtorks, all nodes have the same hardware and characteristics (processor, memory, peripheral devices, etc.). Wireless sensor network is a typical example of a homogeneous network. In a heterogeneous network, nodes differ in hardware configurations and thus cannot provide the same services.

This project is focused on implementing a flat, multi-hop and homogeneous network.

'''Addressing schemes'''

The focus of this project is to provide a robust and reliable unicast and broadcast routing ([https://en.wikipedia.org/wiki/Unicast#Addressing_methodologies Addressing methodologies]). If time permits or for future project groups, multicast can be added.

=== Layers ===

When it comes to code organization, we employs the [https://en.wikipedia.org/wiki/OSI_model OSI model]. In this project, the lower three layers are implemented: physical layer, link layer and network layer.

While implementing individual layers may lead to increased memory use due to duplicated buffers on various layers, it was chosen to specifically not to use cross-layer implementation as we wanted to:

* Use abstraction to simplify the development process
* Allow higher layers to be ported to other platforms as technology improves
* Allow lower layers to be used easily without higher layers as to customized to use in smaller microcontrollers, projects that does not require extra complexity of higher layers, etc.

====Hardware Abstraction Layer====

The hardware abstraction layer (HAL) implements functions that set up the MSP430 core hardware such as clocks, GPIO, UART, etc. This layer allows higher layers in the stack to have access to the hardware through a simple and portable abstraction API regardless of the underlying hardware. By default, the HAL initializes the MSP430 modules to the following settings:

* GPIO - All pins defaults to outputs with an output value of 0, with the exception of:
** P1.0: red LED on-board
** P1.1: input button with internal pull-up resistor (active low)
** P1.5, P1.6: UART Tx and Rx
** P5.0, P5.1: low-frequency watch crystal ACLK source

* Clocks
** MCLK: 25 MHz
** SMCLK: 25 MHz
** ACLK: 32768 Hz (external watch crystal frequency)

* UART
** Baud: 115200 (configurable with predefined symbols, ranging from 115200 to 921600)
** Data: 8 bits
** Parity: none
** Stop: 1 bit
** Flow control: none
** Hardware Rx interrupt disabled by default

* Timers
** Timer0_A0 is reserved for Link Layer operation

The HAL layer also includes ''fputs()'' and ''fputc()'' functions that overrides default ''stdio.h'' functions, allowing developers to use ''printf()'' seamlessly through UART in their applications.

====Physical Layer====

The Physical Layer deals with the physical connectivity between nodes. It set up the CC430 RF module's configuration registers, PA table, node address, as well as include some abstraction functions used in transmitting and enabling/disabling various settings of the RF module.

Various RF configurations are included with Olimex's examples that could be used readily with the physical layer implemented, allowing the physical layer's transfer rate to vary between 38.4k baud and 250k baud, as well as being able to transmit with output power settings from -30dBm to +8dBm.

These settings are configurable using predefined symbols.

====Link Layer====

With the wireless medium being tightly controlled, most wireless ad-hoc network applications operates in the ISM band, which is free from licensing. This means that there is limited channel bandwidth, much less than that of a wired network. Additionally, being wireless, there are many factors that can degrade the quality of the signal, such as noise and interference from other sources.

The Link Layer, sometimes referred to as a MAC layer, involves the functions and procedures to transfer data between two or more nodes in-range of the network. Its primary responsibility is to ensure that data is correct before the user application has access to them and discard incorrect data as it receives.

Furthermore, for data transmission utilizing multi-hop, a link layer must also facilitates safe-guards against [https://en.wikipedia.org/wiki/Hidden_node_problem hidden-] and [https://en.wikipedia.org/wiki/Exposed_node_problem exposed-] terminal problems.

Link Layer protocols commonly used in embedded systems belongs to the ''contention-based'' classification. This means that they are aware of the risks of collisions of transmitted data, while ''contention-free'' protocols commonly used in mobile phone networks, are more applicable to static networks with centralized control.

Utilizing a single channel with limited hardware processing power and aimed to be low power, two implementations of the link layer exists in the project: pure ALOHA and FAMA-NCS.

* '''Pure ALOHA'''

Pure ALOHA protocol is classified as a contention-based protocol categorized in the ''random-access'' scheme. In this protocol, a node may transmit as soon as it is ready. It is suitable for low-load systems with a large number of potential senders.

As the CC430 chip used supporting Automatic Clear Channel Assessment on-chip [http://www.ti.com/product/cc430f5137 CC430F5137] (Listen-before-talk), the pure ALOHA implementation is basically the physical layer implementation with extra address checking and buffers, ensuring that it conforms with the Link Layer interface.

* '''FAMA-NCS'''

FAMA-NCS stands for ''Floor Acquisition Multiple Access'' with ''Non-persistent carrier sensing'' ([http://link.springer.com/article/10.1023%2FA%3A1019146831447 Specification]), where ''floor'' stands for ''channel''. It is a MACA-based scheme that makes announcements before it sends data to inform other nodes to be silent. Unlike MACA protocols, FAMA protocols require collision avoidance to be performed at both the sender and receiver nodes.

To acquire the floor (channel), the sending node sends out a ''Request-to-Send (RTS)''. The receiver responds with a ''Clear-to-Send (CTS)'' back to the transmitter. Any nodes overhearing this CTS packet knows the station has acquired the floor. CTS packets are repeated long enough for the benefit of any hidden sender did not register another node's RTS.

====Network Layer====

- Description

- Significance

=== Packet Format ===

- Photo/Table of the packet

- Size and limitation of the packet

- Description of each byte in the packet

== Deliverable Test Results ==

== Development Tools ==

=== Hardware ===

=== Software ===

==== Code Composer Studio ====

- TI Compiler version

==== SmartRF Studio ====

- Used in RX/TX dBM measurement and RF configuration register generation

- Provide a quick description of how to use this tool for readers

=== Related documentation ===

== Application Development Guide ==

=== Typical Program Flow ===

=== Code Explanation ===

'''Code walk-through for various layers'''

=== Predefined Definitions ===

''' What they are for, why they exist, when to use them'''

=== Usage Scenarios ===

=== Migration Advice ===

- How to port code from this project to other MCU architectures

== Reflection and Improvement ==

== Reference ==

Projects:2015s1-40 Flexible ad-hoc Network A: Physical Layer

2015-10-04T07:00:27Z

A1627539: /* Layers */

Projects:2015s1-40 Flexible ad-hoc Network A: Physical Layer

2015-10-04T06:53:50Z

A1627539: /* Layers */

Projects:2015s1-40 Flexible ad-hoc Network A: Physical Layer

2015-09-29T23:01:02Z

A1627539: /* Background */

Projects:2015s1-40 Flexible ad-hoc Network A: Physical Layer

2015-09-29T22:54:59Z

A1627539: /* Physical Layer */

Projects:2015s1-40 Flexible ad-hoc Network A: Physical Layer

2015-09-29T22:54:01Z

A1627539: /* Hardware Abstraction Layer */

Projects:2015s1-40 Flexible ad-hoc Network A: Physical Layer

2015-09-29T22:53:43Z

A1627539: /* Hardware Abstraction Layer */

Projects:2015s1-40 Flexible ad-hoc Network A: Physical Layer

2015-09-29T22:52:27Z

A1627539: /* Physical Layer */

Projects:2015s1-40 Flexible ad-hoc Network A: Physical Layer

2015-09-29T22:06:56Z

A1627539: /* Application Development Guide */

Projects:2015s1-40 Flexible ad-hoc Network A: Physical Layer

2015-09-29T22:05:24Z

A1627539: /* Detailed Design */

Projects:2015s1-40 Flexible ad-hoc Network A: Physical Layer

2015-09-29T22:04:35Z

A1627539: /* High Level Implementation */

Projects:2015s1-40 Flexible ad-hoc Network A: Physical Layer

2015-09-29T22:04:20Z

A1627539: /* High Level Design */

Projects:2015s1-40 Flexible ad-hoc Network A: Physical Layer

2015-09-29T22:03:59Z

A1627539: /* Hardware Abstraction Layer */

Projects:2015s1-40 Flexible ad-hoc Network A: Physical Layer

2015-09-29T21:45:42Z

A1627539: /* Objectives and Deliverables */

Projects:2015s1-40 Flexible ad-hoc Network A: Physical Layer

2015-08-23T11:14:37Z

A1627539: /* Layers */

Projects:2015s1-40 Flexible ad-hoc Network A: Physical Layer

2015-08-21T13:53:53Z

A1627539: /* High Level Design */

Projects:2015s1-40 Flexible ad-hoc Network A: Physical Layer

2015-08-21T13:43:49Z

A1627539: /* Introduction */

Projects:2015s1-40 Flexible ad-hoc Network A: Physical Layer

2015-08-21T13:15:43Z

A1627539: /* High Level Design */

== Introduction ==

=== Overview ===

- Project name

- Supervisors

- Group members

=== Significance ===

Comparison with other technologies

- Why we're rolling out our own

=== Objectives and Deliverables ===

- Objective

- Deliverable

== High Level Design ==

(basically the proposal document and v0.1 SDD)

=== Layers ===

'''Hardware Abstraction Layer'''

'''Physical Layer'''

- Description

- Significance

'''Link Layer'''

- Description

- Significance

'''Network Layer'''

- Description

- Significance

=== Packet Format ===

- Photo/Table of the packet

- Size and limitation of the packet

- Description of each byte in the packet

== Detailed Design ==

- Describe the inner working of each layer, include flowcharts and global/important variables

=== Physical Layer ===

=== Link Layer ===

=== Network Layer ===

== Development Tools ==

=== Hardware ===

=== Software ===

==== Code Composer Studio ====

- TI Compiler version

==== SmartRF Studio ====

- Used in RX/TX dBM measurement and RF configuration register generation

- Provide a quick description of how to use this tool for readers

=== Related documentation ===

== Application Development Guide ==

=== Main Program Design Guide ===

=== Code Convention ===

=== Code Explanation ===

'''Code walk-through for various layers'''

=== Predefined Definitions ===

''' What they are for, why they exist, when to use them'''

=== Usage Scenarios ===

=== Migration Advice ===

- How to port code from this project to other MCU architectures

== Reflection and Improvement ==

== Reference ==

Projects:2015s1-40 Flexible ad-hoc Network A: Physical Layer

2015-08-12T13:23:51Z

A1627539:

== Introduction ==

=== Overview ===

- Project name

- Supervisors

- Group members

=== Significance ===

Comparison with other technologies

- Why we're rolling out our own

=== Objectives and Deliverables ===

- Objective

- Deliverable

== High Level Design ==

(basically the proposal document and v0.1 SDD)

=== Layers ===

'''Physical Layer'''

- Description

- Significance

'''Link Layer'''

- Description

- Significance

'''Network Layer'''

- Description

- Significance

=== Packet Format ===

- Photo/Table of the packet

- Size and limitation of the packet

- Description of each byte in the packet

== Detailed Design ==

- Describe the inner working of each layer, include flowcharts and global/important variables

=== Physical Layer ===

=== Link Layer ===

=== Network Layer ===

== Development Tools ==

=== Hardware ===

=== Software ===

==== Code Composer Studio ====

- TI Compiler version

==== SmartRF Studio ====

- Used in RX/TX dBM measurement and RF configuration register generation

- Provide a quick description of how to use this tool for readers

=== Related documentation ===

== Application Development Guide ==

=== Main Program Design Guide ===

=== Code Convention ===

=== Code Explanation ===

'''Code walk-through for various layers'''

=== Predefined Definitions ===

''' What they are for, why they exist, when to use them'''

=== Usage Scenarios ===

=== Migration Advice ===

- How to port code from this project to other MCU architectures

== Reflection and Improvement ==

== Reference ==

Projects:2015s1-40 Flexible ad-hoc Network A: Physical Layer

2015-08-12T13:16:55Z

A1627539:

== Introduction ==

=== Overview ===

- Project name

- Supervisors

- Group members

=== Significance ===

Comparison with other technologies

- Why we're rolling out our own

=== Objectives and Deliverables ===

- Objective

- Deliverable

== High Level Design ==

(basically the proposal document and v0.1 SDD)

=== Layers ===

'''Physical Layer'''

- Description

- Significance

'''Link Layer'''

- Description

- Significance

'''Network Layer'''

- Description

- Significance

=== Packet Format ===

- Photo/Table of the packet

- Size and limitation of the packet

- Description of each byte in the packet

== Detailed Design ==

- Describe the inner working of each layer, include flowcharts and global/important variables

'''Physical Layer'''

'''Link Layer'''

'''Network Layer'''

== Development Tools ==

=== Hardware ===

=== Software ===

'''Code Composer Studio'''

- TI Compiler version

'''SmartRF Studio'''

- Used in RX/TX dBM measurement and RF configuration register generation

- Provide a quick description of how to use this tool for readers

'''Related documentation'''

== Application Development Guide ==

=== Main Program Design Guide ===

=== Code Convention ===

=== Code Explanation ===

'''Code walk-through for various layers'''

=== Predefined Definitions ===

''' What they are for, why they exist, when to use them'''

=== Usage Scenarios ===

=== Migration Advice ===

- How to port code from this project to other MCU architectures

== Reflection and Improvement ==

== Reference ==

Projects:2015s1-40 Flexible ad-hoc Network A: Physical Layer

2015-08-12T13:16:04Z

A1627539:

== Introduction ==

=== Overview ===

- Project name

- Supervisors

- Group members

=== Significance ===

Comparison with other technologies

- Why we're rolling out our own

=== Objectives and Deliverables ===

- Objective

- Deliverable

== High Level Design ==

(basically the proposal document and v0.1 SDD)

=== Layers ===

'''Physical Layer'''

- Description

- Significance

'''Link Layer'''

- Description

- Significance

'''Network Layer'''

- Description

- Significance

=== Packet Format ===

- Photo/Table of the packet

- Size and limitation of the packet

- Description of each byte in the packet

== Detailed Description ==

- Describe the inner working of each layer, include flowcharts and global/important variables

'''Physical Layer'''

'''Link Layer'''

'''Network Layer'''

== Development Tools ==

=== Hardware ===

=== Software ===

'''Code Composer Studio'''

- TI Compiler version

'''SmartRF Studio'''

- Used in RX/TX dBM measurement and RF configuration register generation

- Provide a quick description of how to use this tool for readers

'''Related documentation'''

== Application Development Guide ==

=== Main Program Design Guide ===

=== Code Convention ===

=== Code Explanation ===

'''Code walk-through for various layers'''

=== Predefined Definitions ===

''' What they are for, why they exist, when to use them'''

=== Usage Scenarios ===

=== Migration Advice ===

- How to port code from this project to other MCU architectures

== Reflection and Improvement ==

== Reference ==

Projects:2015s1-40 Flexible ad-hoc Network A: Physical Layer

2015-08-03T06:01:26Z

A1627539:

== Introduction ==

=== Overview ===

- Project name

- Supervisors

- Group members

=== Significance ===

Comparison with other technologies

- Why we're rolling out our own

=== Objectives and Deliverables ===

- Objective

- Deliverable

== High Level Design ==

(basically the proposal document and v0.1 SDD)

=== Layers ===

'''Physical Layer'''

- Description

- Significance

'''Link Layer'''

- Description

- Significance

'''Network Layer'''

- Description

- Significance

=== Packet Format ===

- Photo/Table of the packet

- Size and limitation of the packet

- Description of each byte in the packet

== Detailed Description ==

- Describe the inner working of each layer, include flowcharts and global/important variables

'''Physical Layer'''

'''Link Layer'''

'''Network Layer'''

== Development Tools ==

=== Hardware ===

=== Software ===

'''Code Composer Studio'''

- TI Compiler version

'''SmartRF Studio'''

- Used in RX/TX dBM measurement and RF configuration register generation

- Provide a quick description of how to use this tool for readers

'''Related documentation'''

== Application Development Guide ==

=== Main Program Design Guide ===

=== Code Convention ===

=== Code Explanation ===

'''Code walk-through for various layers'''

=== Predefined Definitions ===

''' What they are for, why they exist, when to use them'''

=== Usage Scenarios ===

=== Migration Advice ===

- How to port code from this project to other MCU architectures

== Reflection and Improvement ==

Projects:2015s1-40 Flexible ad-hoc Network A: Physical Layer

2015-08-03T05:16:45Z

A1627539: Created page with ""Look at my wiki, it's the best" - Jack McLean, 2015"

"Look at my wiki, it's the best" - Jack McLean, 2015