itmaybeokay

I'm not entirely certain how the feed is updated by the train. Presumably, it's BLE sensors near/in the stations networked by TCP/IP. In terms of how reroutes are handled, the feed has a route indication, but individually lists stops - each "trip" has every stop the train will arrive at defined, along with arrival and departure times. it's actually GTFS-Realtime, which is a little more of a pain in the butt to interpret because you have to run it through google's protocol buffers, but like, 5 lines of python and you're good to go. So here's something I just pulled from the NQRW feed: trip { trip_id: "125700_N..N" start_date: "20180226" route_id: "N" } stop_time_update { arrival { time: 1519702086 } departure { time: 1519702086 } stop_id: "R01N" schedule_relationship: SCHEDULED } So, based on this document http://web.mta.info/developers/data/nyct/subway/Stations.csv "R01" is Astoria-Ditmars, N I assume is the railroad-Northbound direction So the trip ID, weirdly, is encoded in "hundreths of a minute past midnight" so that train left coney island heading north at 8:57 PM. The 2056 November Stillwell then - That train would be scheduled to arrive at ditmars at 10:07, here we see an arrival time encoded as Epoch time - or seconds since Jan 1 1970 - (pretty sure you know this one Bob, but for everyone else, this sounds weird, but it's how most computers tell time) Anyway, that epoch time translates to Monday, February 26, 2018 10:28:06 PM. 21 minutes late - sounds about right. The schedule_relationship field seems specifically geared toward reroutes - The MTA description of it, however, doesn't make a lot of sense: "It is our recommendation that the realtime feed train data should replace that of the static train schedule data. There will be times when a link between the schedule trip and the realtime trip may be possible but it is not an absolute. Realtime trip information will be made available approximately 30 minutes before the scheduled origin time." -_____- Presumably an extra or a put-in would show up as "UNSCHEDULED". Likely so for reroutes. Anyway, the point is, while the general URL http://datamine.mta.info/mta_esi.php?key=GET-YOUR-OWN-KEY&feed_id=16' (api key redacted) will give you the whole NQRW line, you add a &stop_id=whatever to that and you can get the arrival times for a specific stop - interestingly a request formatted in that manner will give you ALL trains scheduled at that stop, not just on the feed you requested. E.G. that submitted to the NQRW feed at queens plaza will also show the M and the E. Sorry if anyone is bored by this technobabble. I hope more than Bob and I find it interesting.

I'm reasonably certain the full-color LCD clocks integrate the CPU into the case of the display and the only required connections are network and power. The clocks are actually running a full-screen kiosked Chrome browser (I've seen them error out) - so they're loading a web page to display the countdown information. Cable Length would be an issue. HDMI needs a repeater every 100 feet tops - 50 feet ideally. The repeaters can get pricey. And also require power. So easier just to hang a cpu in the display cabinet. I get that the systems are incompatible - but this is so so easily remedied. It takes a trivial amount of hardware and code to translate the GTFS feed provided by the current bluetooth system into a bicolor led matrix. There are people online who will happily sell you one for your apartment. (They're also jerks who haven't open-sourced their code otherwise I'd have one running on the hardware I have already. Jerks.) The point is, the full-color LCD countdown clocks are ultimately fed by a web server which creates an HTML page from GTFS data. The same server could also serve the data as JSON strings - or whatever - that one could parse with a raspberry pi and bitbang onto a LED matrix. The hardware I suggest is a dodgy implementation - but my point is - from the JSON you could translate it into whatever data format the extant and new LED matrix displays savor the flavor of.

Super random, but I thought some of you might enjoy it. Made this for a friend in a transit-oriented facebook group. Mission was "what if there was an entirely transit focused TV station in ny in 1976, what would that look like?"

Northern Blvd and 67 ave are actually on the ESI list already.

The ones next to some doors? If you look on the ground, under the seat beneath the star sticker, there's a locked metal box that has some brake valves in it. The sticker is there to make it easy to find from eye level. I forget what the triangle one was, master door controller it might have been. Can't find the answer and the MTA folks aren't allowed to tell you so that's about as specific as it's gonna get.

