The 2m licor connected to /dev/ttyS2 was removed today.The , and the licors at 16 and 43 meters were reconnected to ports
/dev/ttyS11 ttyS17 and /dev/ttyS17, but we're not sure at this point
which was connected to which port. Perhaps we can query the
serial numbers to determine which is where.
Used
| Code Block |
|---|
(Coef ?) |
ttyS11 by a BEACHON help person at the site.
By checking the serial numbers, with the (Coef ?) command, and comparing against the earlier LICOR log entry, we could determine remotely what unit is connected to what port. Note that the licors at 16 and 43 meters are not in their expected ports; command to determine the serial numbers:
port | height | SN |
|---|---|---|
ttyS2 | removed |
|
ttyS7 | 7m | 1166 |
ttyS11 | either 16 or 43 meters , need to verify | 1164 |
ttyS14 | 30m | 1163 |
ttyS17 | either 16 or 43 meters | 1167 |
The data system from the time the licors on port 11 and 17 were enabled on Dec 2, until the next morning, Dec 3 at 10:26 AM MST was configured in the old way, so the data from the licor on port 17, SN 1167 was given an id of 1,310, and the data from the licor on port 11, SN 1164 was given an id of 1,510. So the licor data at 43 meters and 16 meters is cross-identified during that time period.
Basic 7500 configuration:
...
This resulted in around 400-500 spurious interrupts/sec being reported in /var/log/isfs/kernel. The system is keeping up, top shows an idle value of ~ 70%.
Current Here are the current values from /proc/tty/driver/serial, so it appears that the framing errors are not being generated . The number of framing errors is staying steady at this baud rate.:
| Code Block |
|---|
7: uart:ST16654 port:F1000110 irq:104 tx:1371 rx:1169013368 fe:41917 RTS|DTR 11: uart:ST16654 port:F1000130 irq:104 tx:2133 rx:18900757 fe:21542 RTS|DTR 14: uart:ST16654 port:F1000148 irq:104 tx:1809 rx:590564461 fe:3997 RTS|DTR 17: uart:ST16654 port:F1000160 irq:104 tx:1339 rx:17587617 fe:2321 RTS|DTR |