FADOS Test Reports and GSAS Agent: Turning Board Test Results into an Auditable Record

A technician finds the fault. The board is repaired. Two months later a customer asks what was actually wrong with it, or a quality auditor asks how the incoming batch was screened, and the only answer available is a person’s memory. That is the gap this post is about. Fault detection and fault evidence are two different problems, and the FADOS circuit board testers from CBT Electronic solve the second one with a report file and a small piece of software called GSAS Agent.

If you are new to the underlying technique, start with VI curve tracing explained and come back here. This guide assumes you already know what a V-I comparison is and focuses on what happens after the comparison finishes.

Why a screen result is not a record

V-I signature comparison is a visual method. The FADOS software puts the reference curve and the measured curve on the same axes, and the operator or the software decides whether the difference is inside tolerance. That works perfectly at the bench and not at all six weeks later, because three things vanish the moment the operator moves to the next board:

• Which board it was. Serial numbers get written on a whiteboard, or not written at all.
• What the test settings were. A capacitor that looks healthy at one test voltage and frequency can look different at another. A verdict without its settings is not reproducible.
• What “pass” meant. The tolerance band is an operator-set number. Two benches running different tolerances on the same board produce different verdicts, and neither verdict is wrong unless you can see the setting.

An auditable record has to carry all three. The FADOS report does.

What is in a FADOS test report

The report the FADOS software produces is structured as a header and a per-point table.

The header identifies the unit under test and the outcome: the board serial number, the board name, the date and time of the test, and then three counts, the total number of test points, how many were OK, and how many were out of tolerance, with the split also expressed as percentages. The report carries an overall PASS or FAIL banner derived from those counts. The example report printed in the FADOS booklet (PDF) shows a failing board with 100 test points, 26 in tolerance and 70 out of tolerance, The booklet does not say what was wrong with that board, and the report does not need to: its job is to record the measurement, not to name the fault.

The body of the report is one row per test point, and each row carries the settings alongside the verdict: the point number, the test voltage, the frequency, the current, the tolerance that was set for that point, the measured fault rate, and the test result for that point. That is the part that makes the record reproducible. Anyone reading the report a year later can see not only that point 47 failed, but at what voltage, at what frequency, and against what tolerance it failed.

Reports come out of the FADOS software as Excel files, which is why the summarisation step described below is a file-watching job rather than a hardware feature.

Which FADOS models produce reports

Report saving and analytics is not present across the whole family. Per the current CBT Electronic specification table for the four models:

The distinction is worth reading carefully, because the memory function and the report function are not the same thing. Every FADOS model can record a golden board signature and compare a suspect board against it, so every model can find the fault. Saving that outcome as a structured report you can file, send and audit is a capability of FADOS9F1, FADOS XI and FADOS MUX. If traceability is a requirement rather than a nice-to-have, that constraint should drive the model choice before anything else does.

Where the report comes from in a MUX workflow

On a manual bench the operator triggers a report after probing. On a FADOS MUX station the report is the natural output of the test cycle, which runs in four steps:

1. Configure. Set the MUX parameters, voltage, current, frequency and so on, and specify how many test points are to be recorded.
2. Reference. Select “Reference” and the system generates V-I graphs for the designated test points on a known-good board.
3. Record. Store the recorded V-I data in a designated folder on the PC. This is the golden dataset the line will compare against.
4. Test. Retrieve the saved file and run “TEST”. The software compares every configured point and reports either “all points in tolerance” or the count of points that fell outside it.

The MUX is supplied with 100 channels as standard and can be cascaded to expand the channel count up to 200 channels, so the number of test points a station can cover is a fixture question rather than a software one. Direct PCB connection is possible where the board has a test-point connector; otherwise the MUX interfaces to a bed-of-nails fixture. The detailed deployment sequence for that station is covered in FADOS MUX in production.

GSAS Agent: the report, summarised, with a QR code attached

An Excel file per board is a record, but it is a bad one to hand to a person. Nobody scrolls a hundred-row spreadsheet on a shop floor, and emailing spreadsheets to customers is how versions get lost.

GSAS Agent sits on top of that output. It reads the Excel report the FADOS software has written, gives the summary an engineer or an auditor actually needs, and hands it back with a QR code that puts the full document one scan away. The booklet describes what it produces rather than how it is wired in, so confirm the exact integration with GSAS for your setup.

The useful property is the indirection. The QR code is small enough to print on a label, and it resolves to the complete report rather than to a summary of it. The person holding the board gets the one-line verdict from the label and the full per-point table from their phone, and neither of those needs anyone to go and find a file.

