Breaking News

GLOBAL Wi-Fi NEWS bulletin

We’re a long way from simple greasepaint and limelights. In today’s world of live entertainment, precision is everything. A spotlight that arrives a fraction too late, a sound cue that doesn’t quite match the performer’s position or a camera angle that misses the emotional beat can pull audiences out of an otherwise magical experience. For Vienna-based zactrack, the mission is simple but ambitious. Make those distractions disappear.

Powered by Ultra-Wideband technology from Qorvo, zactrack enables real-time performer tracking through wearable trackers that capture highly precise positional data on stage. This data is calculated and seamlessly transmitted to lighting, audio, video and camera systems, transforming how they work together in real time. The result is seamless, immersive performances that feel effortless to audiences and empowering to creative teams.

From Data to Drama

“We are now coming from the entertainment industry,” said Chief Technical Officer Christoph Rosenberg. “The core of zactrack has always been processing data. You’re getting some data input, you process it and you control different protocols or fixtures.”

That “core math,” as Rosenberg describes it, is the brain of the system. It predicts motion, calculates positioning and distributes precise tracking data across lighting consoles, audio systems, media servers and cameras. Early systems relied on complex fiber-based solutions. Over time, zactrack embraced Ultra-Wideband as the ideal input technology for real-time performer tracking.

Today, zactrack builds its own Ultra-Wideband hardware using Qorvo DWM modules, combining accurate positioning with low latency and high reliability. The tracking data feeds directly into Zactrack’s software engine, enabling automated control across an entire production.

The technology has evolved far beyond its original purpose. What began primarily as a lighting tool is now a creative and strategic platform used across multiple disciplines.

A Creative Connector

zactrack Marketing Manager Yvonne Bolhar-Nordenkampf has seen firsthand how the technology brings people together.

“At the very beginning, people implemented it as a technical solution,” she explained. “They had an issue, and it solved that issue. But then it became so much more.”

On London’s West End alone, zactrack systems are currently used in more than 10 productions. Designers who initially adopted the system for automated follow-spot functionality are now leveraging it for immersive audio and media effects, all synchronized to performer movement.

Traditionally, lighting, audio and video departments worked in parallel but rarely in close collaboration. Tracking data is changing that dynamic. With a single, reliable source of positional information, multiple departments can build from the same creative foundation.

“It has become a creative tool, but also a connective tool,” Bolhar-Nordenkampf said. “Hardware and software that were just technical systems are now connecting people in productions.”

That sense of community extends beyond the stage, as zactrack has expanded its online presence by launching a dedicated Discord channel and sharing designer interviews on Instagram, creating spaces where users can connect, exchange ideas and learn from one another. By encouraging long-time users to share their expertise with newcomers, these platforms foster collaboration, knowledge-sharing and a global network of designers and technicians united by shared creative experiences.

Transforming the Audience Experience

For audiences, the impact is immediate and emotional.

Rosenberg describes a simple example: in a traditional theater setup, when a performer walks across the stage, their voice still appears to come from the front. With Ultra-Wideband-based tracking, immersive audio systems can shift the sound in real time to match the performer’s position. Even with eyes closed, the audience senses exactly where the actor stands.

Photo_1_zactrack_Pro_System_Setup-Reflection_15012026_copy.jpg

zactrack PRO is an automated follow-system to fulfill all requirements for big projects. People and objects in motion are tracked with high accuracy and represented in a 3D model. High-precision mathematics automatically control moving lights, video and sound devices.

Lighting has undergone a similar evolution. Instead of a single static white follow-spot, any moving head fixture in the rig can dynamically track a performer from multiple angles, eliminating harsh shadows and opening new creative possibilities.

“You are not limited anymore to fixed positions,” Rosenberg said. “When people get these ideas, they start to think more creatively.”

That creativity was on full display at the world premiere of “House of Dancing Water” by Dragone in Macau, one of the world’s most technically ambitious productions. Sitting in the audience after months of development, Rosenberg felt the emotional payoff.

“When you put so much effort and work into a project and then feel how smoothly it goes. Without this technology, the production wouldn’t work. That feeling is really special,” he said.

A Global Stage

Now celebrating its 17-year anniversary, zactrack operates in more than 30 countries and is trusted by global brands and productions, from Maria Theresia – Das Musical in Vienna over The Hunger Games: On Stage in London to AVATAR’s In the Airwaves World Tour.

Behind the spectacle is a powerful partnership built on precision positioning. As productions demand greater accuracy, new frequencies and ever-higher reliability, Ultra-Wideband technology continues to unlock new creative frontiers.

“We’re always looking into new technologies to move forward,” Rosenberg said. “And we hope Qorvo is the right brand to go into the future with us; with new ideas, new frequencies, new accuracy.”

For performers, designers and audiences alike, that future looks brilliantly in sync.

Want the backstories about RF technology? Explore our blog.

Ready to look under the hood? Discover our robust library of technical articles.

CEO/CTO Dr. Ali Fard will discuss RF front-end advancements on Oct. 8

ZURICH — Oct. 2, 2026 — QuantalRF, the pioneering developer of RF semiconductor and antenna solutions, today announced that CEO/CTO Dr. Ali Fard will speak at Wi-Fi World Congress Europe 2026. Hosted by Wi-Fi NOW, the free, three-day virtual event runs Oct. 6–8 and brings together the European wireless industry to discuss the future of intelligent connectivity. Other speakers include MediaTek, Silicon Labs, NXP, Intel, Cisco, HPE and the Wi-Fi Alliance.

Dr. Fard will present “Enabling Future Wireless with Innovations in RF” on Thursday, Oct. 8, from 17:45 to 18:05 CEST. The final day of the event focuses on the wireless technologies that will define the next decade. In his session, Dr. Fard will explain why RF front-end technology has not kept pace with advances in Wi-Fi standards and how CMOS SOI intelligent, adaptive architectures can improve power efficiency and range while lowering cost for next-generation Wi-Fi access points, mobile devices and edge AI.

“Future wireless systems—from Wi-Fi 8 to satcom and edge AI devices—will demand far more from hardware, especially RF,” said Dr. Fard. “At QuantalRF, we’ve redesigned the RF front end from the ground up to deliver better efficiency and integration on mature silicon processes. I look forward to sharing how these innovations can help the wireless industry close the gap between what Wi-Fi standards promise and what RF hardware can deliver.”

To attend this virtual event, register here.

About QuantalRF AG

