Overview

Below we discuss the various ways the Phoenix MDK can collect data, and what types of sensors are required to collect each type of data. Please read this section carefully. The Phoenix MDK is a very sophisticated counter/classifier with many options. Reading and understanding this section first will greatly simplify operation later.

Sensor Miss Code Definitions:

The Four Basic Storage Modes

Before attempting to use your Phoenix MDK, you should first become familiar with the four fundamental modes of operation. The mode that you select determines the type of data that will be collected, and whether the information will be combined with other entries or stored individually. These modes do not cover WIM applications.

Sensor and Sensor Modes

The Phoenix MDK supports Road Tube Air Switches, Inductive Loops, Remote Inputs, Piezo Resistive and Piezo Electric Inputs. Road Tubes, Remote Inputs, and Piezo Sensors are considered “axle” sensors, since they are activated by individual axles. Inductive Loops are considered “presence” sensors, since they become activated by the metal in the vehicle passing over, and become un-active when the vehicle leaves. The Remote input will support any type of sensor which will give a momentary switch closure.

Since there are variations with each sensor (for example, Inductive Loops will have slightly different amounts of inductance), the Phoenix MDK performs automatic tuning or adjustment for all sensors except for Piezo Resistive by default. The user must tune Piezos manually or enable auto piezo calibration during setup using the Phoenix MDK keypad or a PC/laptop computer and the Centurion Software. See section 3d3 for more information.

When in Per-Vehicle (raw) storage or Binned storage modes, four types of sensor arrangements (sensor modes) may be selected:

In Count Storage mode, you can select either a Presence Sensor or an Axle Sensor. In Timestamp (Sensor) Storage mode, you can select a Presence Sensor, an Axle Sensor, or Both.

The way sensors are divided up among the lanes depends on the storage mode (Raw, Binned, etc.) and the sensor mode (Axle-Axle, Pres-Pres, etc.). Table 1 shows the divisions of the sensors.

Sensor and Count Modes always use the same lane number as the sensor number for input to that lane. Per-Vehicle (Raw) and Binned Modes will always use two inputs for each lane, with the sensor numbers shown in the table.

Per-Vehicle (Raw) and Binned modes are the classification modes, so they can also take advantage of two slightly more complicated sensor modes, “Axle-Pres-Axle” and “Pres-Axle-Pres”. The first and last sensors, either the two Axle or the two Pres, are ALWAYS the same as shown in Table 1. The difference comes in the middle sensor.

The system works AS LONG AS THERE IS NEVER ANY CONFLICT BETWEEN LANES FOR SENSORS. This can occur if you use different axle configurations on different lanes and you are using “Axle-Pres-Axle” or “Pres-Axle-Pres” on the higher numbered lane. Still confusing? Hang in there, it gets simpler. Let’s try an example.

Example 1: Suppose you selected Pres-Pres for lane #1 and Axle-Pres-Axle for lane #2, according to the Table 1 (for lane #1) and Table 2 (for lane #2).

In this case, Pres 2 (underlined) is specified for BOTH lanes 1 and 2! This situation is referred to as a SENSOR CONFLICT and is automatically detected by the software. If a conflict occurs, the Phoenix MDK will not allow you to start collecting until the conflict is resolved.

Now, for further example, suppose you chose Axle-Pres-Axle for lane #1 and Pres-Pres for lane #2, according to the same tables.

