Blog from March, 2020

iss3 dsm down 3/15-3/21

The iss3 dsm stopped reporting data around 17:15 UTC on 3/15. I had assumed that it got turned off before ISS left Santa Barbara and so didn't look into it, but that was not the case. Leila visited iss3 and power cycled the DSM on 3/21 and now it's reporting again. I don't know if the DSM was unresponsive or if nidas just stopped recording data. 

Looking at the logs there's our old friend the USB disconnect on 3/15 15:45:

Mar 15 15:43:40 localhost kernel: [157315.468311] usb 1-1.1: USB disconnect, device number 3
Mar 15 15:43:40 localhost kernel: [157315.468971] smsc95xx 1-1.1:1.0 eth0: unregister 'smsc95xx' usb-3f980000.usb-1.1, smsc95xx USB 2.0 Ethernet
Mar 15 15:43:40 localhost kernel: [157315.469180] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup

Everything looks like it usually does when this happens, except this message is new:

Mar 15 15:45:10 localhost rsyslogd-2007: action 'action 2' suspended, next retry is Sun Mar 15 15:46:40 2020 [try http://www.rsyslog.com/e/2007 ]
Mar 15 15:46:41 localhost rsyslogd-2007: action 'action 2' suspended, next retry is Sun Mar 15 15:48:11 2020 [try http://www.rsyslog.com/e/2007 ]
Mar 15 15:48:11 localhost rsyslogd-2007: action 'action 2' suspended, next retry is Sun Mar 15 15:49:41 2020 [try http://www.rsyslog.com/e/2007 ]
Mar 15 15:49:41 localhost rsyslogd-2007: action 'action 2' suspended, next retry is Sun Mar 15 15:51:11 2020 [try http://www.rsyslog.com/e/2007 ]

It repeats every 90 or so seconds until the DSM gets rebooted on 3/21.

By the isfs log it looks like the USB stick was read-only and the ethernet was also not working:

Mar 15 15:43:40 localhost dsm[1787]: EMERGENCY|SampleOutput: FileSet: /media/usbdisk/projects/SWEX/raw_data/dsm-iss3_%Y%m%d_%H%M%S.dat: IOException: /media/usbdisk/projects/SWEX/raw_data/dsm-iss3_20200315_120000.dat: write: Read-only file system
...
Mar 15 16:01:56 localhost dsm[1787]: WARNING|McSocketMulticaster: inet:0.0.0.0:0: IOException: inet:192.168.0.56:30002: send: Network is unreachable

So I'm guessing the DSM wouldn't have been reachable over ssh while it was unresponsive, but I'm not sure.

A few issues occurred with the 449 MHz wind profiler in SWEX.

First, during unpacking, it was found that the three MMCX connectors used on the PCIe expansion card were all broken off during transport.  The cables were zip tied to the frame for strain relief and the PC secured to the side of the rack with bungee cords.  However, during transit, the computer managed to shift and the MMCX plugs were sheared off by the cables attached to them.  As a result, both the board and the cables were unusable, the board because of the broken off connectors and the cables because the broken pieces were stuck in the cable ends and could not be extracted.  A replacement card and cables were sent out from Boulder.  The replacement card had been previously modified with a lower output impedance MOSFET by Kyle during testing of the M4 system where it was seen that the capacitance of the long coaxial cable used to carry the control signal for a Tx switch was causing issues.  The board required minor modifications (output J6 needed to be reconnected to its buffer circuit output), which was completed on site.  Testing with the oscilloscope showed the repair fully functional.  The system set up was then completed with the 5 kW amplifier installed.

However, the system failed to produce RF pulsed because the 500 W Delta Sigma driver amplifier would not bias when the gate control voltage was applied.  Voltage and gate bias signals were checked and found to be correct at the amplifier inputs.  Liz took the cover off the amp and the issue was traced to a failed CMOS driver IC (p/n).   The module will be taken back to Boulder and repaired.  The datasheet for the CMOS driver has an absolute maximum input voltage just over 5 VDC, which is the voltage level out of the PCIe expansion card, produced by its on-board buffer driver.  The CMOS driver also only needs TBV VDC in order to switch its output.  Therefore, I would like to investigate if the output voltage of the PCIe buffer chip may be lowered slightly to provide margin to the absolute input voltage of the CMOS driver in the Delta Sigma amplifier.   It is possible that reflections caused when we use an o-scope to look at the gate signal timing, with respect to the RF pulse, that we could be inadvertently generating voltages on the gate control line above the chip's ratings and damaging it.   I'm thinking we may be able to lower the supply/output voltage of the PCIe card's buffer by adjusting resistors on the card's voltage regulator.  Will have to investigate once back in Boulder.   In the meantime, the 5 kW amplifier was removed from the system and the 2 kW Delta Sigma backup power amplifier installed.   The system was then successfully started and is operational.

It is noted that the 2 kW Delta Sigma amplifier is outputting ~1.52 kW of pulsed RF power.   The RF drive level at the input to the Delta Sigma HPA box was measured with the Keysight power meter (with 20 dB attenuation on it) to be +17.5 dBm, which is the required input level to drive the amplifier fully, per testing in the lab.  The AC current draw of the HPA is 3.61 Amps, as determined by observing the ammeter on the power strip the HPA is plugged into when the system is idle versus when running.   The system is running at an 8% duty cycle, meaning the average RF output power is 121.6 W, while the amplifier is consuming 433.2 W, so the HPA is running at an efficiency of ~28%, which seems low.  The datasheet will be checked to verify expected efficiency, but I am concerned that one of the 500 W modules withing the 2 kW HPA may have failed, explaining why we are not getting the full 2 kW out of the amp.  We can test the other 2 kW amplifier in the lab for comparison.

Several other tests were performed on the system today to verify operation.    First, the LO power levels at the input to the RFE troughs were checked.  They measured +10.7, +10.6, and 10.7 dBm for Channels 0, 1, and 2, respectively.  The mixers in the troughs are Mini-Circuits ZFM-15-S+ that have a nominal required LO level of +10 dBm, so LO levels are good.

Next, the receiver gains were measured by using the portable Anritsu VNA in CW mode with several attenuators on its output to inject a very low level CW signal at 449 MHz into the antenna port of the Tx/Rx circulator cables in the RFE troughs and the resulting 60 MHz RF powers measured at the Pentek inputs using an oscilloscope (Vrms measured and power calculated as P (dBm) = 10*log10(Vrms^2/50)+30).   The exact value of the RF signal injected into the Tx/Rx circulator is not known because the signal level is too low to measure, but is estimated from the measured output power of the VNA and the nominal values of the attenuators used, which was ~-66 dBm today.   The measured Rx gains were 51.5, 51.2, and 51.9 dB  for Channels 0, 1, and 2, respectively.   This shows that all three receive channels are functioning in a similar manner, meaning there are no bad components in the chains.   Also, these numbers are comparable to the ~54 dB of gain measured during the SAVANT field project.   Thus, the receivers are deemed to be operational.

Third, the LO out of the RIM box was connected directly to the portable Anritsu spectrum analyzer to check that the RIM functionality was working.   The spectrum is shown in the image below (once I get it uploaded).  The four frequencies seen match the frequencies displayed on the front of RIM box.  RIM functionality is operational.


Next, the length of the HPA Gate signal was adjusted slightly such that the tail of the RF pulse was clipped cleanly as seen in the images below. 

  


A new range calibration was then conducted.  One had been conducted earlier but the test pulse was found to be off by ~300m.   96 counts were added to the Rx Delay to compensate for the 96 counts added to the Tx Delay earlier this week (which allows time for the RIM frequencies to fully switch before the Tx pulse is generated).    The range test pulse is now centered in the 3073m gate.

Finally, Bill experimented with different starting range gate heights to determine how low the profiler can see.  Because pulse coding is used, once the first gate picks up some of the Tx pulse, it is carried forward into the next several gates by the processing.  It was determined that setting the first gate to 200m above the ground was a good level.    

Images of the configurations screens for the SWEX profile are shown below for reference.

    


During setup it was found that the markers for the 449 antenna panel clamps were off, except for one section. Using the measurements from this section we were able to correctly figure out the placements for the clamps. Once the panels and clamps were installed the colored tape indicators were replaced. Below is a diagram showing where the clamps should be placed as well and the geometry of the 449 frame. Starting from the yellow corner (A) and going clockwise the clamps should be placed at approx. 3'10 1/2" from each intersection. 






For SWEX the 449 Profiler is orientated such that the E-field points towards the red corner which is in the direction of the ISS trailer, pictured below. Johns simulations of the profiler helped in determining the best placement.

CH 0RedPanel 0Front End #0
CH 1YellowPanel 6Front End #4
CH 2GreenPanel 4

Front End #6