smallspy
Senior Member
They were supposed to know who they were going to buy the gates from 2 years before they actually bought them?
Dan
Toronto, Ont.
|
|
|
- Thread starter P23
- Start date
They were supposed to know who they were going to buy the gates from 2 years before they actually bought them?
Dan
Toronto, Ont.
steveintoronto
Superstar
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.
AlvinofDiaspar
Moderator
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
steveintoronto
Superstar
They were supposed to "plan ahead"! The idea does seem a bit nebulous amongst some circles it seems.
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.
TOareaFan
Superstar
Every project should be on hold indefinitely....just in case another project comes along.
TOareaFan
Superstar
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?
EastYorkTTCFan
Senior Member
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
Senior Member
Same as how they were supposed to know the hight of the new stretcars when they rbuilt St. Clair and the plkatforms on Roncesvale as well?
Kyle Campbell
Active Member
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
mdrejhon
Senior Member
<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:
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>
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:
DSC
Superstar
or that it would be good to spend millions on fixing the old streetcars so they can last for several more years because BBD were going to screw up!
Leo_Chan
Senior Member
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.
mdrejhon
Senior Member
Hey, can't blame me for making it semi-readable to non-programmers.
Code:
// Dumb, simplified computer programming example *wink* *wink* ;-)
Last edited:
rankman
New Member
For me the real issue is whether he uses tabs or spaces in his code.
Student99
Active Member
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.
++