FAQ

You may certainly switch the batteries, or order lithium batteries from Tehama. However you will not see any significantly longer life, perhaps 5% at most. Lithium batteries ARE recommended if the MDT will experience sub-freezing temperatures or daily temperature swings in excess of 30º F.

The MDT assumes a dry contact connection for the pulse input. The Pulse input is tied high to the battery voltage (nominally 3.0V) through a high impedance pull-up resistor. Closing the dry contact switch at the meter drives the pulse input low which generates a count. The meter switch must be closed for more that 25 mS to pass the MDT’s de-bounce logic.

Generated pulse meters (Badger RTR, Zenner, Hersey) also work with our MDT, however some of these meters generate a pulse shorter than 25mS (older Hersey, newer Zenner). Those meters require our “Hersey” MDT that does not implement the de-bounce logic.

The input signal from generated pulse meters should not exceed 4.5V. A generated pulse meter with a voltage value higher than this could damage the MDT (for example some Carlon water meters).

No. Hersey MDTs are Generated Pulse type meters, as are Badger Recordall and Zenner meters for example. If the Hersey MDT is connected to a reed switch meter, there is a very high potential the MDT will over-count due to the mechanical “bounce” of the reed switch.

Yes, this information IS read by the Encoder MDT. Since it is static data, it is only sent once a day. Therefore it could take up to 24 hours for you to see the serial number in the CIT or your daily reports.

Alkaline batteries start at 3.1V and linearly degrade. Once they reach 2.2 you have 4-6 weeks left before they stop working. This is not the case for primary lithium batteries, they stay above 3.1 volts for 4-5 years. Once they reach 3.0V they can fall off the cliff rapidly and might have a few days left before they stop working.

Be sure that an email is associated in the Alert Email Configuration box and that the Quick Set for battery alerts is checked as well. For a better understanding of this alert click on the "Description" box in the CIT.

-Y, instantaneous, every rising edge counted no matter how fast they come (within reason, but probably higher than 1000 per second).  -P, 25mS minimum pulse width, or 20 a second.

The DCAP uses about 2 kWh per month or roughly 24kWh per year. This applies to all the various DCAP sizes.

The Repeater consumes under 5 kWh per year.

30-50 MB if just generating 1 report / day

100 MB if monitoring and using the CIT more than a few times a month

On our older DCAPs with the external antenna, this can happen for a minute or two after power-up as the DCAP performs a self-check. This check is much faster on our diversity DCAPs.

If the flashing is persistent beyond a few minutes, a power cycle might resolve it. If that doesn’t work, contact Tehama.

Our TFA DCAP is a hybrid system that contains a full Tehama system and adds a serial interface to connect to an Inovonics FA receiver. Thus the DCAP is able to receive data from both Tehama MDTs and Inovonics PMTs. The TFA DCAP is managing two totally separate systems: MDTs can't talk to Inovonics repeaters, and PMTs can't talk to Tehama Repeaters. However the data is collected from both and presented as a single set of data in the CIT and the daily reports.

There is no minimum speed required for the DCAP to operate and the quantity of data is very low, on the order of 2MBytes per day.

Please Inquire using the Contact button at the upper right

In most cases Windows will automatically download and install the drivers required for our configuration cable. If this does not happen, you can get drivers here: https://www.ftdichip.com/Drivers/VCP.htm

For CIT to communicate with the DCAP:
Connection to *.tehamawireless.net on port 1717:

For email: outgoing SNMP connection to the following URLs on port 587:
email-smtp.us-east-1.amazonaws.com
smtp.mailgun.org

For cloud data:
api-v3.tehamawireless.net on HTTPS port 443

In a working site, active alerts should always say false. The CIT will indicate an active alert when it detects one, such as low battery voltage, repeater unplugged, leak detection, etc.

Our leak detection alert is designed to monitor for “Continuous Flow” leaks, e.g. something like a leaky toilet or faucet that will trigger some usage every hour for a 24 hour period. You can configure this time period to any value you wish, however 24 hours is the default.

