Green Line LRT

[grant1simons2]

I have too. So don't think that I haven't, there are still sketchy bad people in this world

[Tcmetro]

I'd be worried about my bike being stolen anywhere, but especially in the central cities. Growing up near Dinkytown, it was quite common for my friends to get their bikes stolen, locked or unlocked.

[talindsay]

I simply won't take my road bike anywhere that I can't take it in with me. Working at the U and living in Longfellow, most people I know have had bikes stolen, including me, and in almost all cases they were locked up with good locks. A friend of mine had his bike stolen in ten minutes while he was in the alumni center on campus, with the bike properly locked in the muddle of the day - and it wasn't an expensive bike.

So yeah, there's a reality that, nice neighborhood or not, bikes are easy to steal and plenty of people do it. I wouldn't lock my bike up at any of the green line stations - I'd leave it securely in my office and then ride the train. But must people don't have an office 200 feet from a light rail station.

[Anondson]

Mayor Coleman has his say on signal timing.

http://www.startribune.com/opinion/comm ... 14891.html

We learn Met Council likes detectors over GPS.

[MNdible]

"Despite a six-month period designated for testing, Metro Transit, for whatever reason, was not able to begin running the trains on a full schedule until a week before the June 14 opening."

We also learn that Mayor Coleman is passive-aggressive.

[twincitizen]

I loved that too, "for whatever reason".

You just know he had to take a little shot at Metro Transit after Brian Lamb's recent remarks blaming the city.

[nate]

My train this morning just barely missed green lights at Lexington, Dale, and Western. An extra 10 seconds of green light for the train to clear these intersections would have turned an annoyingly-slow 18 minute ride from Lexington to Central into a smooth 13 minute ride.

It's disappointing that this continues not to be brought up. Coleman talks about "optimizing" the line without inconveniencing car traffic, but this means the trains have a roughly ~15 second window in order to make it through the major intersections. That's a very narrow window that, once missed, creates a delay that cannot be made up for. There needs to be some flexibility on the green lights at major intersections in order for the line to run as planned.

[talindsay]

"Despite a six-month period designated for testing, Metro Transit, for whatever reason, was not able to begin running the trains on a full schedule until a week before the June 14 opening."

We also learn that Mayor Coleman is passive-aggressive.

Yeah, that was pretty ridiculous. Way to pass the buck. I like that he mentioned that but he didn't mention how St. Paul didn't start trying to set up the timing on their lights until a month before the opening.

[mulad]

Definitely interesting to hear that there was a debate about whether to use loop detectors in the tracks vs. something based on GPS. Of course, there isn't any single solution that's really best for determining train positions -- the ETCS system for regular and high-speed mainline passenger trains in Europe has some versions which use a combination of track sensors, GPS, wheel speed sensors, and even ground-facing radar as a backup mechanism for determining vehicle speed. They can use a specialized implementation of the GSM cellular network to regularly send and receive data, though some versions of ETCS only use detectors/transcievers set between the tracks (known as "balises").

An urban street rail line is a significantly different beast, but it would be nice if we could get a detailed comparison of the best-of-breed technology out there versus what has been put on the Green Line. I definitely expected that whatever system was implemented would be transmitting data continuously to tell the signals where the trains are. It's been surprising to learn that the signals only get intermittent updates when trains pass over detectors. Unfortunately, that appears to have some nasty side-effects -- I've mentioned before how I've seen trains get "forgotten" by the traffic signals along 4th Street in downtown Saint Paul if they miss a signal. Some signals along 4th only include a train phase in the signal cycle if a train has been detected, and it appears to assume that a train gets through, even though the crossover tracks by TPT have their own set of interlocking signals which can be in conflict with what the traffic signal thinks is the correct thing to do. There's also a pair of crossovers near Pascal (just east of Snelling) which I'm suspicious may cause problems of their own.

Anyway, like Mayor Coleman said in his op-ed, I don't think that a design using track detectors is fatally flawed, but it would clearly be a lot more finicky in terms of timing.

I still tend to think the "green wave" of lights along University should be set up based around the stair-step stop-and-start travel pattern of the train, rather than the linear motion of cars. I doubt many drivers would even notice.

[VAStationDude]

On a westbound train one minute late into the Fairview station. Actually made up time on University. Was three minutes late out of rice Street Capitol.

[Mdcastle]

My only thought is traffic engineers go with what they're comfortable with. Track sensors have been in use for many decades but GPS has never been used here before. Probably thought they could make old technology work rather than learn and implement something from scratch.

[Silophant]

Idk if it would even be from scratch, though. All the Metro Transit buses have GPS location implemented, and there's at least one route that uses it for signal priority. Sure that's in Minneapolis, not St. Paul, but that shouldn't be an excuse.

[EOst]

Another person got hit this morning at Westgate.

[ProspectPete]

Unfortunately it appears to have been a fatal accident. The hearse just arrived.

[HuskyGrad]

