The Presto Card System and the TTC Mon, Jan 30. 2017
The Metrolinx stored-value payment system, Presto, has been used by a number of transit systems for many years, including Brampton, Burlington, Durham, GO Transit, Hamilton (HSR), Mississauga (MiWay), Oakville, Ottawa (OC Transpo), and York Region (YRT/Viva). Although there have been some significant glitches, the Presto system works well overall on those systems. I used Presto for years on Viva in Vaughan and really liked it.
Presto is about to rolled out to Toronto's TTC system, and unfortunately, the rollout is not going well, and will not go well on the current course.
How Presto Works
The Presto card has two main attributes:
- It is a stored-value system. That means that the actual value is stored on the card itself, unlike an Interac direct debit card or a credit card, where the value is managed by a remote computer system. The advantage to a stored-value card is that the transaction can be processed locally, without the delay of contacting a remote computer, and a reliable data connection is not required (useful when boarding a bus in a tunnel or underpass, or when a communications network is down). [For the geeks in the crowd, the Presto card uses a Mifare DESFire technology compatible with the ISO/IEC 14443 Type A standard, 13.56 MHz (the same frequency band used by NFC devices in cellphones and Interac/credit cards, but different from the RFID system used for most door access cards and dongles), with 4 kilobytes of data memory (if you want to compare this to your USB flash drive, that's 0.000004 GB, or about one typewritten page of text). Paper Presto cards for visitors will probably be similar to the paper passes used on other systems, which are similar to the plastic cards but have less memory, typically 64 bytes].
- It is a radio-frequency ID/near-field communication contactless system. This means that the card contains a tiny speck-sized computer, a small amount of flash memory, a radio circuit, and an antenna which goes around the perimeter of the card. When the card is held up to a reader, a radio signal from the reader provides enough energy to boot the card's computer, which then communicates with the reader to exchange information and, when necessary, to store revised information (such as a new balance) in the card's flash memory. Yes, it is amazing that all that can take place in the fraction of a second that you hold the card on the reader.
These attributes define the way the system works.
Loading Value Online
One of Presto's challenges comes when you want to load value on the card online -- through a web browser or your phone. Once you've gone to Presto's web site and performed the transaction, the Presto system has to get the additional value onto your card. Since the card readers throughout the system do not get in touch with a central server during a card tap, the only way to ensure that your card gets updated with the
added value is by sending an update to every vehicle or station in the entire system that there's a load-value transaction pending for your card. That means that thousands of readers from Ottawa to Hamilton have to store a list of every pending online-load transaction, and when you tap your card on any of the readers, they have to very quickly search through their stored list to see if they should add value to your card. After one of the readers loads the value onto your card, a message is sent back to the central servers, and the transaction is eventually removed from the queue on the all of the card readers. This is the reason that Metrolinx tells Presto users to allow 24 hours after an online load transaction before the value will be loaded onto their card
-- and in my personal experience, in rare cases it's several days longer.
The issue with this is that it doesn't scale very well. The volume of data that needs to be sent from the central servers to the card readers to manage online loading increases with the product of the number of reader locations and the number of people performing online card loads.
With a very small number of active TTC Presto users, the system isn't currently seeing anywhere near the load that it will need to carry a year from now. Many current TTC riders with Presto cards also use other payment methods such as tokens, because Presto cards aren't accepted at all locations yet -- including convenient unattended second entrances in many of the TTC stations. In addition, many Presto users have learned to avoid online load transactions, and load their cards in person at service counters or self-load machines.
You can see the impending challenge: when Metropasses subscriptions move from physical cards to Presto, there will be over 50,000 additional online updates per month. Hopefully, these transactions will be spread over a period of time and not dumped into the system all on one day, but in any case, these thousands of additional updates will strain a system that appears to have trouble with existing volumes.
Variations in the Use of the Presto System
There is significant variation in how transit systems use Presto cards. For example:
- GO Transit expects riders to tap on at the start of their trip and tap off at the end, and charge by the distance travelled (failing to tap off results in a penalty charge, plus fare to the end of the line).
- YRT/Viva provides 2 continuous hours of travel after you tap on to their system. Additional taps do not result in a deduction from your card (unless you press a button for a second-zone add-on for travel between the North and South parts of York region). This system provides certainty in the minds of the users, but it does leave room for some problems -- for example, if you tap on to a hour-long Viva trip from Markham to York University 90 minutes after you first tapped for the trip; your trip will finish after the 2h has expired, but tapping on to the Viva trip will not deduct a fare because you still have 30 minutes active on the previous fare; I wonder how fare enforcement works in this case? This system does have the benefit of allowing you to stop and buy milk on the way home from work, or duck out for lunch and get back to the office on a single fare.
- Some systems permit you to load passes on your Presto card, while others (such as GO) just stop charging you additional fares when you have hit a maximum pass-equivalent amount within a month or week.
Problems with the TTC's Implementation of the Presto System
The TTC's specific implementation of the Presto system has several significant pain points:
- TTC Presto fares continue to use the TTC one-continuous-trip transfer system, which permits you to transfer as many times as necessary for one continuous trip regardless of duration. This means that it's not permissible to stop to shop or have lunch during a trip. The challenge with integrating this approach with the Presto is that the system's software has to determine whether a tap on a second vehicle is a continuation of a trip (no additional fare charged) or a new trip (fare charged). This is complex to calculate when the original tap was on the other side of the city and the system is running perfectly, but it's impossible when weather delays, vehicle breakdowns, traffic problems, special events, or detours delay a portion of the trip. When using paper transfers, the rider could explain to the driver or collector why their transfer is older than expected, but this level of discretion does not exist in the Presto system. Solution: the TTC should switch to a time-based transfer system, allowing unlimited travel for 90 or 120 minutes per trip regardless of the number of vehicles used.
- The TTC's Presto readers do not display any information about the transaction taking place during a tap -- just whether it is Accepted or Declined. The rider is left in the dark about whether a vehicle transfer is charged as a second transaction or accepted as a transfer on the original fare. In addition, the user has no idea when value-load transactions take place, nor the current balance on their card. A rider who is assuming that transfer transactions are being processed correctly or that online loads are being stored on the card in a timely fashion can be easily stranded after their one grace transaction (a single negative-balance transaction is permitted, with a penalty charge). In
contrast, other systems (such as YRT/Viva) clearly display the transaction amount and card balance on every tap (although their poorly-lit screens are a lot harder to read than the TTC's bright colour screens). It has been argued that the ability to check one's balance and transaction history online mitigates the need for at-time-of-tap transaction and balance information, but this puts the onus on the rider to frequently login and check that the system is performing as expected. Solution: the TTC should display transaction, value-load, and balance information at every tap. At a minimum, there should be some indication of a low-balance state (less than 2 TTC fares remaining on card).
- The TTC's self-load machines are routinely out of order, especially
(according to a fare collector, to my surprise) around the end of each month. They look like they are fully online, but they fail to recognize an inserted Presto card and thus commence any transaction. Solution: this should be addressed by the contract with the Presto technology providers, and vendor performance penalties should be in place and enforced.
- The Toronto-York Spadina Subway Extension (TYSSE) project will require a new fare structure. Right now, over 2000 buses enter the York University campus every day, including Brampton Zum, YRT/Viva, GO, and TTC. When these buses are moved off-campus later this year, York University and Seneca@York students and staff will need to take a short subway ride to the new connection points north of campus. Paying a complete TTC fare on top of the Zum/YRT/Viva/GO fare for this privilege will in most cases double riders' transit costs. Solution: the system needs to provide a rebate of the TTC fare when tapping on to these other services, or better yet, Metrolinx should negotiate a multi-system fare that includes time-based travel on all interconnected systems.
Running LEAP: Portable 64-Bit ARM Computing Sat, Sep 19. 2015
I really want a 64-bit ARM laptop, but no one is shipping them yet -- not even Vero Apparatus.
So, I've put together the next-best-thing: a portable, wireless system assembled from off-the-shelf components. The resulting system weights ~1.8 kg (4 lb), has a 5-6 hour battery life, and fits in my laptop bag. It has microSD for storage, an 8-core Cortex-A53 processor, wifi, ethernet, and bluetooth, an external HDMI output for presentations, and 1GB of RAM. The components are held between two sheets of acrylic by 3M Dual Lock fasteners so the configuration can be easily switched up.
This system runs a version of LEAP, our experimental enterprise Linux distribution for AArch64 systems loosely based on the CentOS 7 x86_64 sources, on a 96Boards HiKey. The HiKey isn't officially supported by LEAP (yet), but we expect to support it later this year. I look forward to swapping the HiKey for a 96boards Enterprise Edition board later this year.
If you're at Linaro Connect next week, I'd be glad to give you a peek sometime during the week or on Demo Friday, and I'll blog about how the system was assembled a few weeks down the road.
The OSTEP Applied Research Team Thu, Jul 2. 2015
I haven't introduced my research team for quite a while, and it has changed and grown considerably. Here is the current Open Source Technology for Emerging Platforms team working with me at Seneca's Centre for Development of Open Technology. From left to right:
- Michael (Hong) Huang (front)
- Edwin Lum (rear)
- Glaser Lo
- Artem Luzyanin (front)
- Justin Flowers (rear)
- Reinildo Souza da Silva
- Andrew Oatley-Willis
Edwin and Justin work with me on the DevOps project, which is applying the techniques we've learned and developed to the software development
processes of a local applied research partner.
Michael, Glaser, Artem, Reinildo, and Andrew work with me on the LEAP Project. Recently (since this photo was taken), Reinildo returned to Brazil, and has been replaced by Christopher Markieta (who has previously worked with this project).
I'm dying to tell you the details of the LEAP project, so stay tuned for an announcement in the next week!
Connecting a 96boards HiKey to a Breadboard Sat, Apr 11. 2015
I've wanted to experiment with interfacing the 96boards HiKey (8-core, 64-bit ARM development computer) to some devices, but the 2mm 40-pin header is difficult to bring out to a breadboard (except by individual wires). I designed a simple adapter board and had some produced by the awesome OSH Park prototype PCB fabbing service. The boards are back, and I've been assembling a few of them for testing.
The adapter has a 40-pin 2mm male connector that plugs into the 96boards "low-speed" (LS) female header. It brings those signals to a 40-pin 0.1"/2.54mm header that can be used with an insulation displacement connector (IDC) on a ribbon cable. The other end of the ribbon cable can then be connected to a standard solderless breadboard using an adapter (most of the 40-pin IDC-to-breadboard adapters used with the Raspberry Pi A+/B+/2 should work -- for example, the AdaFruit Pi Cobbler Plus (straight) or T Cobbler Plus (T-shaped), KEYES SMP0047 from dx.com (U-shaped - not checked), or a 40-pin IDC Ribbon Breakout from Creatron in Toronto (straight) -- obviously, the pinouts from the 96boards connector will be different, so ignore or rewrite the pin labels on the adapter board). Update: Watch out for breadboard adapters that connect pins together -- e.g., that are designed for use with a Pi and connect together Ground or Supply pins, which will have different functions on 96boards LS connector. (I found a T-style adapter from DX.com that has this issue).
These first-try "Alpha 1" boards are not ideal -- they're bigger than they need to be, the board occludes one of the 96boards mounting holes, and the routing is wonky (I let the autorouter do its thing, and ended up with a couple of unnecessary vias and some wild traces). Nonetheless, the board seems to do what it was intended to do. I'm going to work on a second-generation design, but it may be a little while before I get around to it.
If you're interested in using this design, it's licensed under CC-BY-SA and can be downloaded or ordered from the OSH Park sharing site.
You can use this with the 2mm (96boards LS) and 2.5mm (IDC) connectors on the same side of the board, or on opposite sides of the board.
If you place them on the same side of the board (see the populated PCB with no cable attached in the photo -- though the IDC socket should be rotated 180 degrees), the pin numbering on the IDC cable will match the 96boards pin numbering. However, the IDC connector will be really tight to the edge of the board -- you may want to slightly angle the IDC header when you solder it on.
If you place them on the opposite sides of the board (the adapter plugged into the HiKey in the photo), the even and odd numbered pins will be swapped (1<->2, 3<->4).
One final note -- these should work fine with other 96boards devices that comply with the Consumer Edition specification -- and hopefully, it won't be long before the DragonBoard 410c is available so we can test this theory!
(The board in the photo is in one of the very basic acrylic cases I built for the HiKeys).
Initial Current and Temperatures on the HiKey from 96Boards Sat, Feb 14. 2015
This board is powered by an 8-core, 64-bit Cortex-A53 ARMv8-A Kirin 620 SOC from HiSilicon with 1GB of LPDDR3 RAM, a Mali 450MP4 GPU, dual USB, eMMC and micro-SD storage, 802.11g/n, and high- and low-speed expansion connectors with I2C, SPI, DSI, GPIO, and USB interfaces.
So far, this has been an incredible board to work with, despite some teething pains with the pre-release/early access software and documentation (and a few minor quibbles with the design decisions behind the 96Boards Consumer Edition spec and this first board). It's not in the same performance class as the ARMv8 server systems that we have in the EHL at Seneca, but it's a very impressive board for doing ARMv8 porting and optimization work -- which is its intended purpose, along with providing a great board for hacker and maker communities.
I experimented with the board last week and took some readings at home today, and thought I'd share some of my findings on board current draw and temperatures, because it may be useful to those planning alternate power supplies and considering temperatures and airflows for cases:
- Current consumption: The board draws ~120 mA at idle (Linux login prompt) with nothing connected, and about 150-155 mA with a basic USB fast ethernet adapter connected. With ethernet attached and 8 cores doing busy-work (compressing /dev/urandom to /dev/null), current consumption rises to just over 300 mA (297-320). All of these readings are at 12+/-0.25 vdc, so that's under 4W including the USB ethernet. Note that the GPU was basically idle during these tests.
- Temperature: In a room with an ambient temperature of ~21C, with all 8 cores doing busy work (8 processes gzipping /dev/urandom to /dev/null, and top reporting 0.0% idle), the temperature on the SOC heatsink rose fairly quickly to ~48C, and eventually reached 52C, measured using an infrared temperature reader (accuracy of +/- <2C).
A couple of other random observations about the board:
- The board mounting holes accommodate M2.5 screws. Basic hardware stores, including Home Depot (at least in Canada), do not carry M2.5 screws, so I've been thwarted in my efforts to mount this onto an acrylic plate so far (cases will evetually follow, I'm sure, but I always prefer to have boards on/in something and not sitting directly on my desk). I'm sticking some silicon feet on the bottom as an interim measure.
- There is a "USERDATA" partition on the eMMC which is not used by the initial software image. Be sure to format and mount that partition to gain an additional 1.5 GB of space if you're running from eMMC.
I'm looking forward to the release of WiFi drivers and UEFI bootloader support soon, as promised by the 96Boards project.
More notes to follow...