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 traﬃc 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.
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.
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 eﬃcient 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 satisﬁes the requirements of a sensor network. As a programming language, nesC supports and reﬂects 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 ﬁles describing the behavior of the application. In Figure 4, we exhibit a folder containing the code for bike nodes. Besides the typical Makeﬁle documents, there are two ﬁles. BikeNode.nc uses conﬁgurations by wiring them using a wiring syntax. BikeNodeM.nc is the module where the conﬁguration and module behaviors are deﬁned. Photo.nc and PhotoM.nc are existing interfaces provided by the TinyOS source ﬁle that utilizes the photo-sensor on the MDA100 sensor board.
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.
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.
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.
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 speciﬁes the detailed content of the message; the payload which contains the main message; and the conﬁrmation 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 diﬀerent number code between its users. This lock should work similarly to the Ofo lock shown in Figure 7.
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.
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 conﬁgurations 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.
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.
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 ﬁred.
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 diﬀerent 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 . 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.
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.
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.