The Raspberry Pi Transit Appliance

For the last several months I’ve been beta-testing the Raspberry Pi as the processor for our Transit Appliance technology stack, and it’s a very good fit. We use the 512MB “Model B” ($35). By the time we add a case, power supply, SD card and WiFi adapter, the build cost is in the neighborhood of $60.

The image file for our Transit Appliance build of the Raspbian OS is here (1.8GB). It’s our version 1.4 – we’re tracking releases by overall functionality, not per platform. This includes a number of changes to make our loader javascript more robust. Unlike the Atom platform where we use the Iceweasel version of Firefox, this platform uses Chrome (actually Chromium) as the web browser.

Here are excellent instructions for how to burn the image file to an SD card (2GB should work, but we generally use a 4GB card as they are more available) for a variety of OS’es.

A significant difference from the Atom platform is the way WiFi is configured. On the Atom (Webconverger) platform, the WiFi connection parameters are edited in a config file on the SD card. With Raspberry Pi there is a WiFi client app with a nice GUI. To access it, connect a keyboard and mouse (more on that below) and take the browser out of full-screen mode (Alt-F11), and you’ll find the WiFi app on the desktop. After getting your WiFi connection set up, kill the browser entirely (Alt-F4) and it will restart automatically in full-screen mode again.

Connecting a keyboard and mouse is a bit tricky, as there are only two USB ports on the Pi and one of them will already be occuppied with the WiFi adapter. One approach is to connected a powered USB hub. But I’ve found it easier to connect a keyboard that has a built in pointing device. I’ve found the wireless IOGEAR GKM681R very convenient.

One more way the Raspberry Pi version differs: I’ve found that our appliance applications run anywhere from 800 to 1500 hours before they crash (my guess is due to browser memory leaks). Rather than force someone to manually reboot the units after a crash (and if the crash results in a frozen but reasonable-looking display, it might take a while to notice!), on the Raspberry Pi distribution, I’ve added a cron job that reboots the OS overnight (3AM). My hope is that this should result in pretty much entirely unattended operation.

Posted in Raspberry Pi | Leave a comment

New Release of Flat Screen software.

We’ve released version 1.2 of our Linux appliance stack. The principal change is using a new version of the underlying Webconverger kiosk system, which now has much more robust networking, including the ability to support WiFi!

You can download it here (479M ISO Image)

Posted in Linux/PC | Leave a comment

Three-platform Software Release

I’m happy to announce that we have posted software releases of the Transit Appliance platform code for three hardware platforms:

All three downloads represent version 1.1 of our HTML/Javascript Loader system. I’d like to thank Matt Conway for his continuing work on improving the robustness of this tool. Additional information about each release, including installation instructions, follows.

The web site to configure Transit Appliances created with these downloads can be found at


The Insignia Infocast was the device that inspired this project, and while it is no longer being manufactured by Best Buy you can still find a few units in some stores (for a very good price). However, Chumby Industries (the original designer of the platform) has now released a very similar device, the Chumby 8 and we’re delighted that the software we created for the Infocast works without modification on the Chumby 8.

And the new V1.1 release is even more robust!

We are also including a software release for the smaller (3.5 inch screen) Chumby One. While our Transit Boardâ„¢ application will run on the smaller screen, you’ll need a magnifying glass to read it. Watch for an announcement of a transit display application tailored for the smaller screen.

The installation procedure is the same for all the Chumby/Infocast models:

  1. Boot up the device normally and use the built-in tools to calibrate the screen and establish a network connection.
  2. Download the appropriate zip file above for your device
  3. Insert a FAT32-formatted USB thumb drive into your computer
  4. Unzip the zip file into the root directory of your USB drive (don’t unzip into a subdirectory – this will not work)
  5. Power off your Chumby, insert the USB drive, and power it back on
  6. The Chumby should launch into a web browser, and if you have not previously established a configuration, it will prominently display the hardware ID (MAC address) for your Chumby. You can then use our configuration service to set up a display configuration.
  7. After creating your configuration, reboot and your Chumby should display your bus and train arrivals!