QuantalRF is transforming the RF signal chain for wireless communications to deliver an unmatched user experience. Its ultra-compact, highly configurable front-end ICs and extremely efficient antennas substantially improve area, cost, power, and overall performance. Headquartered in Zürich, Switzerland, with R&D centers in the USA and Sweden, QuantalRF has an extensive portfolio of over 225 patents. For more information, visit www.quantalRF.com.

Forward-Looking Statements

This announcement contains forward-looking statements that reflect our current expectations and projections about future events. These statements are not guarantees of future performance and are subject to risks, uncertainties, and other factors that may cause our actual results to differ materially. We undertake no obligation to update any forward-looking statements. A non-exclusive list of risk factors may be found on our website at www.quantalRF.com/forward-looking-statement.

Wi-Fi HaLow USB Dongle HaLowFly-Field Testing

 

𝙏𝙚𝙨𝙩𝙞𝙣𝙜 𝙒𝙞-𝙁𝙞 𝙃𝙖𝙇𝙤𝙬 𝙞𝙣 𝙩𝙝𝙚 𝙛𝙞𝙚𝙡𝙙 𝙟𝙪𝙨𝙩 𝙜𝙤𝙩 𝙚𝙫𝙚𝙣 𝙚𝙖𝙨𝙞𝙚𝙧!

Keeping your setup clean, compact, and completely 𝗵𝗮𝗻𝗱𝘀-𝗳𝗿𝗲𝗲.

When conducting signal validation or field testing with our 𝗛𝗮𝗟𝗼𝘄𝗙𝗹𝘆 𝗨𝗦𝗕 𝗗𝗼𝗻𝗴𝗹𝗲, holding both your phone and the dongle can be a hassle.

To solve this, we’re introducing a 𝗳𝗿𝗲𝗲 𝟯𝗗-𝗽𝗿𝗶𝗻𝘁𝗮𝗯𝗹𝗲 𝗽𝗵𝗼𝗻𝗲 𝗮𝘁𝘁𝗮𝗰𝗵𝗺𝗲𝗻𝘁 𝗰𝗹𝗮𝗺𝗽!

🛠️ 𝗛𝗼𝘄 𝘁𝗼 𝘀𝗲𝘁 𝗶𝘁 𝘂𝗽 𝗶𝗻 𝟯 𝘀𝗶𝗺𝗽𝗹𝗲 𝘀𝘁𝗲𝗽𝘀:

1️⃣ 𝗗𝗼𝘄𝗻𝗹𝗼𝗮𝗱 & 𝗣𝗿𝗶𝗻𝘁:

Get the free STL file from our website and print it with your 3D printer.

2️⃣ 𝗦𝗻𝗮𝗽 𝗶𝘁 𝗶𝗻:

Securely insert your HaLowFly into the printed clamp.

3️⃣ 𝗠𝗼𝘂𝗻𝘁 𝘁𝗼 𝗣𝗵𝗼𝗻𝗲:

Use double-sided tape to attach the clamp to the back of your phone.

🌧️ 𝗡𝗲𝗲𝗱 𝗲𝘅𝘁𝗿𝗮 𝗽𝗿𝗼𝘁𝗲𝗰𝘁𝗶𝗼𝗻 𝗳𝗼𝗿 𝗼𝘂𝘁𝗱𝗼𝗼𝗿 𝘁𝗲𝘀𝘁𝗶𝗻𝗴?

Our IP55 Waterproof HaLowFly is designed for field applications where additional protection from dust and water is needed.

👉 𝗛𝗮𝗟𝗼𝘄𝗙𝗹𝘆 𝗨𝗦𝗕 𝗗𝗼𝗻𝗴𝗹𝗲 & 𝗳𝗿𝗲𝗲 𝟯𝗗-𝗽𝗿𝗶𝗻𝘁𝗮𝗯𝗹𝗲 𝗳𝗶𝗹𝗲:

Connect Any Device to Wi-Fi HaLow in 10 Seconds: Fast & Easy Guide

💧𝗜𝗣𝟱𝟱 𝗪𝗮𝘁𝗲𝗿𝗽𝗿𝗼𝗼𝗳 𝗛𝗮𝗟𝗼𝘄𝗙𝗹𝘆:

IP55 Waterproof Wi-Fi HaLow USB Dongle, HaLowFly

𝙉𝙤𝙩𝙚:

The 3D-printable STL file is available for free download upon purchasing the HaLowFly. The physical clamp is not included in the product package or sold separately.

#AsiaRF #WiFiHaLow #HaLowFly #IoT #SmartCities

The 20 Meters That Decide Churn

A healthy network dashboard may be hiding broadband customer frustration.

Consider the customer whose AI prompt times out repeatedly, moments after a successful speed test. The network operations center reports healthy infrastructure. Latency is within target. There are no outages. Somewhere between those measurements and the failed request, the provider’s account of the service has stopped explaining the customer’s experience.

The customer still needs help.

For broadband operators, the last twenty meters between the gateway and a subscriber’s device are a useful way to frame that problem. Trouble here can turn a working connection into a support call. If it keeps happening, the provider has a retention problem to investigate, even when its network metrics look good.

In a 2025 survey of U.S. telecom customers, 69% cited reliable network connectivity as a top decision factor, narrowly edging out affordability.¹

The industry has spent decades building the infrastructure and monitoring systems broadband depends on. That investment was necessary. Operators need to know when capacity is constrained, or a node is failing. Cloud-managed Wi-Fi has since extended their view into the home, giving them access to device behavior, Wi-Fi conditions, and application performance that were once difficult to observe.

That visibility has already transformed day-to-day operations. Many of the issues that once generated support calls, from Wi-Fi channel selection and device steering to routine security threats, can now be identified and addressed automatically. For a large share of subscriber interactions, the network can increasingly optimize itself.

The remaining issues are different. They are less frequent, but significantly harder to diagnose because they don’t point to a single root cause. A Zoom meeting freezes even though the speed test passes. A Claude AI prompt times out despite healthy Wi-Fi. A household reports “slow internet,” but the underlying issue could involve the application, the device, RF conditions, or something outside the provider’s network altogether.

The challenge is becoming more urgent as AI evolves. Our recent research found that 86% of homes in Plume’s dataset now interact with a large language model at least once a quarter, and two-thirds do so regularly. But the next wave isn’t simply more AI conversations. It’s AI agents that perform increasingly complex tasks on behalf of users, creating longer-running workflows, more application interactions, and more opportunities for something to go wrong.

