Process of Bus Tracker

In terms of API for bus information. We managed to receive an API key from the PRT and start with the information provided. Among these we found that route data or vehicle locations might be useful. Also we tested with the web hook from prt to see how the API works.

When started to test with data from multiple routes and couldn't visualize the data in a legible way, as the indicators would get more complicated. So you went back to the one route solution. We chose to hook our argon with the data of prediction time for inbound bus route 61D at Forbes & Morewoods that takes all of the team members back to residence in Oakland from campus.

Below is the photo showing the process of testing the bus tracker on serial print monitor. We started with mapping the maximum brightness of the LEDs using the prediction time into the range of 255-100, meaning when the bus is almost there it would be fully on in red, when it is far away it would be a dim blue light. But it appears that the dim part of yellow and blue is not really seen. So we chose to map the brightness of each LED using its time within its range of loop. In that case the brightness is more obvious in every time range. 

We also found that the the analogWrite() could not turn the LED completely off and found some clear explanation on the Arduino Reference Page:

The PWM outputs generated on some pins will have higher-than-expected duty cycles  ... and may result in a value of not fully turning off the output. [5]

On argon the duty-cycle of each PWM group is not stated clearly, judging from the fact that the red LED is brighter than D4 and D6, D2 has a higher duty-cycle than the D4 and D6 pins. To solve this it would be necessary to add a digitalWirte( ledPin, LOW) to make sure that the LEDs are completely turned off when the loop finishes. But from a perspective of ambient display, what's the harm of a LED that is almost off? It might demonstrate a status without catching too much attention.