Offline, Google Drive or LAN: pick the mode that matches the site

GSAS Agent supports three connection modes, and the choice is dictated by what the site’s IT policy allows rather than by preference.

Offline mode. Reports are saved locally on the system. Nothing leaves the machine. This is the correct mode for an air-gapped test bench, and in Indian practice that means defence and aerospace repair depots, and any bench sitting inside a plant network segment where external connectivity is simply not granted. The record is still complete and still structured; it just lives on that machine and gets backed up by whatever process already covers that machine.

Google Drive mode. Reports are saved to Google Drive with an automatically generated QR code. This is the mode that makes sense for a multi-site service organisation, or for a repair shop whose customers are elsewhere. The scan works from anywhere, so a customer who has the board in hand in one city can read the report without anyone forwarding anything. It obviously requires that the site accepts a cloud service holding test data, which is a decision for the customer’s IT and quality functions and not one to make on their behalf.

LAN mode. Reports are saved to a local server with a QR code for convenient access. This is the middle path and, in our experience with Indian manufacturing sites, the most commonly acceptable one. The plant keeps the data inside its own network, the QR code still works from any device on that network, and the quality department gets a single server location to back up and to point auditors at.

What this changes for a repair shop

A board repair shop lives on two arguments it cannot currently win with paperwork: what was wrong with the board when it arrived, and whether it was fixed when it left.

With a report attached to each job, both become boring. The incoming test report is the record of the fault as found, timestamped and tied to the serial number. The outgoing test report against the same golden reference is the record of the repair. A QR label on the dispatch note lets the customer verify it themselves without a phone call. For warranty disputes about whether a board was already faulty on arrival, a dated incoming report is a considerably stronger position than a technician’s recollection.

There is a second, quieter benefit. Because each report carries the test settings, a shop that sees the same board type repeatedly builds a searchable history of which points fail on that model. That is the raw material for knowing which spares to stock.

What this changes for an EMS line

For an EMS operation the driver is usually a quality management system rather than a customer dispute. A quality management system will expect the results of inspection and test to be recorded, and those records to be identifiable and retrievable later. GSAS states that as engineering guidance rather than quoting the standard, which is paywalled. A folder of per-board Excel reports keyed on serial number satisfies that in a way a whiteboard does not.

The practical uses are:

• Incoming inspection. A report per incoming assembly, so a batch problem from a supplier is provable rather than suspected.
• End-of-line screening. A report per unit shipped, retained against the serial number.
• Repair verification. Evidence that a reworked board was retested rather than just rebadged.
• Golden-board control. The reference dataset is a file in a known folder, so it can be revision-controlled alongside the board revision it belongs to.

The traceability point matters more than it used to. Indian EMS work increasingly serves automotive and EV, aerospace and defence, industrial automation, medical devices, power and energy, telecom and consumer electronics customers, and in most of those sectors the customer’s own audit obligations flow down to their suppliers.

What the report does not prove

Three honest limits, because a record that overstates itself is worse than no record.

It is a signature comparison, not a functional test. A board can pass every V-I point and still fail in the application, because the method verifies component-level and interconnect-level behaviour rather than system behaviour. The report evidences the screening, not fitness for purpose.

The verdict is only as good as the tolerance. Set the tolerance too wide and the report says PASS on boards that should have been held. This is why it matters that the tolerance is recorded per point in the report body. A reviewer can see the setting and challenge it.

The reference is a decision, not a fact. The golden dataset was recorded from boards someone chose to call good. If the reference board had a latent defect, every subsequent comparison inherits it. Recording the reference from more than one known-good board, and re-recording it when the board revision changes, is what keeps that honest.

None of these are reasons not to keep the record. They are reasons to keep the settings inside it, which is exactly what the FADOS report format does.

Setting this up in India

GSAS Micro Systems is an authorized CBT Electronic engineering partner and assembles FADOS units at our Bengaluru facility. Beyond supplying the hardware, our applications team helps with the part that actually determines whether the traceability works: choosing the test points, recording a defensible golden reference, setting tolerances that catch real faults without generating false failures, and picking the GSAS Agent connection mode your IT and quality functions will sign off on.

We support FADOS installations and reporting workflows across India from Bengaluru, Hyderabad, Chennai, Pune, Mumbai, Delhi NCR and Visakhapatnam, with INR invoicing under GST, on-site commissioning and operator training.

Download the FADOS booklet (PDF) for the full model comparison and specification tables, or talk to us about your boards.

Request a FADOS quote · Book a demo