I don't think it would help much, since the only other thing stopping queens plaza is the R. Some local riders between 71 and Roosy will take it to transfer to the E or F at Roosy - but remember those are both going via 63rd and not stopping at Queens Plaza. Yes - people at the intermediate local tracks could backtrack to transfer but would they? I like the idea because hey what a novelty to get to brooklyn some night on a one seat ride. But i'm not worried about evenings - i'm worried about the rush, getting to manhattan.

Honestly, unless they're supplementing the R - queens blvd will be a nightmare. R trains during the peak of the rush generally lose like 3-4 minutes to crowding on a good day. This looks problematic enough that I put in for the week off. -______-

Do you have Adobe Illustrator? If you download the official PDF from the MTA and run it through this website to remove the edit password: https://smallpdf.com/unlock-pdf You can edit it as a vector with all the layers intact in Illustrator. It's still a little daunting, but with patience you could make it look as good as the original at any size! (such is the magic of vector graphics) I'm looking at it now, entire lines are isolated under clip groups with paths underneath them. Youd have to slice up the paths, duplicate, and nudge around, moving text out of the way and fixing station icons accordingly. Painstaking work - but would be very cool.

Actually - Rob, what do you know about the type of bearings those trucks use? Ages ago when I had this cranky old BMW, one of the rear wheel bearings went dodgy on me and the rumble resonated through the body making it sound like I had put a giant playing card in the spokes of a 50 foot bicycle. I feel like the sound of a failed (or aging) bearing resonating through the wheels and rails could sound like this. But yeah - if it's just the gearbox, I at least don't remember this noise, which means either 1- The gearboxes are doing this as they age - which would generally be a bad sign as that means parts are different geometry than they used to be. 2- Replacement gearbox parts or gearbox assemblies do this and the old ones don't.

I'm not sure if this is what they're talking about - if so, sounds like, might be gearbox? Note that the inverter whine starts before the train moves, but the 'howl' seems to pitch proportional with train speed.

The trouble is if you "extract" one R train you could wind up with a headway of 20 minutes. Adding M trains doesn't help that much, considering I have to choose a broadway or 6th ave station before I board. The 46's don't deal with crowding super well - 8 less doors per train. The following QBL R is going to be crowded, and subsequently delayed. Further - if it's an R-46 set you're sending to 96 - harder to communicate to passengers its terminal. Yes there's always the PA - but it doesn't always work. None of this is the end of the world - I just think the change would hurt more than it helps.

I do agree that wrapping cars and the "cuomofied station initiative" are utter wastes of time - but I would argue that rolling stock is as important as tracks and signals. Just as it is senseless to buy a new Bentley to drive down a potholed dirt road, it's senseless to eschew the vehicular upgrades, repave the road to autobahn standards, and expect a 50 year old jalopy to perform admirably. The road, the signals, and the rolling stock must all be working in good order. Since car replacement is, seemingly unavoidably, a lengthy proposition, I would argue it is important they continue working on that as they simultaneously work to maintain and update the physical plant. I'm not saying the cars are of greater importance at all, but they're of comparable importance. To a lesser extent, realtime data - not per-se the platform clocks, but the data feeds, are a somewhat important stop-gap measure. Before I leave home or before I leave work, I can check my phone and see if there's a huge gap, or a conga line, which would indicate a problem with more granularity than a service alert. I agree that probably not everyone uses the realtime data like I do and it might be a leap for plently to make the kind of logical leaps but - well - assuming they are working to simultaneously maintain and update the plant, the real-time data is useful in the interim and will be useful going forward. I'm in full agreement that the #1 priority should be tracks and signals though.

I found a rendering, but only of the station entrances. Trust me, you do NOT want to see what the downtown stairs exit from.