Together, these harder-to-diagnose issues create what we call the experience gap: the difference between observing that something went wrong and understanding why it happened well enough to act and improve it. The challenge is no longer collecting signals. It is determining which signals matter, connecting them into meaningful context, and doing so while there is still time to improve the subscriber’s experience.


Inside the Home

The average household in Plume’s dataset now has more than 22 connected devices. Increasingly, those devices are interacting not only with people, but with AI services acting on their behalf. On any given day, a laptop joins a video call while someone else streams a match in 4K. A PlayStation console competes with a cloud backup. A Nest camera uploads footage in the background. The mix changes as people move between rooms and devices, often without thinking about the connection.

This is where the experience gap becomes visible.

A subscriber trying to finish the yearly objective-setting session with their boss on Teams has little reason or ability to distinguish an access-network problem from a Wi-Fi or device problem. The meeting is being interrupted. A diagnosis that stops at a successful speed test leaves that interruption unexplained.

A speed test alone cannot reconstruct what happened during the call. That requires relating the relevant measurements to the device, the application, and the time of the interruption. Even then, the cause may lie outside the provider’s control. The useful outcome is a diagnosis that narrows the problem enough to guide the next step.

A stalled AI workflow introduces another kind of symptom to investigate. Unlike a single prompt-and-response interaction, an AI agent may complete dozens of coordinated actions across multiple cloud services before returning a result. If one step fails, the operator still has to determine whether the interruption originated in the home, the access network, the application, or somewhere else entirely.

Operators now have access to network, Wi-Fi, application, device, and customer data that would have been difficult to assemble a decade ago. A single interrupted call can leave evidence across several of those systems. The work is in connecting that evidence. Which signals explain the interruption? Has it happened before? Does it persist after the apparent fix? Those answers give a support agent something to work with when the customer calls.


Where the Information Stops Being Useful Across the Board

Customer care makes the cost of incomplete context visible. An agent may begin with little more than “unhappy customer on line 2.” The subscriber describes the symptoms, reboots equipment, and repeats a speed test. These steps can be useful. Their value is harder to defend when the provider has already collected information that could have narrowed the investigation.

The test for an operator is whether that information reaches the person handling the call in a usable form. Collecting device and Wi-Fi data somewhere in the business does not mean an agent can connect it to the interruption the customer is describing.

Operations teams face the same difficulty when a healthy access network leaves them with no clear next step. They need to follow the problem beyond the modem and identify which part of the connection warrants attention. A dashboard can show where a measurement crossed a threshold; someone still has to decide what that means for this subscriber.

Commercial decisions depend on that distinction, too. A household struggling with coverage and one that needs more capacity may both report slow internet. Treating those complaints as the same upgrade opportunity risks ISPs recommending a service that leaves the original problem unresolved.

For product teams, the question becomes whether a service changes the experience it was designed to improve. Leadership needs to know whether spending on that service reduces avoidable support work or helps retain subscribers. Answering either question requires connecting what happened in the home, what the provider did, and what happened afterward.

More telemetry alone cannot supply that answer. Nor can an analysis delivered after the customer has called again or canceled.


What Happens After an Alert

An alert can help an operator intervene earlier. It can also become another item in a queue. Its value depends on the response it makes possible.

If each alert requires someone to assemble the same evidence before deciding what to do, the provider has made the problem more visible while leaving much of the investigative work intact. As the subscriber base grows, that work grows with it unless the operating process changes.

A useful operating model would bring the relevant evidence together and help teams decide which problems need attention. Where a remedy can be applied safely, the provider should be able to act and check the result. Where the cause remains uncertain, the agent should inherit the investigation already completed rather than ask the subscriber to start again.

Preventing a support call is a demanding standard. The operator must identify a developing problem, choose an appropriate response, and confirm it helped. A prediction without a workable intervention adds another alert. An intervention without a check leaves the provider guessing about its effect.


A New Operating Model for Broadband

An operations leader should be able to ask why customer satisfaction dropped across a region and get help investigating. Today, that question may send people searching through dashboards, reports, and logs before they can even decide where to look.

Consider how that investigation could work. The system identifies the affected households and finds that most share a gateway model. Reboots increased during a heatwave, with failures concentrated on a particular firmware build. The operations team can examine the evidence and test a specific explanation. Engineering receives an investigation it can act on, including a proposed remedy to evaluate. What begins as an NPS question ends with a concrete engineering action.

Commercial teams need that depth of understanding when deciding which households should receive an upgrade offer. Video calls that deteriorate during working hours might suggest demand for a work-from-home service. But if weak Wi-Fi coverage is causing the interruptions, the offer needs to address coverage. More bandwidth alone would leave the customer paying more for the same problem.

An investigation could establish which households have a coverage issue and whether the proposed service would resolve it. Commercial teams could then make an offer with a clear rationale. Households needing a straightforward fix could be routed to care, with the evidence already attached. What begins as a support symptom ends with a targeted revenue opportunity.

These decisions require information to travel with the customer’s problem. A finding about a gateway fault should inform the next support conversation. An unresolved coverage issue should be visible to the team preparing an offer. After an intervention, the provider needs to know whether the interruptions stopped.

That kind of operating model changes when and how decisions get made. As AI evolves from answering questions to completing work, that shift becomes even more important. Operators won’t simply be supporting more connected devices. They’ll be supporting more autonomous activity across those devices.

Operators should be able to put that understanding to work across their business. Soon, they’ll have a new way to do it.

The same tension surfaces in nearly every campus networking conversation with customers: security teams need to move faster, but the network cannot afford to stop.

That tension isn’t new. What’s new is the speed of security threats. In a post-Mythos world, attackers are using AI-assisted tooling to find, adapt, and weaponize vulnerabilities faster than traditional infrastructure operating models were designed to handle. At the same time, campus networks carry more critical traffic than ever: clinicians and carts in hospitals, robots and sensors on factory floors, point-of-sale systems in stores, students and research on university campuses, and now, AI agents that can act continuously across applications and data.

The question is no longer only, “How do I remediate faster?” but also, “How do I reduce exposure immediately, preserve uptime, and still make permanent software updates in a controlled way?”

That’s the operating model this blog post is about. Live Protect and Extended Fast Software Upgrade (xFSU) are two different capabilities, but together they point to a future where campus infrastructure can defend, adapt, and update with minimal disruption.

