News   Dec 20, 2024
 1K     5 
News   Dec 20, 2024
 768     2 
News   Dec 20, 2024
 1.4K     0 

Metrolinx: Presto Fare Card

Or if you look at it from the non-TTC perspective, Toronto is remarkably complicated in its transfer system. Most cities use time-based transfers, time-based transfers without backtracking (Go Transit has this) or only allow a single out-of-system transfer (New York City, for example). Toronto's bizarre system is as many transfers as you want, but only if you're taking the most direct route to your destination, except for one streetcar route that uses time-based transfers.
You are really not adding anything to this conversation. I think we all fully understand this and it has been discussed at length higher up the thread. I cannot remember any UTer who thinks the current TTC transfer Rules are sensible or that they should be continued in an automated environment (at vast costs in programing!)
 
In all fairness to every side of this topic, information on vehicle positioning methods for both TTC and GO is very difficult to find. Without accurate GPS information (and it can be highly accurate, but far from 100% of the time with the satellite positioning systems both GO and TTC use), basing fare calculation on it alone is going to be unreliable.

I get that it's inaccurate, yes. But, failing operator error, Presto will know what route it is. My GPS coordinates can be forced into a default location on that route, presumably the start point for that direction of travel as input by the operator. I tapped on the subway at Kipling, then x minutes later I tapped on an eastbound 505 car. That bounds my tap-off location to somewhere west of Broadview Station. Now I'm tapped on VIVA? Ok, it's a puzzle, but now my tap-off location is bounded by the last point on the VIVA route. The puzzle is moot. If I tap an end point, and if GPS gods are willing, the calculation can get more exact, but the default isn't that bad.

It's easy to divide the GTA into zones, with every fare within a given pairing of 'start' zone and 'end' zone having the same fare calculation and the same revenue distribution among agencies. For the moment, City of Toronto is one zone, but that can change. (I won't digress by pointing out that it's a political reality that the fare from Eaton Center to Malvern or Jane/Finch will never be greater than the fare from Eaton Center to a Queen St West coffee shop. Call it the GDeB Factor - it's a reality, ain't gonna happen). The transit operators will argue each possible routing and fare division ad nauseum, but they need to be smacked if they do.

If we are attempting to achieve precise scientific perfect data for each on and off, we are badly overthinking the thing, and we will spend a lot of money that isn't necessary.

- Paul
 
Last edited:
I get that it's inaccurate, yes. But, failing operator error, Presto will know what route it is. [...]
If we are attempting to achieve precise scientific perfect data for each on and off, we are badly overthinking the thing, and we will spend a lot of money that isn't necessary.

- Paul
Agreed! For the purpose of your proposal to simplify determining a simple 'transfer y/n' it's virtually inconsequential. The worry is for thinking this can be part of a later distance based fare system. I can now see part of their wishing for a 'zone based system' (which in defence of GO, they do), as it greatly minimizes the consequence of slight inaccuracies. But there is talk (and it has merit, albeit conditional) of moving to a completely incremental distance fare, as zone fares present their own form of 'gaming' and inequitable costs.

As it stands, and as reported by numerous authors, one a moderator in this board, merely getting off across the street from Union Station to transfer to the subway has been charged as another fare, not a transfer. The TTC claims that has been "corrected"....but is that the way a future system is going to function?

Took 4 streetcars today and all 4 streetcars had broken presto readers. I swear the reliability is getting worst instead of better.
This is curious, as well as distressing.

When developing systems, when one sees recurrence of many modules failing at the same time, it almost always indicates a common cause, and I'd immediately suspect power feed, and other common supporting systems, including GPS!
 
A
This is curious, as well as distressing.

When developing systems, when one sees recurrence of many modules failing at the same time, it almost always indicates a common cause, and I'd immediately suspect power feed, and other common supporting systems, including GPS!

From what I understood from the report at the last TTC meeting when I watched it on youtube is both the TTC and Metrolinx have found its a software issue and are going through and putting in new SD cards into the readers on the buses and streetcars with the updated software on it. Pus also they sometimes loose signal as they are cellphone based with an antenna on the roof of the buss or streetcar and at any given time can lose reception from time to time..
 
