Intermittent EZ-B Controllers Disconnect Issue

Good info - thanks, Dave. Your tests rule out a lot (FTDI adapters, hub, even the USB-TTL cable present vs removed), which narrows this down. Below I’ll summarize the likely causes left, give a prioritized set of hardware/software tests, and provide two ready-to-run ARC JavaScript scripts you can drop in Script Manager:

• a persistent logger that writes timestamped connection events into a file (so you don’t have to inspect Script Manager), and
• an auto-reconnect + logger that will attempt reconnects and record the outcome.

Before the scripts, quick analysis of what your findings imply

• You swapped adapters/cables and the problem stayed with Connection #0 probably not a single flaky FTDI adapter/cable.
• You swapped/replace EZ-B boards and the problem persisted on index #0 likely NOT a particular EZ-B hardware fault (or at least not the board silicon), but still could be wiring or how that board is powered/connected.
• You switched that EZ-B to WiFi and the disconnect still occurred (and you had physically removed the 3.3V pin) indicates the issue is not exclusively the USBTTL adapter or the VCC on that cable. That points to one of:
  • power supply / wiring problems (intermittent brownouts or poor ground connections affecting that EZ-B specifically),
  • a wiring/connector intermittent (servo power harness, camera plug, ground, or signal wiring),
  • ARC/PC issue that is tied to Connection index #0 (resource or software conflict, other software poking or reconfiguring that index),
  • or a repeated script/skill action in your project that targets index #0 and triggers reconnects (less likely given your tests, but still possible).

Prioritized tests to isolate cause (do these in order)

1. Minimal isolated test (fast, high value)

   • Create a new clean ARC project with only Connection #0 (no other skills/scripts) and connect only to the problematic EZ-B (via WiFi for now). Run it for several hours. If disconnects stop, your original project or another skill is likely causing the problem. If it continues, it’s a hardware/PC-level issue.

2. Power isolation (very likely)

   • Disconnect servos/peripherals from the problematic EZ-B. Power the EZ-B only (no motors/servos/camera). Run long-term. If it stays connected, a servo or peripheral load is likely causing intermittent brownouts.
   • If you have a bench power supply, power that single EZ-B from the bench supply (same voltage) with its own ground, leaving the other EZBs powered as they are. If that cures it, your robot power distribution is suspect (voltage sags, loose connection, bad wiring, ground loop).

3. Swap power harnesses between EZ-Bs

   • Swap the physical power feed/wiring of the problematic EZB with one of the stable EZBs (keep connections otherwise identical). If the problem moves with the harness, it’s wiring/power distribution. If it stays with index #0 (after swapping connectors), it’s either something specific to the EZB slot, the PC, or project.

4. Long-run bench test

   • Put the problematic EZB alone on the bench with only a stable bench supply, run for 24+ hours. If it still disconnects, suspect PC/ARC or network. If stable, suspect robot power/wiring or an intermittent load while in the robot.

5. Windows/PC checks (if hardware tests don’t show the cause)

   • Check Windows Event Viewer (Windows Logs System) at the exact time of disconnects. Look for USB device disconnects or network disconnects. Save those event timestamps.
   • Disable USB selective suspend and allow the PC to keep USB Root Hub powered (you may have already done this but re-check).
   • Set Power Plan to High Performance while testing.
   • Check for other software that may enumerate COM ports or interfere (serial terminals, modem software, virtual COM drivers).
   • If that index always maps to the same physical USB port on your Beelink, try a different backpanel USB port (avoid internal front panel hubs).

6. Connection Diagnostic logs and ARC logging

   • Use the Connection Diagnostic skill and capture verbose logs when the disconnect occurs. Save them and compare with Windows Event Viewer timestamps. Link: https://synthiam.com/Support/Skills/Communication/Connection-Diagnostic?id=16164

7. EMI / cable routing (if cabling runs near motors/power)

   • Re-route the serial/logic cables away from motor power wires. Use shorter, shielded cables if possible. Try a USB isolator (galvanic isolation) if you suspect ground loop or surge.

8. If still unresolved: try a different PC or Linux box

   • Temporarily run the same ARC project on a different Windows machine. If the problem disappears, it’s PC-specific.

Two ready-to-run JavaScript scripts

Notes before pasting:

