Every utility connectivity tender I read specifies throughput, availability and latency — and almost never specifies what the site does about time. That is the gap that turns a two-hour outage into a two-week investigation. A feeder trips, two devices record it, and the two records disagree by half a second, so nobody can say which device operated first. This is a field guide to specifying an industrial 4G/5G router for utilities as part of the grid’s timing architecture rather than as a pipe that happens to carry timestamps.
Written by E-Lins Engineering Team
Two Event Records, One Fault, and a Question Nobody Could Answer
A distribution feeder tripped at 04:12 on a wet Tuesday. The recloser at the substation end logged an overcurrent operation; a pole-top sectionaliser two kilometres out logged the same event. In the control room the two records arrived in the wrong order, and the two clocks disagreed by just under half a second. Two days later the outage report went out with the sequence marked “undetermined”.
Nothing was broken: radios attached, tunnels up, packets delivered, SCADA front end happy. What was missing was a shared notion of when — and that half second cost more engineering time than the fault did.
That is the argument of this article: on the grid the most valuable payload a router carries is not a measurement but a timestamp. Bandwidth is the easiest requirement to meet and the most over-specified; time is what decides whether an incident can be reconstructed, a fault located, a dispatch settled or a tariff applied. Specify the link and forget the clock, and you own a network that works perfectly and tells you nothing.
| The core point, if you read nothing else: treat site time as a designed utility, not a default setting. For every grid-edge site, answer four questions before ordering hardware — who stamps the event, how good is that clock, what happens when the reference disappears, and how will you know when it has drifted. An industrial 4G router for utilities sits exactly where those four questions land: the only wide-area link at the site, the only local clock, and optionally the only GNSS receiver. |
Every platform in the range lists power control among its target applications and ships with a real-time clock disciplined by NTP at defined intervals, with GPS/GNSS optional. Where a router clock is the right answer, where it is not, and how to draw that line before an incident review finds it — that is the rest of this article.
Four Things on the Grid Need a Clock, and They Want Very Different Accuracies
“The grid needs accurate time” is not a requirement — it is six requirements wearing one coat. Separate them: they differ by six orders of magnitude and fail in different ways.
| What consumes time | Order of accuracy | What goes wrong when it is missing |
|---|---|---|
| Sequence-of-events (SOE) reconstruction protection IEDs, recloser controllers, RTUs | ~1 ms | Operation order becomes undetermined; the incident report cannot say which device cleared first |
| Travelling-wave fault location | ~1 µs | Roughly 150 m of line per microsecond of error — the patrol crew walks the wrong span |
| Synchrophasors / distribution PMUs IEEE C37.118 class | ~1 µs | Total vector error exceeds limits; the state estimator discards the data as unusable |
| DER ride-through, dispatch and settlement IEEE 1547-2018 behaviour, VPP dispatch | cycles to seconds | Ride-through events mis-characterised; dispatch windows and settlement disputes |
| AMI interval data and time-of-use tariffs | seconds to a minute | Energy lands in the wrong tariff bucket; load profiles do not reconcile |
| SCADA event ordering across sites IEC 60870-5-104, DNP3, Modbus TCP | 10–100 ms | Cross-site event lists mis-ordered; root-cause analysis chases the wrong device |
| Fleet log correlation Syslog, NMS, fault records | 100 ms – 1 s | Two logs from two sites cannot be read as one story |
The pattern is worth stating plainly: the closer a decision sits to the conductor, the tighter the clock it needs. Protection and fault location live at the microsecond end; commercial and operational processes at the second end. The classic procurement mistakes are buying one accuracy for everything and — far more often — discovering after an incident that no accuracy was bought at all.
Why the Distribution Edge Suddenly Has a Clock Problem
Time used to be a substation problem, and a solved one: a GPS clock in the station, a station bus to distribute it, every IED inside the fence agreed. Out on the feeder, devices were polled and had no clock worth discussing.
That arrangement expired. Distribution automation — FLISR schemes, reclosers and sectionalisers, capacitor bank controllers, fault indicators, power-quality monitors — turned the edge into something that produces events rather than readings. DER made thousands of small sites parties to dispatch decisions. AMI turned the meter into a reporting endpoint. Events and dispatch both need to say when.
Fiber will not follow them: the economics of the tail do not support it, and the sites that most need reporting are furthest from the core. So cellular became the backhaul — increasingly primary rather than backup — and time became something that must be created locally, at thousands of sites, by hardware nobody thinks of as a clock.
Which is why the router is where this lands. At a grid-edge site it is usually the only device with a wide-area link, the only battery-backed local clock, and the only device that can be given a GNSS receiver. Everything here follows from deciding, per site class, which of those roles it plays.
Where the Milliseconds Go: A Timing Budget, End to End
Time is not delivered, it is built — and every hop adds error. Write the chain down and the design questions answer themselves:
| Hop | Typical error contributed | Who controls it |
|---|---|---|
| GNSS signal at the antenna | tens of nanoseconds — with clear sky | Antenna placement, sky view |
| Antenna cable | ~5 ns per metre of propagation delay; loss is the real limit | Cable grade and length |
| Receiver fix quality | nanoseconds to microseconds | Satellite geometry, multipath, canopy |
| Platform clock discipline | depends on how the platform uses the fix | Order code and firmware — confirm |
| Distribution over the site LAN | typically well under 1 ms on a quiet LAN | LAN design and load |
| Distribution over the cellular WAN | 5–100 ms, several hundred under load | Congestion and path asymmetry |
| Application / OS timestamping | milliseconds and up | Where in the stack you stamp |
Two hops quietly dominate. The first is path asymmetry: NTP assumes forward and return delays are equal, and on a cellular link they are not — uplink and downlink take different routes, sit in different queues and are scheduled differently by the radio. The result is a fixed offset no amount of averaging removes, and it moves when the traffic mix moves.
The second is where the timestamp is applied. A millisecond clock is meaningless if the measurement reaches the head-end through hundreds of milliseconds of variable delay and is stamped on arrival. Stamp at the source — in the IED, the controller, the meter — or the network’s accuracy is irrelevant to the record’s accuracy.
| Worked example — why 380 ms matters and 380 µs does not |
| Two recloser controllers on one feeder, each with 1 ms SOE resolution, each stamping locally. Their clocks differ by 380 ms because one is disciplined over the WAN and the other over a station reference. The resolution is fine; the offset between sites is 380 events wide. No amount of bandwidth fixes that. |
NTP Over Cellular: What It Can Honestly Deliver
Measured expectations, not marketing: NTP from a grid-edge router to a well-placed server over a healthy LTE link lands in the tens of milliseconds. Under load, during congestion, or while a fault record uploads, it runs to hundreds — and the offset is not constant, which is worse than being large.
The update interval matters as much as the offset. The datasheets describe a real-time clock supporting NTP updates at defined intervals. If that interval is long, the clock free-runs between updates for hours and everything in the next section applies to those hours. Set the interval against the drift you can tolerate, not against the default.
What WAN-disciplined time is genuinely good for: Syslog and NMS correlation across sites, monitoring timestamps, coarse event ordering, interval metering and operational awareness — most of what a utility fleet does day to day. What it cannot do is anything on the microsecond end of the ladder in Section 02.
Draw the line in the design, not during the incident. No router is a protection-grade time source, and nothing in the datasheets claims IEC 61850-3, IEEE 1613 or PTP grandmaster behaviour — they list an optimized EMC design, a real-time clock with NTP update and an optional GNSS receiver. For SOE, travelling-wave location or synchrophasors, install a dedicated station clock and let the router carry its output. Before designing around GNSS-derived time or PTP, confirm what your order code and firmware actually expose.
| Draw the line in the design, not during the incident. No router is a protection-grade time source, and nothing in the datasheets claims IEC 61850-3, IEEE 1613 or PTP grandmaster behaviour — they list an optimized EMC design, a real-time clock with NTP update and an optional GNSS receiver. For SOE, travelling-wave location or synchrophasors, install a dedicated station clock and let the router carry its output. Before designing around GNSS-derived time or PTP, confirm what your order code and firmware actually expose. |
The rule I use in reviews: NTP over cellular buys correlation, not correlation at one millisecond. Write that sentence into the design basis, define which sites need more, and the rest of the architecture stops being an argument.
GNSS at the Site: Sky View Is the Whole Game
GNSS signals arrive below the thermal noise floor — around −130 dBm. They do not pass through a steel kiosk roof, a switchroom wall or a busbar canopy. At a grid site that is the most common reason a GNSS option under-delivers: the receiver is fitted, the antenna is inside, and the fix never happens.
The placement rules are short and worth putting in the method statement: mount the antenna outside with a clear view of the horizon; keep it away from switchgear, cable trays and busbar runs; use short low-loss coax or a properly amplified antenna for long runs; keep separation from the cellular antennas; and fit a surge arrestor bonded to the station earth. Grid sites are the worst place to skip lightning protection on a roof antenna.
Every platform offers GPS/GNSS as an option with an SMA antenna connector, and the modem lists GPS, GNSS, Beidou. Order the antenna, cable and arrestor with the unit — a router with a GNSS option and no antenna is a specification line, not a clock.
Where there is genuinely no sky — indoor substation, basement switchroom, dense urban canyon — there are three honest answers: run the antenna out, accept documented WAN-disciplined time with a known offset, or feed the site from a dedicated clock. Put the choice in the design basis and alarm on it.
Holdover: The Hours That Decide Whether an Investigation Is Possible
Holdover is what happens when the reference goes away — GNSS blocked, WAN down, NTP unreachable — and the site clock free-runs. Every site does it; almost nobody budgets for it. And the hours after a fault are exactly when references are least available.
| RTC drift rate | Error after 1 hour | Error after 24 hours | Still usable for |
|---|---|---|---|
| 1 ppm | 3.6 ms | 86 ms | SCADA ordering, log correlation |
| 5 ppm | 18 ms | 0.43 s | Operational awareness, interval data |
| 20 ppm | 72 ms | 1.7 s | Nothing time-critical — alarm well before this |
Those numbers move with temperature, which is why a pole-top cabinet in midsummer — swinging 40 °C between night and afternoon — drifts worse than the same board in a climate-controlled switchroom. Treat the table as arithmetic to verify, not as a specification: one ppm is one microsecond per second, and everything else follows.
| How to measure your own drift — one afternoon’s work |
| Discipline the site clock from its normal reference, then remove the reference entirely for 24 hours. Log the clock against a trusted source at the start and the end, divide the difference by the elapsed time, and you have that unit’s real drift rate in ppm — on that site, in that season. Do it once per site class and you can set holdover alarm thresholds from measurement instead of hope. |
Then operationalise it: set a holdover budget per site class, alarm when holdover age exceeds it, write holdover state into the logs alongside the data, and re-verify site time before publishing any sequence from an incident. A timestamp with no quality indicator is an opinion.
Legacy Devices Don’t Speak NTP: Serial, Modbus and DTU at the Edge
Most of what sits on a feeder is not an IP device with an NTP client. It is a meter, a protection relay, an RTU or a fault indicator talking Modbus over RS-232 or RS-485 — and much of it has no clock anyone has ever set. The platforms carry that reality: serial RS-232/485 ports, Modbus support and DTU (serial to cellular) transport.
When the end device cannot stamp its own data, somebody else does — gateway or head-end — which puts both the router’s clock quality and the transport delay inside the record. Two rules follow: stamp at the source wherever the device supports it, because a recloser controller with event buffering beats anything downstream; and if you must stamp on arrival, document the uncertainty rather than pretending the record is precise.
Serial transport is a timing consideration people forget. At 9,600 baud 8N1 the wire moves roughly 960 bytes per second, so a 100-byte poll response spends about 100 ms on the copper — longer than a whole SOE window. Raise the baud rate where the device allows it, and remember that a device polled every five seconds carries ±5 s of ambiguity however good your clock is. Where the protocol allows unsolicited reporting, use it: the clock only helps if the data arrives when the event did.
Station Power, Battery Rails and the Watchdog
Grid sites have their own power conventions and they do not match the router’s. Telecom-style and many utility sites run a 48 V DC auxiliary rail; traditional substations run 110 V, 125 V or 250 V station batteries. The router input is 5–40 V DC with a 5–60 V DC option, with dual or tri inputs and failover.
The honest mapping: a 48 V rail needs the 5–60 V version — the datasheets say as much, noting that where the PoE voltage is 48 V you order the 5–60 V DC variant. Station batteries at 110 V and above are outside the input range entirely and need a properly specified DC-DC converter, sited and fused as part of the panel design. The datasheets also state a 3 A fuse for 9–24 V DC installations — follow it, and use the 2-pin terminal block rather than a DC jack in anything that vibrates.
Input protection is not a nicety here. Reverse polarity and transient voltage protection to ISO 7637-2, plus over-current and over-voltage protection, is what rides through the switching transients that accompany breaker coil operations — not coincidentally, the events you are trying to record.
Why this belongs in an article about time: a reboot destroys clock state, tunnel state and anything buffered, and the moment a station battery dips is when the network is most valuable. Wide input range, dual inputs with failover and a built-in watchdog turn a dip into a log entry instead of a gap in the sequence.
Consumption is modest: roughly 100 mA idle and 300 mA transmit/receive at 12 V (about 1.2–3.6 W). At a 3 W average, a 12 V 20 Ah battery carries the site for roughly two days. For pole-top solar, size the panel against the worst month of the year, not the annual average.
Commissioning Checklist — Ten Steps, in This Order
- Classify each site by time need — microsecond, millisecond or second — before choosing hardware.
- Decide who stamps the event and write it down: source device, gateway or head-end. Stamp at source wherever the device allows it.
- Survey GNSS at the intended antenna position — outside, horizon visible — and record the fix, not the signal bars.
- Order the antenna, cable and surge arrestor with the unit, and bond external antennas to the station earth.
- Set the NTP update interval against drift tolerance, using two internal servers where the APN allows it.
- Measure real RTC drift per site class and set a holdover age alarm from that measurement.
- Match the supply to the input range — 48 V needs the 5–60 V version; 110 V and above need a DC-DC converter; fuse per the datasheet.
- Give time packets their own queue: strict priority for NTP and protection traffic, a shaped ceiling for fault records, firmware and video.
- Lock the management plane: HTTPS only, Telnet and unused services off, RADIUS/TACACS+, SNMP v3, NTP-synced remote Syslog.
- Provision from an NMS template and capture the evidence — clock health, holdover age and time-jump events as reportable fleet KPIs.
Time Packets Are Small and Impatient: Queue Design
An NTP exchange is about 90 bytes. It is the smallest traffic on a utility site and the least tolerant of delay — and it loses to everything, because a router that is busy uploading a fault record will happily put a 90-byte timing packet behind several megabytes of history.
This is the cruel part: the biggest burst on a grid-edge site arrives immediately after the event you need to time-stamp. Digital fault records, disturbance files, camera clips and AMI backfills all queue at once, and the NTP offset spikes in exactly the window the incident review will depend on.
The fix is standard, applied deliberately: DSCP classification plus priority queuing — both halves, because a mark with no queue behind it is documentation. Give bounded streams strict priority: NTP, protection and telemetry, alarms, tunnel keepalive. Give unbounded bulk — fault records, firmware, video, backfill — a shaped queue with a hard ceiling sized from the measured worst hour. Then document where post-fault bulk may go, because it will go somewhere.
The Clock Is an Attack Surface
Time is a security input, not a convenience: log correlation, certificate validity, event ordering, tariff intervals and access rules all trust it. Move the clock and you can reorder history and invalidate an evidence trail — with no alarm anywhere, because nothing failed.
The threats are unglamorous. An unauthenticated or hijacked NTP server sets the clock where the attacker likes. NTP reflection turns your infrastructure into someone else’s weapon. GNSS jamming and spoofing are documented around critical infrastructure, cheap to perform and nearly invisible unless you watch for them. A large time step silently corrupts every record in its window.
The controls: restrict NTP to servers you own, authenticate it where your deployment supports it, and treat any large time step as a security event with an alarm and a log entry. Cross-check plausibility — does the reported position move when it should not, does time jump when nothing else changed. Carry records inside an IPsec tunnel. Lock the management plane: HTTPS only, Telnet and unused services disabled, RADIUS/TACACS+, SNMP v3, remote Syslog with NTP-synced timestamps.
One physical control belongs here because it is cheap and usually skipped: wire the cabinet door to a digital input. A door switch on DI raises an alarm over SMS — out of band, so it arrives even when the data path is what failed. Someone opening an RTU cabinet at 03:00 is a security event, and it should be a timestamped one.
| Ask for the certificate list, not the adjective. The datasheets describe an “extensive list of safety and hardening certifications” without naming grid standards, and make no claim of IEC 62443, IEC 61850-3 or IEEE 1613 compliance. If a tender requires a specific utility standard, request the certificate list for the exact order code and have it attached to the order. |
| “The failure I see most isn’t a clock that’s wrong. It’s a clock nobody ever defined — no owner, no budget, no alarm — so the first time anyone asks what time it was, the honest answer is that nobody wrote it down.” — E-Lins Engineering Team, on utility connectivity design reviews |
What to Spec: Matching the Platform to the Site Class
Grid-edge sites are not one shape. A secondary substation, a pole-top recloser on solar and a compact RTU cabinet in a street kiosk are three hardware problems — one platform for all three is how fleets over-pay at the substation and under-build at the pole.
| Model | SIM | Ethernet | Serial / I/O | Timing | Power & environment | Best for |
|---|---|---|---|---|---|---|
| H685 super-mini 4G | Single SIM | 2 × 10/100 LAN/WAN | RS-232/485, DI/DO × 4 | RTC + NTP; GNSS optional | 5–40 V DC (5–60 V option), dual inputs, −35…+75 °C, IP30; 100 × 60 × 21 mm | Compact RTU cabinets and fault-indicator concentrators where space is tight. Wi-Fi, GNSS, PoE PD, eSIM optional. |
| H750 compact dual SIM | Dual SIM, 8 modes | 3 × 10/100 LAN/WAN switchable | RS-232/485, DI/DO × 4, MicroSD | RTC + NTP; GNSS optional | 5–40 V DC (5–60 V option), dual/tri inputs, PoE PD, −35…+75 °C | The default dual-carrier grid-edge site — two carriers where one mast would otherwise be a single point of failure. |
| H700 dual SIM, multi-port | Dual SIM, 8 modes | 5 × gigabit switchable WAN/LAN | 2 × serial (DB9 + terminal), DI/DO × 4, USB 3.0, MicroSD | RTC + NTP; GNSS optional | 5–40 V DC (5–60 V option), dual inputs, −35…+75 °C; dual-band Wi-Fi | Secondary substations and RTU panels with several devices, where segmentation needs real ports. |
| H900 gigabit 4G, PoE PSE | Dual SIM, dual online option | Gigabit WAN + 4 × LAN with PoE/PoE+/PoE++ | RS-232/485, DI/DO × 4 | RTC + NTP; GNSS optional | 5–40 V DC (5–60 V option), PoE PD or PSE 802.3af/at/bt, −35…+75 °C | Sites that must power a camera, gateway or monitor from the router itself. |
| H900f gigabit 5G | Dual SIM | Gigabit WAN + 4 × LAN | RS-232/485, DI/DO × 4 | RTC + NTP; GNSS optional | Wide DC input, PoE option, eSIM option, −35…+75 °C; ~120 mA idle | Dense urban sites where 5G is real and fault-record uploads are heavy. |
| H820QO IP68 outdoor | Single SIM; dual optional | 2 × LAN/WAN | Built-in high-gain cellular and Wi-Fi antennas, reserved external connectors | RTC + NTP; GNSS optional | IP68, PoE PD, 5–40 V DC (5–60 V option), −35…+75 °C; pole, wall, desktop or DIN mount | Pole-top reclosers and outdoor kiosks — mount it outside the steel and sky view solves itself. |
| M300 USB cellular modem | Single SIM, APN failover | — | USB with ESD protection; GNSS option | RTC; GNSS optional | 5–40 V DC (5–60 V option), IP30; ~85 mA average | Only where the RTU or PLC owns the stack — a WAN interface and no segmentation, so the boundary must be enforced elsewhere. |
Four things to confirm against the order code: the GNSS option, with antenna, cable and surge arrestor on the order; whether the platform exposes GNSS time to the RTC or position only; that the NTP update interval is configurable to your drift budget; and whether PTP / IEEE 1588 hardware timestamping is supported — if not, PTP slaves see the jitter in Section 05 and will not lock.
Fleet-Scale Time: Templates, Rings and Evidence
Everything above is per-site engineering. At a few thousand sites a different discipline takes over: nothing about a site’s configuration should be typed on site, and time configuration least of all.
A utility estate has a handful of archetypes — site class, time requirement, carrier and APN, GNSS fitted or not, holdover threshold. Those should exist as templates, and the site should pick its template up on first boot, build its tunnel and appear in the inventory without a technician opening a laptop. Cloud-based NMS network management with web UI, API and CLI, plus TR-069 auto-provisioning, makes that possible — and the template is where NTP servers, update interval, DSCP policy and Syslog target belong.
Firmware is where fleets get hurt, and grid fleets have a longer walk to every site. A bad image pushed to thousands of unattended devices is a mass outage requiring a technician at each one, because they cannot be reached once they stop routing. Roll out in rings, keep the previous image reachable so rollback is a configuration, schedule pushes for quiet hours, and keep SMS control available.
Then make clock health a fleet KPI rather than a per-site curiosity. Four numbers per site, reported and alarmed: GNSS fix state, holdover age, NTP offset and time-jump events. Those four turn “we believe the clocks are fine” into a report an auditor can read — and catch the slow failure that otherwise surfaces only during an incident review.
Three Deployment Patterns That Illustrate the Decisions
| Pattern A — Urban Secondary Substation in a Steel Kiosk |
| Multi-device site with a local RTU, meters and a switch: H700 for five switchable gigabit ports and two serial interfaces. GNSS antenna out to the kiosk roof with a short low-loss run and a surge arrestor bonded to the station earth; 48 V rail, so the 5–60 V version is ordered; time distributed to local devices over the site LAN; holdover age alarmed. |
| Pattern B — Pole-Top Recloser on Solar, FLISR Scheme |
| H820QO mounted outside the cabinet with its built-in high-gain antennas, so neither the cellular link nor the GNSS antenna fights steel. Power budgeted at 2–4 W against the worst month; dual SIM on signal strength, dial fail and ICMP check; watchdog on. SOE is stamped inside the recloser controller — the router carries it, it does not create it. |
| Pattern C — Collector Substation and DER Cluster on 5G |
| H900f where 5G coverage is real and disturbance records are large. Fault-record upload sits in a shaped queue with a ceiling sized from the measured worst hour; NTP, protection and tunnel keepalive take strict priority; PTP confirmed against the order code before anyone designs a scheme that depends on hardware timestamping. |
Frequently Asked Questions
Q1：Can I use NTP over cellular for sequence-of-events timestamps?
No. Expect tens of milliseconds on a healthy link and several hundred under load — fine for log correlation and interval data, useless at 1 ms. Use a dedicated station clock for SOE.
Q2：Does the GNSS option make the router a time server?
It adds a GNSS receiver (GPS/GNSS, and GPS/GNSS/Beidou on the modem) with an SMA antenna connector. Whether GNSS time disciplines the internal RTC — or is exposed to LAN devices — must be confirmed against your order code and firmware.
Q3：What do I do at a site with no sky view at all?
Three honest options: run the antenna outside, accept documented WAN-disciplined time with a known offset and alarm on holdover age, or feed the site from a dedicated clock. Choose one and write it into the design basis.
Q4：Can I power the router from a 125 V station battery?
Not directly — the input is 5–40 V DC with a 5–60 V DC option. A 48 V rail needs the 5–60 V version; 110 V and above need a DC-DC converter. Fuse per the datasheet and use the terminal block.
Q5：Will it carry PTP / IEEE 1588?
Only if hardware timestamping is confirmed for your exact order code. Without it, PTP slaves see the jitter in Section 05 and will not lock — confirm before the design depends on it.
Q6：How do I demonstrate clock health to an auditor?
Remote Syslog with NTP-synchronised timestamps, measured drift per site class, holdover-age and time-jump alarms, and a per-site time quality report. “We believe the clocks are right” is not evidence.
| Conclusion: Specify the Clock Before the Link |
| A utility network that moves every packet on time and cannot say when anything happened has failed at the one job that matters after an incident. Bandwidth is a solved problem on grid-edge sites; time is not, and it will not solve itself as a side effect of a faster radio. Decide what accuracy each site class needs, decide who stamps the event, give the reference a sky view and a budget for when it is gone — and the hardware choice becomes straightforward. |
| Three things to verify before finalising a grid-edge connectivity design: —Classify sites by time need first — microsecond, millisecond or second — and write down who stamps the event. Let that choose the hardware. —Treat holdover as a designed budget, not an accident. Measure real drift per site class, set the NTP interval and the holdover alarm from that measurement, and report clock health as a fleet KPI. —Confirm every timing claim against the order code: GNSS fitted or not, time discipline or position only, PTP timestamping or not, certificate list or adjective — in writing, before the tender closes. |
Building Distribution Automation, DER Backhaul or AMI Connectivity?
Tell E-Lins your site classes, time requirements, supply rails and markets. We’ll confirm the timing architecture, the QoS and tunnel design, the antenna strategy and the right platform — H685, H750, H700, H900/H900f or H820QO — for the network you actually operate.
