Today was EOP 1, which is planned to continue directly into IOP 4 tomorrow, leaving me without support from the ISS crew. Fortunately all ISFS systems are functioning reasonably well and today was a light day. Some ongoing issues are summarized below.

  • S5: CSAT ldiag remains at 1 since we raised the tower. I will look for another spare in the Pod tomorrow, as I suspect we need to swap the sonic to fix this issue. I may visit the site tomorrow to visually inspect things.
  • S11: No Vbatt.
  • S16: Bad CO2.
  • S18: According to Nagios the raw_data has not been rsync’d in >7 hrs. It also seems like the usb disk is not being found on the DSM - confirmed by nothing returned by lsu command. It seems like another visit to s18 is in order to reboot the DSM.

4 Comments

  1. Gary Granger

    I rebooted s18 remotely so the usb disk is back, and the rsync should catch up soon.  Apparently it can still happen that the USB card disconnects then immediately reconnects.  Everything comes back, except the usb disk comes back as the next device, /dev/sdb instead of /dev/sda, so the mount attempts by NIDAS fail.  The easiest fix is to reboot it, and usually it's ok to reboot it remotely.  Sorry, I should have noticed this problem and rebooted it sooner.

  2. Matt Paulus AUTHOR

    Thanks Gary. Does this mean we will have no data during that time? For some reason I thought I couldn't reboot remotely, so was going to wait until the morning.

  3. Gary Granger

    It means we will only have whatever data made it over the network to EOL during that time.  From a rudimentary check, it looks like the network data stream is fairly complete:

    [isfs@barolo raw_data]$ data_stats -i 18,-1 -a isfs_20220418_0*
2022-04-18,09:56:27|NOTICE|parsing: /h/eol/isfs/isfs/projects/SWEX/ISFS/config/swex.xml
Exception: EOFException: isfs_20220418_080000.dat.bz2: open: EOF
sensor                            dsm sampid    nsamps |------- start -------|  |------ end -----|    rate  minMaxDT(sec) minMaxLen
s18:/dev/ttyDSM1                   18      8       719 2022 04 18 00:00:05.886  04 18 11:59:05.523    0.02 59.971 119.986 4142 4142
s18:usock::32947                   18     10    216718 2022 04 18 00:00:01.065  04 18 11:59:59.051    5.02  0.000   2.998   32   75
s18:/var/log/chrony/tracking.log   18     18     11694 2022 04 18 00:00:00.602  04 18 11:59:55.979    0.27  0.000  12.002  133  133
s18:/dev/ttyDSM2                   18     20     42930 2022 04 18 00:00:00.818  04 18 11:59:58.844    0.99  0.979   3.006   47   47
s18:/dev/ttyDSM3                   18     22    851361 2022 04 18 00:00:00.287  04 18 11:59:59.850   19.71 -0.704   0.605   17   17
s18:/dev/ttyDSM4                   18     40    858511 2022 04 18 00:00:00.244  04 18 11:59:59.816   19.87 -0.703   0.605   60   60
s18:/dev/ttyPWRMONV                18     60    817757 2022 04 17 23:59:59.830  04 18 11:59:59.899   18.93  0.000   2.000    3   90
s18:/dev/ttyDSM5                   18    100    429225 2022 04 18 00:00:00.302  04 18 11:59:59.769    9.94 -0.698   0.700   32   32
s18:/dev/ttyDSM7                   18   2800     51502 2022 04 18 00:00:03.365  04 18 11:59:59.512    1.19  0.006   5.323   26  107

    These samples will not be available in the netcdf until the network data files are merged with the usb data files.

  4. Steve Oncley

    Another data issue I've noticed is the TP01.s9.  It acts like it is exposed to the air, and has been reporting odd values since it was installed.  I'm sorry I didn't catch this earlier!