Transit Developers Google Group
This group is for software developers both inside and outside transit agencies who want to discuss reuse of transit software, open transit data, and interesting things that they've built.
Still need more commitment.
not mentioned in this thread.
But the update interval of the system is something that is known more or
less a priori. You don't need to think deeply and gather lots of ground
truth data or do lots of fancy post processing to evaluate it. Or even if
fixes at stops, due to the low frequency of those fixes, and that the
low frequency was a constraint of the radio network. Joachim Pfeiffer
repeated the first sentence of Sean's message and guessed the same
recognizing that the "right" answer of course varies depending on the many
context-specific objectives and constraints), I wonder what any of it has
to do with methodologies for validating and evaluating the performance of
Everybody's situation is different, see above ("the concept of getting
on public safety networks for voice and using commercial carriers for
data."). Generally, the FCC mandated spectral efficiency requirements
in the UHF and 700MHz spectrum will tend to push more agencies into
You have clearly stated the arguments that agencies use to support not
using a commercial cellular system. But in working with many transit
agencies I have found that those arguments simply do not hold up. The
non-cellular based systems simply don't meet the specs. It doesn't matter
what the requirements are if the vendor simply cannot meet them. With the
to MTA's radio system replacement project. Here, transit uses its own,
dedicated spectrum that exclusively runs data for transit, purpose
built to meet the agency's needs, using radio equipment that is built
for this use. With "tack-on" I was referring to cases where efforts
You are correct that using public safety/voice channels has not proven to be the best solution. But it should be noted that a large number of AVL systems still use this unfortunate technology and some agencies are still pursuing it (i.e. San Francisco Muni). Therefore it still often needs to be dealt with.
"by-product" of CAD/AVL systems does not support this claim. Assuming
decent poll rates (2/s or better), they just fine without "looking at
historical arrival predictions".
"HART's OrbCAD system only logs GPS data at timepoints, only logs GPS
HART has told us that their update rate is also around 2 minutes, or when a bus passes a timepoint. For HART, the bigger issue is the capacity of their radio system in terms of data bandwidth. They are using a proprietary Motorola radio that was designed primarily for voice, with data as an add-on. HART has told us that they are concerned with system reliability when increasing the update rate to any more frequently than it is now, because of the radio channel.
verification. An automated system for looking at historic arrival
predictions is key because only such a system can thoroughly show how well
a system is truly working. It is the only way you can cover all the stops,
day and night, weekdays and weekends, etc. A separate system for examining