You can download it here (479M ISO Image)

• Chumby 8/Infocast 8-inch (22.9M Zip File)
• Chumby 1/Infocast 3.5-inch (22.6M Zip File)
• Debian-based “kiosk” Linux (226M ISO Image)

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 http://transitappliance.com/configure.

Chumbys

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 http://www.pendrivelinux.com/ 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!

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!

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.

Thoughts?

Here’s the presentation: Transit Appliance Project – pdxjs

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!

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?

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!

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.

Our proposition is that to do this, if as much of the common infrastructure, from configuration to the mechanics of fetching arrival information in a standard way, can be made an easily available as open source, commodity services, then the bulk of the creativity of the developer community can be applied to devices and display interfaces, where it can have the most impact.

So this site exists as a place to coordinate the development of those commodity services, and as a gathering point for the discussion and development of interfaces.

This site exists under the auspices of Portland Transport, an Oregon 501(c)(3) non-profit corporation that is primarily known for publishing a transportation blog. But our non-profit status allows us to accept grants and tax-deductible contributions that may help further the transit appliance mission. Our immediate aspirations are regional, but we intend to allow our work to be useful in other transit districts where ever possible.

Welcome to the party! There are two projects that are definitely on our agenda:

• A self-service interface for configuring what transit stops and lines show up on a given appliance (development began at the CivicWebs hack-a-thon and is well under way)
• A standardized javascript object for retrieving arrivals from TriMet, so developers can focus on display, not plumbing. Potentially this will have an architecture to support plugins for other agencies.

Some other possible projects:

• Tweaks to the Qt web browser for better startup and better use of screen real estate on the Infocast.
• A “transit appliance” Linux distro that can be deployed on a USB stick to turn Atom or ARM PC’s connected to flat screen monitors or TV’s into out-of-the-box transit appliances.