Live Protect: Close the exposure window without rebooting the network

Live Protect changes the first part of the workflow.

It’s not a replacement for patching; a permanent software update is still the end state. Live Protect is a targeted runtime capability, validated by Cisco, that can help reduce exposure to a known vulnerability while the infrastructure continues to run.

Instead of forcing every vulnerability response into an emergency upgrade cycle, security and networking teams get a staged model:

  • Start with an advisory that identifies exposure and the fixed software path.
  • Use a validated vulnerability shield where platform, release, policy, and mode are supported.
  • Monitor the shield to understand whether matching events are occurring before enforcement.
  • Enforce the shield where supported and appropriate to block or mitigate the exploit path in real time.
  • Disable or retire the shield after the permanent software fix is applied.

The value isn’t just speed. It’s confidence.

At Cisco, we create and validate Live Protect shield through the appropriate Cisco Product Security Incident Response Team (PSIRT), engineering, and support workflows before we publish customer guidance. They are each targeted to a specific vulnerability condition, observable by operators, reversible when needed, and temporary by design. That’s very different from asking every enterprise to invent custom runtime rules during a crisis.

Live Protect is for supported Cisco products and releases. While it’s not a universal protection for every vulnerability, a generic third-party workload control, or a substitute for permanent remediation, that boundary is a feature, not a weakness. The trust comes from knowing exactly what’s supported, how it’s governed, and when the temporary control should be retired.

For campus and branch networks, this is a major shift. Infrastructure is now part of the attack surface. The switch, router, or controller is no longer just something you remediate after the fact. It becomes an active protection point in the infrastructure itself.

Live Protect helps reduce risk before permanent remediation. A software maintenance upgrade (SMU) can be the patch-style path when that is available and appropriate. xFSU solves a different operational problem: it changes the economics of full software image upgrades.

xFSU: Make software image upgrades easier to deploy

Extended Fast Software Upgrade solves a different operational problem: many access-layer switches don’t have a redundant forwarding path for every endpoint. A traditional reload can take users offline for several minutes. In environments like healthcare, manufacturing, transportation, retail, and higher education, that’s not just an inconvenience—it can become a business continuity issue.

xFSU reduces that disruption by separating the control plane and data plane during the software transition. The control plane can restart and move to the new software while the data plane keeps forwarding using the state already programmed in hardware. Then the data plane is updated in a much shorter disruption window and forwarding resumes using the preserved forwarding state.

Put simply: the network keeps doing its job for most of the upgrade process.

For Cisco Catalyst 9300 Series Switch deployments, this can reduce traffic impact from minutes to seconds where supported. On stacks, xFSU staggers the process across members and uses stateful switchover to preserve continuity. Operators still need to run eligibility checks, meet platform and software prerequisites, and account for feature caveats, but the direction is important: upgrades become more predictable and repeatable, and less dependent on heroic overnight change windows.

That changes behavior.

Traditional upgrades cause three to five minutes or more of downtime. When image upgrades are painful, they get deferred. When they are low impact and validated up front, teams can move toward a more regular software lifecycle. That’s the real security outcome. xFSU isn’t just an availability feature; it’s a security enabler because it helps close the gap between “fixed image is available” and “fixed image is deployed” when an image upgrade is the right remediation path—reducing traffic downtime to less than five seconds on Catalyst 9300 switches running IOS XXE 17.15.2 or later.

Synchronizing security and operations

Live Protect and xFSU should not be viewed as competing solutions. They are two parts of the same operating model. By pairing these capabilities, organizations can move beyond the binary choice between urgent remediation and uptime.

When a vulnerability is disclosed, this pairing allows for a staged, collaborative response. Security operations (SecOps) teams gain a faster path to exposure reduction through Live Protect, while network operations (NetOps) teams maintain the stability of the production environment. Once the immediate exposure is shielded, teams can transition to permanent remediation—whether via SMU or full image upgrade—using xFSU to help make the process is repeatable and predictable.

This model replaces the high-pressure maintenance window with a calculated, transparent workflow. Security teams spend less time pushing for emergency changes that risk business continuity. Network teams gain the operational headroom to execute updates as part of a standard lifecycle. The business gets resilience without pretending uptime and security are separate goals.

Architecting for a connected campus

It’s tempting to borrow operating models from the data center and assume they apply everywhere, but the campus has a different set of operational constraints.

It’s where the physical world connects: users, cameras, badges, building systems, access points, medical devices, industrial endpoints, and AI-enabled workflows. Many of those endpoints are not easy to patch. Many are operationally sensitive, mobile, unmanaged, or single-homed. Increasingly, their traffic is encrypted, machine-generated, and lateral.

That makes the access layer both a security challenge and a security opportunity.

The challenge is that downtime is visible immediately. The opportunity is that the network is already present at the point of connection. If security can be fused into that network layer, then protection doesn’t have to wait for a centralized inspection point or a bolt-on appliance path. It can happen where the user, device, application, or agent enters the environment.

This evolution is the cornerstone of a secure network architecture: moving beyond perimeter-based defense to build trust directly into the platforms that forward data. A network that can protect itself at runtime and update with less disruption serves as a stronger foundation for segmentation, Encrypted Traffic Analytics, zero-trust access, and closed-loop operations.

Achieving continuous network resilience

The era of AI-driven threats demands a move away from static infrastructure management. Attackers are accelerating their tooling, and your networks carry increasingly critical data. To keep up with this pace, the answer cannot be a network that only evolves during rare, high-stakes windows.

Instead, aim for a model that can absorb change safely.

For network teams, this requires several practical shifts in how you manage campus environments:

  • Lifecycle management: Treat every vulnerability response as an ongoing cycle rather than a single, isolated event.
  • Visibility-driven planning: Make software upgrade eligibility a constant metric, so your teams know which segments are ready for updates before the maintenance window opens.
  • Agility prioritization: Focus investments on platforms and topologies that inherently support lower-disruption updates, making long-term agility a standard requirement.
  • Operational alignment: Align NetOps and SecOps around shared evidence and unified metrics to reduce the friction between exposure reduction and infrastructure stability.
  • Small-batch change adoption: Shift the organizational culture toward smaller, frequent, and safer updates, which can lower the overall risk profile compared with rare, large-scale events.

The ultimate goal is infrastructure that defends and evolves while it’s running. By using runtime protections like Live Protect and streamlining the path to full upgrades with xFSU, you can turn campus security from a maintenance-window problem into a pillar of business continuity. This is the promise of secure networking: controls that operate in the right place, at the right speed, without trading uptime for protection.