• Create a folder first (e.g. C:\ARC_Logs). The script will append to files in that folder.
• Replace ControlCommand Connect strings below with the Connect command you use in your project if they differ. (If you paste one of your working ControlCommand lines you currently use for reconnect, I’ll tailor the script exactly.)
• Use Script Manager Add Script JavaScript and paste the code. Use print() to see output in the Script Manager window.

1. Simple timestamped file logger (writes to CSV + appends to Notepad)

• Purpose: permanent file log of connection states for EZB index 0 (change ezbIndex if needed).

// CONFIG
var ezbIndex = 0;
var logFile = "C:\\ARC_Logs\\ezb_connection_log.csv";
var pollMs = 5000; // how often to check (ms)

// helper to log to file + Notepad + Script Manager
function logLine(text){
  var t = (new Date()).toLocaleString();
  var line = t + "," + text;
  File.appendStringLine(logFile, line);
  // Append to Notepad as persistent UI log (Notepad skill must exist)
  ControlCommand("Notepad","AppendTextNewLine", line);
  print(line);
}

// header (only creates file header once)
if (!File.exists(logFile)){
  File.appendStringLine(logFile, "Timestamp,EzBIndex,Status");
}

while(true){
  try{
    var connected = EZB.isConnected(ezbIndex) ? "connected" : "disconnected";
    logLine("EZB" + ezbIndex + "," + connected);
  }catch(e){
    // unexpected script error logged
    logLine("EZB" + ezbIndex + ",error:" + e);
  }
  sleep(pollMs);
}

How to use:

• Let this run in the background. When a disconnect occurs you’ll have an exact timestamped line in C:\ARC_Logs\ezb_connection_log.csv and the Notepad skill. Use those timestamps to compare to Windows Event Viewer or the Connection Diagnostic log.

2. Auto-reconnect + logger (attempts reconnect and records results)

• Purpose: automatically attempt reconnect when disconnected and record whether reconnected succeeded.

// CONFIG
var ezbIndex = 0;
var logFile = "C:\\ARC_Logs\\ezb_autoreconnect_log.csv";
var pollMs = 5000;
var reconnectDelayMs = 1000; // wait after issuing connect

// Note: update this to match the Connect  ControlCommand in your project if different
function connectCommandForIndex(idx){
  // Example pattern used commonly in ARC examples:
  return "Connect" + idx;
}

// logging helper
function logEvent(text){
  var t = (new Date()).toLocaleString();
  var line = t + "," + text;
  File.appendStringLine(logFile, line);
  ControlCommand("Notepad","AppendTextNewLine",line);
  print(line);
}

// ensure header
if (!File.exists(logFile)){
  File.appendStringLine(logFile, "Timestamp,Event");
}

while(true){
  try{
    if (!EZB.isConnected(ezbIndex)){
      logEvent("EZB" + ezbIndex + ",DISCONNECTED - attempting reconnect");
      // Issue the connection command for this connection index
      ControlCommand("Connection", connectCommandForIndex(ezbIndex));
      sleep(reconnectDelayMs);
      if (EZB.isConnected(ezbIndex)){
        logEvent("EZB" + ezbIndex + ",RECONNECTED");
      } else {
        logEvent("EZB" + ezbIndex + ",RECONNECT_FAILED");
      }
    }
  }catch(e){
    logEvent("EZB" + ezbIndex + ",error:" + e);
  }
  sleep(pollMs);
}

Important: Update connectCommandForIndex() if your Connection skill uses a different control name or format to connect. If you paste a working ControlCommand you already use (for example the one you use in your init script), I’ll replace the function with the exact string for you.

What I recommend you run now

1. Start the simple CSV logger (Script A) and run it in the background for a day.
2. When the next disconnect happens, open:
   • the CSV file and copy the timestamped line,
   • Windows Event Viewer System around that timestamp (copy any related events),
   • Connection Diagnostic logs for the same time window (you can copy/paste the verbose trace).
     Post those here and I’ll correlate them and look for patterns (e.g., a device reset, a voltage-related fault, or Windows USB event).

Follow-up questions so I can help more precisely

1. Are servos or other high-current peripherals connected to the EZ-B that is failing? If yes, does a disconnect tend to happen during motion/servo activity or completely randomly at idle?
2. Did the minimal clean ARC project (only that one EZB) reproduce the disconnect? (If you haven’t tried this, please do it next.)
3. Please paste one of your working connect ControlCommand lines that you use manually or in your init script (so I can tailor the automatic reconnect script exactly).
4. ARC version (Help About) and EZ-B firmware version for the problematic board(s).

