Network Everything Final project – Missing stuff finder, by Diana and Peter

Project Name: Missing Stuff Finder

Group member: Diana, Peter

Instructor: Scott


Note: The blue pencil case is the wireless stuff tracker, and the mysterious animal is only for being cute and fun


When we lose our phone, we usually make a phone call to find our phone. But when we can’t find our other stuff like a charger or an Arduino kit, we have no way to find where they are. Therefore, we decided to create something which functions similarly to a phone call. In this way, people can save much time when they need to find their lost stuff.


We designed that our system aims at dealing with the problems under the circumstances where someone misplaces their properties, and thus fails to find it quickly. This can be very annoying when someone is in a hurry, such as leaving for work or school in the morning. So, our system has the following parts:

Website: We create a website with several buttons on the page. People need to login their name first, then they can press the button on the page to make the hardware receivers play music.

Xbees: The Xbee hub will send commands to receivers when a button is pressed. The Xbee receivers will receive signals from the Xbee hub, and then ask the buzzer to play music, notifying where they are. People can stop the music by pressing the real button on the Xbee receivers. If they still cannot find the stuff even it is buzzing, they can also press the button on the web page to stop all the music.

Major Devices Utilized:

Arduino UNO: supports Xbees and Ethernet shields

Ethernet shields: holding websites

Xbees: including Xbee shields and antenna, consisting of a hub and three receivers

Communicating Protocols Covered:

Serial communication: sending commands from ethernet shield(server) to the laptop which runs a twitter API written in Python.

I2C: Supports the communication between the ethernet shield(server) and the Xbee hub.

Xbees (wireless serial communication): one to many communication between Xbee hub and all the receivers.

SPI: Supports the communication between the microcontroller on the Arduino UNO and the Ethernet chip.

Components: Functions, Problems, and Solutions.

Ethernet Shield (Serving website, sending commands to hub via I2C, send to Python script to track each user’s lost and found info)

We used the Ethernet shield to serve a website that controls the whole system. The ethernet shield communicates which both our laptop and the hub Xbee. In terms of the communication between the shield and the Xbee, the Ethernet shield(along with the Arduino UNO), reports user’s operation on the website to the hub Xbee via I2C. On the other hand, in terms of the communication between the ethernet shield and our laptop, there are two different communications happening. First, the laptop, as a client, requests the web page from the server, and interact with it. This part of the communication is based on the HTTP protocol on the application layer. Second, the laptop also listens to the serial port which connects to the arduino that is running the server. Each time the server realizes there is a “finding request” on the webpage, it will send to request and the username to laptop via serial communication. Once the python script which runs a twitter API on the laptop gets a command, it will post a message tracking the history of finding for each user.

We did have some big problems for this part, the first one is about the content of HTTP request. After the user testing on last Friday, we found that our checkboxes on the webpage could be confusing and misleading. So we replaced it with buttons. After the replacement, we couldn’t get the xbees responding correctly. It seemed that the server was not reading the HTTP_REQUESTs correctly. To be specific, the server was always reading both the current content in the “GET” message, and the previous one. After a long time of debugging, we realized that the reason is that we allowed the server to read the entire client request each time, and there was a part called “referrer” which records the previous content in the previous message. Therefore, we solved this problem by adding an upper bound to the length of the requests the server reads each time, avoiding the server from reading the unnecessary parts of message that could cause interference.

The second problem we had was on hardware, which was relatively simpler. Our initial plan was to stack the arduino, the Ethernet shield and the Xbee shield together, which would make a delicious hamburger of control center. However, we then find that this idea would not work. The truth is, the ICSP does cause problem in this case. It is true that the ICSP header doesn’t matter in terms of communication. However, it matters in terms of power supply. The Xbee shields gets it power right from the ICSP headers, and since there is no ICSP headers for Xbee on the Ethernet shield, we cannot stack them together. This is why we used another Arduino for the hub Xbee and used I2C to connect it with the ethernet part.


Note: Here is the control centre! The board with the blue ethernet cable is the ethernet shield, and the one with the silver cable is the Xbee hub. 

Xbee System

