station:

The LMA station name:
lma_cChickasha SE
lma_dDutton
lma_eEl Reno
lma_gGoldsby
lma_hChickasha N
lma_iMinco SE
lma_mMiddleberg
lma_nNewcastle
lma_oOklahoma City
lma_wMinco West
lma_yYukon

sdate:

The Linux system date, from the BIOS clock. Not really very important, but good to know. The clocks on these CPU boards seem to be very inaccurate, they run slow (by about 5-10 minutes/day) so it's a good idea to set them from time to time. On the stations themselves, there is a program to set the clock via the GPS: "/home/lma/bin/gps/set_sysc /dev/ttyS1" would do it (this is done every day via a cron process spawned from lma_energy, so shouldn't need to be done manually anymore). The ONLY thing that the actual system time matters for is that when a data file is created, its initial name is based on the system date and time; when the file is completed, though, it gets renamed based on the actual starting time in the data file. (Update -- this is not done anymore, the data handler itself names them based on the actual starting time of the data.) As for setting system times on the routers, lma_g is setup to be an rdate server, so you could set lma_g's time with the above, and then on a router (because they don't have GPS receivers on them) you could do a "rdate -s lma_g" to keep them in sync. (Also done via daily cron these days.)

stime:

The Linux system time, see the babbling above, same deal.

load:

The system load. x/y/z minute load average. x = 1 minute average, y = 5 minute average, z = 15 minute average. Unless doing something major, these numbers should all be much less than unity. (The one minute one might vary a bit, but for sure, you should generally see the 15 minute average be very close to zero, or else there may be a process consuming too much of the CPU.)

uptime:

The amount of time since the last reboot, usually in days, if no days label, it's in hours or minutes.

/boot

The percent of full capacity for the /boot partition if there is one.

/:

The percent of full capacity for the / partition. (/ is where the core OS is located.) Should always be in the neighborhood of 35-40%. LMA data gets stored on separate partitions (see below).

/:

The percent of full capacity for the /var partition. (/var is where the linux log files are located.) Should always be less than 60%. LMA data gets stored on separate partitions (see below).

tmpfs

The percent of full capacity for the tmpfs filesystem if there is one.

/dev/shm

The percent of full capacity for the /dev/shm filesystem if there is one present.

/usr:

The percent of full capacity for the /usr partition. (/usr is where the bulk of the system programs etc. are located.) Should always be in the neighborhood of 35-40%, basically, this value will never change.

/data0:

The percent of full capacity for the /data0 partition. This is the primary data partition for the non-removable hard-disk. Right now it is where the initial data is written to, and then copies should be made to /data1, where /data1 can be retrieved and archived, once data is archived safely, the /data0 partition can be cleared.

/data1:

The percent of full capacity for the /data1 partition. This is the primary data partition for the removable hard-disk.

hdaT:

The current temperature (Celsius) of the primary hard-drive.

hdbT:

The current temperature (Celsius) of the secondary hard-drive.

PID:

