Skip to content

Test equipment repaired and verified on real traffic

Repair of traffic generators and network test systems, and verification of used units. A test port that stopped linking, a chassis that no longer boots, a used generator you are about to buy. We find the fault and write it up, fix it once you approve, and run the unit on real traffic before it goes back.

Send the model and the symptoms What we take
  1. 01RequestOn request
  2. 02DiagnosticsAgreed per case
  3. 03RepairOn your approval
  4. 04Verification runBefore return

Why a test lab

Three things a repair shop without traffic generators cannot give you

A power-on self-test says the board is alive. It says nothing about a port that links up and drops frames at 70% of line rate, or a fan tray that holds for 10 minutes and then trips. Test hardware is fixed when it passes traffic long enough to get hot. The lab has the generators to prove that.

  1. The repaired unit runs on real traffic

    After the repair the unit goes on the bench with the traffic generators and runs under load. A chassis gets its modules loaded, a load module gets every port at line rate, an analyzer port gets its counters and timestamps checked against a reference port. Holding the load is the finish line.

  2. Diagnostics report before any repair

    You get a written report first: what failed, why, what the fix involves and whether it makes sense for this unit. The decision to go ahead, or to stop at the diagnostics, is yours.

  3. Verification run after the repair

    The report closes with the run after the fix: the same test on the same ports as before, so you can compare the two. Photos and logs travel with the unit.

From intake to return, two gates on the way
Intake model, symptoms Diagnostics report repair / do not repair Repair on your approval Verification run real traffic, the bench Return report, photos, logs YOUR DECISION PROOF

Chassis, load modules, power and fans

What we take and what comes back with it

Traffic generators, analyzers and their chassis, repaired or checked before you rely on them. For each line: what we check, what the fix usually involves and what you receive.

EquipmentWhat we checkWhat we fixWhat you get back
01Test chassis Power rails, backplane, controller and management boards, fan trays, firmware and licence state Power supplies, fans, controller boards, firmware recovery Report, a run with modules loaded in the chassis, photos
02Load modules Every port at line rate, optics cages, memory, temperature under load Port circuitry, optics cages, memory, board-level faults where rework holds Port-by-port run, loss and latency before and after, photos
03Power supplies and fans Output under load, ripple, fan speed, alarms Capacitors, fans, connectors, or a matching replacement unit where repair makes no sense Load test log, thermal soak result
04Used or repaired systems, verification only Inventory against the listing, boot, firmware and licence state, every port at line rate, counters and timestamps against a reference port Nothing by default: faults go into the report with a repair estimate, the fix on your approval Verification report port by port, licence and firmware state, a view on whether the unit is fit for use

Test hardware not on the list: send the model anyway, the intake reply says whether we take it. We do not take RF and radio test equipment.

How it goes

Four steps, nothing touched before you approve the report

  1. 1

    Request

    On request

    Model, serial number, firmware, what the unit did before and what it does now. Alarms, logs and photos if you have them.

    Intake reply: yes or no, and what the diagnostics covers

  2. 2

    Diagnostics

    Agreed per case

    The unit goes on the bench: power rails, ports, fans, memory, firmware and licence state. We find the fault and write what it would take to fix it.

    Diagnostics report with a repair or do-not-repair verdict

  3. 3

    Repair

    On your approval

    Nothing is touched before you approve the report. Then the failed part is replaced or reworked and the firmware restored where needed.

    Repaired unit and a work log

  4. 4

    Verification run

    Before return

    The unit runs on real traffic in the lab: every port at line rate, a thermal soak, the same test before and after. Results go into the report.

    Run results, photos, logs, the unit back to you

Illustrative

Typical scenario

A load module with one dead port and no vendor contract

An operator lab has a load module whose port 3 stopped linking after a power event. The vendor dropped the card two firmware generations ago and a new one is a budget line the lab does not have this year. The module comes to the bench. The diagnostics finds the port circuit damaged, the other ports healthy, the firmware intact. The report says the fix makes sense. After the rework the module runs every port at line rate for a multi-hour soak, port 3 with the same loss and latency as its neighbours. It goes back with the run results and the photos.

Illustrative scenario, no figures from a real repair. Every unit gets its own report.

Found
Port 3 circuit damaged by a power event, remaining ports healthy, firmware intact
Decided
Repair: one circuit, the board otherwise sound. Approved on the report before any work.
Verified
Every port at line rate through a multi-hour soak, port 3 in line with the others on loss and latency

Questions before the request

What owners ask first

What if the unit cannot be repaired?

You get the diagnostics report with the reason: a part that no longer exists, a board damaged beyond rework, a fix that costs more than the unit is worth. The report is yours either way, and the unit goes back to you.

How long does it take?

Agreed per case, after the unit is on the bench. Diagnostics has one date, the repair another, and the part supply decides the second. The report names both.

Where do spare parts come from?

From the same class of hardware where possible: a donor board, a matching power supply, a fan tray of the same type. The report says which part is needed and whether it is on hand or has to be sourced. Sourcing time is part of the agreed timeline.

Is there a warranty on the repair?

The terms are agreed per repair and written into the offer before the work starts. One thing is always included: the verification run results, so you can see what the unit did on the bench before it left.

What do you need from us to start?

The model and serial number, the firmware version, what the unit was doing when it failed, and any alarms or logs. Photos of the front panel and the fault indicator help. The intake reply confirms the address and how to pack the unit.

Is the verification report a calibration certificate?

No. It records what the unit did on the bench, port by port, against a reference, with the method and the date. If your organisation needs an accredited calibration certificate, say so at intake: the reply tells you whether the report covers your case.

Send the model and the symptoms. The intake reply says whether we take it and what the diagnostics covers.

The report comes first. The repair starts only after you approve it.

Send the model and the symptoms All services

Send the shortlist

Describe the unit and the fault

Model, port count and the fault, or the listing of a used unit you plan to buy. An engineer replies within one business day.

Prefer to chat? Message an engineer on WhatsApp

We use what you send only to answer you. See our Privacy Policy.