Bus Tracking

This work is vital to a working arrival system, but it is mostly work with schedules and spreadsheets and databases so it doesn’t produce much in way of pictures. In the mean time please accept this mock-up of an arrival sign display. This is data I typed in by hand, not a live demonstration, and does not represent the final layout. But you can imagine that future signs will include information similar to this example for stop 1_8760

OBA API

This project will be using OBA API for several pieces of information

1. Route data. OBA provides things like the route number, head sign, and a list of stops to get basic information about any route
2. Stop data. OBA provides details about each stop including the routes the serve it, it’s coordinate location, vehicle direction at the stop, accessibility flags, and cross streets
3. Schedule data. OBA knows the list of trips for each route each day and the per-stop scheduled arrival time. The per-stop schedules are designed to match actual vehicle speeds throughout the day and vary from stop to stop throughout the day
4. Live tracking. OBA gets GPS-based location updates for most vehicles every 15-30 seconds throughout each trip, including the last fix location, the time of the last fix, and the last stop the vehicle served

OBA provides this information in many different formats to serve a bunch of different uses, including consolidated arrivals predictions for each stop. If you are writing your own online arrivals system it is likely that you’ll want to consume those feeds directly. But we are running a series of signs with very limited power bandwidth and power and so we will be building our own data system

Our Data

Our system will fetch, reformat and compact the static data like routes and schedules from OBA; data for the next several weeks of scheduled service will be stored in each sign. This stored data allows “as scheduled” updates for any sign even if the update network is offline and provides a fallback for signs that are losing power entirely — they can display the whole fixed schedule until power is restored. This static data will also helps individual signs figure out when they can sleep (no trips scheduled) and when they need to be listening for radio updates (live trip approaching)

Our system will also fetch, transform, and transmit per-trip tracking data, to calculate route delay for any trip that has live tracking from OBA. After analyzing per-stop delay data from OBA for a couple of weeks I have determined that it is a simple delay-from-schedule figure that is applied to the entire route — OBA compares the delay at the last stop and propagates that number forward as a delay estimate at all future stops for the same trip. This means that, for our signs that each know their local schedule, we can transmit a single delay number over the radio network and each sign will be able to determine its unique next arrival time

Both the slow-changing data like schedules and the fast-changing data like tracking will be transmitted over a purpose-built LoRa radio system, which we have already been testing around the area. That work has been going well with handheld tooling but is just getting ramped up to full-sized equipment and quantitative testing. Expect a separate update about that effort in the next few weeks

Independent Tracking

Since our signs will be mounted road-side, it may be possible to directly detect when a transit vehicle is at a stop. Our buses don’t have customer-facing WiFi but I suspect they have the standard fleet WiFi services that most public vehicles do these days. I have setup some mobile test equipment to let me ride around on buses and listen to what they sound like in the radio spectrum

Assuming it is possible to identify transit vehicles via radio signature, our system could have full independent vehicle tracking — even without OBA’s GPS data we could know with high confidence when a vehicle passed a particular stop. That’s sufficient to generate our own route delay estimates and would help us (in)validate unusual data we see from OBA

One limitation in this sort of tracking is that listening is a fairly power-hungry mode for radio equipment. That might be counter-intuitive because transmitting clearly uses lots of power, but receiving often takes much more time. One of the major improvements of BLE over classic Bluetooth is that the “low energy” version allows devices to almost never waste time listening; they transmit a short burst then schedule a future time when they will be listening rather than waiting and listening all the time

It’s hard to know how much power budget we’ll have for our signs until we get some testing done out on the street, but we will be running 24/7 on solar in a place where the sun spends more than a month below 20° elevation, so total available power is a real limitation. We can take a trick from BLE to help; since we know when to expect a vehicle we can wake up our radio only for the few minutes when it should be nearby. That would mean that we miss unexpected vehicles, but would also mean we use radio listening power less than 10% of the time instead of 100% of the time

We might also be able to use mains power for signs that are mounted indoors (or larger solar for signs mounted at cooperating locations) so that we can use extra power to do things like track vehicles and relay radio messages among other (mostly sleeping) signs along the route. Another option for high-power installations is camera-based matching, where we visually look for transit vehicles passing a location

We could also likely track cops with this type of system, at least in the high-power version, as our own sort of reverse-Flock. If they are going to surveil us every time we use the road we should probably have some options for tracking them too

Future Improvements

I suspect after observing live tracking and schedule data it may be possible to produce somewhat better per-stop estimates than OBA provides natively. For example, I expect our system might be able to filter out some of the fake trips that OBA publishes when buses are significantly delayed. Or it might be able to predict delays that occur between particular stops under certain conditions

But to start with it will just be tracking along with OBA data, and we’ll dig into that data with some statistics and human analysis once it’s been running for a while. This data collection has already started so we’ll have some information to work with before any signs go live