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)...

OptixSoft flying team!

If official version doesn't look serious.

15 minutes of effective communication

Does your company staff consist of young enthusiasts? Do they spend much of their free time learning new technologies? Are their professional passions interesting for their colleagues? Would you like to improve the exchange of useful experience and knowledge inside your company?
It’s the same for us. And probably our solution will fit your situation too. What is the point?

From time to time our united team gathers for approximately a quarter of an hour. Someone gives a brief lecture about something new, which will probably be interesting and useful for the others. What for?

First, it allows others to easily pass entry phase when learning new technology. How often do you read about something new and cannot get the point, because you don’t see the whole thing? But the man, who has already spent his time learning new technology and who already has clear idea about it, can briefly describe the main point and why to use the innovation. This will allow others to boost their startup when learning this technology in the future.

Also, such lectures broadens personnel’s mind. It may be useful for average developer when finding a non-typical solution, or for system architect when designing a new architecture.

It is also useful for the speaker. He learns how to speak clearly and gets the public speeches experience. It will have its meaning when communicating inside your company or with customers.

And even more – it’s the way of effective break. Because break is just the change of activity area, isn’t it? And such meetings will not only get an employee out of his everyday job, but will also let him to return to his work with clear mind and probably new ideas.

At last, it’s just another way of communication. There are not so many things that are more important, than communication in team.

So, we have five advantages.
What does it cost? Approximately 15 minutes of your working time per week. It’s not so much, isn’t it?

E.g., yesterday I had a lecture for colleagues; it was about using RAII design pattern in C++ development. If you don’t work at Optixsoft yet and missed a lecture, but if you are a developer and if your language, happily, has destructors, then I would strongly recommend you to learn this pattern. It will make your using of resources significantly easier. This pattern is clearly described in works of such C++ gurus as Stroustrup, Meyers, Sutter and Alexandrescu and is considered as important part of good coding style. You can read about this pattern, for example, in «Effective С++. 3rd Edition» by Scott Meyers or in Wikipedia.

By the way, my name is Alex Korotkin. This is my first post on our company blog. I’m responsible for development at Optixsoft, so my posts will refer to development, more or less. I will be glad to answer your questions. I’m sure that such communications will be useful for all of us.

Optical network monitoring in practice – what do you need to know.

We decided to write a series of publications (articles) about the practical use of optical network monitoring systems (RFTS). Thus, together with the IIT company, we wrote the first article, which is titled "Methods of Optical Fiber Parameters Analysis under Automatic Monitoring" (this article was published in the Russian edition of Lightwave magazine).

As is usual, in the process of creating an article, our work has born a lot of material that goes beyond the originally planned topic. Based upon this material a number of useful articles on the following issues will soon appear:


- Network monitoring system architecture
Here we are going to talk about various ways to set up a monitoring system. We will try to give an answer to such question as: Should OTDR operate continuously or should it start measuring once it has received an alarm signal from a permanently active OPM (optical power meter). This issue is important if it is necessary to save the resources of expensive OTDR devices. Also we will explain the frequent problem of separating zones of responsibility during the monitoring of large networks, covering, for example, several administrative units (subnational entities) within their organizations.

- "Vectorial" method of fiber parameters analysis during automatic monitoring (RFTS)
Since this method has been applied to the monitoring system software, which we develop at OptixSoft, we will describe it in detail. We will give practical advices for users on how to markup the trace properly, how to choose parameters to measure a reference trace, how to optimize the reference trace template to increase the system reaction rate and so on. Such interesting issue like Faults Prediction will be described too.

- Economic effects of the use of monitoring systems (RFTS)
We will try to evaluate once again the qualitative and quantitative effect of using network monitoring system in practice. We will deal with the subject of Reducing Mean Time to Repair has usually been taken to restore communications after the accident. We will describe Faults Prediction usability in case of fiber degradation and other benefits like unification of tools and documents.

New website design!

Congratulations! Finally it happens.

Look at our previous design - also not bad but just a little bit non-informative))).

Let’s save it for the history: