Lesson on the RFSoC handling in KEK testbeam

The DHCP Server (router) PC must be turned on and working before turnning on the RFSoCs
- Once they turned on without the proper IP Address asignment, they are unabled to connect via LAN → We need to have a power cycle (turn off the lack power).
- Linux DHCP server can stop to work for DHCP assignment unexpectedly. It's safe to restart the dhcp service before turn the RFSoCs on (it happened for kea-dhcp4).
Whenever change the host PC handling the RFSoCs, we need to reset their configurations in the babicon, especially the host name (e.g. 192.168.0.3 (QA PC) → 192.168.0.1 (RFSoCDAQ))
ttd can esilly stop working. if the trigger count is not increasing with the proper trigger input, consider reprograming the ttd with its init command in telnet.
gtr stoped working this time. Maybe we just ignore its proper working procedure. But, it didn't ssend the trigger signal even though it blinks the trigger output to the ttd (right red, green led blinks). It might be related to the busy-out from the ttd and busy-in on the gtr
So far, we took the data with a common coincidence electronic by adding the busy-out from the ttd