This alert is NOT intended to catch a busted pipe. For that we have a “Standing Water” sensor that generates an alert immediately when the sensor cable is immersed in water.

There are two primary messages sent by MDTs and RPTRs: Log and Link messages.

Log messages contain the meter reads data and are transmitted every hour, unless you have a ToU MDT in which case Log messages are sent every 15 minutes, synchronized to the top of the hour.

Link messages contain network statistics such as Link Quality, RSSI, Link Partner, etc. These messages are typically sent every six hours for MDTs and every two hours for Repeaters.

The Time Stamps of these two message types are unlikely to be the same. Generally the Log message last timestamp is the most important.

The Node ID is a free-form text field where you can enter any info you like. Many of our customers generate a unique Property ID, and then an MDT ID that could encode the building and apartment number. By combining these into a Node ID, they create a system-wide unique ID for their many thousands of MDTs across the country.

• Grants can be issued to any individual user.  You can control whether that grant has Read-Only or R/W privileges on the Site you are granting access to.
• Grants can be requested by an outside user; all admin users of a CSL (Company Site List) will receive an email and their open CIT will pop up a notice that there are Grant Request in the queue.  There can be more than one admin user.
• Grants can be blanket / global grants, in that one grant can allow the user to access any site on your CSL which you have claimed ownership over.  This extends to Sites you add to your CSL after the Grant was first issued.
• Grants can have an expiration date, so the tech can do their work then no longer have access.  One can also issue “Forever” Grants that don't expire (or do so in 2099).
• Grants cannot be issued to another Company, only to individual users.  Put another way, you can’t grant access to the admin user and thereby extend those permissions to all other CSL users.

We hold data for 6-7 months in the cloud.

The Consumption column is doing very simple math, subtracting the last reading from the first reading *within the time frame of data downloaded* which defaults to 24 hours when you first connect. The Consumption cell will show UNKNOWN if that MDT was Disconnected at the start of the time frame. You can verify this by clicking on the Readings cell and see the early readings as Disconnected.  Without a valid start time reading the Consumption will display as UNKNOWN.

We have three timestamps in our system.  

ReadTime is timestamped at the MDT when the reading is taken, it is the actual read time.  They get the actual time from the beacons send out by the DCAP and Repeaters.

Receive or RX Time is when the DCAP receives the message from the network.  Repeaters and MDTs can store messages if they have a bad link quality and it takes many tries to get the message forwarded.  So this is a useful troubleshooting indicator for the Radio network.

There is a third time stamp recorded when the cloud receives the message, called ClourRxTime.  This is only exposed on the Custom tab in the CIT and again is a useful troubleshooting indicator for Networking issues.  If a DCAP has lost Internet for a week but continues to store messages locally, once it comes back on-line you can see very long differences between ReadTime and CloudRxTime.  

The 81xx -> 89xx (or 83xx ->8Bxx) is really a holdover from when the industry used .out files that had no way to handle a secondary input.  So, we had to create a Phantom RadioID to identify the secondary to conform with the out file constraint.  In all our Apps (CIT/Mobile/Web), you see the secondary as Reading 2 and Consumption 2 tied to the based RadioID.

 The modern way to handle this is to use our now default ALL CSV file that has a column for the Sensor ID so you can tell the two inputs apart without the phantom RadioID.  If you are stuck using the older format, the formula in Hex is to add 0x8000000 to the base RadioID. In Decimal that addition is 134,217,728.

Our 140 and 160 series are Standard, our 170 series are MAX.  We stopped making the 140s in 2015; they were our first-generation MDT with the black case back and mounting tab.  For example, TW-162 is Standard Outsider for Norgas meters, a TW-177S-P is MAX Pulse Submersible.

If you look on the CIT in the Configuration>Site Tab, the top left quadrant will say System Type Standard Range or MAX Range. If you don’t have access to the CIT then you can determine by the label on the DCAP or repeaters or MDTs. Standard range DCAP IDs start with "F3", while a MAX DCAP ID starts with "F4".

Standard range Repeater IDs start with "E3", while a MAX Repeater ID starts with "E4".

