t-rex-iss1: SOFTWARE Messages: 6 Entries..

Doing backup to an external UBS disk.

Tried connecting using firewire (daisy chained to Maddog DVD drive)
but it wasn't recognised.  So disconnected printer from USB port
and plugged in disk there and a Konqueror window popped up.

Backing up (from /data_source directory) using command:
rsync -v -u -r -t * /media/usbdisk/data/miss/data_source/

I replaced the KVH with the one that Lou shipped to us.  After calibrating
it at the Independence Airport, it still doesn't work.  Then at this site
the ingestor went berzerk repeatedly reporting "unexpected data" from the
KVH, so I've just disabled kvh ingest in the configuration.  The profiler
antenna orientation can continue to be measured manually with the compass
and then entered into the radar parameter file navigation script.

Since the satellite internet is never up before the laptop boots, the NTP
startup does not synchronize with its servers.  Restarting the ntpd service
always fixes this, so I just added a crontab entry to restart ntpd every
hour.  That seemed harmless enough.  Here's the crontab line:

30 * * * * /etc/init.d/ntpd restart > /dev/null 2>&1

It might be that ntp would eventually synchronize with the servers and I
just wasn't patient enough to notice.  An easy way to check is to run
ntpq and the 'lpeers' procedure:

[iss@iss1 tklog]$ ntpq
ntpq> lpeers
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 ntp-1.cns.vt.ed 198.82.247.40    2 u   39   64    7  767.470  -13.153  46.794
 ntp-2.cns.vt.ed 198.82.247.40    2 u   37   64   17  790.262   -9.692  26.999
 ntp3.tamu.edu   128.194.254.7    2 u   36   64    7  882.431   -3.500  38.574
 ntp1.tummy.com  132.163.4.101    2 u   34   64    7  784.581  -32.636  43.044
 otc2.psu.edu    18.26.4.105      2 u   36   64    7  854.045   11.158  24.974
 mapr.localdomai .STEP.          16 u    -   64    0    0.000    0.000 4000.00
 iss-mapr.locald .STEP.          16 u    -   64    0    0.000    0.000 4000.00
ntpq>

The script which automatically sets the navigation settings in the POP
radar parameter files now accpets manual overrides of the KVH trailer
bearing and also an altitude.  This makes the following procedure possible
when the KVH is not working:

Read the trailer bearing in degrees from true north (the direction in which
the tongue trailer is pointing).

Stop POP.

Double-click the ruler icon on the left side of the desktop, titled
Navigate Radar Parameters.

This runs a script which prompts for the trailer bearing and the altitude.
The most recent settings will be the defaults.  The altitude (in meters)
can be read from the GPS main screen.

Then allow the script to modify all of the radar par files on the PC and
replace the existing files.

If the KVH is correct, the trailer bearing can be specified as 'auto'.  If
an altitude is not given (ie, it is set to less than zero, like -999), then
the altitude in the par files is not changed, and the correct altitude
must set explicitly with the POP Alt-F3 screen.

NIMA results have not been sent for 3/28 and 3/29, so I came to check on it.

I noticed the gps ingestor (gps_adam) was taking up lots of cpu, 80-90%.
strace showed it looping through select and read: select() was returning that the serial port was ready, but a subsequent read returned 0 bytes:

select(6, [3 5], NULL, NULL, {300, 0})  = 1 (in [5], left {300, 0})
read(5, "", 512)                        = 0
select(6, [3 5], NULL, NULL, {300, 0})  = 1 (in [5], left {300, 0})
read(5, "", 512)                        = 0
...

Restarting the gps appears to have fixed it.  Perhaps this a bug in the edgeport or serial driver.

I then noticed 3 wppp processes running at the same time for the same day, so something got hung up or slowed them down.  I killed all of those and restarted the processing for 3/29.  According to the log for 3/28, a profiler parameter change is preventing that whole day from being processed.

It took about an hour to process one whole day, so I increased NIMA run times to every four hours.

There were old data files from 2/18 with zero length which were causing error log messages in zebra, so I removed them.

Charlie wrote the data_store to a DVD at 7pm Monday March 13 (03Z Mar 14). I will bring this DVD ack to Boulder