News   May 10, 2024
45 Storeys Proposed to Replace 10 Storeys in Islington Village
 2K     2 
News   May 10, 2024
Crane Comes Down at Menkes' Festival Condos as Phase 2 Breaks Ground
 3.2K     0 
News   May 10, 2024
LCH Developments Launching Cliffside Condos Above the Scarborough Bluffs
 1.4K     0 

TTC: New Fare Gate Installation

Student99 said:
So... they installed new old-style fare gates at union a couple years ago, only to rip them out shortly later? Why didn't they get their act together and install the new-style when the station was rebuilt? What a waste of money.
Click to expand...

They were supposed to know who they were going to buy the gates from 2 years before they actually bought them?

Dan
Toronto, Ont.
 
AlvinofDiaspar said:
I think they didn't have a vendor selected before the reopening (much less leading up to construction) - that I can understand. The generally deficient design of the expansion is not so forgivable.

As to the "red shirts" - some are good, others are less useful than vegetables. And at Union, all stand in the way (along with clueless folks who stand in the middle of the concourse asking for directions, checking the phone, etc.)

AoD
Click to expand...
I actually feel sorry for the 'fodder' the TTC hires to make it look like they care. Paid minimum wage, and the agency they're hired through gets a cut of that. They're not allowed to sit down, have only minimum breaks. I guess it's better than being totally unemployed.
 
steveintoronto said:
I actually feel sorry for the 'fodder' the TTC hires to make it look like they care. Paid minimum wage, and the agency they're hired through gets a cut of that. They're not allowed to sit down, have only minimum breaks. I guess it's better than being totally unemployed.
Click to expand...

I do too, until I have noticed that some have zero contextual awareness during rush and became part of the problem they were supposed to help solve.

AoD
 
smallspy said:
They were supposed to know who they were going to buy the gates from 2 years before they actually bought them?

Dan
Toronto, Ont.
Click to expand...
They were supposed to "plan ahead"! The idea does seem a bit nebulous amongst some circles it seems.
AlvinofDiaspar said:
I do too, until I have noticed that some have zero contextual awareness during rush and create more problems than they solve.
Click to expand...
That's the "fodder" aspect. For the ones stuck at the ends of platforms at blocked off stair exits, I always try to strike up a conversation to break what must be an incredible monotony.

In all fairness (groan) they do change their positions around the station so that their monotony is broken into segments.
 
It seems the new gates have been installed for some time at St Andrew.....but not operational......is there a lot to be done after installation before the switch is flipped? Is the delay at this station normal in length?
 
Kyle Campbell said:
Just for my own curiosity, did they prep the gates for eventual zone or distance pricing? When they were purchased, the TTC was pretty adamant about not having such a system, that changed (or you could say was overruled by Metrolinx) much later
Click to expand...
Tne new fare gates are capable of having tap out on them it's just a matter of intsarimg the reders on the back side of them. The fare gate itself doesn't process anything it just finds out from Preto that the card is valid and either has the money or a transit pass on it.
 
EastYorkTTCFan said:
Tne new fare gates are capable of having tap out on them it's just a matter of intsarimg the reders on the back side of them. The fare gate itself doesn't process anything it just finds out from Preto that the card is valid and either has the money or a transit pass on it.
Click to expand...

I just meant I wondered if there was a connection point on the gate that would allow a second reader to be installed or if it would require something more elaborate to convert
 
<IT programmer mode>

Occasionally (not always) I see the new gates sometimes have erratic delays in opening their gates.

Sometimes when I run up to them, they hesistate, and open half a second later.
Other times, they whoosh open almost immediately.

I wonder what is causing this variable hesitation:
-- Variable processing loads in the firmware?
-- Internal poll delays?
-- Light reflections in sensor?
-- False-detection algorithms (e.g. fast moving legs versus reflections/shadows)?

This is important; a person late for work, jogging briskly at 5 meters per second, a 1ms difference means 5 millimeters difference (1/1000 of 5 meters equals 5 millimeters). 10 milliseconds delay means the person has moved forward a massive 5 centimeters forward. That can mean the difference between whoosh-through or "whoa! doors are not opening". Now, 100 milliseconds delay means.....yep..... HALF a meter!

Even if you're moving slowly, at a brisk walk, that's still many centimeters. People's brisk walk speeds from day to day stay extremely consistent over the short time period at similar energy levels (they often vary less than 5%). So don't vary the door-open behaviour by more than 5%. If the doors are not predictably open by the time you're about to crash into them, then the doors aren't really "feeling" reliable.

I hope the door programmers aren't using really bad polling like:

Code: 
// Dumb, simplified computer programming example
while (sensor.Tripped == false)
{
    Thread.Sleep(100); // wait 100 milliseconds
}
Doors.Open();

That would add a variable delay like [0..100] milliseconds. That is bad. 100 milliseconds erraticness is too big, and right now the door-open delay is more erratic than this today --

I'd daresay the erraticness of delay can be up to 300 to 500 milliseconds at its worst. It's not always that bad, but if that even happens once in a while -- 1 in 20 - that's bad for trusting the doors.

