Batch OTDRs inspection with help of SORSE

Just a small note about way we use  SORSE (OTDR Traces Sor format Shell Extension) for our internal needs.

What we have:
- many OTDRs were manufactured and arrived to QA department for approvement
- same reference fiber (testing line) measured by each device at each wavelength and same sor files set stored in each folder  

And now power of Sor Shell Extension used (For example search for "1490_level1us" files to compare/verify metrological parameters):

      Now we can see all traces measured at 1490nm wavelength with Pulse Width 1000ns (1us) from all devices in the same window of Explorer.
     Because same file names means same measurement parameters we can compare them with each others and check deviations at a glance.
    Also by clicking column header we can sort files by any parameter and easily find best and worse units.
  Columns we are checking:
- "Input level" (Backscattering level at the trace beginng, just after OTDR output) 
- "Input reflctance" (How good/bad operator made a connection)
- "End of fiber"  (Verification of  distance accuracy)
- "End reflectance" (Informative field)

Labels: ,

SOR format review ("Standard OTDR Record" for Viewers)

Our company is working many years with OTDR file format (Originally Bellcore 1.0-2.0, then Telcordia GR-196 and SR-4731) and we have something to tell about this topic because our software (especially Fiberizer Cloud - web SOR Viewer and storage) now widely used by customers all over the world to process not only own Agizer OTDR's data but many vendors as well.

1. Offsets notes/issues

1.1. Acquisition offset (AO) and Front panel offset (FPO)
Specification stands: "AO tells how far away from the OTDR the first data point in the trace file is". As a result  AO must be negative  when a number of the first data points belong to internal fiber (before OTDR output connector). 
At the same time internal fiber determined by FPO value. "FPO indicates how much of the saved trace corresponds to lead in fiber."

It means AO and FPO duplicates each other when internal points exists :
-AO = FPO, as FPO > 0

When trace file points start from Nkm (i.e. 0..Nkm points are skipped):
AO=N, FPO = 0

In all other cases parameters are in conflict! (when |AO| <> FPO)

Agizer™ Suggestion: Keep current definition of AO (including negative values) and reject FPO.
Our OTDRs distance calibration procedure is binding moment when light goes through front panel to 0 sec(m) of trace data point by changing AO.

1.2. "Distance" type fields.
 AOD and UOD depend on Group Index (GI) user selected.  User may be confused to see UOD marker in wrong location after he changed GI for whole trace (because all data points stored in time).

Agizer™ Suggestion: Store all values (AO, UO) only in time. FPO has no "distance" pair.

1.3. Problem of binding User Offset to connection between lead-in fiber and link.
To measure distance properly with lead-in fiber user need to input length of his lead-in fiber as User Offset value. But event location is Time type value, so it's not easy task to get 0-accuracy by editing  UO in meters (consider GI)

Agizer™ Suggestion: We are using custom field to keep number of event to bind UO. User has choice: input UO himself; input UO himself but bind to nearest event; input event number. 

1.4. Whether Event and Markers locations must depend on User Offset.
 Specification stands: "Event Propagation Time (EPT) is relative to the beginning of the link (the end of the User Offset fiber). "