Explore how Extended Fast Software Upgrade (xFSU) enables campus switch upgrades and reloads with minimal disruption

Perfectly good projects are going off the rails and missing their ship dates, because of worldwide chip shortages, as the world’s FABs focus on pumping out AI chips.

As of mid-2026, 32-bit industrial MCUs and power management ICs are running lead times as long as 52 weeks, driven by AI infrastructure eating into the mature foundry capacity that IoT parts depend on. Automotive-grade MCUs are still sitting at 26 to 40 week lead times through Q2 2026. That’s down from the 52+ week peaks of the prior shortage cycle, but still long enough to force a mid-program part change on most connected products.

That number is the actual argument for a Firmware Abstraction Layer (FAL). Not portability as a design virtue. A parts shortage that arrives mid-program and forces a chip swap on a schedule you don’t control.

When that swap happens, the cost depends entirely on how the firmware was written. If power management calls, event loop timers, and socket buffers are wired straight into the original vendor’s SDK, a driver swap turns into a rewrite. That’s especially true when application code up the stack had no business knowing which chip was underneath it. If none of that is wired in, it’s just a new driver behind an interface that hasn’t changed.

The Industry is Moving, But Not Fast Enough To Save You

Silicon vendors know this pain point exists, and 2026 has brought real movement. Silicon Labs launched Simplicity SDK for Zephyr at CES 2026, a QA-tested Zephyr distribution built for its wireless chips. The SDK is MCU-agnostic and lets developers mix MCU vendors inside one project, which is a genuine step toward portability rather than a new flavor of lock-in.

Nordic moved in a similar direction with the nRF93M1, announced at MWC 2026, which ships with built-in coexistence control for Wi-Fi and cellular radios sharing one module.

Both of these solve coexistence within a single vendor’s silicon. Coexistence across vendors is a different problem, and it’s still an open problem at the RTOS layer. Zephyr’s Bluetooth stack currently binds to a single controller, so a product can’t natively run Bluetooth radios from two different vendors at once. A proposal to fix that has been open since July 2025, still not shipped.

So vendors are getting better at owning coexistence on their own chips. Managing radios across vendors is still on the OEM to solve, and that’s exactly what a FAL is for.

Step 1. Identify Every Radio and Every Place They Can Collide

List every radio in the product, whether that’s BLE, Wi-Fi, cellular, or UWB. For each one, write down the vendor, the SDK version, and the frequency band it operates in.

Then map where they can interfere with each other. A Wi-Fi transmission can wipe out an incoming BLE advertising packet on the same band. A cellular modem waking up for a paging window can starve a UWB ranging session of power budget. These collisions come from physics, not software architecture, and a single vendor’s SDK has no idea another radio even exists on the board.

This inventory is the spec for everything that follows. Skip it and you’ll end up designing an abstraction layer for radios that don’t actually fight each other, while missing the pair that does.

Step 2. Design the Power State Machine Before Writing Driver Code

Vendor SDKs manage power per radio. BLE connection intervals, cellular eDRX timers, and Wi-Fi power-save modes each get handled separately, by their own SDK, with no visibility into what the other radios are doing at the same moment.

Replace that with one system-level state machine that every radio driver reports into. Two states cover most products, System_Sleep() and System_Active(). Before switching states, the FAL checks every active radio and picks the lowest power level that all of them can safely handle.

Work out the timing rules on paper first. Decide which radio’s constraints are allowed to hold up a sleep transition and which aren’t. If you get this wrong, you’ll spend the second half of the project chasing power bugs that only show up once two radios are active together.

Step 3. Build One Error Taxonomy Across Every Vendor Stack

A cellular modem times out silently over several seconds. A BLE driver drops the connection instantly with a stack-specific status code that means nothing outside that SDK. If you leave this alone, the application layer will fill up with chip-specific if/else branches for every vendor you’ve ever integrated.

Translate every vendor error into a small set of system-level states instead, things like LINK_TEMPORARY_LOSS or HARDWARE_UNRESPONSIVE. The application layer reacts to these states and never has to know what a specific vendor’s error code means.

This step tends to have the biggest payoff for the smallest amount of code, which is also why teams skip it first under deadline pressure. It doesn’t block a demo. It blocks the fifth product revision, when nobody on the team remembers which vendor’s error code meant what.

Step 4. Put One Component in Charge of Arbitration

Antenna sharing, board-level power rails, shared bus access. When two radios need the same physical resource at the same moment, something has to decide who goes first, and that decision can’t be left to whichever driver happened to initialize last.

Build a single arbitration component that owns every shared resource on the board, and routes every radio driver’s requests through it. Don’t let a driver talk to a shared antenna switch or a shared power rail directly, even when the vendor SDK makes that shortcut tempting.

Most of your real RF debugging time during bring-up ends up here anyway. A clean arbitration boundary keeps those bugs in one file instead of scattered across three different vendor codebases.

Step 5. Wall Off OTA Updates and Certification Scope

Radio firmware updates need their own execution pipe, separate from application code. A failed radio firmware update shouldn’t be able to take down the rest of the product. And when only a wireless component changes, keeping the update isolated means regulatory recertification stays scoped to the radio abstraction module instead of pulling your whole application layer back into scope.

The cost difference here is real. A pre-certified wireless module cuts FCC certification cost by 60 to 80 percent and roughly halves the timeline compared with a custom RF design. Keep the split clean and a wireless-only change stays a wireless-only filing. Mix it with application code, and the whole product can get pulled back into certification scope.

If your OTA pipeline currently pushes application code and radio firmware through the same mechanism, split them now, while it’s a small job, rather than during a hardware revision, when it isn’t a small job anymore.

Where This is Playing Out Right Now

There’s a live example of this on the Zephyr project. A team building on an NXP 88W8987 Wi-Fi combo module wants to add Bluetooth, and the open issue confirms there’s no upstream Bluetooth HCI driver for that chip, even though the Wi-Fi side already works.

The thread lays out three options. Add a second Bluetooth chip from a different vendor. Work from an unofficial vendor driver outside the mainline Zephyr tree. Or redesign the hardware around a different combo chip entirely, which the thread notes isn’t always possible once BOM, supply chain, and certification decisions are already locked in.

