When first starting out, it may look overwhelming... but stick with it and put in the work up front

When first running the DIS Protocol Analyzer, you may really be surprised by the number of errors it captures. To top it off, we are continuously to the list of detected errors.

For instance, one of the exercises that we use in our testing, the exercise consists of over 3 Million DIS packets over the span of 45 minutes. This exercise had approximately 40 companies participating in the exercise. The exercise contains 352 entities and 444 radios.

Let me start by saying, in this particular exercise, there were a great deal of DIS Standards that were not strictly enforced. In this exercise, we detected over 2200 errors and 5300 warnings. Keep in mind, that in most cases, an error or warning is only reported once for a given entity or radio!

When you first look at the error file that is produced from the exercise you will normally see a number of errors/warnings that occur quite often. For instance, there were many radios that had power settings that were much too high. For an error such as this, an warning message similar to the following is reported:

[5.360] WARNING Transmitter Power of 55.1188 dBm (325 W) is probably too high for 2340:1:1058:78 (PLEXSYS Interface Products) usually below 45 dBm (30 W)

In the error file, this warning occurred for 152 of the 444 radios! This would be an obvious candidate to have users correct in order to get rid of 152 warnings right off the bat!

Next, you would pick another obvious error, for instance, if find another error that is reported commonly such as:

[7.520] WARNING Questionable bandwidth (0) requested for radio 1515:21958:9099:6 (Alion Science and Technology) should probably be at least 8 KHz you will find that there were bandwidth problems on at least 63 radios. In correcting these two problems you have quickly taken care of around 4% of the 5300 warnings that were reported.

Many of these warnings detect best practices that are violated. Correcting many of these problems could very well head off problems that you haven't even detected yet.

Many of the main culprits of errors such as these will occur the first time an entity or radio is received and would therefore be toward the top of the error report. This is also where you will find entities/radios that are created by those that shouldn't be creating them or if multiple sources are trying to publish them. You will also be notified if an improper DIS enumeration is occurring.

Ideally, the number of errors and/or warnings SHOULD be minimal. If they are not, this should be your first goal. The errors reported normally explain what's happening in "plain English" and provide you enough information to know "who is doing what." In order to get to this point however, you really need to define you network as much as possible utilizing our Network Manager. It does not take very long to do and will save you tons of work down the road because it pretty much describes the "who" part of it.

As you knock off more and more of these errors/warnings, the number of errors and warnings reported will quickly be reduced and you will begin to see forest through the trees. You will be able to really get down to the pesky problems that until now, could take weeks to find and fix.

Recently, we were helping debug a very difficult problem. If we have already taken out a lot of these miscellaneous errors, then when a hard error occurs, it is much simpler to find and fix the problem you are chasing.

Presently, we detect HUNDREDS, of possible error conditions. If you run into an error/warning condition that we are not currently detecting, please let us know.