Agizer™ Suggestion: User Offset is used when time values recalculated to distance values just before displaying for user. As a result all time values (including Event locations are stored relative to 0sec time (adjusted by AO/FPO)

1.5. Connection of fibers with different Group Indexes (or Helix Factor).
Real link consists of many fibers spliced together and for accurate distance measurement need to extend format by including sections (from point N to point M) with different GI. Same as it is currently done for different Pulse Widths.
It is especially useful for bi-directional analysis when we need to bind events of the traces measured  from opposite directions.

2. String fields (like Comments, fiber type, etc... )

2.1. There is Language Code in General parameters (like EN, CH, RU) which is not exactly tell us encoding table was used for selected language.

Agizer™ Suggestion: Add "U8" language code for any languages and use UTF-8 encoding.

3. Thresholds (Loss, Reflectance, End-Of-Fiber)

3.1. Specification stands: "Events table should contains information about events along the fiber trace that the fiber trace analysis software has identified as exceeding the user selected
event threshold levels (see Fixed Parameters Block)"

Agizer™ SuggestionConsider threshold values as alarm levels (pass/fail) to highlight certain events. At the same time Events table must include ALL events (including passed - OK, i.e. lower than thresholds) which analysis software was able to identify.

Otherwise skipped event might affect next event parameters calculation (see next figure):

Left approximation shoulder have wrong attenuation coefficient and event loss is also incorrect.

4. Other

4.1. Signed short integer (multiplied by 1000 scale) is not enough for some fields.
For example Attenuation Coefficient Lead-in Fiber (ACI) for Event need more accuracy for some applications (like 0.1234 db/km). 

4.2. Zero level of dB scale (vertical axis). It's described quite well in specification but some vendors understand it in a different ways.
We understand it as follows: 
- Maximum level (top of chart) is 0dB (maximum backscattering/reflection level which OTDR can measure)
- Minimum level (bottom of chart) is -65dB (negative value because signal attenuate along the trace)

We are glad to welcome software and fiber optic engineers to discuss these issues.

Labels: , , , , , , ,

New version of SOR Shell Extension

Starting from Windows Vista Microsoft has changed the API to add custom Explorer columns, breaking backward compatibility with shell extensions written for Windows XP. That's why our first Windows Vista/7 compatible version of SOR Shell Extension did not support the feature on these versions of Windows. Our users, which had updated their OSes, told us they were missing the custom columns feature. So, we have just uploaded a new version of SOR Shell Extension, which adds this feature back on Windows Vista and 7.

Feel free to download the new version from our site.

Labels: , ,

First iPhone application designed specifically for handling and analyzing fiber optic OTDR results will appear on the market in September 2011

Belarus, Minsk, Aug. 15, 2011

Wide practical experience of software and hardware development for fiber optic test&measurement industry and awareness of the fact that smartphones will further be more and more integrated into business processes allowed OptixSoft company to take a decision of development first iPhone application for engineers working closely with fiber optics - Fiberizer.

Fiberizer allows telecommunication engineers, fiber optic line installers and other experts using OTDR results in their job to review and analyze OTDR traces compliant with Telcordia GR-196 & SR-4731 standard in format of *.sor files. There are such features implemented in Fiberizer app as: possibility to connect and work with cloud based file sharing services like DropBox, Google Docs, utilizing of powerful usability multi-touch gestures for work with OTDR trace displaying, etc. OptixSoft mean to Fiberizer app release in Apple AppStore in September 2011.

Currently everyone can submit his email on the and he will be notified once app is released.

About OptixSoft: Optixsoft is small software development company based in Minsk, Belarus. It provides system, cloud, mobile and desktop software development for companies occupied at fiber optic and test&measurement industry.

For more information, contact:

Eugene Belianka,

Fiberizer product manager


New version of SOR Shell Extension

There is a new version of SOR Shell Extension - Windows shell extension, that makes working with Bellcore GR-196/SR-4731 (.sor) files more convenient. This update contains several fixes and improvements, the most valuable from which are, probably, Windows 64-bit support and registry access fix.
You can download the update from our site.

P.S.: This is not an April Fools' Day joke :)

Labels: , , ,

We are Growing and Developing new Business! Agizer.

Specialists of OptixSoft Software Company have accumulated experience in instruments design. Since our Firmware Engineers and Product Managers have been working closely in T&M industry over the years, we decided to bring our own vision of Test Instruments to the market.

News! OptixSoft supports and participates in new start-up which name is Agizer!

Recently we've completed a good job and launched pilot Agizer project - OPX-350 OTDR.
Of course our major responsibilities are software/firmware/OS and nowadays our managers supervise platform hardware design to meet our requirements.
Optical module was developed by newly created team, which consists of professionals with good portfolio in industry.

Next innovation project is on the way - it is small wireless measurement boxes controlled by customer mobile device (any PDA like iPhone, iPad, Android powered gadget).
Our apps at the AppStote and Android Market coming soon!

We are keep doing in T&M industry!

Garbage collector and local variables

If you are a C# programmer, then I have a question for you. How do you think, how many times the string "GC called" will be written to console by the following code:

using System;
using System.Threading;

class GarbageCollectorTest
   public static void Main()
      Timer t = new Timer(CallGC, null, 1000, 1000);

   static void CallGC(object o)
      Console.WriteLine("GC called");

Correct answer: depends on compilation parameters. In release build the string will be written only once. Debug version will write it until the user presses a key.

In C++ a local (automatic) variable's lifetime is defined by variable's scope - the variable will be destructed when program flow goes out of the scope.
In C# the lifetime of such variable is defined by how long the variable is used. I.e., the variable may be destructed before it goes out of scope, if garbage collector considers that it's not used any more.
In debug version variable's lifetime is artificially extended to its scope.

In Java, as far as I know, the JVM specification allows similar realization of garbage collector.

P.S.: If you are a C# programmer, but this post became an eye-opener for you, then read Jeffrey Richter's book "СLR via C#". You can find much more interesting and useful for.NET development in it.

Labels: ,

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