Skip to end of metadata
Go to start of metadata

We visited rsw05 yesterday to get the DSM on the network. This is a viper v1. I logged in on the console, verified still could not ping radio or anything else.

The config says the METEK is in port 5, but actually found it in port 1, even though port 5 still had the cap with the leash. The mote was correct in port 2. USB at 54%.

vio reports ports are off, even though they clearly are on...?

    daq@rsw05:/media/usbdisk/projects/Perdigao/raw_data$ vio 5
0
daq@rsw05:/media/usbdisk/projects/Perdigao/raw_data$ vio 2
0

After Dan climbed the tower to replace the bulgin ethernet cable with a straight ethernet cable, and came down dressing the cables, we finally realized that the ethernet and metek cables had been swapped from the beginning. That makes a lot of sense, since it explains why there was no signal at all on ethernet rather than just bad signal, and why Dan could hear the Metek at the beginning, very loud, but couldn't after I disconnected what I assumed was the ethernet bulgin.

The Setra pressure sensor was not plugged into power, now the a2d pressure measurements look much better.

We plugged the METEK into port 5 and verified that the messages looked good. The Viper-radio link now works over the new ethernet cable, but probably it would have worked over the bulgin ethernet also. Later, from ustar, I ran update, rsync, tinyproxy, and clean-usb playbooks successfully on rsw05. rsw05 has been up since 2017-04-12, probably the last power outage.

Today, there is no METEK data. Looking back for data on port 5 at rsw05, this is the first data file where messages appear and look good, at least at first:

    [daq@ustar raw_data]$ data_stats rsw05_20170415_150215.dat
    2017-04-16,11:47:44|NOTICE|parsing: /home/daq/isfs/projects/Perdigao/ISFS/config/perdigao.xml
    Exception: EOFException: rsw05_20170415_150215.dat: open: EOF
    sensor                              dsm sampid    nsamps |------- start -------|  |------ end -----|    rate minMaxDT(sec) minMaxLen
    rsw05:/dev/gps_pty0                  36     10      6986 2017 04 15 15:02:15.645  04 15 15:59:59.645    2.02  0.135  1.148   51   73
    rsw05:/var/log/chrony/tracking.log   36     15       237 2017 04 15 15:02:26.327  04 15 15:59:52.910    0.07  0.000 16.199  100  100
    rsw05:/dev/ttyS5                     36    100    174737 2017 04 15 15:02:15.771  04 15 15:55:16.049   54.94 -0.005  0.359    2   89
    rsw05:/dev/dmmat_a2d0                36    208     69288 2017 04 15 15:02:15.597  04 15 15:59:59.999   20.00  0.048  0.052    4    4
    rsw05:/dev/ttyS2                     36  32768       693 2017 04 15 15:02:20.421  04 15 15:59:55.402    0.20  0.195  5.695   11   52

But a few minutes later in this file problems appear:

    [daq@ustar raw_data]$ data_dump -i 36,100 rsw05_20170415_150215.dat
|--- date time --------| deltaT len data... 2017 04 15 15:02:15.7711 0 44 M:x = 124 y = 519 z = -38 t = 2218\r\n 2017 04 15 15:02:15.9941 0.223 44 M:x = 125 y = 523 z = -4 t = 2257\r\n 2017 04 15 15:02:16.0165 0.0224 44 M:x = 87 y = 514 z = -2 t = 2248\r\n 2017 04 15 15:02:16.0389 0.0224 44 M:x = 68 y = 535 z = -11 t = 2236\r\n 2017 04 15 15:02:16.0613 0.0224 44 M:x = 122 y = 528 z = -8 t = 2203\r\n 2017 04 15 15:02:16.0837 0.0224 44 M:x = 158 y = 520 z = -7 t = 2191\r\n 2017 04 15 15:02:16.1061 0.0224 44 M:x = 112 y = 511 z = -3 t = 2195\r\n ... 2017 04 15 15:05:47.0883 0.05001 44 M:x = 170 y = 141 z = -46 t = 2119\r\n 2017 04 15 15:05:47.1386 0.05031 44 D:x = 32767 y =-32768 z = 32767 t = 0\r\n 2017 04 15 15:05:47.1611 0.02245 18 E:quality < 10%\r\n 2017 04 15 15:05:47.1698 0.008694 20 E:data lost 40403\r\n 2017 04 15 15:05:47.1883 0.01849 44 M:x = 167 y = 150 z = -43 t = 2114\r\n 2017 04 15 15:05:47.2384 0.05013 44 M:x = 176 y = 154 z = -50 t = 2121\r\n 2017 04 15 15:05:47.2884 0.04997 44 M:x = 170 y = 154 z = -51 t = 2126\r\n 2017 04 15 15:05:47.3450 0.05668 44 M:x = 171 y = 149 z = -48 t = 2116\r\n ...

Then finally it goes berzerk:

    2017 04 15 15:06:26.2324    0.05      44 M:x =    55 y =   175 z =    15 t =  2126\r\n
    2017 04 15 15:06:26.2823 0.04994      44 M:x =    60 y =   177 z =    14 t =  2129\r\n
    2017 04 15 15:06:26.3391 0.05681      44 M:x =    64 y =   181 z =    16 t =  2132\r\n
    2017 04 15 15:06:26.3547 0.01561      89 C:\xbf\xa5\xbf\xb7\xbf\x9d\x95\x95\xbfK\xbf\xa5\xbf\xbf\xbf\xbf\xbf\x95\xbf\x17\xbf\xc5\xbf\xbf\x9b\x9d\xd9\x9f\xe5k~\xc0~\xee\xe8+\xfb\xfb\xfb\xfb\xfb~\xfb~\xa5\xbf\xbb\xbf\xbf\xbf\x9f\xbfK\xbf\xa5\xbf\xbf\xbf\xbf\xbf\x9f\xbfW\xbf\xa5\xbf\xbf\xbf\xbf\xbf\xdb\xe5\xebu\xcb]\x95\xbd\xb7-\x97M\xbf\xa7\r\n
    2017 04 15 15:06:26.4005 0.04579      19 E:unknown symbol\r\n
    2017 04 15 15:06:26.4099 0.009346      44 D:x =    67 y =   182 z =    19 t =  2133\r\n
    2017 04 15 15:06:26.4323 0.02237      89 C:\xbf\xa5\xbf\xbf\xbf\x95\xaf\x9d\xbf\x0b\xbf\xa5\xbf\xbf\xbf\xbf\x9d\x91\xbf\x17\xbf\xa5\xbf\xbf\x9b\x9d\xd9\xdb\xe5\xeby\x8b~ 155 Z"-     5 t!\x1d !\xb210MJ\xa2~~~($"0 Z"-     0 T"-    \r\n
    2017 04 15 15:06:26.4786 0.04634      19 E:unknown symbol\r\n
    2017 04 15 15:06:26.4880 0.009367      44 M:x =    68 y =   183 z =    19 t =  2126\r\n

Occasionally there are still good messages. It stops entirely at 15:55:16. Given the theory that the Metek was plugged into the 24V ethernet port for a few weeks, maybe it burned up? I have no other explanation for this behavior.

I suppose we could try a different port.