Our alarming and found system is essentially consist of a hub and several receivers (in our case, three). First, for the communication between the hub and the Arduino running an ethernet shield, we used I2C. We thought we could stack the Arduino, Ethernet shield, and the Xbee shield together like a hamburger, but it turns out that the Xbee gets power from ICSP, and there is not ICSP output headers provided for Xbee shield on Ethernet shields. Then, when the Xbee hub receives the message about which stuff the user is looking for, denoted by 0, 1, and 2, the Xbee broadcasts the message, in the format of “stuff_id + command” to all of the receivers (since it is a one to many communication). After that, the receivers, which are assigned a unique id each, decodes the message by basically subtracting their id off the message, and if the outcome reads “H”, the buzzer goes off, thus notifying the user where the missing stuff is. Finally, when the user finds the buzzing stuff, he or she can go there and press the  button on the stuff to turn it off (The user can also turn things off on the website, which triggers the hub to send an “L”, with the same encoding and decoding scheme). What’s more, the whole Xbee system runs on a program that implements state machine, therefore, the receiver switches between different states(e.g buzzing or silence) in order to avoid any interference that might occur. The biggest problem about the Xbee system is on flow control. The Xbees do have flow control algorithms built in them, but since their receiving buffers are bigger than those on the UNO, we had to add our own flow control in our arduino codes. Of course we didn’t use the flow control algorithm as TCP, which would be horrible. Our idea is instead, making sure that the receivers always read faster than the speed of sending. What’s more, each microcontroller should clear its buffer before switching from a state to another, thus avoiding the system to become messed up by the redundant messages left in the buffer (the redundant messages are created because multiple signals are sent for any single commands to deal with potential packet loss, since wireless is less stable.)


Note: Here comes the trackers, and their internal look. Again, the bear is just for being cute.


Considering the success rate of posting tweets,we didn’t use MKR1000 which runs with temboo. We chose an API offered by twitter and run it on our laptops. It can read data from serial, decode the data from Arduino to python, and then send tweets. But there are still several problems. First, you are not allowed to send the same tweets within around 24 hours. In order to solve this issue, we added a counter to it, incrementing it to record how many times a user has lost a certain stuff, and simultaneously avoiding creating duplicated tweets. But then we found that the counter wouldn’t restart from zero when we change to another user name. So we created a dictionary in Python to store all the user information, and solved this problem. After testing the API for several times, we found that the API would crush down when we login with “Diana”. It’s because in twitter, letter “d” (along with “F”, and “U”) are default shortcuts for directing message, follow or unfollow a certain person, and are thus reserved from API. To avoid the shortcut issue, we added “T_T” to the beginning of every tweet.

Screen Shot 2017-05-20 at 10.35.50

Note: the above is the result on the twitter account

Screen Shot 2017-05-20 at 10.35.36

Note: The above is the twitter API running in terminal.

Future Development & Takeaways

First of all, as what scott has suggested in class, having multiple “missing stuff” playing music all together might cause confusion, we think there are two approaches to deal with this. First, we could force that there can only be one device playing music at a time, which means that when the user is switching from one device to another without “shutting up” the previous device, that device will be turned off automatically before the second one go off. Actually, it was our original design, which can be implemented with only three more lines of codes. However, we then found that a user might want to find two stuffs at a time, and we then changed to adding the “give up” button which can turn off all the devices. Therefore, if we were to improvement on this part, we would take the second approach, that is, giving different devices different music, thus allowing users to differentiate each stuff from all the other.

Secondly, another improvement, a rather ambitious one, would be extending the system to broader use. At this moment, the system can only find the “temporarily missing stuff” within a certain range(about 30 meters), but people might want to find any of their belongings anywhere they want. This would require refinement in terms of at least two aspect. First, the server should be relocated. We would definitely need a online virtual server which can support actual multiple clients. Second, we can no longer rely on Xbees. In this “universal finding system”, every device needs to get online, report their location to the server.

In conclusion, we feel that the process of doing this project turns out to be a very rewarding experience. We get the chance to try out several relatively advanced communication protocols, ranging from HTTP(request and responses) between server and clients to Xbee one to many communication. Most of the communication approaches we picked were actually the ones in which we were interested, but not entirely confident with. Therefore, after doing this project, we feel that we gained a solid and comprehensive understanding of building and appreciating networks in modern context, which is truly a satisfying closure for our valuable experience in this exciting class over the semester.

Thank you for reading, now that’s see the video demo:


Web server:

Xbee hub:

Xbee receiver:

Python twitter API:

Note: I am only posting the script that calls the twitter post function, which also keep track of each user’s information. In terms of the twitter post script itself, it was provided by twitter, you can find it on the website of twitter API or on github.

Leave a Reply