Every one of those options costs something, and the reason the team is stuck choosing between them is that nobody drew the FAL boundary early enough. A team that already has a power state machine, an error taxonomy, and an arbitration layer in place can absorb a second radio vendor as a driver-level change. A team without one ends up making this decision in a GitHub comment thread, mid-project, instead of in a design review months earlier. Our previous post goes more into this – Architecting Multi-Radio Embedded Devices with BLE, Wi-Fi, LTE, and UWB.

Decide Ownership Subsystem by Subsystem

You don’t need to own every layer for every product. What matters is deciding, for each of the four systems above, whether you build it yourself or lean on the vendor SDK.

If you’re shipping on a single vendor’s chip for a short product life, with no planned cost-down or radio swap, take the vendor’s SDK as it comes, coexistence tools included. The speed advantage is real, and there’s no multi-vendor problem to solve.

If you’re running radios from more than one silicon supplier, this applies to you. It also applies if you’re building a product line meant to last three to seven years through component shortages and cost-downs. Build the power state machine, error taxonomy, arbitration layer, and OTA isolation yourself. Leave everything else on the vendor SDK.

Most teams don’t need to build a FAL from scratch. They need these boundaries drawn correctly before the second radio vendor shows up as a surprise instead of a plan.

Final Word

Multi-radio products get harder to maintain when the boundaries between vendor firmware and system firmware are unclear. Defining those boundaries early gives your team more options when hardware, suppliers, or product requirements change.

embedUR brings 20 years of experience building wireless stacks, controller firmware, and cross-vendor abstractions for connected products. If you’re planning a multi-radio product or preparing for a hardware refresh, our engineering team can help you define the right firmware boundaries.

Schedule a Firmware Architecture Review with our experts and protect your product roadmap against silicon delays, unexpected chip swaps, and costly recertification cycles.

AUSTIN, Texas, Oct. 7, 2026 /PRNewswire/ — Works With Summit 2026 – Silicon Labs (NASDAQ: SLAB), the leading innovator in low-power wireless connectivity, today announced a set of developer initiatives that makes it easier to build, extend, and operate increasingly capable IoT devices. Unveiled at the company’s seventh annual Works With Summit, the new offerings expand what developers and their AI agents can create on the Silicon Labs platform, while helping customers develop, deploy, and manage intelligence at the edge.

News at a Glance

  • Design with AI: The Simplicity AI SDK is now in public Beta and supports AI coding assistants including GitHub Copilot, Cursor, and Codex. Silicon Labs is also introducing Simplicity Design Intelligence, a broad and growing set of capabilities designed to understand hardware and software intent, help customers turn that intent into a working product, and verify the implementation against the original intent. Hardware Intent is the first capability.
  • Build and extend: The Silicon Labs open-source community is launching in Beta with Bluetooth® Low Energy (LE), giving developers access to sample applications and tooling and a direct way to raise issues, propose fixes, contribute code, and extend the Silicon Labs software platform.
  • Scale edge intelligence: Silicon Labs’ platform-agnostic edge AI and machine learning tools can now connect with Databricks, the data and AI company, so customers can manage data, models, embedded optimization, and hardware test results with governed enterprise data and AI workflows on the Databricks Data + AI platform.

Development Complexity Cannot Scale with IoT

As connected products add intelligence and custom hardware, building them grows more complex. Developers navigate specialized SDKs, configuration tools, debugging environments, and hardware constraints while using general-purpose AI assistants that do not inherently understand Silicon Labs devices or embedded workflows. Development teams also need better ways to share improvements and manage AI models as intelligence moves from the cloud onto edge devices. If workflows become harder with every new capability, development complexity becomes a barrier to scaling IoT.

“More capable silicon should not create more development complexity,” said Manish Kothari, Senior Vice President of Software at Silicon Labs. “We are giving developers and their AI agents a connected path from hardware and software intent through implementation, community contribution, and the complete AI lifecycle.”

Simplicity AI SDK and Simplicity Design Intelligence Connect Intent to Product

Simplicity AI SDK has entered public Beta, giving developers and their AI coding assistants structured access to Silicon Labs SDKs, tools, documentation, and connected hardware. Rather than requiring a proprietary AI assistant, the SDK works with tools developers may already use. GitHub Copilot, Cursor, and Codex are supported in the Beta. This grounding gives general-purpose AI assistants Silicon Labs-specific context. The first officially supported experience focuses on Bluetooth® Low Energy (LE), with workflows spanning project creation and configuration, building, flashing, debugging, network and power analysis, documentation search, and hardware interaction.

Simplicity Design Intelligence extends that foundation. It is a broad and growing set of Silicon Labs capabilities designed to understand hardware and software intent, help customers realize that intent in a working product, and verify the implementation against the original intent. Hardware Intent is the first capability. It uses product requirements, board schematics, and other input hardware documentation from datasheets to meeting notes to guide pin, peripheral, and software configuration, then compares the result with the original intent. This can find pin conflicts, peripheral mismatches, and missing constraints before fabrication and help reduce avoidable board respins.

“We’ve been working closely with Silicon Labs as an Alpha customer, evaluating how the Hardware Intent Agent can streamline hardware development across our current and future products while providing feedback on new features as it progresses towards general release,” said Limor Alkelai, Co-CEO, at Risco Group. “We see its potential in enabling quicker and more robust development.”

Collaborate, Build, and Extend Through the Open-Source Community

Drawing on its experience advancing open-source development for Matter, Thread, and Zephyr, Silicon Labs is launching its open-source developer community in Beta, beginning with Bluetooth LE. The mantra is simple: build and extend. Developers can build with Silicon Labs sample applications and tooling, then extend the platform by raising issues, suggesting fixes, and contributing through pull requests.

Accepted contributions can move through the company’s normal engineering and testing processes into future SDK releases. Even before acceptance, proposed fixes and discussions can remain visible to other developers, giving the community another way to share knowledge and solve common problems. The Silicon Labs applications team will support issues raised on GitHub, and Silicon Labs plans to expand this approach to additional wireless technologies over time.

Scale the Complete Edge AI Lifecycle with Databricks

As edge AI grows, model development also needs to connect with the data and AI infrastructure enterprises already use. Silicon Labs is partnering with Databricks to bring embedded edge AI into Databricks, creating a unified, governed foundation for connecting edge devices with enterprise data, AI, and machine learning workflows.

