The Shuttles Project launch was a big hit in our building. Our Android and iOS apps had over 200 combined downloads in the first month of the official publication by just word-of-mouth without any commercial promotion.
A user from another company in the building came to our floor to report an app problem on his new Android phone. He told us the app was so ingrained in his office routine that he couldnt come to work without it! We found the problem was caused by a new Android firmware over-the-air (FOTA) update from Google released the day before. The problem was fixed quickly, and the user was happy again.
On the other hand we saw some problems with the device we were using for the initial launch:
Logistics: The logistics for the drivers was not working well with the device we had chosen. The Queclink device was not well-secured in the cab, so it floated around various places and often got in the way.The device was being powered by the 12-volt receptacle in the cab and had a battery that powered it for a time after the ignition was was turned off. However, the battery in the device did not make it through the entire night, and unfortunately the Queclink device needed a manual power-on button press after losing power. The drivers have enough to do without trying to remember to do that every day.
Location: The Queclink device supported only 5Hz GPS location samples. This meant that it couldonly obtain location once each 5 seconds. That could work for many applications, but in the case of a shuttle thatis traveling relatively short distances, this wouldbe a problem. The riders wanted to know where the shuttle waswith greater accuracy than 5 seconds.
Extended Information: Our riders wanted to know not just where the shuttle is now but where it is headed. Is it headed toward them or away from them? The property managers wanted to know if the drivers are driving safely. Are there a lot of excessive braking, acceleration, and turning? The Queclink device didnot support any of this information.
Protocol: The Queclink device only supported 2G access with TCP protocol rather than 3G with UDP protocol. For connectivity over 2G cellular, TCP couldtrigger re-transmissions that can introduce additional delays and cellular connectivity costs.User experience suffered because many riders were using the shuttle app to time their arrival time at the pickup locations. The delay in location update caused some users to miss their rides.
We decided to make a change and selected the CalAmp LMU-3030.
This device slides into the OBDII (On-Board Diagnostics version 2) connector in the shuttle so it can stay securely out of the way of the driver. It also has a built-in battery like the Queclink device, but in this case, when the battery runs out and then power is applied again it, automatically turns on and starts sending data. Those characteristics make it much easier on the driver.
On the location side, it supports 1Hz GPS location, and this is plenty for our needs and provides heading along with the location. The 3030 also has an accelerator for monitoring driver behaviors. The connection to the OBDII port provides access to additional information such as fuel level and engine loading.
Finally, 3G access and UDP protocol is better suited for this application where we want low latency / low cost over cellular and are not heavily concerned with losing a packet here and there.
Problems solved. The system just works as it should without human intervention. The drivers are much happier.
Read the Shuttles Projectpart I here,part II here, part III here, and part IV here!