Distributed temperature sensing (DTS).

OptixSoft Company’s Blog has started new trend from now - "Invited Blogger". We will invite engineers and specialists in related fields from outside (fiber optics, software development, etc.) to post at our Blog. It may help us to hear and share different opinions and ideas.

Here is the first such post written by our friend and fiber optic specialist Andrew Luzgin (currently working for FOD Ltd).

Distributed temperature sensing – is a great technology on OTDR base.

A few words about theory. Well known, that original OTDR measures a backscattered Rayleigh light in the optical fiber. Except Rayleigh effect, there are another scattering effects in the oprical fiber (not in fibers only, of course). It is so called Brillouin and Raman scattering. The intensity of the Raman scattered light is very sensitive to optical fiber temperature. So, it is available to measure distributed temperature along optical fiber. It can be original singlemode (SM) or multimode (MM) fibers. Both fiber types application has merits and demerits.

Simplified schematic of DTS system is below.

At first glance, it looks like an original OTDR, but DTS includes optical filter (OF) and optical commutator (OC). These parts are necessary to choose Raman light from total backscattered signal. And then — a usual OTDR. In a simple case, it can be an OTDR interface with some special processing on the software level.
Nowadays, DTS system becomes a powerful attribute for environment research, fire alarm, piping control etc. Of course, most useful application is a long time temperature monitoring. This allows storing information about control object, producing necessary analysis and predictions.

Many thanks to Invited Blogger - Andrew Luzgin.

How we bring OTDR to work in customer environment. Integration issues.

We have already passed a long way of integrating different OTDRs to customer environment. As our experience grew, we adopted different approaches to this problem. And now it's time to note some important milestones in this history.

In the beginning:

(It was long time ago… we've just started)

We had not got any defined and documented OTDR data exchange protocol by the time when the first customer asked about non-GUI OTDR for his system. Since it was urgent requirement we had to describe OTDR protocol in the following way:

Send Byte 0x77
Receive Byte 0x08
Send Byte 0x90 0x54 0x62
Receive 15 Bytes : 0xX1 0xX2 .... where 0xX1 is the number of data points...

And so on, with intricate explanation of how to process raw binary data and several samples on C programming language.

Problem with this approach arises if OTDR data needs some additional processing on client's side. In another cases this way may be just good anough.

Next approach:

(several month later)

At that moment we had completed OTDR interface specification and had built several DLLs (Dynamic Link Libraries). They acted as upper level OTDR drivers and customers were able to incorporate OTDRs into their their own systems using DLLs' exported functionality (MeasSetup(), MeasStart(), MeasData(), etc). There were several requirements to use these DLLs, such as using particular programming language (C++) and using defined common data types and structures (GR-196, SOR, Standard OTDR Record class library). Our solution was built with C++ programming language and was cross-platform, so it was the same for Windows and Linux environment.

And the next one:

The next project was RFTS (Remote Fiber Test System) development, in which RTU (Remote Test Unit) is controlled via Ethernet. One of requirements was to use standardized remote interface to RTU, so we decided to specify our RTU TL1 protocol.

Actually, pure TL1 is not 100%-suitable for OTDR-like devices, but with some improvements we have created protocol, that has met requirement completely and now RTU could be controlled remotely via TL1.

I'd like to mention that this is also a cross-platform solution (on both client and server sides). We used it successfully for Linux and Windows based applications.

Still another approach:

LabVIEW.

First, a simple idea to use our USB osciloscope (with LabVIEW driver) as OTDR for lab purpose arised. Then automation requirements have forced us to learn LabVIEW environment deeper.
So now there is just one more way of OTDR integration. First of all, it is suitable for using different instruments simultaneously via lab applications.

To be continued (about COM, .NET and web-services)...