LTE DIN Rail Digital Transmitter with Ethernet Communication and Analog Outputs for Time of Periodic Event Applications

LTE Time of Periodic Events Transmitter Frequently Asked Questions

What's the difference between pulse width and time delay measurement on this transmitter?

Pulse width measures how long a single input signal stays in its active state, while time delay measures the elapsed time between a pulse arriving on one channel and a pulse arriving on the other; which mode to use depends on whether the application cares about the duration of one event or the gap between two separate events.

Why does the transmitter measure between two channels (A and B) instead of just one?

A single channel can only time a pulse against itself, such as its own on-time; using two independent channels lets the transmitter time the interval between two physically separate events — one triggering A and a later one triggering B — which single-channel timing can't capture.

When should I use averaged readings instead of individual pulse measurements?

Individual readings are useful when each specific event's timing matters on its own, such as checking whether one particular cycle ran long; averaging across multiple pulses is better suited to noisy or naturally variable signals where the underlying, typical timing is what a control loop or trend chart actually needs.

What does 0.2 µs resolution mean in practical terms?

It's the smallest timing increment the transmitter can distinguish between two measurements; for applications timing very short events or requiring fine discrimination between near-identical intervals, this resolution determines how precisely two close readings can be told apart.

Does the Ethernet interface affect measurement accuracy?

No — timing accuracy comes from the transmitter's internal signal conditioning and timing circuitry; Ethernet only changes how the already-measured reading is transmitted digitally onto the network, separate from the isolated 4-20 mA analog output.

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

No — the transmitter connects directly to a LAN via its own RJ45 jack, without requiring a separate serial-to-Ethernet gateway in between.

Can this transmitter provide both an analog signal and a digital network reading at the same time?

Yes — the isolated 4-20 mA analog output and the Ethernet-based digital data are both available from the same measurement, so one can feed a PLC analog input or chart recorder while the other is polled over the network.

What kind of signal do the A and B inputs expect?

They accept periodic pulse-type digital inputs, such as those from proximity sensors, photoeyes, or contact closures marking the start and end of an event — the same general category of signal used to trigger a timing measurement in most panel-level automation.

Is this transmitter suitable for DIN rail control panels alongside other equipment?

Yes — it mounts on standard DIN rail, the same mounting format used for relays, terminal blocks, and other panel components, so it integrates into an existing panel layout without custom mounting hardware.

How is this different from a transmitter that measures rate or frequency?

A rate or frequency transmitter reports how often events occur per unit of time; this transmitter instead reports the timing characteristics of the events themselves — how long a pulse lasts or how much time separates two pulses — which is a different measurement even when both are derived from a similar pulse train.

LTE Time of Periodic Events Transmitter Questions From the Field

My timing readings look inconsistent from cycle to cycle even though the process seems stable — what should I check?

Switching from individual pulse measurement to averaged pulse width or time delay across multiple pulses is the standard way to smooth out normal event-to-event variation; if readings are still inconsistent after averaging, sensor mounting and signal quality on the triggering channel are the next things to check.

My time delay reading seems to be measuring the wrong pair of events — what's the likely cause?

Since time delay is measured specifically between channel A and channel B, confirming which physical sensor or trigger is wired to each channel is the standard first check when the reported interval doesn't match what's physically happening on the line.

My pulse width reading reads much longer or shorter than the actual event duration — what should I check?

A mismatch between the reported pulse width and the actual event usually points to the triggering sensor's signal not cleanly matching the true start and end of the event — for example, sensor bounce or a threshold set too sensitively — so checking the sensor's signal quality and trigger threshold is the standard first step.

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 analog output reading and my Ethernet reading don't seem to match — why?

Both outputs are derived from the same underlying measurement, so a mismatch usually points to a scaling or range configuration difference between how the analog output and the digital reading were each set up, rather than two separate measurements being taken.

My averaged reading changes very slowly even though I can see individual events happening faster than that — is this normal?

Yes — averaging across multiple pulses is designed to smooth the reading over time rather than update on every single event; if faster response to each individual event is actually what's needed, switching to individual pulse measurement rather than averaging is the appropriate setting.

Can I use this transmitter if my two events are triggered by different types of sensors on channels A and B?

Yes — the A and B channels are independent digital inputs, so different sensor types can trigger each channel as long as both provide a signal the transmitter can read as a clean pulse; verifying each sensor's output type is compatible with the transmitter's input is the standard first step during setup.

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.