Once routes/stops are configured and WiFi is working…there’s literally nothing to do. About once a minute the screen will update with the latest predictions (arrival times in minutes, or hours and minutes), and every few minutes it will contact the NextBus server to synchronize its predictions.

There are no buttons to press or menus to navigate. This is an intentional design decision, based on my own experience with using the service. It’s most useful if the information is all simply there, now. If you’re pressing buttons, you might already be missing a bus.

One of e-ink’s most endearing attributes — maintaining an image even without power — is a potential liability in an application like this. If the program crashes or if the WiFi network can’t be reached, the last predictions would still be on the screen, getting progressively more wrong. The “Last checked” time at the bottom of the display lets you know when the NextBus server was last contacted…this should never be more than a few minutes off track. The code does its best to recover gracefully from errors…but if something does go wrong, the “Last checked” time is how you’ll know.

Other Configurable Settings

Aside from the transit routes and stops, there are some other configurable settings that can (and sometimes should) be adjusted.

In code.py, below the list of stops, are a few global variables. Each of these is pretty well commented in the code, but for posterity…

QUERY_INTERVAL determines how often to contact the NextBus server and update predictions, in seconds. By default this is set for four minutes (4 * 60 seconds). NextBus does have bandwidth caps, so you don’t want this too frequent.

MAX_PREDICTIONS limits how many predictions to show for each route. NextBus allows up to 5…but screen space is limited, and really I’ve never found that many predictions to be helpful. Like weather prediction, things get more uncertain the farther you look ahead. The default here is 3, though it may show less if that’s all the data available from NextBus (usually at a bus route’s end-of-day).

MINIMUM_TIME is a limit (in seconds) below which arrivals will not be shown. By default this is 5 minutes (5 * 60 seconds). You’ll want to configure this for your reality. For example, I know that a brisk walk will get me to any of my stops in about six minutes…five if I really boogie. Any less, I just don’t want to know, and I’ll plan my time around the next arrival. Bus Zen.

I feel very strongly about this. Bad things can happen when you hurry…falls, injuries, crossing busy streets unsafely…seen it all. Sometimes ignorance is bliss. Set a reasonable MINIMUM_TIME and just catch the next bus alive!

CLOCK_SYNC_INTERVAL sets a time (in seconds) to sync up the MagTag’s internal clock with an internet time server, because it can’t quite maintain perfect time on its own. This really only affects the “Last time” shown at the bottom of the display. Prediction times will always work regardless, since these come from NextBus. Default is every 6 hours (6 * 60 * 60 seconds).

TIME_ZONE shouldn’t be set in the code…you add this to the same settings.toml file that holds your WiFi credentials, like so:

CIRCUITPY_WIFI_SSID="your-wifi-ssid"
CIRCUITPY_WIFI_PASSWORD="your-wifi-password"
timezone="America/Los_Angeles"

CIRCUITPY_WIFI_SSID="your-wifi-ssid"
CIRCUITPY_WIFI_PASSWORD="your-wifi-password"
timezone="America/Los_Angeles"

A list of valid time zone strings can be found here. These are associated with cities, not traditional timezone names, so you may need to search around to find one that matches up with your longitude.

If you don’t set this up, that’s okay! The time server does a pretty good job of geolocation — estimating your location and time zone based on internet address.