Door opening delay ideally should be millisecond exact, to feel predictable. However, even 50ms is superior to the current 300ms-500ms range of unpredictability. Just a mere few milliseconds is actually human perceivable -- the difference between whoosh through the doors and suddenly stopping your movement to wait for the doors to open. A variable delay can make it extremely hard to choose a speed to go, that you would trust the doors to open-on-time by.

Right now, they're rushing a deployment, but ultimately, the firmware should be refined over time.

The good thing is, they are firmware upgradeable remotely (well...eventually). The hardware is probably fine, as long as they behave like the whoosh moments.

Also, some resonant-vibrating-compensating algorithms should be added to the wide wheelchair doors. Basically, intelligently modulate pulses to the door-open/close servo motors to prevent bouncy opening-closings. They'll also open/close faster as a result. The mass of the doors is known, so you can pre-program a known motor-pulsing algorithm to more smoothly (and quickly) open the mass-laden wide gates without the bounciness I see.

The first attempt to open as fast as possible causes the door to kickback that it almost completely pauses at 45 degree angles. Dialing the initial motor acceleration down a notch will cause faster top-speed at 45 degree open, and cross the finish line (fully open) sooner.

</IT programmer mode>
 
Last edited:
  • Like
Reactions: PMT
mdrejhon said:
<IT programmer mode>

Occasionally (not always) I see the new gates sometimes have erratic delays in opening their gates.

Sometimes when I run up to them, they hesistate, and open half a second later.
Other times, they whoosh open almost immediately.

I wonder what is causing this variable hesitation:
-- Variable processing loads in the firmware?
-- Internal poll delays?
-- Light reflections in sensor?
-- False-detection algorithms (e.g. fast moving legs versus reflections/shadows)?

This is important; a person late for work, jogging briskly at 5 meters per second, a 1ms difference means 5 millimeters difference (1/1000 of 5 meters equals 5 millimeters). 10 milliseconds delay means the person has moved forward a massive 5 centimeters forward. That can mean the difference between whoosh-through or "whoa! doors are not opening". Now, 100 milliseconds delay means.....yep..... HALF a meter!

Even if you're moving slowly, at a brisk walk, that's still many centimeters. People's brisk walk speeds are extremely precise (they often vary less than 5%). So don't vary the door-open behaviour by more than 5%. If the doors are not predictably open by the time you're about to crash into them, then the doors aren't really "feeling" reliable.

I hope the door programmers aren't using really bad polling like:

Code: 
// Dumb, simplified computer programming example
while (sensor.Tripped == false)
{
    Thread.Sleep(100); // wait 100 milliseconds
}
Doors.Open();

That would add a variable delay like [0..100] milliseconds. That is bad. 100 milliseconds erraticness is too big, and right now the door-open delay is more erratic than this today -- I'd daresay the erraticness of delay can be up to 300 milliseconds.

Door opening delay ideally should be millisecond exact, to feel predictable. However, even 50ms is superior to the current 300ms-500ms range of unpredictability. Just a mere few milliseconds is actually human perceivable -- the difference between whoosh through the doors and suddenly stopping your movement to wait for the doors to open. A variable delay can make it extremely hard to choose a speed to go, that you would trust the doors to open-on-time by.

Right now, they're rushing a deployment, but ultimately, the firmware should be refined over time.

The good thing is, they are firmware upgradeable remotely (well...eventually). The hardware is probably fine, as long as they behave like the whoosh moments.

Also, some resonant-vibrating-compensating algorithms should be added to the wide wheelchair doors. Basically, intelligently modulate pulses to the door-open/close servo motors to prevent bouncy opening-closings. They'll also open/close faster as a result. The mass of the doors is known, so you can pre-program a known motor-pulsing algorithm to more smoothly open the mass-laden wide gates without the bounciness I see.

</IT programmer mode>
Click to expand...
I don’t know what triggers me more: You putting block open brackets on their own line, or the Urban Toronto Forums having code support but not have Twitter tweet imbedding.
 
Leo_Chan said:
I don’t know what triggers me more: You putting block open brackets on their own line, or the Urban Toronto Forums having code support but not have Twitter tweet imbedding.
Click to expand...
Hey, can't blame me for making it semi-readable to non-programmers. ;)
Code: 
// Dumb, simplified computer programming example *wink* *wink* ;-)
 
Last edited:
smallspy said:
They were supposed to know who they were going to buy the gates from 2 years before they actually bought them?

Dan
Toronto, Ont.
Click to expand...
Yup! When the station was rebuilt, the presto switch was in the works already. I think even a few stations had some presto readers. They could have expedited their selection process for the new fare gates. Or heck, re-used the old ones temporarily. But instead they bought shiny new old-style gates only to rip 'em out a short time later? Hope they got some scrap metal value out of them.
steveintoronto said:
They were supposed to "plan ahead"! The idea does seem a bit nebulous amongst some circles it seems.
Click to expand...
++
 
You must log in or register to post here.

Back
Top