There are four parts to our wireless sensor network. Sensor nodes, also known as motes in North America, are nodes capable of collecting and processing sensory information. In our wireless sensor network, sensor nodes are also able to communicate with other connected nodes in the network. We plan to install a mote on every bicycle in the bike sharing program.

Furthermore, hub nodes should be installed at every bike parking lot on campus. These hub nodes are the second part of the network. The hub node is the fundamental unit for this bike sharing program. The hub has two functions. The hub can detect the identity of each bike present within its range and capture the signal that represents the locking and unlocking of each bike. The hub can also communicate with other hubs and/or the base station to distribute and update information across the network.

The third part of the network is the base station, where all the data is collected. The base station is directly connected to a computer. The base station handles the traffic of bike rentals by updating the information of available bikes and assigning available bikes to users. A model of the network with one single hub is shown in Figure 1.

Figure 1: An overview of the proposed bike sharing network. This model of a how our bike sharing network operates on a high level. Bike nodes will transmit data exclusively with the hub nodes when the bike nodes are in park mode. Hub nodes send, receive, and relay data to the base station either directly or through other hub nodes. In the case where a hub node is too far away from another hub node, a relay node is used to communicate in order to connect the hub to another hub or the base station so that the information is relayed to the place it needs to be received.


In Figure 1, the model consists of four main components: the bikes with the motes attached, the hub for collecting and transmitting data, and the PC for monitoring and code implementation. In the model, the motes communicate with the hub via radio communication. The hub communicates with the PC using UART (universal asynchronous receiver/transmitter) communication.

Lastly, due to range limitation of hub motes, routing motes are required to bridge two hub motes that are too far away from each other. These motes do not need to collect sensory data; instead, their function is to pass packets between two or more hubs. A top level design we suggest for the Danforth Campus can be seen in Figure 3.

Figure 2: Proposed top level design of bike sharing program using wireless sensor networks for the Danforth campus, including the South 40. The blue dots represent where we propose hub motes should be located, which are bike stand locations; the yellow dots represent the areas we suggest router motes should be installed so that hubs can communicate information to hubs that would otherwise be out of range.

In Figure 2, we are suggesting that 73 motes be installed on the Danforth campus; we suggest 46 hub nodes be installed at all the bike parking locations on campus and 27 motes to be installed as relay nodes in areas between long distances of hub nodes. In Figure 3, the blue nodes labeled 1-46 indicate hub nodes; the yellow nodes labeled 47-73 indicate relay nodes. The blue node labeled GW (gateway) represents a base station located in Lopata Hall.


Sensor networks typically require a small physical size and low power consumption. This means software must make efficient use of the hardware, i.e. processor and memory. The nodes in the system we have designed run on TinyOS, an operating system designed for low-power wireless embedded systems. TinyOS is used because traditional operating systems are not suitable for wireless sensor networks. The various nodes implemented in the system are programmed in nesC, a dialect of the C language. TinyOS has an event driven architecture that satisfies the requirements of a sensor network. As a programming language, nesC supports and reflects the design of TinyOS. nesC extends the function of the C language by supporting components that provide and use various interfaces (similar to traditional C functions).

In a TinyOS application, there are usually two or three files describing the behavior of the application. In Figure 4, we exhibit a folder containing the code for bike nodes. Besides the typical Makefile documents, there are two files. uses configurations by wiring them using a wiring syntax. is the module where the configuration and module behaviors are defined. and are existing interfaces provided by the TinyOS source file that utilizes the photo-sensor on the MDA100 sensor board.

Figure 3: TinyOS application folder. This is an example of a TinyOS application folder. This is the folder we used for coding the bike nodes. The seven files in this folder enable the application that runs on the bike nodes. We programmed the first four files; the rest of the files were included to complete the functionality of the application.

Additionally, we will run some Java code on the base station computer. The Java code reads from the input data stream on the serial port and makes changes accordingly on the back end of the bike sharing program.

Bike Nodes

For our prototype, we are using a 2.4GHz MPR2400 MICAz mote (shown in Figure 4) on both bike nodes and hub nodes. The sensor nodes will be equipped with an MDA100 sensing board. MICAz is a versatile model ideal for designing and prototyping for this program. Using its large prototyping area we can implement the sensor design on the MDA100 sensing board and connect it to MPR2400 MICAz using the 51-pin bus. For an actual usable prototype, a MICA2DOT microsensor mote or a TinyNode mote might work better.

Figure 4: MPR2400 MICAz mote. A MICAz mote will be attached to each bike in the bike sharing program. Others will be used as hub nodes and relay nodes, located at various parts of campus.