In fairness, I don't think they are going to be using QR for standard farecards, just for fare payment from within the MTA eTix app. That reader seems to also contain NFC - at least, it has an NFC logo on it. On the one hand, I agree - QR - or really, any form of optical recognition is both backwards and failure-prone. On the other hand, without dramatically upending the nature of - and requirements for - their LIRR mobile ticketing solution - I'm not sure what else you could do. The options are either: 1) Disallow combination monthly LIRR/Metrocard purchases via the app 2) Require NFC compatible device for use of the app, and revamp the app to use NFC - which would basically require switching partners, or Masabi changing JustRide to support something beyond optical recognition. The thing is - QR actually does make sense for many applications - Rail: scanners needed only by conductors/ticket collectors, so you've got maybe, 200 in a system. Air: scanners needed at gates and security checkpoints - not that many. In both these scenarios they are operated basically by employee. Venue: You get the point. NYC Subway: Over 4,800 optical scanners to be operated by any one of like 3 million people, none of whom care about the disposition of the scanner. Masabi is trying to shoehorn the solution they have into the system, and yes thankfully they are including other modes such as NFC in their READERS - but - yeah. I don't see an alternative where they keep the LIRR eTix platform, and allow monthly metrocard purchase in the app, but don't have to support QR EDIT: It's also worth noting that Masabi's SLA is for 3 9's - or 99.9% uptime. Which sounds great... Except that means there can be 8 hours a year when you just can't get through a turnstile - and somehow I doubt they'll just open the gates if the system goes down.

That looks like what's described in this article from last summer https://www.theverge.com/2016/8/24/12614986/mta-subway-new-york-mobile-ticket-masabi-mastercard This looks like it would read NFC as well - which I hope is what they go with for primary fare-payment, as I'd imagine the glass getting dirty on these things would present a hindrance to their quickly and accurately reading the code. I know QR has some redundancy, but - idk man, optical recognition seems like the worst thing in the world in the subway - just an instinct. Also relevant, MTA Press release from July 2016 http://www.mta.info/press-release/mta-headquarters/governor-cuomo-announces-accelerated-rollout-mta-etix-mobile Takeaway #2: Given the way people fumble with metrocards, this is gonna make people drop their phones, and then the QR won't scan from a broken screen.

I'm not trying to rip you to shreds - trust me - I live in astoria - the go's are annoying because it means if i'm late to work, I'm EXTRA late to work. I just don't have any patience for the outlook that service changes are somehow inconvenient by design, that GO's are instituted in convey maximum spite. Frankly - this is a narcissistic position to take, it lies adjacent to the point of view where any hurdle on one's path is an intentional attack. I know too many people like that and if you think about it, you probably do as well. None of us, individually or collectively are so important that powers at the transit agency want to give us the shaft. Nobody is sitting in the rail control center pleasuring themselves to the thought of those crowded trains in astoria. It isn't about me, it isn't about you, it's about trying to run a railroad.

Oh - it's another "Dark Cabal Secretly plotting to intentionally screw people over and or save money" thread, then. I'm pretty sure the GO doesn't save them one red cent. And if your theory were true, would they not suspend the W evenings post-rush as well? My god - what a horrifying thought. But I'd reckon the whiny hipsters would rather move deeper into BK than be caught dead moving to queens. "theres no music scene there, broh". Also - just pointing out that those hipsters are generally whining because of complete shutdowns of sections of the line. I'm not defending them, but you're literally suggesting a conspiracy and claiming that a neighborhood is getting the shaft over a 30-train non-rush-hour reduction. I won't go so far as to accuse you of whining - but - I mean, there's irony, no? They can't do outdoor work overnights on elevated lines, as you probably know. So, any and all maintenance on the line has to be done mid-day or weekends. It has NOT been every other week. For october, so far the GO is only scheduled the first week. Next week there is no GO. Have you considered the Q101 to steinway street? I agree that it's not a conspiracy. (you probably meant to say "not a conspiracy theory"). It has nothing to do with adding service to 2nd ave. It has to do with reducing the TPH on the astoria line to allow work to be done. In order to do that, the W gets displaced. It used to turn at 57/7 - but you can't turn trains there without mucking up the Q - easier to just send them north to 96, and reduce their frequency to 3tph so they don't interfere much while crossing. Leave the 68's out of this, they're great on the astoria line. I've never seen a 68 delayed at ditmars so they could change the rollsigns. If a W pulls in and the next train is supposed to be an N, they'll often just send the second train that pulls in out first if it's NTT or signed as a november. It's not hypocrisy. Not even remotely. That change affected the TPH at 9 stations and then displaced riders at 5 more stations onto a shuttle train to transfer, and then transfer back if they wanted the 5. The Astoria line is 6 stations. You're talking about an extra 20,000 riders per day at the bronx stations, with trains that hold less passengers per. Not sure why I go on with these detailed rebuttals, but there you go.

