AIM 882 produces internally inconsistent results

 

AIMuhfI have had cause to validate the output produced by an AIMuhf measurement using AIM882 (current version, released about three months ago).

The test scenario is a pair of nominal 50+j0Ω loads on a Tee piece, connected to the AIMuhf by about 1m of RG58 coax and swept from 10 to 50MHz.

Screenshot - 16_01_2015 , 15_40_27

It is mental arithmetic that the VSWR should be very close to 2:1, and since the loss of the cable is quite low, VSWR should be almost uniform with frequency.

The scan was saved using the “save graph” function which creates a proprietary format file (.scn) and a csv file of measured and derived values.

Since the .scn file appears to contain freq vs polar Z, and the .csv file can be recreated from a .scn file, it would appear that the polar Z data is the root data.

So, I have calculated R, X and VSWR from the polar Z data in the .csv file, and compared them to the same values reported directly in the .csv file.

Clip 090

Above, a comparison of the VSWR calculated by AIM and by me. The error might not seem huge, but it is way higher than should be expected.

Clip 091

Above, a comparison of R calculated by AIM and by me. The error might not seem huge, but again way higher than should be expected.

Clip 092

Above, a comparison of X calculated by AIM and by me. The error might not seem huge, but again way higher than should be expected.

It is interesting that in the case of the R and X curves, they agree almost exactly at the first data point. This hints some kind of failure in the algorithms to calculate these values over a data array.

The following graphic is from a .SCN file of real world measurements with smoothing turned off.

Screenshot - 22_01_2015 , 09_02_02

I turned smoothing off to see if it was the cause of this problem, but the inconsistency occurred in a freshly saved .CSV file after turning smoothing off. Above, the graphic shows SWR=1.2 and ReturnLoss=33dB (inconsistent), the text in the right of the screen shows SWR=1.2 and ReturnLoss=20.96dB (inconsistent) and the saved .CSV record for that frequency shows :

Freq(MHz),SWR,Rs,Xs,Zmag,Phase(deg),Rho,ReturnLoss,%ReflectedPower
7.155500,  1.065385,  49.865057,  2.688103,  47.605021,  3.523407,  0.095705,  20.381344,  0.915937

Note that SWR does not reconcile with the screen shot (13% error), Rs and Xs do not agree with the screenshot (96% and 20% errors), and Zmag does not reconcile with Rs,Xs in the same record (5% error).

The fact that the SWR curve minimum does not coincide with the ReturnLoss maximum (plotted upside down for some reason) is a strong hint of problems.

The issue here is not the inherent accuracy of the instrument, but internal inconsistencies in the CSV file which have to be the result of software defects.

There are also inconsistencies in the data and curves in the screenshot above.

But the question is, how does software get released with such errors. It hints that there is not a standard test suite against which new releases are tested to ensure accuracy.

It would seem prudent to always regard AIM software as in need of validation.

Screenshot - 16_01_2015 , 15_44_11

If you are inclined to use ZPLOTS, it displays an SWR curve that is inconsistent with the polar Z values.

Screenshot - 17_01_2015 , 08_31_39

Above, inconsistency shown on the main graphic display. At the cursor, SWR is shown as 1.799 and Return Loss as 10.89dB (which are consistent with each other), but the SWR line shows around 1.8 and the Return Loss line shows around 30dB.

Screenshot - 17_01_2015 , 08_39_06

If we calculate the SWR and Return Loss of the displayed Rs,Xs wrt Zref, the SWR is 1.06 and Return Loss 30dB (as shown on the two curves).

Conclusions

  • AIM 882 software produces internally inconsistent results and is not to be relied upon.