This is the process ID for the lma_DataHandler program (the program which actually collects data from the LMA board, and writes it to disk). If there's a number there, then it is running. If there isn't a number, there is a problem. Note, no checking is done to ensure that only one process is running, so this isn't a perfect test, but if there's a number there, and the rest of the other things below are okay, we are golden. Also, this number is good to know, because to shutdown the handler program cleanly, you should do a "kill -QUIT pid" where pid is that number. Doing this signals the handler program to quit cleanly, and to rename the current data file based on the time information in the data stream. (Update: don't worry about -QUIT anymore, just kill it if you need to.)

PIDM:

This is the process ID of the lmaMirror program, the daemon which keeps /data0 and /data1 in sync.

pll_h:

This is the high byte of the 16-bit phase count. The top bit (MSB) is actually the lead-lag bit, explained below.

pll_l:

This is the low byte for the phase-lock loop phase count.

pll_c:

This is the count for the phase-lock loop, this value represents the number of 40ns windows we were off from the last GPS pulse per second. This number should generally be less than 10 or so, nominally in the 0-5 range. This number is reported in hex.

pll_ll:

This tells if the phase lock loop was leading (1) or lagging (0) the GPS PPS. (So, a pll_c of 5 with a pll_ll of 1 would mean that our oscillator was 5 'ticks' (5 40ns windows, or 200ns) ahead of the GPS PPS.

pdate:

This is the date, as reported by LMA board. This is coming straight off the GPS, so it damn well better be correct.

ptime:

This is the time, as reported by the LMA board.

temp:

This is the temperature (Celsius) of the LMA board.

RH:

This is the relative humidity (raw uncalibrated scale) at the LMA board.

gps:

The number of satellites being tracked by the GPS receiver, as reported by the LMA board.

current trigfile:

The name of the current trigger log file, for a recent second. (Trigger logs are found in /home/lma/log/.)

trig ID:

The station letter, as reported in the trigger log, for a recent second.

tgps:

The number of satellites being tracked by the GPS receiver, as reported in the trigger log file, for a recent second.

tdate:

The date, as reported in the trigger log file, for a recent second.

ttime:

The time, are reported in the trigger log file, for a recent second.

tver:

The firmware version for the LMA board, as reported in the trigger log file, for a recent second.

tthresh:

The threshold (in hex) of the station, as reported in the trigger log file, for a recent second.

ttemp:

The temperature (Celsius) as reported in the trigger log file, for a recent second.

trh:

The relative humidity (uncalibrated, raw number) as reported in the trigger log file, for a recent second.

ttrigs/s:

The current trigger rate as reported by the trigger log file, for a recent second.

fl/day (0) (-1) (-2)

This is the count of number of data files collected for the current(0), previous(-1), and day before that(-2).

current datafile:

The data file which the lma_DataHandler program is current writing to (assuming it is currently active, otherwise it would be the one last written to).

data ID:

The station letter, as acquired from the current data file, for a recent second.

dgps:

The number of GPS satellites being actively tracked, as reported in the current data file, for a recent second.

ddate:

The date of the status which is being reported on in the current data file, for a recent second.

dtime:

The time of the status which is being reported on in the current data file, for a recent second.

dvers:

The firmware (or LMA) version running on the LMA board.

dthresh:

The threshold of the status which is being reported on in the current data file., for a recent second

dll:

The lead-lag bit for of the status which is being reported on in the current data file, for a recent second.

fifos:

The fifo-status for the status word currently being reported on in the current data file. This is a hex number, 3 bits. 0x7 means the fifos are not empty, are not full, and are less than 1/2 full. Should usually be a 0x7.

dtrigs/s:

The current number of triggers for the second of status being reported on for the current data file, for a recent second.

PLDtrigs/s:

The current number of triggers for the second of status being reported on for the current data file, for a recent second. This should be compared against dtrigs/s, they should be the same. If they are not the same, the LMA board is losing data.

Mon%:

This is the percentage of how much the current data file has not been monotonic in time, most likely the result of phase-lock loss with the GPS receiver. Phase loss is normal, so this only reports as a warning if the monotonicity percentage is greater that 0.5%.

Sync%:

This is the percentage of how many data sync issues are found in the current data file, data is being lost by the LMA board. Data sync loss is not normal, so any value greater than zero is reported as a warning.

/data0 cnt:

The number of LMA data files on the /data0 data partition.

/data1 cnt:

The number of LMA data files on the /data1 data partition/drive.

fc mo:

The month which the fifo-check was last performed. Probably corresponds with the last reboot, but it might be a good idea to stop collection every now and then (say once every few weeks?) and check them.

fc day:

The day which the fifo-check was last performed.

fc res:

The result of the fifo-check. 0=problem, 1=success.

bb mo:

The month that the fifos were last configured with the byte-blaster, and put into data collection mode.

bb day:

The day that the byte-blaster was last run.

bb res:

The result of running the byte-blaster, 0=fail, 1=success.

HD errors?

Attempts to detect if there have been recent hard drive errors (searches the log file for the current day only). It's possible that some may be missed, so regular inspection of the actual log file is still recommended.