I always thought that when they had two, one of the cords only goes half way, and the other goes all the way across the road. That way, the count on the short cord is one direction of traffic, and the count on the long cord is both directions, so you can calculate each direction’s traffic, without having devices on both sides of the road.
I’ve always assumed that it was option 1, speed and/or direction of travel. I don’t see what’s not to like about that data. If I were a traffic planning person, I imagine that would be handy stuff to know.
I don’t think it can be 1 because the distance between axles on different vehicles varies. And you also have different numbers of axles on various vehicles, so you’d have no way of knowing if 2 hits were a front and back axle on one vehicle, or a back and front axle on 2 vehicles.
I’d repeat the argument against that position, but it was so drenched in bogosity that I can’t even follow it. (Digo yo.)
Cars are rarely close enough that you would make that error. And, even when they are, there are breaks in traffic that will let you recalibrate to the beginning of the next car. Similarly with >2 axle vehicles. Plus, you can always just discard any sections that your algorithm can’t make sense of. You’re looking for averages, here.
Given how close the cables are, tho, differences in axle distance would result in enormous errors in speed calculation. I think the data would be useless.
And what about semi trucks? The distance between the 2nd and 3rd axles could easily be the same the distance between the truck’s 3rd axle and the front axle of a following car.
What does the axle distance have to do with it? Assuming each cable has its own sensor, one cable detects two (or more) pulses, and the other cable detects the same number of pulses immediately after. The time delay depends only on vehicle speed. Divide the distance between the two cords by the time delay and you get vehicle speed.
The first section is definitely a single vehicle. The middle section is probably a truck with trailer followed by a car, but it could some other weird combination. A conservative algorithm might discard the data because it’s ambiguous. Or, you might observe that trucks are almost always short+long, and adopt a less cautious approach, yielding truck+car. So I think it is quite possible to tell vehicles apart with just two sensors.
There are sensors like this on the road I drive to work (back road in a rural area). A friend of mine believes if there is enough traffic on the road, improvements will be made. Therefore, he is driving around more than usual, purposely trying to inflate the data for the road on which he lives. He is even talking about going out with a hammer and trying to artificially inflate the data.
If one cable goes across the road, spanning both traffic directions, and it provides a single output pulse each time it’s run over, how can the logging/counting device tell which direction the vehicle was going? What if two cars, travelling in opposite directions, cross the cable at approximately the same time? One pulse might be from car #1’s wheels, the next from car #2. This would throw both speed and direction calcs off.
Same problem if 2 cables both span the road. I can see how 1.5 cables would be better, but not perfect.
Could the cables work as proximity sensors instead of physical switches? Then one car or truck would be one pulse.
But I’ll bet they don’t sense motorcycles at all. Our in-road sensors are oblivious to them.
I thought it was two, placed as they are, so that Cars / Lighter trucks could be “read” but, Big Rigs with more wheels - arranged differently on the vehicle, will cancel each other out, when both hit the cables at the same time.
Unless things have changed since I last used to deploy these, the long one gives traffic counts in BOTH directions and the short one for just the one lane (say, Southbound). To get the true Northbound number, you subtract the Southbound tally from it. Posters above already figured this out, I’m just confirming.
I don’t recall for certain if the machine counted axles or axles/2, or if there is a setting that would control which method was used. For the models we used, I’m leaning towards axles/2 (the first hit, incremented the counter wheel halfway, the second hit made it rotate fully to the next number).
The above applies to the old-style pneumatic type. There may well be new-fangled types that measure additional data, but for just basic traffic counts the old (read: cheap) type works just fine.
When your front tire hits the first cable, the timer is started. When your front tire hits the second cable, the timer is stopped. If the distance between the two cables is known, then it’s easy to calculate the speed. The error in the speed measurement would be a fucntion of:
Uncertainty of distance between cables.
Uncertainty in clock’s time base.
Quantization error (due to the fact that time is measured in discrete intervals).