Linux/PC Release

While the Chumby devices are great for “counter-top” applications, we’ve been itching for a larger flat-screen Transit Appliance and we’re now releasing one!

Our Linux/PC software turns any PC into a transit appliance. The typical configuration is an inexpensive Atom-based PC (we’ve tested on the Foxconn NetBox-nT525 and ASUS EeeBox B202) coupled with a monitor or flat-screen HDTV.

To use this release you’ll need to download the ISO image and then burn it to a USB drive or SD Card (depending on the media your computer accepts). There are a number of tools for different platforms that allow you to do this. I personally use UNetbootin from Windows, but there’s a nice tutorial on the many tools available at and you can find tools for any platform.

You may also need to modify the BIOS settings on your PC to make the removable media the first boot device – follow the manufacturers instructions.

Boot off of the removable media and you should launch into a web browser and get a report indicating that your device is not yet configured. Use our configuration service and enter the hardware ID (MAC address) to create your display configuration. Then reboot and go!

At this time the Linux release only supports wired Internet connections, but we hope to add reliable WiFi support in the future.

I’d like to thank Scott Garman for his assistance and coaching in adapting the Webconverger kiosk browser project code for use in this effort!

Posted in Chumby/Insignia Infocast, Linux/PC | 6 Comments

Getting Ready for Transportation Camp

Transportation Camp West is next weekend, and I’m putting the finishing touches on my presentation about the Transit Appliance project. Please take a look and make suggestions!

With the help of my co-developer Matt we also have San Francisco’s MUNI buses up in the tool and Matt is working on BART now, so we’re no longer just a Portland service. Here’s an example!

Posted in Presentations | 1 Comment

Next Steps – Defining Agency Adapters

I’ve completed a re-write of Transit Boardâ„¢ to eliminate the server-side components and talk directly to the TriMet and NextBus arrivals web-services (in the case of NextBus, I’m using YQL, at the suggestion of my co-contributor Matt, to act as a proxy to get around cross-site data restrictions in AJAX).

Now that this is out of the way, I want to move on to a general architecture for the component we’re calling ‘Agency Adapters’. My current thinking is that there are two components per agency, a set of ‘updaters’ and an ‘updater factory’.

This thinking is based on my experience with TriMet, but I think it’s probably reasonable for covering a variety of ways that agencies may provide AVL services. It seems pretty clear to me that it will probably be necessary to allow for multiple AVL service calls per agency.

For example, with TriMet, their service will return results for up to 10 stop locations. So if my display requires 12, I’m going to need to make 2 calls. In addition, if one or more stops serves the Portland Streetcar (included in TriMet’s GTFS data, but not its AVL web service), I need to make a separate call to NextBus.

So I propose that at startup we call an ‘updater factory’ for each agency in our configuration. We would pass all the stop/line configuration information for that agency to the factory, which would in turn create and return an array of ‘updater’ objects.

Each updater would be responsible for handling all the web service calls for a specific subset of stops/lines (with the division decided by the factory). The updater would worry about issues like how frequently to call the service, logging errors, etc. and would maintain an ‘arrivals array’ with the current best set of predictions for the the delegated stops/lines.

The updater would expose an API allowing its arrivals array to be accessed, possibly along with some kind of indication of how fresh/stale they are.

The next layer up in our application stack would include a process that polls all the available updaters and builds an aggregated arrivals array.


Posted in Architecture | Leave a comment

JavaScript as a Key Technology

Both the appliance configuration tool and the Transit Boardâ„¢ application are coded primarily in JavaScript. I’ll be presenting tonight to the Portland JavaScript Admirers’ group about how we’re using this technology.

Here’s the presentation: Transit Appliance Project – pdxjs

Posted in Presentations | Leave a comment

Beta Release of our Configuration Service

I’m happy to announce that we now have a beta release of our Transit Appliance configuration service available at

