Blog

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

Labels: , , ,


1 Comments:

At September 27, 2008 at 10:02 AM , Anonymous joubert said...

good work on OTDR!

 

Post a Comment

Subscribe to Post Comments [Atom]

<< Home

Optixsoft - Software Development For Fiber Optics. Copyright 2013. All rights Reserved.
optixsoft
Home  |   Company  |   Services  |   Products and solutions  |   Portfolio  |   Client care  |   Contacts  |   Blog  |   Site map