Woman was wearing headphones. http://www.startribune.com/local/minnea ... 78391.html


Sent from my iPad using Tapatalk

[Mdcastle]

Didn't know Minneapolis already used GPS already, but I'm not sure how helpful it would be for the Green Line.

GPS is mandatory for something like buses, where there is no possibility of fixed track sensors and you need more distance than is provided by optical sensors. For rail, you're still limited by the traffic control equipment. I'm not a traffic engineer so I might be incorrect on some points, just a nerd who plays with traffic control equipment in his garage and basement.

The preempt input on a traffic controller is a digital on/off; it provides 24 volts DC that when grounded tells the controller to go into whatever alternative programming has been entered. GPS is provided by externals devices (including some by 3M, more noted for it's ubiquitous optical preemption systems). When a train passes a fixed point, it grounds the input. In other words it doesn't say "Train coming at 30mph" It says "train passing now". Just like a track sensor. Light rail preemption is a tiny, tiny percentage of the installations, so it's not worth it for the controller manufacturers to do something better so it's up to the engineers to make things work with current technology. Of course there are multiple pre-empt inputs, but still a fixed number. Minneapolis has the advantage because they use 2070 series controllers, where you buy the hardware and software seperately, or even write your own programs; all the other agencies use NEMA controllers where you buy the hardware and software as a package. So Minneapolis in theory could write a program to deduce the speed of a train by when it passes various GPS locations, but St. Paul is stuck with available software.

The main advantage of GPS is if a train sensor doesn't work well in a particular location, you can move it by as little as 10 feet just by programming instead of moving a physical sensor. And you can put the controller in pre-empt at different times depending on the train speed, but once it's tripped, if the train slows down or speeds up there isn't a continuous input to the controller telling it where the train is allowing it to adapt for that once it's in preempt.

[Minneapolisite]

Woman was wearing headphones. http://www.startribune.com/local/minnea ... 78391.html

So sad. All it takes is you forgot to look one time.

[David Greene]

Woman was wearing headphones. http://www.startribune.com/local/minnea ... 78391.html

So sad. All it takes is you forgot to look one time.

Indeed. Required reading.

http://www.metrotransit.org/close-call- ... y-reminder

[Silophant]

Didn't know Minneapolis already used GPS already, but I'm not sure how helpful it would be for the Green Line.

GPS is mandatory for something like buses, where there is no possibility of fixed track sensors and you need more distance than is provided by optical sensors. For rail, you're still limited by the traffic control equipment. I'm not a traffic engineer so I might be incorrect on some points, just a nerd who plays with traffic control equipment in his garage and basement.

The preempt input on a traffic controller is a digital on/off; it provides 24 volts DC that when grounded tells the controller to go into whatever alternative programming has been entered. GPS is provided by externals devices (including some by 3M, more noted for it's ubiquitous optical preemption systems). When a train passes a fixed point, it grounds the input. In other words it doesn't say "Train coming at 30mph" It says "train passing now". Just like a track sensor. Light rail preemption is a tiny, tiny percentage of the installations, so it's not worth it for the controller manufacturers to do something better so it's up to the engineers to make things work with current technology. Of course there are multiple pre-empt inputs, but still a fixed number. Minneapolis has the advantage because they use 2070 series controllers, where you buy the hardware and software seperately, or even write your own programs; all the other agencies use NEMA controllers where you buy the hardware and software as a package. So Minneapolis in theory could write a program to deduce the speed of a train by when it passes various GPS locations, but St. Paul is stuck with available software.

The main advantage of GPS is if a train sensor doesn't work well in a particular location, you can move it by as little as 10 feet just by programming instead of moving a physical sensor. And you can put the controller in pre-empt at different times depending on the train speed, but once it's tripped, if the train slows down or speeds up there isn't a continuous input to the controller telling it where the train is allowing it to adapt for that once it's in preempt.

Ah, cool. Makes sense that St. Paul's having trouble getting it to work properly then, and that close misses at one light make for compounding problems down the line.

[David Greene]

So Minneapolis in theory could write a program to deduce the speed of a train by when it passes various GPS locations, but St. Paul is stuck with available software.

The main advantage of GPS is if a train sensor doesn't work well in a particular location, you can move it by as little as 10 feet just by programming instead of moving a physical sensor. And you can put the controller in pre-empt at different times depending on the train speed, but once it's tripped, if the train slows down or speeds up there isn't a continuous input to the controller telling it where the train is allowing it to adapt for that once it's in preempt.

It wouldn't solve the changing speed issue and would require separate software from hardware, but increasing/reducing a delay loop in the software after the sensor is trigger would effectively "move" the detector further from/closer to the intersection. Of course, if the delay loop is already zero you can't "move" it any closer.

If the detectors are physically "close enough" to the intersection, changing speed shouldn't be much of a problem, right? OTOH, the physical distance limits the maximum value of the delay loop, obviously.

It seems to me like the biggest problem here is software lock-in, something the Free Software movement has been on about for nearly 50 years.