Currently it only supports TriMet (and Portland Streetcar, since Streetcar is included in the TriMet GTFS file). So you will only have a meaningful experience within the TriMet service district.

It is capable of creating both bookmarkable browser configurations and configurations for the Infocast ‘appliance’. Paired with this release we have a new version of the Infocast boot stick that calls the new service to get its configuration.

As promised, the project has been open sourced (under an Apache 2.0 license) and has a hosting page on Google Code.

Looking forward to feedback!

Posted in Configuration Service | 6 Comments

The “Phone Home” Pattern and Roles in the Transit Appliance Ecosystem

The core idea for transit appliances is that they are from a user perspective, very simple devices. Ideally the only control is an on/off switch.

To support this and to support deployment at scale, you want a device that can simply be installed and then remotely configured and managed. This leads to the ‘phone home’ pattern – the idea that when an appliance is powered up, the first thing it does is ‘phone home’ to get its configuration information. For our Insignia Infocast prototype this looks like a simple HTTP GET request passing the MAC (ethernet) id of the device as its identifying information. Here’s a diagram of the interactions that then ensue:

Here’s the sequence described:

  • The appliance “phones home” with a unique id and gets back a URL pointing to a configured application (assumes the full configuration can be described in a URL).
  • The appliances uses the URL to fetch its “application” (an application in this case being an HTML page with Javascript [or conceivably Flash] logic embedded).
  • The application then issues an ongoing series of AVL queries to the data provider (running for hours, days or even weeks).

So who are the parties in this ecosystem?

  • Appliance providers – provide hardware platforms that can display web pages. These can be viewed as “web browser kiosks” at the simplest level (although they do not need to provide user input devices like keyboards and mice or touch screens).
  • Configuration providers – provide a user interface via which configurations can be established and maintained specifying what devices use what applications and display what set of arrival information.
  • Application providers – provide alternative ways of displaying arrival information for various use cases.
  • AVL Providers (probably mostly transit agencies) provide access to the actual arrival data.

What are the relationships that need to exist in this ecosystem?

  • Appliance providers MUST partner with configuration providers. An appliance has to know where it ‘phones home’ to. An agreement must exist that the configuration provider will answer!
  • Configuration providers must have knowledge of application providers, but don’t necessarily have to have a formal relationship if the application providers have made their URL configuration formats open and accessible.
  • Application providers must know how to get AVL data from the data providers.
  • AVL providers (transit agencies) don’t have to do anything other that document the interfaces to their data.

Obviously a single entity can play more than one role. To take TriMet’s Transit Tracker as an example, the user is the appliance provider, using their PC as the appliance and TriMet plays all three other roles: configuration provider (menus to select stop), application provider (display of arrivals) and the AVL provider (populating the arrivals).

It’s not clear to me yet how roles will break out in the real world, but I can tell you that in trying to bootstrap this ecosystem Portland Transport is going to try to play three roles:

  1. Appliance provider – we’re going to at least prototype several types of appliances (the Infocast being the first, I also want to get something wall-mounted, probably driven by a cheap PC, out there as a prototype). We may continue to play this role in the Portland region, working to get the hardware widely distributed, but have little ambition to supply the actual appliances outside Portland. We may also find it more effective to identify partner organizations that can do this more efficiently than we can.
  2. Configuration provider – this is the service we’re working hardest on at the moment. This feels like an organizing role in the ecosystem, bridging the various other partners. We’re going to open source all the code involved, so other people could get into this, but it’s not clear to me why multiple configuration providers are an advantage in the ecosystem, so maybe this is an enduring role.
  3. Application provider – my hope is that there are many, many of these so we can provide users with lots of alternatives. But we’ll continue to develop Transit Boardâ„¢ as an example in this category. And we may provide software components to make it easy for other people to develop applications.

Does this identification of roles and relationships make sense? Who are candidates to fill the various roles? Are there different ways to think about this ecosystem?

