Overall, our prototype only serves as a preliminary model for what could eventually be implemented on a college campus. There are several aspects of this prototype that can be improved upon further testing and evaluation.

Bike Nodes

The prototype we designed was not physically implemented on a bike. We did not physically implement the design because we do not want to use the photo-sensor on the MDA100 in the implementation design. In our brain-storming session, we decided a mechanical snapaction switch located in the lock of the bike would be the best way to implement the design. Some examples of adequate snap-action switches are displayed in Figure 11. The mechanical switch would send a signal indicating the state of the lock. Because the lock only has two possible states, the switch allows us to not use data processing for detection, and thereby conserves energy.

Figure 1: Examples of snap-action switches. These various types of miniature snap-action switches could simplify our proposed design of the bike nodes as well as improve energy efficiency.

The code we implemented for the bike nodes refers to an event when the base station sends an unlocking code to a bike. In the case where the data packet with an unlock code is not properly sent, it could cause the bike node to refuse to unlock when it should. This state can only be resolved when the base station resends the data packet. Although it seems to be a rather insignificant delay for one bike, this could be problematic when the system is scaled up to include 100 bikes. We would like to look into the idea that locking/unlocking could be a state variable for changing from the base station side, and the state of the lock can be changed automatically. This design is simple in terms of coding, but requires a much more powerful bike lock as the state of the lock is changed mechanically using electric control. This also opens up the potential of adding a dynamo to the bike for power sustain.

Figure 2: A Shimano dynamo. The Shimano dynamo is capable of generating electrical energy when the bike is being pedaled. This component would increase the self-sustainability of each bike at the cost of a more expensive unit price.

Hub Nodes and Relay Nodes

A potential improvement for the relay nodes is an algorithm that solves the number and placements of various relay nodes. When we designed the top-level node placements, we did not have a concrete idea of how many nodes we should place. The top-level design shown in Figure 3 is an estimation based on the number of bike stands we have seen around campus.

Figure 3: 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.

The project can benefit greatly from extensive testing to determine the maximum distances the hub nodes and relay nodes can reach in all types of weather conditions. This would be great when the project can be implemented to other campuses or communities.

Base Station

The base station handles the receiving and sending of data stream from all of the nodes. We wish to fully incorporate the data stream into a complete functional application. The Java code we worked on is rather simple, as it only provides basic functionality. To further develop the prototype, we could benefit from a Java GUI. At the back end, a user database should be included as well. These additions would allow us to build a simple mobile application.

Miscellaneous Potential Extensions

The design of this bike sharing wireless sensor network allows for the potential to triangulate the location of a bike using the nodes surrounding the bike. Though our design provides a general location of a bike, a more precise localization of a bike would be helpful for both a user and the administrator of the program. A more precise location of a bike allows a user to easily identify an available bike. This function would also aid an administrator of the program to find a bike that needs service, whether that service is changing a battery in the mote, fixing a problem a user reported, or moving the bike to a more optimal location for its use.

We would also have liked to design our own protocol for this program to optimize energy efficiency. The protocol we used, XMesh, is functional enough; however, we would have liked to explore other options that could optimize the use of energy for our system, specifically. For example, there is a protocol called S-MAC that causes the transmitter to sleep periodically because although a radio may not be actively transmitting or receiving when awake, it is always actively listening for a signal.

These are just a few ideas of how our design could be improved upon. There are many other potential applications for the data collected by the nodes in our design.