From what I understood from the report at the last TTC meeting when I watched it on youtube is both the TTC and Metrolinx have found its a software issue and are going through and putting in new SD cards into the readers on the buses and streetcars with the updated software on it. Pus also they sometimes loose signal as they are cellphone based with an antenna on the roof of the buss or streetcar and at any given time can lose reception from time to time..


seriously with all other surrounding agencies running presto for years HOW HARD can it be???!!!! its not like theyre the pilot users....how can yrt , mw, bt etc have worked out the bugs and now being the last installer
they get all the glitches with no end in sight?! its not like theyre running a signficantly different system. They only real difference is just a newer unit. The wiring and connections should all be similar to the other agencies...
UNLESS....once again ttc is trying to reinvent the wheel???
 
seriously with all other surrounding agencies running presto for years HOW HARD can it be???!!!! its not like theyre the pilot users....how can yrt , mw, bt etc have worked out the bugs and now being the last installer
they get all the glitches with no end in sight?! its not like theyre running a signficantly different system. They only real difference is just a newer unit. The wiring and connections should all be similar to the other agencies...
UNLESS....once again ttc is trying to reinvent the wheel???
I think you've hit the nail on the head the TTC and metrolink are reinventing the wheel. The established Preto machines can only be used with presto cars the ones the TTC are adding are able to be adapted to open payment. Alo keep in mind the TTC has more vehicles then any other transit agency plus they also have a lot of things to deal with that the others don't like tall buildings downtown it often interferes with the cellular signal plus also if buses or streetcars go into underground terminals they can lose the signal too]
 
From what I understood from the report at the last TTC meeting when I watched it on youtube is both the TTC and Metrolinx have found its a software issue and are going through and putting in new SD cards into the readers on the buses and streetcars with the updated software on it. Pus also they sometimes loose signal as they are cellphone based with an antenna on the roof of the buss or streetcar and at any given time can lose reception from time to time..
I'm glad to see the discussion moving to questioning what we're being told, as I've been digging for half an hour, mostly backwards, to find the following. It's far from conclusive, but does give an indication of how the TTC is using binder-twine and bubble-gum to hold things together right now, and note that a disproportionate number of complaints are on the CLRVs, which were supposed to be replaced by now. Buses are another matter...

I'm going to have to post reference backwards in sequence as I have limited time to compose and edit this: Even though I'm not licensed as an RF tech, I'm familiar with the multiplex and subsidiary communications (piggyback) methods almost always used in these cases, albeit it was my understanding that bus and streetcar Presto devices are stand-alone from central control, and upload and download info only in batches, usually at the beginning or end of shift. The OS, however, or some run files might be data bus connected, I don't know, I still can't find any basic let alone technical description on-line:

upload_2017-1-22_1-6-12.png

[...]

upload_2017-1-22_0-59-49.png



https://ttc.ca/About_the_TTC/Commis..._Dispatch-Automatic_Vehicle_Location_CAD-.pdf

[...] Buses and streetcars use the Communications and Information System (CIS). This system employs transmit facilities throughout the city. Each bus and streetcar has a Transit Radio Unified Microprocessor (TRUMP) set on board. This is attached to a transponder receiver, which allows CIS operators to track the location of the vehicle using an older computational system known as dead reckoning. The TRUMP also allows the operators and CIS operators to send and receive text messages for such things as short turns and route adjustments. There is also the option of voice communications between the operator and the CIS operator. The CIS was conceived in the late 1970s and was fully implemented in 1991. With the introduction of the NextBus GPS technology, the CIS positioning system is now[when?] using a combination of GPS data and the old dead reckoning sign-post system. In the event that internally managed TTC communications are unavailable, the TRUMP unit operates on Bell Mobility's CDMA network to communicate with divisional operations and transit control. Recently, the TTC began research into transitioning from the outdated and antiquated CIS to a newer computer aided dispatch (CAD/AVL) system. Utilizing this technology would help improve headways, provide more reliable communications and allow divisional supervisors to locate vehicles in real time (the current GPS system only sends location updates every 20 seconds). There is no current estimate of when this technology is to be implemented. Each TRUMP unit on every streetcar and bus is equipped with a silent "yellow alarm" key which can be activated by the operator in the event of an emergency on board. When activated, CIS supervisors and transit control dispatchers are able to hear what is going on via a high-quality boom microphone located in front of the steering wheel and dispatch emergency responders. There is also a "red alarm" key, which enables one way communication with CIS once pressed. This can be used in events such as fires when immediate assistance is required and two-way voice communication would prove detrimental to safety. [...]
https://en.wikipedia.org/wiki/Toronto_Transit_Commission