If you want, I can:

• tailor the reconnect script to use the exact Connect command you currently use, or
• give step-by-step screenshots to capture Event Viewer and Connection Diagnostic logs, or
• suggest a USB isolator or specific model of USB-to-TTL FTDI adapter if you want to re-test with isolation.

Next best step: run the simple logger, capture one disconnect event with Windows Event Viewer and Connection Diagnostic log, paste those timestamps/log snippets here, and I’ll analyze them for the most likely root cause.

interesting.... reviewing the log file i can see the disconnect...

2025/12/08 13:09:57 -05:00C:\Users\Robot Brain\Documents\ARC\My Projects\B9 Robot Control.EZBTCP Comm Error: Unable to read data from the transport connection: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
2025/12/08 13:09:57 -05:00C:\Users\Robot Brain\Documents\ARC\My Projects\B9 Robot Control.EZBSent: 196
2025/12/08 13:09:57 -05:00C:\Users\Robot Brain\Documents\ARC\My Projects\B9 Robot Control.EZBReceived: 0 0
2025/12/08 13:09:57 -05:00C:\Users\Robot Brain\Documents\ARC\My Projects\B9 Robot Control.EZBBytesToExpect: 2
2025/12/08 13:09:57 -05:00C:\Users\Robot Brain\Documents\ARC\My Projects\B9 Robot Control.EZBDisconnected
2025/12/08 13:09:57 -05:00C:\Users\Robot Brain\Documents\ARC\My Projects\B9 Robot Control.EZBTCP Comm Error: Disconnected
2025/12/08 13:09:57 -05:00C:\Users\Robot Brain\Documents\ARC\My Projects\B9 Robot Control.EZBSent: 199
2025/12/08 13:09:57 -05:00C:\Users\Robot Brain\Documents\ARC\My Projects\B9 Robot Control.EZBReceived: 0 0
2025/12/08 13:09:57 -05:00C:\Users\Robot Brain\Documents\ARC\My Projects\B9 Robot Control.EZBBytesToExpect: 2
2025/12/08 13:09:57 -05:00C:\Users\Robot Brain\Documents\ARC\My Projects\B9 Robot Control.EZBDisconnected
2025/12/08 13:09:57 -05:00C:\Users\Robot Brain\Documents\ARC\My Projects\B9 Robot Control.EZBTCP Comm Error: Disconnected
2025/12/08 13:09:57 -05:00C:\Users\Robot Brain\Documents\ARC\My Projects\B9 Robot Control.EZBSent: 196
2025/12/08 13:09:57 -05:00C:\Users\Robot Brain\Documents\ARC\My Projects\B9 Robot Control.EZBReceived: 0 0
2025/12/08 13:09:57 -05:00C:\Users\Robot Brain\Documents\ARC\My Projects\B9 Robot Control.EZBBytesToExpect: 2
2025/12/08 13:09:57 -05:00C:\Users\Robot Brain\Documents\ARC\My Projects\B9 Robot Control.EZBDisconnected
2025/12/08 13:09:57 -05:00C:\Users\Robot Brain\Documents\ARC\My Projects\B9 Robot Control.EZBTCP Comm Error: Disconnected
2025/12/08 13:09:57 -05:00C:\Users\Robot Brain\Documents\ARC\My Projects\B9 Robot Control.EZBSent: 198
2025/12/08 13:09:57 -05:00C:\Users\Robot Brain\Documents\ARC\My Projects\B9 Robot Control.EZBReceived: 0 0
2025/12/08 13:09:57 -05:00C:\Users\Robot Brain\Documents\ARC\My Projects\B9 Robot Control.EZBBytesToExpect: 2
2025/12/08 13:09:57 -05:00C:\Users\Robot Brain\Documents\ARC\My Projects\B9 Robot Control.EZBDisconnected
2025/12/08 13:09:57 -05:00C:\Users\Robot Brain\Documents\ARC\My Projects\B9 Robot Control.EZBTCP Comm Error: Disconnected
2025/12/08 13:09:57 -05:00C:\Users\Robot Brain\Documents\ARC\My Projects\B9 Robot Control.EZBSent: 200
2025/12/08 13:09:57 -05:00C:\Users\Robot Brain\Documents\ARC\My Projects\B9 Robot Control.EZBReceived: 0 0
2025/12/08 13:09:57 -05:00C:\Users\Robot Brain\Documents\ARC\My Projects\B9 Robot Control.EZBBytesToExpect: 2
2025/12/08 13:09:57 -05:00C:\Users\Robot Brain\Documents\ARC\My Projects\B9 Robot Control.EZBDisconnected
2025/12/08 13:09:57 -05:00C:\Users\Robot Brain\Documents\ARC\My Projects\B9 Robot Control.EZBTCP Comm Error: Disconnected
2025/12/08 13:09:57 -05:00C:\Users\Robot Brain\Documents\ARC\My Projects\B9 Robot Control.EZBSent: 203
2025/12/08 13:09:57 -05:00C:\Users\Robot Brain\Documents\ARC\My Projects\B9 Robot Control.EZBReceived: 0 0
2025/12/08 13:09:57 -05:00C:\Users\Robot Brain\Documents\ARC\My Projects\B9 Robot Control.EZBBytesToExpect: 2
2025/12/08 13:09:57 -05:00C:\Users\Robot Brain\Documents\ARC\My Projects\B9 Robot Control.EZBDisconnected
2025/12/08 13:09:57 -05:00C:\Users\Robot Brain\Documents\ARC\My Projects\B9 Robot Control.EZBTCP Comm Error: Disconnected
2025/12/08 13:09:57 -05:00C:\Users\Robot Brain\Documents\ARC\My Projects\B9 Robot Control.EZBSent: 197
2025/12/08 13:09:57 -05:00C:\Users\Robot Brain\Documents\ARC\My Projects\B9 Robot Control.EZBReceived: 0 0
2025/12/08 13:09:57 -05:00C:\Users\Robot Brain\Documents\ARC\My Projects\B9 Robot Control.EZBBytesToExpect: 2
2025/12/08 13:09:57 -05:00C:\Users\Robot Brain\Documents\ARC\My Projects\B9 Robot Control.EZBDisconnected