You cannot use the RadioID to distinguish MDTs.  You will have to rely on the part number, which for Standard range MDTs take the form TW-16xxx while MAX MDTs start with TW-17xxx.

The one "exception" is our display only devices; these do not have a radio and their part number starts with TW-105.

And MDT part number suffix "-N" was our original encoder MDT only for Neptune meters.  We later changed it to -E when we added support to read all encoders (Sensus and Neptune).  You will also see suffix "E+" starting in 2021, this adds support for reading 8 dials on recent Neptune meters.  Before we were limited to only reading six, as it was developed when the older ProRead registers only had 6 moving dials. 

Other popular MDT suffixes:

-G for GWF meters (this is a direct read protocol much like encoder) -P for Pulse -PP for dual pulse -EE for dual encoder

The solar repeater battery has some temperature limitations and the unit is designed to prevent any damage at the temperatures extremes.

The repeater can operate from battery power between -4º F to 140º F (-20º C to +60º C). If the temperature is outside of this operation range AND the solar voltage is too low (night time) then the unit is put in a sleep mode.

Regardless of temperature, the solar repeater will operate when there is enough sunlight on the panel. If the temperature is within the charging temperature range, energy from the solar panel will first power the repeater, and any excess solar energy will charge the battery.

Continuous operation over 122º F (50º C) could lead to a reduced battery life. It is highly recommended the system is setup such that the solar panel protects the Repeater and battery box from direct sunlight.

Under normal conditions, a fully charged battery will last over seven days with zero sunlight (i.e. with a snow covered panel).

It takes only 4 hours of direct sun to fully charge a fully depleted battery

During a 100% overcast day, the panel will provide more than enough energy to the batteries to power the repeater through the night.

Check the Power LED. If it is off then check the DCAP power.

If the Power LED is on (green), then issues can range from an unplugged or faulty Ethernet cable, a change in Internet settings or service provider, new networking equipment, or loss of power to a switch that the DCAP is connected to.

Where the Ethernet cable plugs in, there are green/yellow lights; if those are off there is a physical connection problem within the Ethernet LAN (cable unplugged, switch unpowered). If those connector lights are OK, then check the Status LED on the front of the DCAP. If it is orange/red, then that indicates there is likely been a change in the property's internet configuration. If the Status LED is Green, then our older DCAPs may need to be power cycled. Unplug the power for 20 seconds until the Power LED goes out, then re-power. If the Status LED is off completely, then the DCAP is defective and we can issue an RMA to replace it should it still be under warranty.

Repeaters that are plugged into a GFIC outlet causing the outlet to trip my need replaced or a specific brand and model.  Some brands are very bad, others less susceptible to tripping.  The only ones we know of that have been specifically designed to shield RF interference are manufactured by Leviton, specifically their part number GFWR1-W.   The feedback we've heard is that these don't' trip near our Repeaters, though the spacing should be at least a few feet if possible.

Yes, this meter usually has a few pulse outputs, we recommend using the 1KWh/pulse.  The terminal block has outputs for 10, 100, and 1K (Wh/pulse) and one called ISO COM.  The wiring is polarity sensitive to our MDT, so feed the 1K to our pulse input and the ISO COM to our COM pin.

To reset an MDT's count to zero the tech needs to push and hold the button for 10-12 seconds at the time they take the IMR reading.  All is not lost if that doesn't get done like here.

• First get the date and time when the IMR reading was taken.

• Ensure the CIT or WebApp has data from this IMR reading time.

• Set IMR to 0 and CF to 1 and look at the data graph or table. From this you can see the raw MDT count at the IMR time.

• Set the IMR to the difference (IMR - Raw MDT count) value.  It may or may not be a negative value  

• If you are in the CIT, remember to save.

One other hint about our system: We only store pulse counts from the MDT.  Anytime we display data to you or generate a daily report, we dynamically generate what you see by applying this formula:  Reading = IMR + (MDT Count * CF).  If you change either IMR or CF and go back and look at the readings, you will see the new CF and IMR applied.

Our policy is to require a take-over form, signed by the property management or owner before we can transfer control. You can download the transfer form here.