[IDD #KUD-512290]: Backup NOAAPort source ?

Hi Jerry, et. al,

Quick follow-up to my comment that the C/N as seen on (one?) your Novra S300N 
is terrible:

I believe it was in the fall of 2014 that we contacted you when fighting our own
NOAAPort ingest problems.  I think that I remember that during those email 
exchanges
someone in the Data Center told us that you were seeing C/Ns in the high 16 
ranges
(I think I remember 16.7, for instance).  If my memory is correct, then it 
would seem
that something significant has changed in your NOAAPort ingest setup.  Exactly 
what
this might be, I can not guess.  I can, however, tell you about a couple of 
things that
we did when revamping our own NOAAPort ingest setup and hope that something 
strikes
a cord with someone there:

- the UCAR NOAAPort dish is an standard installation that was made by the NWS 
for
  COMET a number of years ago

  Because of this we are a bit limited as to what we can tweak at the dish.  
However,
  we did convince the COMET folks that a dish inspection and re-alignment was
  in order.  One of the things that was uncovered by the inspection (by
  a company we use for our GOES-GVAR related dish issues) was a "funky" female 
to
  female connector that was in the signal path and about 15' from the LNB.  The
  connector was taken out, cleaned thoroughly with contact cleaner, re-installed
  and waterproofed as part of the troubleshooting effort.

- The dish-side opening of the LNB mount housing had a plastic cap that 
evidently
  was installed to keep things like paper wasps from building nests in the feed
  horn.  We found that we could improve our C/N by at about a half DB by 
removing
  the cap.  The improvement was much more when water vapor trapped in the volume
  inside the cap condensed to droplets.  We have always been indending to put 
the
  cap back on, but I don't feel good about this given the expected C/N decrease
  and the notion with "don't mess with things when they are working well".

- we also did an inspection of the signal cable (quad shielded RG-6) everwhere
  that it was visible (we did not pull it out of the extensive conduit that
  housed the great majority of its run)

  We found that the cable was in excellent condition, so that we dropped that
  line of investigation.

- I ran a number of tests to see if tweaking the line amplifier connected to
  the signal cable have any effect on number of ingest errors (number of Gap
  messages and accompanying number of missed frames)

  The only thing I found was that I could make things worse, not better.

- we replaced the two Gbps switches that our two Novra S300Ns Ethernet output
  was connected to with much higher quality units

  We found that this had a positive impact on ingest quality (again, #Gaps
  and #missedFrames).

- we stopped interrogating our Novras from multiple machines

  We had been running cron-initiated once-per-minute interrogations of each 
Novra
  S300N by several machines.  Since cron jobs are always kicked off at the
  top of the minute, the effect was that a number of interrogations were being
  run at the same time.  This turned out to be a BIG no-no.  We dropped back
  to interrogating each Novra S300N from a single machine, and with this we
  saw a BIG drop in #Gaps/#missedFrames.

  Stonie Cooper of Planetary Data provided Novra with an ingest test bed
  that they could use to study how well/poorly their firmware was working.
  The result of the investigations was a new version of the firmware (V2R17)
  that supposedly got rid of most of the problems caused by interrogating
  the Novra S300Ns too much.  Our testing did not show much improvement, but,
  then again, we had already worked around the interrogation-induced problem
  by dropping our interrogations back to once-per-minute.

After all of the above, and not due to any additional tweaking, we noticed a
steady improvement in C/N from the high 15s to the high 16s.  The time series
plots I provided in a previous email are pretty representative of what we
have been enjoying for quite some time.  There have been, however, some periods
where the C/N will decrease at least a dB with no apparent reason.  Luckily,
our ingest quality during those periods have remained good, so we didn't worry
about it.

After we had our own NOAAPort ingest "under control" (it is never really under
control), we turned our attention to the installation at LSU/SRCC.  We convinced
the SRCC folks that some changes were needed there, and they moved their
NOAAPort ingest machine to the same building on top of which their dish is
located; replace their ingest machine; upgraded the firmware on their S300N;
and ran their signal cable through conduit.  We would see their ingest go 
through
periods where the total volume of data being successfully ingested and turned
into LDM/IDD products would dive down to the kinds of levels that you
are now experiencing on your two NOAAPort ingest machines, np1 and np2.
Thinking that they had some sort of a TI source on an upper floor of the
building their dish is mounted on, I worked with their system administrator
to run a number of tests to see if anything could be done to firm-up their
ingest.  One of the tests that I asked them to perform was to remove the
signal cable from the LNB and then run a continuity test on their cable.
Unfortunately, or actually fortunately, the person trying to unscrew the
coax connector from the LNB twisted the connection into the LNB and
ruined the unit (a Norsat 3120, I believe).  We sent them a spare that
we had inherited from RAL a number of years ago, and it was installed on
their dish.  After the new LNB was in place, and concurrently with a
technician there paying close attention to grounding their signal run
conduit and dish, their ingest quality became as good, if not better
than ours.  What we took away from the several months worth of troubleshooting
was that their LNB had problems/was failing intermittently, and that
replacing it was the biggest thing in solving their problems.  The
grounding of conduit and dish was also very important, but it was not
the most important thing, replacing the LNB was.

Steve and I just looked at a long term look at the ingest volumes reported
on np1 and np2:

Unidata HomePage
http://www.unidata.ucar.edu

  Data -> Operational IDD Status
  http://rtstats.unidata.ucar.edu/rtstats/

    Cumulative IDD Summary Statistics -> Statistics by Host
    http://rtstats.unidata.ucar.edu/cgi-bin/rtstats/sitesummaryindex

What we think we see is that there was a significant change in the volume being
ingested on both np1 and np2 sometime during the later part of 
February/beginning
of March:

np1.ssec.wisc.edu Cumulative volume summary Graph:
http://rtstats.unidata.ucar.edu/cgi-bin/rtstats/rtstats_summary_volume1?np1.ssec.wisc.edu+GRAPH

np2.ssec.wisc.edu Cumulative volume summary Graph:
http://rtstats.unidata.ucar.edu/cgi-bin/rtstats/rtstats_summary_volume1?np2.ssec.wisc.edu+GRAPH

So, I am of the opinion that your problem is probably being caused by
a problem with your LNB.  I base this comment on two things:

- your C/N used to be in the high 16s

- our experience with the system at LSU/SRCC

If you would like to chat about this, I am available until 5 today at 
303.497.8642.

Cheers,

Tom
--
****************************************************************************
Unidata User Support                                    UCAR Unidata Program
(303) 497-8642                                                 P.O. Box 3000
address@hidden                                   Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage                       http://www.unidata.ucar.edu
****************************************************************************


Ticket Details
===================
Ticket ID: KUD-512290
Department: Support NOAAPORT
Priority: Normal
Status: Closed