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 52But 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\nOccasionally 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.