but essentially that's saying the host disconnected which is "impossible" if the usb is not powering down the port. because the serialport should stay open the entire time. and your log shows a reconnect occurs...

i first wondered if there's another device in a script query that isn't responding - such as  a sabertooth or something. But when that happens, the ezb usually presents a red led and the communication protocol locks up. but in this case, that isn't showing happening. i can see in the log that the port disconnects, but it reconnects...

2025/12/08 13:10:03 -05:00C:\Users\Robot Brain\Documents\ARC\My Projects\B9 Robot Control.EZBAttempting connection on 192.168.4.216:23
2025/12/08 13:10:04 -05:00C:\Users\Robot Brain\Documents\ARC\My Projects\B9 Robot Control.EZBConnected to 192.168.4.216:23
2025/12/08 13:10:04 -05:00C:\Users\Robot Brain\Documents\ARC\My Projects\B9 Robot Control.EZBReports EZB v4 OS With Comm 2

that tells me the ezb doesn't actually get out of command protocol sync - and instead was entirely unaware that there was a disconnection. the disconnection occurs on the Windows OS side. i'm still leaning toward either power saving on windows or an EZB brownout causing a reboot. but even a reboot wouldn't tell windows because the EZB simply restarts and the USB uart hardware device is entirely unaware of that.

Good catch, DJ - that log is the smoking gun. The errors show ARC lost the TCP connection to the EZB (192.168.4.216:23) with the message "Unable to read data from the transport connection", then ARC immediately reconnects. That tells us the disconnect is a network/TCP layer event (host-side or network) rather than an EZB protocol corruption at the servo/command level.

Below is a concise diagnosis and a prioritized set of tests/fixes (with exact steps and quick scripts you can drop into ARC) to isolate and fix the root cause.

What the log means (short)

• ARC’s TCP client to the EZB stopped receiving replies and raised a transport error (socket read timeout or socket closed).
• ARC then reconnected successfully, so the EZB responded after ARC re-established the socket - meaning the device itself didn’t necessarily "lock" the ARC protocol.
• This pattern commonly points to a network/host-side interruption: WiFi driver, AP/router, power-saving, IP conflict, firewall/antivirus, or transient network interference - but we still need to rule out EZB reboots and power issues.

Prioritized checklist (run in order)

1. Continuous ping test (fast - immediately informative)

• From the Beelink, open a Windows CMD and run: ping 192.168.4.216 -t > C:\ARC_Logs\ping_ezb_216.txt
• Let it run until the next disconnect. Compare ping drops with ARC timestamp for the disconnect.
• If ping fails at same time, it’s network-level (WiFi/router/EZB). If ping stays OK while ARC disconnects, that implicates ARC/TCP stack or something closing sockets locally.

