The project was delivered as a joint engagement between Opticore and JTS. Opticore handled construction, splicing, and field testing. JTS handled engineering, workflow design, software development, and quality control.
The scope
The site layout was straightforward in principle. A central hut sat near the middle of the property. From that hut, single-mode fiber ran out to roughly one hundred row IDFs. Each row IDF fed a spine fiber down its own row, with drops to each of 500 panels along the length.
Row dimensions:
- 3,000 feet long, split by a central service aisle (1,500 feet in each direction)
- 40 feet center-to-center spacing between rows
- 500 panels per row, roughly 6 feet apart
Fiber plant totals:
- About 100 trunk fibers from hut to row IDFs
- A 3,000-foot spine fiber inside each row
- 50,000 panel drops
- Roughly 230 miles of fiber in the ground when it was all said and done
For context, 230 miles is about the driving distance from Cleveland to Pittsburgh and back. All of it inside one site boundary.
Site capacity sat in the tens of megawatts. The site was one of several the developer was building across the region on similar architectures.
The acceptance requirement
The customer's requirement was simple to state and hard to execute at scale. Every panel had to pass end-to-end loss testing from the central hut back to the panel's transceiver. Not sampled. Not spot-checked. Every link.
That meant 50,000 individual tests, documented, signed off, and handed over in a form the customer's engineering team could actually use.
The customer wouldn't take .sor files. Their field and ops teams were not fiber specialists. They wanted PDF acceptance reports with a clear pass/fail per link, measured values, test configuration, and date stamps. That was the contractual deliverable.
What the project would have looked like without us
Here's what was going to happen on the manual path. A splice crew would run OLTS at 1310 and 1550 nanometers on every link, write results on paper or into a spreadsheet, and hand over a stack of binders at the end of each row. Someone back at the office would type that into a report. The customer would get the report, scan it, file it, and never look at it again unless something went wrong.
A few things made that unacceptable at this scale.
Error rate. Fifty thousand manual data entries introduces mistakes. The ones that get caught cost rework. The ones that don't get caught show up as mystery outages six months later.
Timeline. Writing by hand and typing into spreadsheets doesn't scale. The construction schedule couldn't absorb that overhead.
Zero reuse value. The report sits in a filing cabinet. The fiber plant does its job or doesn't, and nobody knows which until a transceiver fails.
Someone on the engineering side decided to do it better. That decision opened the door for JTS.
The architecture
The fiber plant design itself was conventional. The engineering decision we made was in how to test and document it.
Trunk fibers from the central hut terminated in row IDFs. Standard single-mode, OS2, buried in conduit where appropriate. Nothing exotic.
Inside each row, a spine fiber ran the full 3,000 feet. Drops went to each panel transceiver with pre-connectorized assemblies, factory-tested and length-matched. Field splicing was limited to the trunk and the spine-to-drop junctions.
Equipment:
- EXFO OLTS at 1310 and 1550 nanometers for every acceptance link
- EXFO OTDR for troubleshooting and spot verification
- Standard inspection and cleaning gear per IEC 61300-3-35 before every mate
The real engineering work was upstream of the fiber. The customer's original scope required PDF deliverables that their engineering team would then manually review, trace by trace, level by level. That was how they had always done it. The volume at this site made that approach untenable.
JTS developed a workflow built around .json files captured from the OLTS. Every test result imported directly into a custom monitoring platform, which checked each measurement against expected commissioning levels and tracked drift over time. The platform then generated the PDF acceptance report automatically as an easy-to-read pass/fail table, delivered to the client daily.
The customer got the deliverable they had contracted for, in the format they knew. What they didn't realize they were also getting was real-time visibility into how many devices were coming online each day and live access to site capacity. All of it automated.
The acceptance workflow in practice
The field workflow was tight by design. A test tech moved through a row with the OLTS source at the IDF and the meter at each panel location. Results captured to the instrument. At the end of the segment, the tech synced the instrument. Our software pulled the raw test data, matched it against the project record, flagged any out-of-spec links, and produced the PDF.
When something failed, the OTDR came out. The tech ran a trace from the IDF toward the failing drop, located the event, and the crew repaired it. The repaired link got re-tested on OLTS, and the record updated.
The PDF reports followed JTS format and matched exactly what the customer had agreed to in the acceptance plan. One link per entry. Measured loss at both wavelengths. Pass/fail determination. Instrument metadata. Technician identifier. Date and time.
By the end of the build, the acceptance package was tens of thousands of pages of PDF documentation, all generated automatically from test data. Zero manual transcription. Full traceability from the field capture to the signed-off deliverable.
The monitoring platform
The developer treats their fiber plant as mission-critical infrastructure. A degraded transceiver at a panel means lost production. A failed link in a row means dozens of panels dark across the site. At this scale, visibility is not a dashboard. It is operations.
The developer already operated a regional NOC that watched inverter output and site telemetry across their portfolio. What they didn't have was fiber-layer visibility. If a transceiver started to degrade, loss drifting or Rx power sagging below threshold, the first they'd know was when the panel showed up as underperforming in inverter data days or weeks later. By then, root cause was buried.
JTS proposed and built a custom monitoring platform that put the fiber layer on their radar in real time. Every transceiver was monitored continuously. The platform tracked:
- Transceiver temperature
- Transmit power
- Receive power
- Correlation between panel inverter output and expected production
- Alarm thresholds set per link based on commissioning values
When a transceiver drifted outside configured thresholds, the platform generated an alert and pushed it into the developer's existing NOC workflow. From there, the NOC's automated dispatch logic routed a ticket to the appropriate regional field technician. No human in the loop between the fiber-layer anomaly and the dispatch.
Fully automated. One hundred percent.
The platform ran as a web app with role-based access. NOC operators saw alerts in their existing single pane of glass. Field techs got dispatch tickets in their mobile workflow. Engineering had a dashboard view of trends across the portfolio.
The architecture matters for the business story. JTS wasn't selling a point-of-sale monitoring product. We built the layer that sat between the physical fiber plant and the developer's existing operations infrastructure. That's a different sale, a different margin, and a different ongoing relationship.
What this project proved out
Three things worth naming.
Acceptance can be automated end-to-end. The decision to pull test data straight from the OLTS and generate PDFs programmatically shaved weeks off the documentation timeline and eliminated transcription errors entirely. On a build with fifty thousand links, that math is not subtle.
We recognized a problem and offered a solution. The customer didn't ask for a monitoring platform in the original scope. They asked for fiber installation, acceptance, and PDF documentation that matched their standard process. We saw a gap between the fiber plant and operations visibility and proposed a solution that closed it. That approach turned a one-time build into an ongoing relationship.
Scale rewards tooling. On a small site, you can get away with spreadsheets and manual processes. At fifty thousand links across hundreds of miles of fiber, you cannot. The teams that invest in automation on these builds finish on time and have artifacts to hand to their customer. The teams that don't, don't.
Where this applies today
Utility-scale solar is one shape of this problem. The same pattern shows up on hyperscale data center builds, long-haul fiber routes, FTTH deployments at metro scale, and digital substation projects. Anywhere the fiber count and link count exceed what a manual process can realistically absorb, the economics of automation take over.
The engagement described above was a bespoke, large-scale build. The same core engine that drove it is available on this site in simplified form:
- The Fiber Analyzer handles one trace at a time in the browser.
- The Fiber Analysis tool handles a job's worth of files at once.
Both are free and useful for individual projects and spot checks. They are not what the solar developer received. That version ingested and processed thousands of files automatically, in real time, feeding a live monitoring platform tied directly into the customer's NOC.
The JTS API is the first productized path to that same capability for teams that need their own stack doing the heavy lifting. Custom integration work at the scale of the solar project is available by engagement.
Run your own job through the same engine. Drop a whole job's traces and OLTS/OPM results into Fiber Analysis and get a pass/fail verdict per fiber, free and in your browser.
Open Fiber Analysis →