J. Batch, J. Kissel

In efforts to resolve the 16Hz harmonics (from here on "16HzH") seen intermittently on the X1 SUS Electronics Test Stand, we decided to upgrade the front end code generating software from RCG 2.0.1 to RCG 2.1.5, along with associated other GDS software. In short, the upgrade took only a few hours (if that), and appears to have succeeded, both in our standard "does it *really* work?" tests and in getting rid of the 16 HzH. However, we should keep an eye out for the 16HzH popping up in the future (i.e. when we get a full QUAD's sensors back up and running, as opposed to merely 6 OSEMs on a BSFM).

Among the other tests (described below), we performed the same test we performed this morning, using two models (QUAD and BSFM) to simultaneously readout the same ADC channels, measuring both test points and frame builder channels. Knowing that the problem had been seen on different channels at different times, I made sure to look at all six degrees of freedom (see pages 1 - 6). All six DOFs show no sign of the aggregeous 16HzH. Further, the test was performed after several restarts of the front end process (which had been known to cause the 16HzH to jump from channel to channel), and still showed now sign of 16HzH.

Excellent!

The QUAD and BSFM still need to be "prepared," in the the matrix values must be restored, and filter settings to be corrected from their initial start up state. This will be done first thing tomorrow morning.

Details
-------
[What was done for the upgrade (forgive my Jedi Level 5 understanding, Jim was blazing through this stuff like a BOSS)]
The upgrade from RCG 2.0.1 to RCG 2.1.5 includes several bug fixes (e.g. bus creator/selector problems), newly supported Simulink parts (e.g. RMS block), the ability to use long channel ~50 names in EPICs, and most notably it changes the extension for frame builder channels from having the extension "_DAQ" to "_DQ".

However, in order to be sure that EPICs could handle the extra long channel names, it required a recompilation of several other associated software such as mbuff, awgtpman, and daqd/nds and re-installing them the kernel, target/gds/bin/, and target/gds/, respectively. Also, the GDS software (dataviewer, dtt), agwstream, and EPICs themselves needed upgrading and recompilation. Finally, once the above associated software was upgraded, and the RCG "release" folder was linked to a checkout of the advLigoRTS-2.1.5/ tag, both the x1susquad and x1susbsfm models needed to be recompiled.

*phew!*

[Once the upgrades were finished]
We ran through a battery of tests (some that are now a standard part of the CDS upgrade checklist -- DCC number eminent, "GDS Test Plan"):
- Open Dataviewer, look at test point channels and frame builder channels, see if it works
- Open DTT, take a spectra of a few channels, both in real time, and in the past, just to see if you can
- Use awggui to inject a small sign wave, and look to see if you see the excitation in dataviewer
- use awgstream from a terminal to inject a small excitation, see if you see it in dataviewer
- Open Matlab, make sure all mDV software is in place (gps, get_data in particular)
- Use Matlab's get_data to retrieve some data from NDS / frame builder
- Use Matlab's awgstream wrapper to send in an excitation, see if you see it in dataviewer

The only file that needed to be changed (for each model) where the .ini files, which are responsible for letting the frame builder know what channels are to be stored. This was a simple fix -- just replace all instances of "_DAQ" with "_DQ", then run a "DAQ Reload" from the GDS_TP MEDM screen (the result of which should be that the top middle indicator light should go green, and read 0x0). The foton (chans/.txt file), and the test point manager file (.par file) did not need to be restored or changed.