2. Disable WiFi power saving on the Beelink (very common cause for mini-PCs)

• Device Manager Network adapters your WiFi adapter Properties Power Management uncheck "Allow the computer to turn off this device to save power".
• Control Panel Power Options Change plan settings Change advanced power settings Wireless Adapter Settings Power Saving Mode Set to "Maximum Performance".
• Also disable USB Selective Suspend (Power Options USB settings USB selective suspend Disabled).
• Reboot and monitor.

3. Check Event Viewer at disconnect time

• Windows Event Viewer Windows Logs System. Filter by time around the disconnect.
• Look for USB, network or TCP related entries and copy them here. They often show driver resets or network adapter issues.

4. Wireshark or TCP capture (if comfortable)

• Capture traffic to/from 192.168.4.216 and look for who sent a TCP FIN or RST, or there were large retransmits/timeouts. If the FIN/RST is from the PC, an app or driver is closing it; if from the EZB, it means the EZB closed the socket. If neither, you’ll see retransmits/timeouts.

5. Test on a different network (quick)

• Temporarily make the EZB connect to a phone hotspot or your phone hotspot and run ARC on the Beelink using the same WiFi (or connect the Beelink to phone hotspot). If disconnects stop, your primary AP/router or WiFi environment is suspect.

6. Try a different NIC or use Ethernet (if possible)

• If the Beelink can use Ethernet, test with wired connection - if stable, the issue is WiFi driver/AP or interference.
• Or try a different USB WiFi adapter (known-good dongle) to rule out the built-in WiFi driver.

7. Static IP / DHCP reservation (remove any IP conflict possibility)

• Give the EZB a static IP in the EZB webserver or set a DHCP reservation on your router for that MAC address.
• Avoid multiple devices ever accidentally using the same IP.

8. Firmware & ARC upgrades / reboot strategy

• Ensure EZB firmware is current: https://synthiam.com/Support/Hardware/EZ-B-v4
• Ensure ARC is up-to-date: https://synthiam.com/Products/ARC
• Reboot the Beelink after driver changes.

9. Router/AP checks

• Check router logs for client disconnects.
• Try changing WiFi channel to avoid interference (especially if many networks are near).
• If you have both 2.4 GHz and 5 GHz, try the other band.

10. If you still suspect power/ground issues

• You already removed the TTL cable and still saw disconnection in WiFi mode - that strongly reduces the chance the USB-TTL VCC or cable is the cause. But if the EZB shares a power rail that could be causing brief reboots, bench test the EZB alone with a reliable bench supply and see if disconnects persist.

Immediate steps I recommend you run now (exact commands & scripts)

1. Run continuous ping and save:

• In Windows CMD on the Beelink: ping 192.168.4.216 -t > C:\ARC_Logs\ping_ezb_216.txt
• Watch for lost packets or timeouts and match the timestamp to the ARC log disconnect.

2. Quick TCP keepalive and logging script to run inside ARC (JavaScript)

• This will poll the EZB webserver and log failures + attempt reconnect. Paste into Script Manager New Script JavaScript. Replace IP if different and ensure folder exists (C:\ARC_Logs).

// EZB TCP monitor + auto-reconnect - edit ip/index as needed
var ezbIP = "192.168.4.216";
var ezbIndex = 0;             // connection slot index for Connect0/Connect1 etc.
var logFile = "C:\\ARC_Logs\\ezb_tcp_monitor.csv";
var pollMs = 5000;
if (!File.exists(logFile)) {
  File.appendStringLine(logFile, "Timestamp,Event");
}

function logLine(txt) {
  var t = (new Date()).toLocaleString();
  var line = t + "," + txt;
  File.appendStringLine(logFile, line);
  ControlCommand("Notepad", "AppendTextNewLine", line);
  print(line);
}

while (true) {
  try {
    // small HTTP GET to EZ-B webserver to test responsiveness
    var resp = Net.hTTPGet("https://"; + ezbIP + "/", 2000);
    if (resp === null || resp.length === 0) {
      logLine("HTTP_EMPTY_RESPONSE," + ezbIP);
    } else {
      // healthy
      //logLine("HTTP_OK," + ezbIP);
    }
  } catch (e) {
    logLine("HTTP_ERROR," + ezbIP + "," + e);
    // try reconnecting if EZB connection is down
    try {
      if (!EZB.isConnected(ezbIndex)) {
        logLine("ARC:EZB_not_connected_attemptingConnect" + ezbIndex);
        ControlCommand("Connection", "Connect" + ezbIndex);
        sleep(1200);
        if (EZB.isConnected(ezbIndex)) logLine("ARC:Reconnected_" + ezbIndex);
        else logLine("ARC:ReconnectFailed_" + ezbIndex);
      }
    } catch (re) {
      logLine("ARC:ReconnectAttemptError," + re);
    }
  }
  sleep(pollMs);
}