Bell to Shut Down Entire CDMA Network by Early 2017

  • by Gary Ng on Tuesday, April 8th, 2014 - 8:57pm PDT
Bell users on the company’s CDMA network can start counting down the days because an internal memo details a nationwide shut down by January 1, 2017, reports MobileSyrup.


Below is the timeline for the shut down:

  • March 31, 2014: CDMA EVDO network partner to shut down in BC and Alberta (excluding Edmonton/Calgary)
  • December 31, 2014: CDMA 1xRTT network partner to shut down in Thunder Bay
  • July 1, 2015: CDMA EVDO network shutdown in Ontario, Quebec, New Brunswick, Newfoundland and Labrador and PEI; CDMA 1xRTT network shutting down in BC (excluding Fort Nelson), Alberta, parts of Quebec
  • January 1, 2017: entire CDMA network to start shutting down
It’s no surprise Bell would consider shutting down its legacy CDMA network, considering the real money nowadays is with high end smartphones and data usage on faster LTE networks.

Telus already has plans to shut down its CDMA network by 2015, a move to cut costs as it moves customers over to its newer 4G/LTE networks through hardware upgrade opportunities.
http://www.iphoneincanada.ca/carriers/bell/bell-shut-down-coma-network-2017/

There may be a reprieve, extended even further:
Bell to start decommissioning its CDMA network on January 31st, 2017
By Ian Hardy

Aug 15, 2016

The end of an era is near.

According to sources, Bell will begin decommissioning its CDMA network, starting in Alberta, British Columbia and the Gaspé region of Québec, on January 31, 2017.

Since its heyday, Canadian carriers have transitioned to the evolved GSM standard, building out networks that support HSPA and LTE, which incorporates SIM cards for easy device switching and billing. We first reported Bell’s intention to shutter its CDMA network back in April 2014. At that time, Bell had not set a specific timeline for the move.

“Decommissioning CDMA will affect all voice, text and data services over the 1XRTT network,” said a source within Bell. Customers currently using a Bell CDMA device will have to move to a HSPA+ or LTE capable device.

After it completes the first phase of the shutdown, Bell will proceed to decommission parts of the network in Saskatchewan on June 30th. It will then do the same in Ontario, Québec and the Atlantic provinces, as well as Fort Nelson, British Columbia, sometime in April 2018. [...]
http://mobilesyrup.com/2016/08/15/bell-cdma-canada-2017/

Note reference to 'SIM Cards'. That may have been the 'SD cards replaced' referred to by East York, or if the very newest equipment being interfaced, it might be a combination SIM/SD card. PR people get these things mixed up...or even go as far as to purposely mislead. Rather than my spelling out a conjecture, there's enough info above to reach several conclusions, none of them good unless steps are taken to ameliorate the compounding levels of possible incompatibility.
 

Attachments

  • upload_2017-1-22_0-59-49.png
    upload_2017-1-22_0-59-49.png
    35.1 KB · Views: 294
  • upload_2017-1-22_1-6-12.png
    upload_2017-1-22_1-6-12.png
    78.1 KB · Views: 321
Last edited:
seriously with all other surrounding agencies running presto for years HOW HARD can it be???!!!! its not like theyre the pilot users....how can yrt , mw, bt etc have worked out the bugs and now being the last installer

The rollout in Ottawa didn't exactly go smoothly and it also came after most of these other agencies. The Presto team either isn't scaling up staff as necessary, or is failing to learn from their own mistakes, or has massive turnover and poor training.
 
