LTE DIN Rail Digital Transmitter with Ethernet Communication and Analog Outputs for Analog Input Totalizer Applications

LTE Analog Input Totalizer Transmitter Frequently Asked Questions

Why does the transmitter convert the analog input to a frequency internally instead of measuring it directly?

Converting to frequency lets the transmitter use the same precise, quartz-referenced period-timing technique used across the LT/LTE Series for high accuracy, and makes totalizing straightforward since a frequency signal's pulse count over time directly represents an accumulated quantity.

Why is square root extraction needed for differential pressure flow signals specifically?

Differential pressure flow transducers (used with venturi meters and orifice plates) produce a signal proportional to the square of the actual flow rate due to the physics of pressure drop across a flow restriction; square root extraction reverses that relationship so the displayed rate and total reflect true flow rather than the transducer's raw squared output.

Does choosing 0-1 mA, 4-20 mA, or 0-10V input affect measurement accuracy?

No — accuracy is specified as ±0.01% of full scale ±1 count across all three input types; the choice is determined by which signal type the connected transducer or process loop actually produces, not by any accuracy tradeoff between the three.

Does the Ethernet interface affect measurement accuracy or update rate?

No — accuracy and the update rate of up to 25 conversions per second come from the same signal conditioning used across the analog totalizer product line; Ethernet only changes how the reading is transmitted digitally rather than over serial data.

What does the 1/rate function actually compute?

It inverts a rate reading into a time value — for example, if a rate signal represents conveyor speed, 1/rate can be scaled to show the time it takes material to travel a fixed distance, such as passing through an oven, rather than showing the speed itself.

Can this transmitter totalize a signal that requires custom curve linearization instead of square root extraction?

Yes, with the Extended main board — custom curve linearization uses up to 180 user-entered data points and a spline-fit approach to correct nonlinear transducer outputs that don't follow a simple square-root relationship, extending the totalizer to transducer types beyond standard DP flow.

Does the total remain accurate regardless of which gate time is selected?

Yes — totals are calculated as the product of rate and elapsed time in seconds regardless of the selected gate time, so changing the gate time affects display update speed and averaging but doesn't introduce a systematic error into the accumulated total.

What happens to the total if power is lost mid-process?

Totals are stored in non-volatile memory, so an accumulated total survives a power interruption and resumes from where it left off once power is restored, rather than resetting to zero.

Do I need a gateway device to connect this transmitter to my network?

No — the transmitter connects directly to a LAN via its own RJ45 jack over Modbus TCP, without requiring a separate RS485-to-Ethernet gateway.

Can multiple analog input totalizer transmitters be networked together?

Yes — the transmitter supports up to 247 digital addresses via Modbus TCP, allowing many individually addressable transmitters to coexist on the same Ethernet network.

LTE Analog Input Totalizer Transmitter Questions From the Field

My totalized flow reading seems too low at low flow rates but accurate at high flow — what's the likely cause?

If square root extraction isn't enabled (or is enabled when it shouldn't be) for a differential pressure transducer, low-flow readings will be disproportionately affected because the squared relationship compresses low-end signal more than high-end signal; confirming square root extraction is correctly enabled and matched to the actual transducer type is the standard first check.

My total doesn't match what I'd expect from manually multiplying an average rate by elapsed time — why?

The transmitter calculates total continuously as rate times elapsed time at whatever gate time is set, which accounts for rate variation throughout the period; a rough manual calculation using a single average rate will diverge from this if the actual rate fluctuated meaningfully during that time, rather than indicating a transmitter error.

My transmitter isn't showing up on the network — what should I check first?

Confirming the transmitter's IP configuration matches what the network expects, and that the physical Ethernet cable and switch port are functioning, are the standard first checks before suspecting a transmitter fault.

My reading is unstable specifically at very short gate times — what should I check?

Very short gate times trade averaging stability for speed, so genuine signal noise that would otherwise be smoothed out becomes more visible in the reading; trying a longer gate time is the standard first step to confirm whether the instability is inherent to the signal or specific to the short gate time setting.

My 4-20 mA totalizer reads zero total even though the current loop shows a valid signal — what's the first thing to check?

Confirming the transmitter is actually configured for totalizing mode (rather than rate-only display) and that any external reset input isn't stuck in a reset-active state are the first checks, since a valid input signal with an active reset condition or wrong mode configuration would produce a persistent zero total.

Can noise on the analog input loop cause false total accumulation?

Yes — noise superimposed on the analog signal gets converted along with the genuine signal into the internal frequency, so persistent electrical noise can accumulate into the total over time; checking cable shielding, grounding, and loop wiring quality is the standard remedy for unexpectedly high totals with no corresponding real flow.

My Modbus TCP polling occasionally times out even though the transmitter appears connected — what's the likely cause?

Network congestion or too many devices polling the same transmitter simultaneously can cause intermittent timeouts; checking polling frequency from all connected clients and network traffic load is a common troubleshooting step.

Why would switching input type (say, from 4-20 mA to 0-10V) require recalibration?

Each input type uses a different internal input impedance and signal path, so a calibration performed under one input type configuration doesn't automatically carry over to a different input type; recalibrating after changing which analog input type is selected is the recommended practice.