3. Run Netstat at the time of failure

• When a disconnect happens, on the Beelink CMD run: netstat -ano | findstr :23
• See if the TCP connection disappears or if there’s a TIME_WAIT/FIN/RESET state. Capture the output.

4. Collect evidence

• The next time a disconnect happens, copy:
  1. The ping_ezb_216.txt around that timestamp (a few lines before/after).
  2. The ARC log lines (you already have good samples).
  3. Event Viewer System entries for that timestamp.
  4. Output of netstat -ano | findstr :23 at that timestamp (if possible).

Share those and I’ll correlate exactly whether the socket is being reset by the PC, the EZB, or network layer.

Other useful hints & recommendations

• Try binding ARC to the EZB using a static IP or DHCP reservation; avoids occasional DHCP reassignments.
• If you suspect Beelink WiFi driver instability - test on a second PC or rent/borrow a small laptop for an hour to reproduce. If stable on another PC, it’s the Beelink drivers or OS settings.
• If you want to remove TCP entirely for a test: use a direct serial (USB-TTL) connection for a long run (you already tried this earlier, but try again with direct port and no hub). If both TTL and WiFi tests disconnect on the same index when connected to the same EZB device, that suggests something project/ARC-index-specific (rare) - but earlier you said switching adapters and boards didn’t help, so this is likely NIC/AP/driver related.
• Update the Beelink drivers (WiFi & chipset) from Beelink or Intel/Realtek vendor pages.

Follow-ups I need from you (so I can target advice)

1. What ARC version (Help About) and EZB firmware version are you running?
2. Router/AP make/model and whether EZB & Beelink are on the same SSID/band (2.4GHz vs 5GHz).
3. After you run the ping + ARC monitor script above, paste the ping snippet and the new log lines from the monitor when the next disconnect occurs.
4. Any Event Viewer messages (copy/paste the System log entries around the disconnect).

If you want, I’ll:

• Analyze the next batch of ping + ARC logs and Event Viewer lines and point to the exact layer causing resets.
• Provide a tailored netsh/Wireshark capture guide and a short PowerShell command to automatically capture netstat at the moment of disconnect.

Which of the above tests will you run first? If you like, start with the ping (A) + the ARC monitor script (B) and post the results/timestamps - I’ll analyze them immediately.

@DJ,

Thanks for looking into this on your side.

Yes, you're correct. The EZB reconnects. This is because I have a script that loops every 30 seconds that checks the connection status of the three connected EZBs on my robot (Connection numbers 0,1 & 2). When it sees that one of them are disconnected, in this case conection 0, the script will automatically reconnect it.

When I lose the connection on 0 all either I or the script monitoring the connection has to do is cluck the connection button in the connection skill. I do not have to reboot the EZB like I've had to do in the past when a bad serial command is sent to something like a Sabertooth. The connection is just initiated once lost and the EZB connects. No EZB reboot needed.

As mentioned, this happens on connection 0 if the EZB in USB connection mode or if I physically remove the USB to serial converter cable and disable WIFI in the EZB interface and communicate over WIFI.

I've disabled all power saving settings in the Win 11 OS (In Power Options and in Device Manager), disabled Selective Suspend and turned down the baud rate on all Win Com ports, in ARC and the EZB to 9600.

I've also replaced two of the three EZBs and rerouted power cables away from the signal cables the best I could.

I'm down to power or ground issues. All EZBs are getting 12vcd.

I do have some servos and a Kangaroo 2x motor controller connected to this problem EZB that are powered from a different AC to DC Power supply then this EZB is. Maybe a neutral / ground problem? I'm thinking of trying to run a jumper from the ground pins of the problem EZB to the ground pins of another EZB close by, or maybe connect the DC neutrials of both AC to DC power supplies togather.  Shot in the dark.

