Meter Accuracy

We often hear people evaluating the merits of “soft meters” over “hard meters” in order to distinguish a metering system running on a multi-purpose device (like a handheld device) from a purpose built meter.

However, they often overlook aspects that actually matter. It is not the packaging nor the display but the choice of source data to derive time and distance that matters. It is also important to consider how the device uses the data to calculate the metered amount at any given point in time.

Nowadays, time can be measured accurately (VDS3 has an onboard real-time clock that is synced with NTP) but distance measurements are less straightforward. Older taxi meters utilise a wheel tick methodology to count wheel rotations in order to measure distance travelled but there is an obvious drawback – manual calibration is required, and subject to tyre pressure, the results can vary over time.

With the improvement of location services, especially on handheld devices, some believe that using location services is accurate enough for distance calculations in meters. However, in reality, location services do not always perform consistently due to a number of factors, such as:

Lack of an unobstructed view of the sky throughout the journey (tunnels and bridges can cause problems, but in cities with tall buildings, the GPS signals tend to bounce off buildings, creating havoc with location services; the signal can be on the correct side of the road and in the next moment, it can be observed hopping across the map).

Variations in frequency of receiving location data – there can be many reasons why location data can become stale. In the ideal world, driving on a perfectly straight road at a constant speed, it is possible to computationally compensate for a lack of location data, however, if you encounter many road turns or twists, the calculated distance can quickly divert from the actual distance travelled and the meter will no longer display the correct amount when location updates are not provided at consistently short intervals.


Ideally, distance travelled could simply be gleaned directly from the vehicle itself.  Unfortunately car manufacturers do not externalise this information (for valid reasons). So how does VDS3 do it? It uses vehicle speed updates on the OBD bus to calculate distance travelled.

However, the speed data cannot be consumed directly as it diverges from the actual speed of the vehicle. Therefore Net-Cabs developed an algorithm that utilses an adjustment factor to derive the actual vehicle speed at any given point in time. As the adjustment factor is not always identical in every vehicle, it was necessary to develop an automatic calibration of the adjustment factor. Once the speed of a vehicle is accurately attained, it is straightforward to calculate the distance travelled. We have embedded ODB circuitry in the VDS3 controller and it simply connects to the vehicle (plug one end of the OBD cable into the controller and the other into the vehicle’s OBD port).

As an additional benefit, VDS3 can access a wealth of real-time vehicle data from OBD that can be utilised for comprehensive vehicle management. If the OBD cable is unintentionally unplugged, VDS3 will detect that, alert the driver and the systems administrator, and temporarily fall back to location services for meter calculation until the OBD cable is plugged back in again.

VDS3 Meter  

Rate Sets

In Australia, every state has its own legislation for fare rate calculation. Considerations for rate calculation include: time of day, public holiday rates, number of passengers, type of vehicle, wheelchair presence, disability and government levy charges. In addition, other various factors that must be observed include flagfall, distance/time metrics, extras and road tolls.

Historically, drivers had to manually select a tariff which allowed for widespread abuse and fraud. Tariffs were typically statically programmed and limited to an operational region. Even today taxi meters in Australia struggle to meet legislative requirements.

An example is a traditional meter which has been programmed for Melbourne metro. If the driver drives a passenger out of the metro area into a regional area and picks up another passenger on the return journey, the meter should apply the regional tariff and not the metro tariff. However, as traditional meters are unable to apply rates for different regions and to perform the relevant rate calculation, this does not occur.

Additionally there are regions where fare rates are not legislated. Here the taxi operators are free to set their own rate sets which typically are not supported by other meters.

The VDS3 meter always uses the latest applicable published rate set and knows how to calculate the correct fare. The benefit is that a VDS3 controller can be shipped anywhere in Australia (or elsewhere) without needing to configure a rate set in advance.

The administrator can make changes to tariffs with ease (if rates must be updated due to a change in legislation, or maybe a taxi operator wants his own custom fare schedule). In this instance, we have developed an interface in the administration portal that provides a wide range of flexibility in defining rate sets.

With our solution, you don’t have to be a computer programmer to create or update a rate set. An approved administrator can simply copy an existing rate set, make changes to it and then publish the new rate set to a range of VDS3 devices at a scheduled time.

Net-Cabs VDS Regions Definitions.

Net-Cabs VDS Regions Definitions.

Rate Set Report for the State of Victoria:
VDS Fare Rates.

View in new window due to page length.


Unfortunately there are always rogue drivers who will try to take advantage of passengers. A typical example may be when a passenger jumps into a taxi and the driver demands prepayment. Often the demanded amount is not in line with the journey cost and the passenger probably would not know any better.

To combat this, the government issued a mandate that the meter must be started for every unbooked taxi job. However, what about when a dubious or intoxicated person jumps in the taxi at night and wants to be driven to a distant destination? Taxi drivers are not allowed to refuse passengers but they also have a sixth sense for fare evaders. For this, Net-Cabs introduced a prepayment function. The driver can set the destination into the VDS3 and the system will calculate the maximum fare amount for the journey based on the applicable rate set.

The driver cannot increase it, preventing defrauding the passenger, but can reduce it if the passenger is not able or willing to pay the full amount. If the preset amount is accepted and paid by the passenger, the driver can take the passenger to the destination without fear of losing the fare.

VDS3 Prepayment Flow  

Card Scanning

To support a broad range of cards that use custom themes, we have integrated card scanning with OCR (optical character recognition) into VDS3.

When a government disability scheme uses custom cards, VDS3 is able to scan these cards, validate them and link the card photo to the job, all in real time. Combined with the in-vehicle security camera stills, photos of the card used and its real-time card validation, the system provides a comprehensive safety net against card fraud.

The VDS3 solution has been successfully integrated with state government schemes (such as MPTP in Victoria) thereby solving the limitations surrounding processing proprietary card systems such as Cabcharge.

VDS3 Card Scanning  


The number of toll roads have been steadily increasing in Australia. The payment schemes differ from provider to provider and the rates are typically updated quarterly.

Net-Cabs has developed automated road tolling with VDS3 and provided an intuitive management interface that caters for a multitude of tolling schemes. For that, Net-Cabs consulted with major road toll companies and applied the acquired knowledge to the VDS3 implementation.

Road Tolls Configuration for VDS3  


After concluding a trip, the “Finalise Fare” screen is displayed with the calculated fare amount for payment.  All mandatory fees and discounts are automatically applied. The driver is able to add supported card schemes, a tip or apply extras (where applicable) before choosing a payment method.

The payment method options are “Not Paid”, “Corp Account”, “Paid Cash” and “Pay by Card”. When “Not Paid” is selected, the driver is asked to provide a reason why the fare has not been paid. “Corp Account” is used for assigning the payment to an authorised corporate account that the operator has set up. “Paid Cash” is recording payment received in cash and “Pay by Card” triggers a card transaction with the integrated payment terminal.

Tax invoices and payment receipts can be printed, emailed or texted to the passenger. Printed documentation is mandatory in most states and taxis must have infrastructure to accommodate this.

Payment Options  
Payment Report for Corporate Accounts
Net-Cabs Admin Payments on Corporate Accounts.