Last edited:
The rollout in Ottawa didn't exactly go smoothly and it also came after most of these other agencies. The Presto team either isn't scaling up staff as necessary, or is failing to learn from their own mistakes, or has massive turnover and poor training.
Agreed. It's not that Presto hasn't had problems most everywhere, if not everywhere, it's the case that some systems where it's installed are more problematic than others, or inversely, less complicated to troubleshoot.

As a poster prior has mentioned, the diverse and very large size of the TTC, plus legacy hardware and software systems, and an obvious reluctance to 'spend what it takes' and fully inform the public has compounded the implementation. (and local councils and Presto/Province are as much to blame as the transit system itself). What boggles me is the TTC board's insistence on pressing ahead with further untested implementation when their hardware is so wanting.
 
Agreed. It's not that Presto hasn't had problems most everywhere, if not everywhere, it's the case that some systems where it's installed are more problematic than others, or inversely, less complicated to troubleshoot.

As a poster prior has mentioned, the diverse and very large size of the TTC, plus legacy hardware and software systems, and an obvious reluctance to 'spend what it takes' and fully inform the public has compounded the implementation. (and local councils and Presto/Province are as much to blame as the transit system itself). What boggles me is the TTC board's insistence on pressing ahead with further untested implementation when their hardware is so wanting.

you raise a good point....why couldnt ttc be satisfied with an initial rollowout of a baseline system with just the card and phase in open payment all in one. Is there any other system that is using their units with the led display?
it seem like they took an unnecessary risk with essentially protoypical equipment on canada's largest system and prayed that it would work well. Not to mention they rushed the implementation process (which really shouldve been done earlier but their initial schedule was too lax) so they really are reaping what they sowed. Might i hazard a guess that if they stuck witht the tired and tested G1 units earlier, they wouldve at least had more of an understanding of the potential problems with interfacing since all other agencies have been using the same unit for years.
 
...it seem like they took an unnecessary risk with essentially protoypical equipment on canada's largest system and prayed that it would work well. Not to mention they rushed the implementation process (which really shouldve been done earlier but their initial schedule was too lax) so they really are reaping what they sowed.
In all deference to the TTC, they didn't want Presto initially. Like all Ontario systems, it was forced on them. (K-W has refused to use it, it would be interesting to see how they've made out, because their radio communications system (and perhaps data piggybacked?) is/was abysmal). I'm not defending any level of government or transit org or Presto, but any 'blame' must be shared by all. The point I'm getting to is that had the TTC gone with the card they had invested millions into (I can't recall the name of the card) before being 'blackmailed' into taking Presto, their moving fleet communications system may still have been the weakest link.

And on that point, and further to East York's post on 'cellphone based signal', I've been reading reams of articles to garner information otherwise missing from reports that are unavailable, and urbantoronto published this some months back:
A Bit Awkward? PRESTO Enters Adolescence on the TTC
October 20, 2016 3:04 pm | by Alex Gaio | 15 Comments
[...]
When asked for comment, Metrolinx clarified that the devices installed on the TTC and OC Transpo are connected to the central system through a cellular model and update several times a day. It was also noted that customers should not have to wait more than a few hours to tap their cards on a TTC or OC Transpo device after loading online.[...]
http://urbantoronto.ca/news/2016/10/bit-awkward-presto-enters-adolescence-ttc

Reference to *which* devices (stationary or vehicular) is only inferred, not stated in that article, but let's assume vehicular. Fixed would almost inevitably be by web datastream, albeit when the central server(s) update with Presto's master remains an open question. There may be two or more completely independent systems, in part to isolate malware and attacks. I'm being diplomatic...

No system is going to work faultlessly initially. What still boggles me is the manic agenda of the TTC Board pushing ahead with the subway to surface vehicle tap-on or subway gate tap-off in lieu of all the existing and glaring problems extant, let alone what happens if further sophistication is pressed with communications systems from decades back.

Dammit! You still can't understand what in hell they're saying over public intercom systems in the TTC. Missing an essential alert for delays is one thing (and no-one can hear, I'll blurt out what I've just written to howls of laughter on the subway)(it really ticks me off, especially when in older systems in other cities, you can hear every word, as you should)...so what happens in an emergency?

The TTC had better re-learn how to walk before pretending it can run.
 
Last edited:

Back
Top