Explaining the Pulsar Formulae



          This page is written in response to an e-mail from a client who had ordered one of our instruction packages, and wanted to know a bit more about his directions and operations on his calculator.  Admittedly, the Pulsar taximeters are a bit of an enigma to many of us at first, this technician included. Meters like the Centrodyne are straight forward in programming; if you want to program in a waiting time charge of $36.00 per hour in the Centrodyne 600 series meters, for instance, you find the correct address and enter “3600”. Done. With the Pulsar, however, you have to calculate a “factor” and enter this obscure value into the correct address. It is our contention that the Centrodyne meters were probably built by people who had been cab operators, while the Pulsar’s were designed by an engineer – a formula person. Now, either method will work, but the Pulsar method is less logical and more unnecessarily “technical” in nature to most of us. (Note: Both brands are excellent quality. We proudly sell both at www.TaxiCabElectronics.com.) [ Oh, we also offer a CD with spreadsheets which make the formulae dance, and do all the math for you. Just plug in the numbers you need for your fare, and the spreadsheets tell you the correct entry for each programming slot. We also preprogram your new meter (no charge) before we ship it to you, to further relieve your stress. You still need the calculations so you can change your rates later on. ]
          Rate programming is required in order to instruct your meter how to charge fares and fees. We need to tell it how to use distance information received from the vehicle, and how to compute the fares charged. We also need to be able to calculate “waiting” time fees when the vehicle is idling, or traveling under about 12 miles per hour, according to national regulations. And then there are “extras” and so forth. Let’s try to sort this out.
          First of all, note that, with all current Pulsar models, the settings for the initial meter programming should be for 1000 pulses per mile (or per KM if you use that system). There is a “quick calibration” feature which will adjust all the calculations to the actual information from your vehicle when you do the calibration the first time. After you calibrate, write down the values for future reference.
          Just for reference, the meter requires that 3.0 entry of 1/10th the actual number of pulses in a mile, in order to calculate other factors inside the processor. It has to do with the early part of the fare, but the manufacturers still have not cleared that in my mind. Suffice it to say, you MUST enter that data accurately. If you leave that at zero or some random number, your fare will not calculate properly through all facets.
          When you turn on your meter, the “flag drop” fee is placed on the fare screen.  That charge is sometimes called a “sit down” fee or similar terms. The client gets to ride a certain distance under that fee before the meter starts charging the per-mile fees. We tell the meter how long that travel is when we enter a decimal fraction as “initial distance”. It often is the same fraction of a mile that is used for the mileage calculation in the rest of the ride. For instance, if your “Flag Drop” fee is $3.00, the immediate fare charge pops up $3.00 when you press the “hired” button. It sits there unchanged until you have traveled the “initial distance” which we entered into the appropriate slot when programming. Maybe that distance is to be 1/8th mile. The entry into the “initial distance” slot is 0.125. [Obviously, 1 divided by 8 equals .125.] Pulses.html

          There is a requirement that the mile be broken into fractions in order to charge the fare. Let’s say you want to charge $2.00 per mile. Your charges can come in 20¢ bites every tenth of a mile, or they can come in 25¢ bites every eighth of a mile, or even 50¢ bites every quarter mile. To tell the meter what fraction of a mile to use, we make an entry in a program slot titled “subsequent distance”. If we wanted the mile divided into tenths, we would enter 20¢ into the “money increment” slot in the program, and the meter would use 0.100 as the decimal fraction for “subsequent distance”. That’s entered as “100”.

          Now comes the fun part. The “waiting time” factor. Follow me through this process: Let’s say you want to charge $30.00 per hour wait time. That is 3000 pennies. Your meter will use the same coin amount you have specified for distance calcs, to figure the waiting time. In the example above the coin was 20¢. So you divide 20¢ into 3000¢ and find you will need 150 increments of 20¢ in order to get your $30.00 in an hour. [150 times 20 equals 3000.] So your meter will change 150 times in an hour, and each change will jump the fare 20¢. Now we need to know how long each increment of time will be, in seconds. [Doesn’t this sound “engineer” to you? :) Yikes!  ]

          There are 3600 seconds in an hour. And your hour will be broken into 150 chunks. 3600 divided by 150 is 24, so every 24 seconds, you will make 20¢ waiting outside the Piggly-Wiggly to be your customer’s get-away car. Hmmmm! Did I really say that?

          Now here’s where it gets strange. The formula used to calculate a “time factor” for the Pulsar meter is this; Number of Seconds Per Increment of time, times 1000, and that answer divided by “subsequent distance” as entered. To this moment, I’m not clear on why they do that, but it has to do with the other formulae inside the processor chip in your meter. The who-sit and the whats-him combine to krabitz the gurnswagger. I have asked the engineer to clarify it for me and that’s the best I can do. Anyway… In our example, you ended up with 24 seconds, and your subsequent distance was 0.100 which was entered as “100”, so your calculation will look like this:

                                                                                                                          (24 X 1000)    / 100       = 240
                                                                                  

          The time factor is 240. It is indeed a factor, and not a real value for the finished program. This factor is entered into the appropriate slot in the meter program. The meter does it’s thing, (gurnswaggers and all) and the waiting time is charged in our example, at 20¢ every 24 seconds… which gives you $30.00 per hour. Clear as chocolate syrup!

          “Extras” is of course, a flat fee that can be added to the fare by the driver if he/she pushes a button. It can be used for extra stops, or extra baggage, special fees like airport charges to the cab for sitting in the taxi-line. The “extras” fee is pre-programmed as you specify, and can be limited so the driver cannot over charge with the button. There is a place in the program to specify the amount of money, and another place to specify the number of times the button will work.

          I trust this clears up some of the mystery. I learned when studying metaphysics years ago, that a true metaphysician is a person who knows the solution to all situations, without necessarily possessing the benefit of understanding the problem. It has always worked for me. I’ve always loved mathematics, studied electronics and nuclear power, programmed computers in several computer languages, and I have yet to see the reason for all the external math in this application.  If you want to end up with $18.00 an hour, why can’t you just enter “1800” and let the meter calculate all the numbers? But that’s the way it was designed, and by golly, it works well once you plow through the “cyphers”. Happy plowing! :) Make it easy: buy the spreadsheet CD.

–Fred Stock 2/28/10