Posted in Architecture | 2 Comments

An Architecture Stack for Javascript Transit Appliances

Currently I’m aware of two “browser-based” transit display applications: Transit Boardâ„¢ which is a hybrid of server-based and Javascript technology produced by yours truly for Portland Transport, and an as-yet-unreleased pure Javascript application that TriMet is working on. There may well be others that I’m not aware of.

My belief is that the potential for HTML/CSS/Javascript apps in this space with a variety of use-case-specific interfaces is very large, and part of the brief for this site is to make it easier for developers to crank out different UIs. To that end I want to propose an architecture stack that would support easy UI development:

I’m going to describe these from the center outward. The core data element would be a queue of arrivals, represented in an agency-independent way. Here are some of the data elements I would suggest should make up a common representation of an arrival:

  • Number of seconds until the arrival
  • Clock time of the arrival
  • Is the arrival time an estimate based on AVL or a scheduled time?
  • Route id of arrival (preferably a GTFS route_id)
  • Location id of arrival (preferably a GTFS stop_id)
  • Trip id of arrival (e.g., GTFS trip_id)
  • Direction of arrival (e.g., GTFS direction_id)
  • Textual information (headsign, e.g., GTFS trip_headsign or trip_short_name) describing routing or destinations
  • Service alerts associated with this arrival (detours, delays, etc.)

The overlap with GTFS is not accidental – there is obviously a big overlap with the data elements used for scheduling, and I hope that overlap extends into an AVL standard protocol.

This arrivals queue would be populated by one or more agency adapters (consumers of REST services for example). In Portland, to get a complete set of arrivals for some stops, it would be necessary to query the REST services for both TriMet and Nextbus (for Portland Streetcar arrivals). If at some point we have a standardized AVL REST API (the AVL equivalent of GTFS) we could just code one adapter (passing agency endpoints as a parameter), but until then we’ll need agency adapter modules for each unique REST format.

I’ll take a moment here to put in a plug for JSONP REST services. The Javascript “same origin” security policy is a tricky obstacle that generally means that a web interface has to be sourced from the same domain as the REST API is served from. That’s pretty restrictive! There are two ways around this: proxy servers that route the data through the same domain as the application is served from (but these consume resources that don’t add any other value) and the use of the JSONP format, which is an exception to the same origin restriction. I’m very pleased that as a result of a request coming out of the CivicWebs Hackathon event, TriMet added JSONP as a supported format (if you’re already supporting JSON, JSONP is a pretty easy addition, just a little bit of extra wrapper syntax).

OK, now working in the other direction from the arrivals queue, we could simply have UI developers directly read the arrivals queue (and we should provide this option). But I also think we could make life easier for UI developers (our mission!) by providing some standard services they are likely to want to make use of. Examples I can think of off the top of my head include:

  • Access arrivals sorted by time of arrival
  • Access arrivals grouped by stop_id
  • Paging services (e.g., split arrivals display into multiple pages of ‘n’ arrivals each)
  • Refresh interval management

I’m sure there are more. Better if we can code these once with good APIs than to make UI developers re-invent the wheel over and over again.

So what do you think? Is this a reasonable stack? Are there components I’m missing? Can something be simplified? Other services that should be included in the API?Let me know how you think this can be improved!

Posted in Architecture | 2 Comments

Infocast Pricing, Networking

My current favorite hardware platform for Transit Appliances is the Insignia Infocast (8″). At some point I need to do a post on the characteristics of this device that make it so friendly for this application… but that’s for another day.

On Wednesday, Best Buy’s web site was showing the pricing as $129.99 (down from $169.99). Black Friday ads today show it at $99.99!

Also, in the process of setting up an Infocast at the Portland Building (home of many of the City of Portland’s bureaus) I found that the list of Ethernet USB Adapters for the Chumby apparently also applies to the Infocast, so in situations where WiFi is not convenient, there are other options.

Posted in Chumby/Insignia Infocast | 10 Comments