An initial Silicon Labs MLOps SDK experience connects devices with Databricks to help capture data from the device fleet. Once the data is in Databricks, all the familiar MLOps tools and training pipelines and GPU resources are available directly for training. Once a model is trained, the Silicon Labs ML Profiler can provide directionally accurate feedback on whether a model fits target hardware and its memory and CPU requirements. That feedback can help ML engineers iterate while remaining in a familiar Databricks environment, connecting model development with the enterprise data and governance that underpin production AI. This approach helps enterprises extend AI from the cloud to the edge without creating separate data and AI stacks for embedded workloads.

A Platform that Developers Can Build and Extend

Together, these initiatives scale the development system at three levels:

  • The Simplicity AI SDK and Simplicity Design Intelligence help developers and their AI agents move from hardware and software intent to a working product, with Hardware Intent as the first of a growing set of Design Intelligence capabilities.
  • The open-source community gives developers a direct way to build and extend the platform.
  • Silicon Labs edge AI tools and Databricks connect embedded AI development with enterprise data and AI governance. Silicon Labs intends to make increasingly capable silicon easier to use and earn the position of platform of choice for embedded wireless development.

Availability and Next Steps

The Simplicity AI SDK Beta is publicly available, with official support initially focused on Bluetooth LE and support for GitHub Copilot and Codex. An alpha release of Hardware Intent, the first capability in Simplicity Design Intelligence, is planned for January 2027.

The Silicon Labs open-source community Beta launches with Bluetooth LE, and its sample applications are accessible on GitHub for code review and contributions.

Initial Silicon Labs MLOps tools are available in Databricks today.

About Silicon Labs

Silicon Labs (NASDAQ: SLAB) is the leading innovator in low-power connectivity, building embedded technology that connects devices and improves lives. Merging cutting-edge technology into the world’s most highly integrated SoCs, Silicon Labs provides device makers with the solutions, support, and ecosystems needed to create advanced edge connectivity applications. Headquartered in Austin, Texas, Silicon Labs has operations in over sixteen countries and is the trusted partner for innovative solutions in smart home, industrial IoT, and smart cities markets. Learn more at https://www.silabs.com.

SOURCE Silicon Labs

New distribution partnership brings Zyxel’s Point-to-Multipoint and Point-to-Point outdoor wireless solutions to WISPs and broadband providers

Anaheim, California, Sept. 29, 2026 – Zyxel Communications today announced a new distribution partnership with Streakwave Wireless, expanding access to Zyxel’s outdoor wireless solutions for wireless internet service providers (WISPs), broadband providers, MSPs and VARs.

Through the partnership, Streakwave will distribute Zyxel’s growing portfolio of Point-to-Multipoint (PtMP) and Point-to-Point (PtP) wireless solutions, providing customers with new options for extending high-speed connectivity to hard-to-reach locations, building wireless backhaul links and expanding broadband coverage without the cost and complexity of new fiber builds.

The partnership combines Zyxel’s broadband and networking expertise with Streakwave’s experience in wireless broadband distribution, giving customers greater access to outdoor wireless solutions and specialized distribution support for deploying and expanding their networks.

“Outdoor wireless gives service providers greater flexibility to extend high-speed connectivity where traditional wired infrastructure may be difficult or costly to deploy,” said Shawn Rogers, Sales Operations & Product Development Manager at Zyxel Communications. “Our partnership with Streakwave makes it easier for customers to access Zyxel’s PtMP and PtP solutions through a distributor with deep experience in the wireless broadband market.”

WiFi 7 PtMP Built for Modern WISPs

At the center of Zyxel’s outdoor wireless portfolio is its FWA7 WiFi7 PtMP platform, designed to deliver multi-gigabit connectivity for last-mile broadband deployments. The solution combines WiFi 7 Multi-Link Operation (MLO), adaptive antenna technology, intelligent resource management, and cloud-based management to help WISPs maintain reliable connectivity in demanding outdoor environments.

The FWA7 PtMP family includes:

  • FWA7 Root Plus: Premium 4×4 outdoor WiFi 7 PtMP base station with integrated smart antenna designed for high-capacity coverage and performance-demanding service areas.
  • FWA7 Root: Flexible 2×2 outdoor WiFi 7 PtMP base station with support for compatible third-party external antennas, providing greater flexibility for different coverage and deployment requirements.
  • FWA7 Leaf Plus: High-performance subscriber CPE that connects to the PtMP base station for reliable multi-gigabit last-mile access.

Root Plus supports long-range coverage of up to 6 miles (10 km) and up to 7.4 Gbps theoretical total Tx/Rx throughput, while Leaf Plus provides subscriber CPE speeds of up to 4.4 Gbps theoretical throughput. The platform uses WiFi 7 MLO across 5 GHz and 6 GHz, along with smart antenna technology designed to optimize near-and far-field coverage.

Zyxel’s outdoor wireless solutions integrate with the Nebula cloud management platform, enabling zero-touch deployment, remote monitoring, and centralized management. This helps WISPs deploy and manage distributed networks more efficiently while reducing onsite management and truck rolls.

Point-to-Point Connectivity for Long-Distance Links

For dedicated Point-to-Point connectivity, Zyxel’s NWA55AX PTP outdoor wireless bridge provides WiFi 6 AX2400 performance with speeds up to 2.4 Gbps and links of up to 6 miles (10 km). Factory-paired as a two-piece kit and ready to deploy, the NWA55AX PTP provides a simple way to connect campuses, warehouses, farms, remote buildings, and other locations without the need for new cabling.

“Zyxel’s outdoor wireless solutions are a strong addition to our portfolio as our customers look for reliable and flexible ways to expand their networks,” said Charles Listwan, Sr. Product Manager at Streakwave. “The addition of Zyxel’s PtMP and PtP solutions gives our customers more options for addressing last-mile connectivity, network expansion, and other outdoor wireless applications.”

Extending Connectivity Beyond the Reach of Fiber

Together, Zyxel’s PtMP and PtP solutions provide flexible options for a range of outdoor connectivity requirements. PtMP enables WISPs and broadband providers to serve multiple subscriber locations from a central base station, while PtP provides dedicated wireless links for applications such as network backhaul and building-to-building connectivity.

Designed for outdoor deployments, Zyxel’s PtMP and PtP solutions combine weather-resistant construction with cloud-based management to support reliable connectivity in challenging environments.

The partnership with Streakwave expands availability of these solutions through a distributor focused on the wireless broadband market. Beyond outdoor wireless, Zyxel’s comprehensive portfolio spans PON/XGS-PON, WiFi 6 and WiFi 7, 5G FWA, switching, security, wireless access and cloud-managed networking, helping service providers and businesses build and expand their networks.