In addition, When the connection 0 is lost the EZB does not seem to reboot. I've been near the robot when the connection is lost and I do not hear the startup chimes like I do when the robot first starts up and powers up the EZBs. When configured for WIFI connection I do not hear the announcement that the EZB is connected to my Network. I can simply click the Connection 0 button in ARC and ARC will reconnect to the EZB and everything will work.

Furthermore, ARC is aware that there is no connection when it drops. The Connection 0 button in the Connection Skill in ARC goes dark and then shows the word Connect on it. Like I mentioned, I then click it to reconnect (or the script watching the connection will reconnect). The button will then show that the connection is made.

arc is aware because it times out receiving a response from a command, not because it detects a disconnection. although i'm confused becuase we're switching between discussing tcp wifi and usb/uart. this conversation started with usb/uart so if it is changing to a new connection type, it should be a new thread. let me know.

Thanks - good detective work so far, Dave. You’ve narrowed a lot of variables out (FTDI, cables, boards, camera pin VCC, power-save settings) and the logs DJ posted are useful: ARC reports a TCP transport read error then immediately reconnects successfully. That pattern means ARC’s TCP socket lost contact at the network/host layer (not a firmware/protocol corruption on the EZ-B), and since you don’t hear EZ-B startup chimes the EZ-B is usually not rebooting. That keeps a few likely suspects:

• Host / network TCP interruption (WiFi driver, AP/router, IP conflict, or Beelink interruption).
• A Windows/ARC socket issue on that connection slot (some process, periodic query or resource exhaustion closing the socket).
• Power/ground noise still possible but less likely because the EZ-B doesn’t reboot and the disconnect happens with both USBTTL and WiFi modes.

Below I’ll give a short prioritized plan, safe grounding/power tips, and two small JavaScript scripts you can drop into ARC to help diagnose and mitigate (keepalive + logging, and an automatic reconnect logger). After you run a few steps please paste the logs and I’ll analyze them.

Prioritized next steps (do in order)

1. Minimal-isolation test (most informative)