Figure 5: MDA100 sensor board. An MDA100 sensor board will be attached to each sensor mote.

For the actual model, a mechanical sensor must be built into the lock to detect the state of the lock. In the prototype, we are using a light sensor built onto the MDA100 sensor board. The presence/absence of light will be used to simulate the action of locking and unlocking a bike.

The MICAz mote is appropriate for the hub motes, however, it is a bit bulky and unseemly to put on a bike. In a more ideal application, we suggest using a much smaller mote, such as the MICA2DOT. A size reference of the MICA2DOT can be seen in Figure 6.

Figure 6: MICA2DOT microsensor mote. The MICA2DOT microsensor mote has the functionality of a mote and a sensor board on hardware the size of a nickel. In comparison, the size MICAz mote we are using for prototyping purposes is comparable to an Altoid tin.

Hub Nodes

Besides the motes that will be installed onto the bikes, we will also have motes installed at each bike parking site. These botes, also known as hub nodes, need to send data packets to the base station. There are four main components to the data packets. The TinyOS header determines the destination of the packet; the protocol header specifies the detailed content of the message; the payload which contains the main message; and the confirmation message which acknowledges the reception of the data packet. Another important function of the hub nodes is relaying the unlocking message to the bike nodes. The base station will send out a data packet containing a random integer data type that contains the new unlocking code for the lock. The lock should then be programmed to unlock when that unlocking code is pressed into the digital keypad. In theory, we would like the bikes be able to be unlocked using a different number code between its users. This lock should work similarly to the Ofo lock shown in Figure 7.

Figure 7: Ofo lock. Ofo is a Chinese company that is currently designing a bike lock with a digital key pad. For our project, we would like to use a lock of similar design. The digital key pad would be programmable via mote, and a mechanical sensor would be placed in the latch pit to determine the state of the lock.

Based on our preliminary tests, the motes can communicate with the hub within a range of 10m. For our model, we are using the photosensor on the MDA100 sensor board to exhibit the digital use of an analog sensor. However, in real application, a mechanical sensor would be put inside the lock to determine its state.

Relay Nodes

The main function of the relay node is to extend the range of hub nodes where hub nodes are separated by a large distance. Generally, the code for relay nodes has the same type of configurations as the code for hub nodes. However, the code for the relay nodes lacks the function to send and receive data packets fro bike nodes. The forwarding addresses of all the hub nodes and relay nodes are predetermined. This saves us the trouble of creating a routing algorithm for this project. In this project, all hub nodes and relay nodes have predetermined, stationary locations because the bike parking sites on campus have already been built and are stationary.

Base Station

The base station of this project is connected to a PC running Java code. The main purpose of the base station is to provide availability information regarding the bikes. The base station PC requires a USB port for the mote interface board (MIB); we are using the MIB520, shown in Figure 8. The Java code running on the base station has the potential to be developed further into a mobile application. As this is not the main focus of our project, we mainly want to ensure the code is able to update the number of bikes stored in an area. The base station should also be able to send messages to each hub, individually; the hubs can then pass messages to bike nodes.

In our code implementation, the base station prints the incoming data to the serial port. This data stream is then picked up by the Java application for parsing and analysis. In a separate class, Java assigns number codes randomly, and communicates back to the serial port. The new data is then picked up by the base station and forwarded to the hub nodes, where the hub nodes communicate with the bike nodes.

Figure 8: MIB520. The MIB520 is a mote interface board that provides USB connectivity to the MICAz motes. A MICAz mote can function as a base station with the MIB520.


There are two types of communication occurring in this project. During bike node to hub node communication, all data packets are transmitted one on one. The only focus during this phase of the communication is scheduling the bike nodes to send the sensor data to the hub nodes when the timer is fired.

During hub node to base station communication (including relay nodes), a multi-hop mesh networking protocol called XMesh is implemented. We chose a multi-hop protocol for two reasons: this protocol will reduce power consumption for individual motes as they can simply communicate to the nearest mote, and this protocol will allow motes at different parking locations to communicate with the base station as each hub can act as a relay node.

XMesh also provides acknowledgement for packet delivery on both ends. When the gateway node receives a packet, it sends an acknowledgement message to the node that sent it. If the source node fails to receive an acknowledgement message, it attempts to resend the packet [6]. This is crucial to our project because we prioritize the accuracy of the number of available bikes more than the speed in which they are being updated.

Packet Parsing

The raw data received from a single mote requires parsing on the software side. The structure of the data packets is detailed in Table 1.

Table 1: Structure of data packets

Within the data packet, the most important data to retrieve is sourceaddr and originaddr. These two packets will tell us the identity of the bike and the location of the hub that the data was sent from, respectively.