About Zyxel:

Zyxel has been connecting people and businesses to the internet for more than 35 years, delivering networking solutions designed to make connectivity more reliable, secure, and easier to manage. Its portfolio spans security, switching, WiFi, broadband access, and outdoor wireless solutions, including point-to-point (PtP) and point-to-multipoint (PtMP) technologies for WISPs, service providers, MSPs, businesses, and other professional network environments.

With a global presence and decades of networking experience, Zyxel continues to develop practical, scalable solutions that help customers extend connectivity, build and manage networks, and support evolving deployment needs across indoor and outdoor environments.

About Streakwave:

Streakwave Wireless, Inc. is a global distributor of wireless, networking, telecommunications, security, and connectivity solutions, providing all the tech businesses use to connect. Since 2001, Streakwave has served WISPs, service providers, MSPs, VARs, system integrators, enterprises, and other technology professionals with products from leading manufacturers and the services needed to simplify purchasing, fulfillment, and deployment.

With distribution and fulfillment capabilities across the United States and decades of experience in wireless and networking, Streakwave combines broad product availability, knowledgeable support, and flexible business services to help customers build, expand, and manage their networks.

For more information about products and services, visit www.streakwave.com

What Middle East hoteliers need to know about in-room entertainment, connectivity, and guest engagement

The guest room is becoming a digital environment. Guests bring their own devices, content, and expectations with them. They expect hotel technology to work together without creating extra steps or frustration.

For Middle East hotels, the challenge is even more nuanced. A diverse guest mix, multilingual needs, local considerations, and rising expectations around digital experiences all shape what a connected guest room needs to deliver.

This white paper explores how hoteliers can move beyond the traditional hotel TV to create a more connected, flexible, and guest-focused experience.

Inside This White Paper:

  • Why the traditional hotel TV is no longer enough and what today’s guests expect from in-room entertainment.
  • How connectivity, entertainment, and guest services can work together instead of creating disconnected experiences.
  • What localisation really means for Middle East hotels, from multilingual experiences to the needs of diverse guest populations.
  • How guests’ own devices and content can become part of the room experience, alongside the hotel’s managed entertainment offering.
  • What hoteliers should consider before investing in connected-room technology, whether they are building new or modernising an existing property.

The connected guest room is not about adding technology for its own sake. Rather, it’s about creating an experience that works naturally for the guest and supports the way people actually travel today.

Explore this white paper to see what a more connected guest room could mean for your property.

ACCESS FULL DOCUMENT HERE

Steel mill floor covered by 7SIGNAL monitoring

Inside a North American steel mill, time is measured in molten metal. The company’s hot mill converts raw slabs into finished coils at the pace of about 35 coils per hour, approximately 20 tons per coil, selling at roughly $1,000 per ton, depending on market prices. When production stops, the losses are immediate.

“The impact to the hot mill being down is about $4,500 per minute of lost margin,” says a wireless engineer for the mill. “We produce about 35 coils per hour and roughly 20 tons per coil. Those prices fluctuate with the going price of the market and cold roll and hot roll prices. That’s a justification we can use for Wi-Fi sensors.”

Those tools include 7SIGNAL Sensors: a wireless-experience management platform that the mill’s wireless manager and his team deploy. In a business where a six-hour window separates recovery from an extended outage, wireless reliability is a production asset.

Wi-Fi performance monitoring platforms for manufacturing and logistics facilities collect and analyze wireless reliability for scanners, robots, and connected equipment. All this gear underpins operations and production. A dropped connection can stop an automated crane.

Steel mill snapshot

  • Global steel manufacturer with operations spanning dozens of countries
  • Facility dates to the early 20th century; integrates legacy infrastructure and automated systems
  • IT organization covering desktop, security, OT/ICS, and wireless across a “mini-city” that includes warehouses and steelmaking operations
  • Managing a multi-vendor environment: Cisco, Cisco Meraki, Siemens, ProSoft, and VMware/Broadcom

Challenge: Knowing what’s happening on the network

Steelmaking is, in part, a logistics challenge. Inside the mill’s facilities, cranes receive wireless instructions about which coil to pick up, where to move it, and when. A scheduling system tracks thousands of coils in a single building. If wireless connectivity falters, even briefly, manufacturing stops. If a stoppage is prolonged, lost production follows.

The challenge was knowing what was happening on the network in real time and over time, independent of the vendors whose hardware was generating that data.

7SIGNAL provides an independent view. It is a vendor-agnostic Wi-Fi monitoring platform, working alongside wireless infrastructure to deliver an endpoint perspective that infrastructure dashboards can’t capture. Getting all the devices performing well meant understanding what was happening at the edge of the network.

Solution: Getting a client-side view of Wi-Fi

The mill deployed 7SIGNAL Sensors throughout its facilities, placing independent monitors in the wireless environment that collect data from the device’s perspective, not the access point.

The 7SIGNAL monitors are patented sensors, RF hardware appliances deployed on-site as a monitoring layer, with a single sensor capable of monitoring up to six access points continuously.

Simultaneously proactive and reactive

“If you set up the 7SIGNAL tool to do events and alarms, then you’re commissioning that tool to give information to show data and be almost proactive,” the wireless manager says. “Those reports offer trends to help predict where problems are. We can set thresholds.”

The sensor data enables the mill’s wireless manager to catch access points that appear functional in Cisco Prime Infrastructure but are dropping clients. This is a critical distinction in an environment where a dropped connection can stop a crane.

Eliminating finger-pointing

Wireless problems can trigger a cycle of blame between teams. Workers question the network. An IT team looks to the endpoint, or application. Without objective data, each group points elsewhere and resolution drags out.

“With 7SIGNAL, there is far less finger-pointing,” the wireless manager notes. “7SIGNAL tells you what’s wrong.”

Armed with evidence, the mill’s IT team can direct the right people to the right fix without debates. Minutes matter when downtime can add up to an hours-long lapse in production.

Validating coverage

“I use 7SIGNAL for base level testing and to define coverage without having to do reactive troubleshooting,” the wireless manager says. “Before buying 7SIGNAL, I’d tell a technician to go out with a spectrum analyzer, laptops, and wait in the mill for a problem to happen. It’s a proactive approach now.”

“7SIGNAL pays for itself 10 times over when we avoid a typical downtime event,” says the mill’s wireless manager.