• Create a brand-new ARC project that only contains the Connection skill (Connection #0) and nothing else. No other skills or init scripts.
• Connect only the problematic EZ-B (use WiFi first). Let it run for several hours.
  If it stays connected, the original project has something causing the socket interruption. If it still drops, it’s PC/network or EZB environment.

2. Continuous ping + netstat (quick evidence)

• On the Beelink run: ping 192.168.4.216 -t > C:\ARC_Logs\ping_ezb_216.txt (let it run until a disconnect occurs).
• When a disconnect occurs, immediately run: netstat -ano | findstr :23 > C:\ARC_Logs\netstat_23.txt
• Save the ping and netstat outputs and the ARC log timestamps. If ping shows timeouts at the same time as ARC, that’s a network drop. If ping stays clean while ARC sockets drop, it points to something closing the socket on the PC (driver or ARC).

3. Try a different PC or hotspot

• Run the same minimal ARC project on a laptop or other PC. If the problem goes away there, the Beelink is implicated (driver, OS setting, bloatware).
• Alternatively, put EZ-B on a phone hotspot (or connect Beelink to phone hotspot) and run. If stable, the main AP/router is suspect.

4. Check router/AP and DHCP

• Ensure no IP conflicts (assign a static IP to the EZ-B or a DHCP reservation). Avoid duplicate IPs on the network.
• Check router logs for client disconnects around the timestamps.

5. Capture who sent the TCP FIN/RST

• If you can run Wireshark/tshark on the Beelink, capture traffic filtered to the EZ-B IP and inspect whether FIN/RST comes from the PC, router, or the EZ-B. I can help with the exact capture command if you want.

6. Keepalive / heartbeat (workaround + diagnostic)

• Send a small keepalive or HTTP GET to the EZ-B every 15-30s to keep the socket active and to log failures (script below). You already have a 30s monitor - the script below logs more detail and attempts reconnect.

7. Ground/power grounding checks (safety-first)

• Don’t tie AC neutrals from two different AC supplies together - that’s dangerous and unnecessary.
• If you suspect ground differences between separate DC power supplies, connect the DC negative ("-") terminals of the supplies together (common DC ground). Use the DC outputs, not AC neutral. Use a short, heavy gauge jumper from the negative terminal of the problem EZ-B’s supply to the negative terminal of a nearby stable EZ-B’s supply.
• Ensure good star grounding, tight crimps/terminals, and avoid thin stranded jumpers where mechanical vibration may cause intermittent contact.
• Add ferrite chokes on data and power cables and use shielded USB/TTL cables if possible.
• If you want absolute isolation, use a USB isolator or an opto-isolated serial link for the TTL lines.

8. If you still suspect power rail noise

• Power the problem EZ-B from a known-good bench supply (alone) for an extended period. If it stays connected, the in-robot power wiring or motor controller coupling is the culprit.

Safety note: Only connect DC negatives together. Do not tie AC neutrals or earths unless you’re confident of the PSU design and safety - consult your PSU documentation or a qualified electrician.

Scripts to use in ARC (1) Keepalive + detailed logger - poll the EZ-B web server and log successes/failures. Create folder C:\ARC_Logs first.

Paste into Script Manager Add Script JavaScript. This will print to Script Manager and append to file and Notepad skill.

// EZB HTTP keepalive monitor + log
var ezbIP = "192.168.4.216";   // adjust if needed
var ezbIndex = 0;              // ARC connection index
var logFile = "C:\\ARC_Logs\\ezb_keepalive.csv";
var pollMs = 15000;            // 15 seconds

if(!File.exists(logFile)){
  File.appendStringLine(logFile, "Timestamp,Event,Details");
}

function logLine(event, details){
  var t = (new Date()).toLocaleString();
  var line = t + "," + event + "," + (details ? details : "");
  File.appendStringLine(logFile, line);
  // Optional UI; Notepad skill must be added to project
  try{ ControlCommand("Notepad","AppendTextNewLine", line); } catch(e){}
  print(line);
}

while(true){
  try{
    // small HTTP GET to EZ-B webserver to test responsiveness
    var resp = Net.hTTPGet("https://"; + ezbIP + "/", 3000);
    if(resp == null || resp.length == 0){
      logLine("HTTP_EMPTY_RESPONSE", "");
    } else {
      // healthy
      logLine("HTTP_OK", "len:" + resp.length);
    }
  } catch(e){
    logLine("HTTP_ERROR", "" + e);
    // optional auto reconnect attempt if using TCP index
    try{
      if(!EZB.isConnected(ezbIndex)){
        logLine("ARC_ATTEMPT_RECONNECT", "Index:" + ezbIndex);
        ControlCommand("Connection", "Connect" + ezbIndex);
        sleep(1200);
        if(EZB.isConnected(ezbIndex)) logLine("ARC_RECONNECTED", "");
        else logLine("ARC_RECONNECT_FAILED", "");
      }
    } catch(re){}
  }
  sleep(pollMs);
}

(2) Simple connection-event file logger (if you want only connect/disconnect timestamps):

// Simple EZB connection status logger
var ezbIndex = 0;
var logFile = "C:\\ARC_Logs\\ezb_conn_events.csv";
var pollMs = 5000;

if(!File.exists(logFile)){
  File.appendStringLine(logFile, "Timestamp,EzBIndex,Status");
}

while(true){
  try{
    var status = EZB.isConnected(ezbIndex) ? "connected" : "disconnected";
    File.appendStringLine(logFile, (new Date()).toLocaleString() + "," + ezbIndex + "," + status);
  } catch(e){
    File.appendStringLine(logFile, (new Date()).toLocaleString() + "," + ezbIndex + ",error:" + e);
  }
  sleep(pollMs);
}

What to capture next (please paste these if/when the next disconnect happens)

• The keepalive CSV lines around the disconnect time.
• The ping_ezb_216.txt lines around the same timestamp (if you run continuous ping).
• netstat -ano | findstr :23 output at the time of disconnect.
• Any relevant Windows Event Viewer System log entries for that timestamp (copy the entries).
• Confirm whether the minimal project (only Connection #0) reproduced the disconnect.

Follow-up questions for you

1. Did you run the minimal ARC project (only Connection #0)? If so, did the disconnect still occur?
2. Are the Beelink and EZ-B on the same WiFi band (2.4 vs 5 GHz)? Which AP/router model are you using?
3. Do disconnects correlate to any activity (motors/servo motion), or happen while idle?
4. Can you run the keepalive monitor above and paste the log lines for the next disconnect?

If you want, I’ll:

• Analyze ping + keepalive + Event Viewer logs you paste and point to the exact layer (PC, router, or EZ-B).
• Give the exact Wireshark/tshark capture filters and steps to determine which side sent the TCP FIN/RST.
• Recommend a specific USB isolator model and how to wire DC grounds safely for testing.

Which of the above scripts and tests will you try next?