How is maintaining these things not going to be a nightmare? The lighting on the canopy, and in the handrails, and behind the exit signs? I cannot imagine any of this looking good in 10 years.

If it's the same beeping that's on the 1 train, it's the alarm on the cover for the emergency brake. As the train vibrates and accelerates sometimes it moves the cover enough to momentarily lose contact with the switch, and it beeps. Sometimes, it will be a longer solid beep if the cover's significantly out of place, and if I'm close I give the thing a good rap with my hand, which usually takes care of it.

I actually timed it out one week and averaged it at 46 st. Not sure if these are remotely helpful to anyone but meh - here ya go. These were times until the doors closed. 2 Stations away: 3min 45 sec 1 Station away: 2 min 25 sec Now Arriving: 1 min 5 sec

Service Change Posted: 01/09/2017 8:20AM Due to a water condition at W 4 St-Washington Sq, the following service changes are in effect: Some southbound and trains are running on the line from 59 St-Columbus Circle to W 4 St-Washington Sq. Southbound trains are running on the line from Jackson Heights-Roosevelt Av to W 4 St-Washington Sq. Some southbound are running on the line from Court Sq to Bergen St. There is no train service between Forest Hills-71 Av and Essex St in both directions. Expect delays in ,, , , , and train service. Allow additional travel time.' woooooowwwww that's a bad monday morning.

I presume the system that feeds the clocks also gives information to the dispatchers, kind of like ATS. I would be shocked if it did not. That said, I doubt the "smart reroute" has a lot of viability. Sure, you could have the rerouted E skip 57th st because it doesn't normally stop there, but what about the passenger that was trying to go to 7av? If the train is rerouted via a line, it should make the stops on that line. Skipping the station, I don't think it would save all that much time, and the level of confusion it would cause seems not with it. But if you REALLY want to get jiggy with your data - start processing anonymized IMEI's from the Transit Wireless network. Say whaaaaaaat? Well, by looking at the stations where an individual phone enters and exits the system, a new, far more granular picture of ridership can be generated. You can pass this through a cryptographic hash or something similar so it's not actually traceable to a particular riders identity to ease privacy concerns. For bonus points: You can extrapolate the number of passengers within a margin of error aboard a given train. Double bonus points: Over days to months, by comparing ridership load to OTP you can extrapolate the future delays on a given train, and perhaps ready a put-in or hold a leading train to help offset.

Hey there's the first Romeo's via 63 since construction got underway in earnest on there haha

Hey guys, does anyone know if they request the last 5 years, or lifetime driving records? for reference - There was an accident that was my fault 13 years ago, and a speeding ticket like 10 years ago, and I'm wondering if that would put me in the thanks-but-no-thanks pile before I spend moneydollars on this. Thanks.

As was stated LED and CFL are available in a great many color temperatures. Any fluorescent - except one specifically designed for film/photo has a green spike in it's response. Compared to the fluo station lights those look LED to me - but not a fair comparison. The shape of the bulb is different for LED but it's not apparent in the video the shape of the bulb. Honestly - I could have sworn I saw the heatsinked/only-dome-lit bulbs in the 2700k variety - but you've seen a lot more of the tunnels than I have. 4/5000k leds are generally cheaper and more lumens/watt (hence why they're used for streetlights now) so maybe thye would stay with them for tunnel lighting if they were going LED. TBH its possible they ordered the bulbs for SAS years ago before the LED became common. I'm just a bit of a lighting enthusiast which is why I was like what do you mean CFL. (big part of cinematography)