Frequently Asked Questions, Transit Division

Sensors are active infrared, designed and manufactured by Infodev specifically to count passengers entering and exiting public transit vehicles. The technology is proprietary, therefore detailed technical information is not provided.

In general, the sensor detects the presence or absence of passengers, along with their direction. It solves the problem caused by passengers pausing for various reasons under the sensor before definitely moving across the detection zone. For example, a passenger slightly popping in to ask if the driver goes to a certain bus stop and popping back out once he receives the answer will not be counted.

We have installed both low floor and stair buses: Nova Classic, Nova LFS, New Flyer and Van Hool.

Usually, one sensor is sufficient to cover an entrance. Some buses with very wide exits require 3 coordinated sensors

Accuracy is a complex subject which we can discuss at length later. However as a preliminary approach, in low-traffic stops, accuracy is around 97% going down to 91% in high-traffic stops.

Getting 80 % of locations right from GPS readings is easy, but such a result is not really usable. The details are necessary. We have a very robust algorithm integrating data from various "senses" (GPS, odometer, tables) which produces recognition as complete as possible given the data. Right now, processing is done offline. If it were necessary to produce real-time recognition, for example for next stop announcements or priority signalling, it could be coded in the data loggers themselves.

Note that producing the raw GPS coordinates has the advantage of showing everything, allowing fine tuning of tables and a better understanding of how the GPS works in various parts of the city.

We use two complementary sources of data: non-differential (conventional) GPS and odometer readings. The GPS by itself is insufficient for state-of-the-art position recognition. Sometimes the GPS can miss readings because of the urban canyon effect or give false readings due to reflections from buildings. These "holes" and false readings must be filled using complementary data. The odometer is also the easiest way of deriving accurate speed measurements.

Recognition of stops is very close to perfection: 0 metres! For non bus stop-related halts, there are many different approaches: one consists of using a form of post processing DGPS (PPDGPS) relating vehicle measurements to fixed GPS measurements, usually installed in the Transit company's garage or office. Resolutions of 10M are common with this method.

The receiver is mounted inside the data logger, and the antenna is fixed on the top of the bus.

Inputs are many: passenger detection sensors, door switches, GPS (atomic clock time, longitude, latitude, heading, GPS quality), odometer, motor On/Off status (optional).

The system provides all requested data except for ramp deployment. Since our system is a generalized on-board data-logging co

This could be done on-board, but at present it would require special work to integrate the algorithm. The users of the data will have locators, because our software will provide this information.

Depending on the level of activity, the logger will store from 1 to 4 weeks of data. The user is in no rush to download the data before losing it. Memory is 1 Mb.

Data is usually transmitted via our high-speed infrared link. It communicates at up to 115 000 bauds over a range of 3 to 7 metres. One end of the link is placed inside the bus and the other end at one of the fuelling bays in a garage. Download is fully automatic, without any human intervention.

An auxiliary means of downloading data is to use our hand-held data collector. This device is used for manual downloading in the event that data is needed before the vehicle returns to the garage.

Downloading occurs whenever a bus is refuelled, usually every 1 to 3 days.

XMODEM, a very common protocol, is used to guarantee the integrity of downloaded data.

Data ends up in an ordinary micro computer, usually a laptop installed in the garage. One computer per garage is all that is necessary. To it are connected the IR links. Usually, the garage computers are linked to the user's network so that the user can retrieve the data for further processing.

Refuelling can take up to 3 minutes. Usual download time is 30 seconds.

Files from the vehicles are initially in CSV format. They are transmitted using specialized transport protocols ensuring 100% accuracy. No data is ever lost. All of it is usable by any of your personnel.

The only component open to public view are the sensors. Made of die-cast aluminium, not plastic, they are very robust and can take much abuse. Most people will not notice them.

The logger is in a NEMA-4 case. All wiring is passed through rubber grommets. The equipment could be hosed down during cleaning without experiencing any adverse effects.

The system is powered from the vehicle's electrical sources, from 12 to 24 VDC. Typical current required is 500 mA. The equipment is well protected against voltage drops and noise.

Our systems can certainly work in light rail vehicles. They are actually installed in OC Transpo's trains.

The computer needs an Intel Pentium processor or equivalent and Microsoft Windows 95 or 98 or NT.

There is no database software required.

The first phase of data processing, bus stop and route identification, produces CSV files: a very common, public format used in Excel and many other major software. The valid data is then integrated in the software's database. We have developed our own format to provide very good response times despite the large quantity of data produced, The data is made available to other software processes by exporting to CSV, DBF or MSACCESS formats via ODBC.

Everything is open until the data is integrated in the database as described in the previous subsection.

Only validated data is added to the database. Validation means that stops and routes have been identified and that counts are within set precision tolerances.

At present we do not need to use error correction algorithms. However we are looking at this to better the system. After adjustments, minimum accuracy in most circumstances is 95%.

When data doesn't verify, it means that something is very wrong. Data is never thrown away. It can be modified and reprocessed if desired.

Standard processing to validate only requires clicking the mouse and pressing enter on the keyboard. We will work together to decide what standard reporting is required. These reports would be produced just as simply. There can be no standard good for everyone. We have started a user group to have a good communication flow and feed the development process.

We routinely work with Hastus data from our customer's systems.

Most of the required reports are presently available.

Our software cannot be modified by the user nor by a third party, mainly because software is complex and it is easy to create problems. What we provide to outside people is the data with which they can do whatever they want.

With us, software is a lot less costly than what transit is used to, mainly because our software is not priced by utility, but by complexity of function. Our aim is to provide a complete software system to all our customers. Enhancements requested by a customer which can be used by most of our other customers will become part of our standard offering. We aim to have only one software offering that can be customized for each customer.

Our APC equipment is running at the following locations in Canada: STCUQ (Quebec City), STRSM (Montréal), STL (Laval), Calgary Transit, Winnipeg Transit, OC Transpo, Toronto Transit Commission.

All equipment and software is covered by a one-year warranty. Subsequently, a service contract is available at a yearly cost from 9 to 12% of contract, depending on various client parameters.

Our equipment is very reliable. MTBF specifications are not in the technical manuals for the GPS receivers we have been using from major suppliers such as Motorola. All the more reason why we have no MTBF available for our equipment. Determining MTBF is a very complex statistical procedure which we are in no position to undertake. We have thousands of sensors and data loggers installed throughout the world, and under normal conditions of operation very few have failed. Equipment under warranty or service contract will be replaced.

Training is part of a usual APC project. Complete documentation (paper and video) is available in French and English. We send experts on site to train the users.

Some equipment is left at the client's site to minimize disruptions of operations. If a sensor needs to be changed, for example, a bus need to be serviced only once removing the faulty part and replacing it immediately. The connectors are chosen to be connected and disconnected quickly.

The system is designed to be maintained and locally serviced by the client's competent technical employees. They are the ones most knowledgeable about the buses. Response time is therefore as short as you can make it.

On our end, equipment can be shipped and be at your location within 24 hours. Software servicing and maintenance is provided via telecommunications with pcAnywhere, a program which links our technician's computer to the client's computer in the garage. Files can be replaced, programs upgraded and operation monitored instantly.

We supply everything. However, in some cases, simple mounting brackets might be needed to be made during installation.

One bus, one day, one installer, once people are familiar with the installation. Our systems are designed to be installed and maintained by your people. It is very easy. Those who have installed our systems have all appreciated the simplicity of installation.