Now, there is no conflict and the system can operate. When the system does detect a sensor conflict with another lane (and note that the higher number lane will always be the lane in conflict, so lane #1 will never be in conflict since it is the lowest lane number), you will receive an error message and the software will not continue operation.

The Phoenix MDK also contains many advanced sensor analysis routines to improve data accuracy, including examining both sets of axle and presence sensors, the tossing out of too short spacing (for example: eliminating a road tube bounce, which can cause a false count), and the determination of missed axles.

Dynamic Sensor Assigning:

Since the Phoenix MDK uses sensors in a certain order (depending on setup) sometimes your configuration is limited by the default assignment of sensors. To accommodate unconventional sensor inputs, the Phoenix MDK allows for the sensors to be rearranged or reassigned to different inputs. This feature is only available during serial port programming via the PC.  The assignment of sensors is done by lane and is done using the Centurion software. Sensors can be assigned to any lane in any combination with the exception that the sensor not be assigned more than once.

As an example you may have a site that was wired incorrectly and cannot be rewired easily. In this case it may be easier to just reassign the sensor inputs to allow the unit to count or classify traffic correctly. In the following table the scenario represented would be that of a site that was “wired” backwards. By reassigning the sensor inputs we have allowed the lane assignments to appear correctly:

Per-Vehicle (Raw) Storage and Specific Functions:

In this mode, an individual record is kept for each vehicle encountered. Any combination of one to eight lanes (depending on how many and what type of sensor inputs the boards are installed) can be enabled. If any lane is configured for directional mode (the ability to classify traffic traveling in either direction), an additional lane of traffic data is created. For example, if lane # 1 is enabled and is configured in directional mode, the counter would create lane # 9 for vehicles traveling in the opposite direction on lane # 1.

Note that the directional lane is not an actual separate lane – it is the same physical lane but simply traffic moving in the opposite direction. It is recommended that the directional option be used whenever the possibility of two-way traffic exists, such as a one-lane road or an area on a two lane highway where there is much passing of slower vehicles, thereby using the oncoming lane.

Four separate modes of Per-Vehicle (Raw) Storage are available. Lanes are not individually set; all lanes will be in the same mode.

 There is some give and take with the modes. Enhanced Raw will give a more precise record than Normal Raw; however, more memory space is used. The same comment goes for Raw with Bins – more memory to keep track of which bin it would have gone into. Appendix B gives an approximation of the number of vehicles which can be stored in memory depending upon which mode you choose.

While in Raw Storage, the user can select any of the four Sensor Modes (Axle-Axle, Pres-Pres, etc.) for each lane. The system will ask the user for Sensor Spacing and the Loop Length (if using presence). The maximum sensor spacing is 99.9 feet, and the maximum loop length is 25.5 feet.

Per-Vehicle (Raw) Storage also supports “Lane Overlap”. If axle sensors are used to collect data from two lanes of traffic, the Lanes can be configured as shown in the figures below. Note that the shorter tube is in the near lane (lane #1), and is activated first by oncoming traffic. This configuration will allow you to collect data from two lanes using four road tubes where one set of tubes crosses both lanes.

Same Direction		Opposite Direction

Per-Vehicle (Raw) data is stored in a straight fashion. As vehicles are detected and the information (speed, length, etc.) is gathered, the data is stored sequentially in memory in long record. During collection, or during testing, the Phoenix MDK will allow you to monitor any or all lanes.

Binned Storage and Specification Functions

Binned Storage is very similar to Per-Vehicle (Raw) storage that you can have any combination of lanes and each lane can be enabled for directional operation shown as additional lanes of traffic. Binned Storage supports the same sensor modes and lane configurations.

The difference in the modes is the method of storage. In Per-Vehicle (Raw) Storage, the Phoenix MDK stores all data in chronological order as the vehicles are detected and data is registered (speed, length, etc.). Binned Storage sorts and classifies the data into separate categories or “Bins”. The vehicle is then added to the correct Bin #. In this fashion, you can retrieve totals for various types of vehicles.

There are five classification Bin types (not Including WIM data):

Each lane can also be enabled to do two dimensional binning of either “Speed by Length”, “Speed by Axle”, or both. This mode creates a table giving you individual speed bins for each vehicle type or for each vehicle length category.

Each category or “Bin” has been predefined as to what it represents. For example, Axle Bin #1 is for motorcycles, Speed Bin #1 is for vehicles traveling between 1 and 19.9 MPH. While these bins have preset to be the most common categories, you may change the type and number of bins for each binning mode. See the Centurion Software Help Menu for more information on modifying these bin definitions to your own specific needs.

Binning Storage also supports the “Lane Overlap” function. Refer to the previous section, “Per-Vehicle (Raw) Storage and Specific Functions” for a detailed explanation.

Count Storage and Specific Functions

In Count Storage Mode, the only information stored is the number of vehicles that have been detected in each lane. Up to 16 lanes are supported (depending on the number and type of sensors input boards installed) in this mode. Normally, each lane will use one sensor to collect the count. When a Road Tube or Piezo Sensor is used as the lane sensor, the count may be divided by two. Since loop sensors hold presence for the duration of a vehicle, the divide by two option is not used by loops.

Storage of the counts is performed in the same manner as outlined above for Binned data (i.e. using “record intervals”).

There are two specialized sensor configurations for count data when two axle sensors are used (normally road tubes); they are Lane Subtraction and Directional.

Lane Subtraction	-	This mode is used when you want to get individual lane count from two different lanes of traffic from one side of the road. The road tube attached to lane 1 (or any other ODD numbered lane) is laid out across both lanes. The road tube attached to Lane 2 (or the next even numbered lane) is laid out across one lane. The Phoenix MDK will subtract the even lanes from the odd lane’s count to obtain the proper directional count for the odd numbered lane.     Traffic Direction does not matter   Odd Number Lane Must Be Longer Tube (i.e. Lanes 1,3,5,7,9,11,13, or15)
Directional	-	This mode is used for counting two-way traffic on a narrow road. A road tube pair (such as 1-2 or 3-4) are laid out across both lanes with road tube one foot apart. The phoenix will  determine (from the order of actuation) the proper directional count for each lane.

You can monitor any or all lanes during collection or testing, with the system showing you the current lane totals for the record interval.

Sensor Storage and Specific Functions

Sensor Data Storage or (Timestamp) is a flexible mode of storing traffic data. Data is stored sequentially when a sensor is activated, allowing custom software to organize the data in a way tailor made for the user.

Sensor Data Storage (Timestamp) stores the simplest form of data. Inside the Phoenix MDK is a timer that counts down (starting from 16,777,216) at the rate of 10.695 KHz (10,695 cycles per second). When its 24-bit timer counts down to zero, it recycles to 16,777,215. At the rate of 10.695 KHz, the time it takes to revolve through the counter is 16777215/10695 or about 26 minutes. When a sensor is activated, the counter stores the lane, type of sensor, and the timer reading. When the sensor is activated again, it stores the lane, time, type of sensor, and the new timer reading. The counter will store an “A On” for an axle strike, a “P On” for a presence sensor turning on, or a “P Off” for a presence sensor turning off.

Example:

Let’s say we have two Presence sensors in a road, 10 feet from the leading edge. In the Phoenix MDK, we turn on Lane #1 and Lane #2 and select Pres as the sensor.

A record of strikes might appear as such –

            1:14:38:56 (3369138) P On

            2:14:38:56 (3367017) P On

            1:14:38:56 (3366577) P Off

            2:14:38:56 (3364057) P Off

Now, what this means is that the Presence Sensor in Lane 1 was activated at 14:38:56 (2:38pm + 56 seconds) when the timer was at 3,369,138. Lane 2 was activated with a Presence On when the timer was at 3,367,017. Lane 1 lost presence of a vehicle when the timer was at 3,366,577. Lane 2 lost presence of a vehicle when the timer was at 3,364,057.

The question you might ask now is, “OK, so what’s the point?” Well, we know

• The distance (10 Feet)
• The time from activating the first sensor to activating the second sensor, this is a 3,369,138-3,367,017 = 2,121 timer cycle.

Since we know the timer is running at 10,695 cycles per second, we can divide the number of cycles by the cycles per second rate and get the amount of time, or 2,121/10,695 = .198317 seconds. Now, since distance = rate X time, then rate = distance/time, or 10 feet/.198317 seconds = @50.42 feet per second. Using some conversions, this comes out to about 34.4 Mph. (if it’s a 25 Mph zone, somebody is speeding!).

Since you know the loop length, and have calculated the vehicle speed, you could also calculate the length of the vehicle. This is the exact process the Phoenix MDK used in Binned and Per-Vehicle (Raw) Modes.

If you were using tubes, you could calculate speed, number of axles, axle length between individual axles, and overall axle length. Combine the two (using the option of Axle-Pres-Axle or Pres-Axle-Pres) and you can calculate everything the tubes can plus overall vehicle length. Quite a bit of information from a few timer counts.

As with other storage modes, during testing or collection you can monitor any or all lanes.