12.12.14 Experiment

[ppyordanov]

The experiment today lasted about two hours and was conducted on the premises of the university campus. The process of populating the map on the server has started:

http://178.62.100.239/

Before proceeding to the experiment data, an important note to make is that I updated the SCK case. The container that was previously used to store and carry it around obstructed almost every sensor on the board:

• temperature , noise, solar panel, air (due to the micro-climate environment that is present in the box)

I decided to improve the sensor accuracy and reliability by modifying the case and created my own version that would still be easy to carry around and protect the board but would also uncover the vital sensors that are going to be used for this project (the noise detector as well as the CO and NO2 chips). What I did was to use a similar food storage container. I cut a circular hole in the lid so that air could flow freely as well as avoid sound wave obstructions. I also poked a hole for the attachment string to go through:

I then charged the SCK battery and tested the wi-fi connectivity on my network once more to make sure that everything is functioning properly as the kit seemed to lose connection quite often when moved around:

• SCK turned off:

• SCK charging & connecting:

Finally I placed the whole assembly in the container using the vibration protective foam from the previous configuration and sealed the whole unit with some duct tape as seen on the photos below:

Placing the SCK in the container careful not to obstruct any sensors with the protective foam. The air inflow is not hindered in any way. Another ventilation hole can be added on the other side or diagonally to improve this further, although this will pose a more serious hazard if using in a rainy weather:

• Assembly side view:

• Assembly top view:

• Assembly close-up view showing that the top board sound and air sensors have direct access to surrounding environment:

Here is some information on how the experiment was conducted and what results were observed.

To start with, there were some issues before tracking started as the Smart Citizen Kit did not update its sensor readings and was repeatedly sending the same data to the server. Its sensors just stopped working due to the cold weather, although this is just an assumption (based on the fact that the thermometer was constantly showing -30 C). I had to go back to reconfigure the whole system and after resetting the kit and making sure it works as expected and transmits data on a regular time interval I connected to my portable access point network and resumed the experiment.

Different temporal windows were used to see how the Android client behaves and what output it transmits to the server (an initial window of 60 seconds was used for the first couple of routes, then it was reduced to 30 and 10 seconds accordingly). About 15 different routes were recorded around the university campus during the whole test duration:

The server is displaying aggregated data. Different routes can be clearly distinguished:

• Overview of all routes on the campus map:

• A close-up view showcasing parts of 3 different routes:

In the screenshots above it becomes clear how wi-fi network latency and delays have influenced transmission time. I experimented moving with different speed. Walking slow and fast as well as riding a bicycle with different speeds to check how the output will vary and was continuously monitoring the system via the probing details that are displayed on the screen while tracking. I would also check the route view on the Android device as well as on the server immediately after recording each route.

Note: Client-server data transmission is configured in the following way: once the user stops tracking a route, the route geo-location data along with the context data retrieved from the SCK is automatically transmitted to the server and becomes visible immediately. A consideration is to add an upload button as it was in version 1.2 so that the user can choose when and which routes/ tracking sessions to actually upload.

Some notes regarding performance: the accuracy of the GPS sensor embedded in the mobile device used (Nexus 7) started varying which caused some fluctuations in the data output as it can be seen on the screenshots. This variance needs to be addressed and I suspect it would be directly related to the delay involved in the SCK updates retrieval process (as GPS reading intervals are directly tied to reading SCK's sensor data). I will make amendments to the Android application, recompile it and check whether this will help to improve the accuracy.

[ppyordanov]

This task has been completed and can be closed now.