Zubax Kucher – Connection Timeout During ESC Initialization

Support
,
1

Hi Zubax Team,
We are currently facing a connection issue with Zubax Kucher while connecting to our Telega/Myxa ESCs. Kucher detects the device and successfully initializes the I/O worker and COM port, and we are able to receive the initial device information. However, during the connection/register initialization process, the connection times out and Kucher reports “Could not connect.”
From the logs, we are seeing errors such as:

  • Register read request ... has timed out
  • Register discovery request at index 261 has timed out
  • ChannelClosedException: Cannot send to the channel because it is not open

The I/O worker starts successfully and the COM port is opened before these failures occur. We have also observed this issue on multiple laptops, while Kucher works normally on other laptops some times.
We have attached three Kucher log files from the failing cases for your analysis. Could you please review the logs and help us identify the likely root cause and the recommended solution?
Thank you.

20260828-151013-11592.log (42.6 KB)

20260829-154226-11052.log (21.5 KB)

20260829-153415-16536.log (22.6 KB)

2

The logs point to a problem in the host-side communication environment. Kucher opens the COM port and receives valid device information. In the 28 August log it also discovers all 312 registers, twice. The failures occur later, at different register reads or during discovery.

The important message is:

Babysitter is exiting normally. IO worker process is alive: False, explicit quit request: False

The host-side I/O process has stopped without an explicit request to close it. The register timeouts and ChannelClosedException then follow; they are consequences of the closed communication channel, not evidence that the named registers are faulty.

In three attempts where the worker’s own shutdown timestamp is available, it stops approximately 10.7–11.2 seconds after opening the port. POPCOP has a 10-second watchdog for communication from the parent application. This makes a stalled host process or inter-process communication a particularly useful lead. The watchdog’s diagnostic is written to standard error rather than the regular log, so the attached files do not conclusively identify that mechanism.

Please try the following:

  1. Compare a failing laptop with a known-working laptop, keeping the ESC, power supply, USB cable and Kucher build unchanged. A native Linux installation or live Linux session is also a useful control. Avoid virtual machines, USB-over-IP and USB redirection during this test.
  2. Close Kucher and any other serial-port applications, then check Task Manager for leftover Kucher/Python processes before starting one fresh instance. Keep the laptop awake, connect its power supply and close heavy background workloads during initialization.
  3. Check Windows Security Protection History, corporate endpoint-security logs and Windows application events around the failure time. Ask your IT team to check whether Kucher’s child processes, temporary executable files or inter-process communication are being blocked or suspended. The packaged application extracts into a temporary _MEI... directory. If an interference event is found, use a targeted application exception; there is no need to disable protection system-wide.
  4. Connect directly to a laptop USB port with a known-good short data cable, without a hub or dock. If Windows records USB disconnect/reconnect events, compare another port and have IT check the USB/chipset driver and power-management settings. Temporarily disabling USB selective suspend or the relevant USB hub’s power-saving option can help isolate that cause.
  5. The No module named 'psutil' line is not a fatal startup error: it means the optional process-priority adjustment was unavailable. If testing your source build, install psutil in the same Python environment that runs Kucher, then repeat the test. Installing it into an unrelated system Python will not change a packaged Kucher executable.
  6. Capture standard error as well as the application log. From the Kucher source directory, with the source build’s Python environment activated, run python zubax-kucher --debug > kucher-console.txt 2>&1, reproduce the failure, and retain that console file together with the corresponding Kucher log. Look specifically for POPCOP IO WORKER: MASTER HEARTBEAT TIMEOUT. Please also record the Windows version, Kucher build and whether the same test works on the control laptop.

An ESC parameter reset or firmware reflash is not the appropriate first troubleshooting step for this host-process shutdown.

3

Hi Mammoth,
Thanks for your response.

We have worked on your test case explained above, these are the findings from the test case.

  1. We used direct and short length USB cable to connect ESC instead of using Hub.
  2. While running the 6th point of your explanation and command, we could not found any Master Heartbeat timeout. For this we are attaching the logs for your reference.
    3.Please find the console after we executed the command.

kucher-console.txt (20.3 KB)

4

The new log shows the PC’s I/O worker stopping before Kucher can request the device information:

16:00:46.899  Started IO worker process with PID 15780
16:01:12.904  IO worker process with PID 15780 initialized successfully
16:01:12.906  IO worker process is alive: False, explicit quit request: False

There is a 26-second delay, then the worker is already dead when Kucher tries to use it. The “initialized successfully” message means the parent received a startup acknowledgement; it doesn’t mean the process remained alive. This is different from an ESC failing to answer a register request.

The file contains no heartbeat-timeout message. My earlier watchdog explanation remains unconfirmed.

There is also a capture issue: the _MEI112162 package path shows this run used the packaged Windows executable, not the source version. There are no DEBUG entries either. The Windows executable is built without a console, so redirecting its output is not a reliable way to collect the child process’s standard error. I should have explained that distinction more clearly.

Please try these next steps:

  1. On the affected laptop, run from the Kucher source checkout, with its Python environment and dependencies installed. Close other Kucher instances. From that checkout’s directory, use Command Prompt (cmd.exe):

    python -u zubax-kucher --debug > kucher-console.txt 2>&1

    Connect once, wait for the error, then close Kucher before attaching the output. The new file should contain DEBUG entries and a package path pointing to the checkout, not _MEI.... If setup or launch fails, send that error instead.

  2. Ask IT to check Windows Application events and endpoint-security history around 16:00:47–16:01:13 on 9 September, using the laptop’s clock. The worker PID in this attempt was 15780. Look for a process crash, termination or suspension; please include any recorded exception or exit code. Don’t disable security protection globally.

  3. Repeat with the same ESC, power supply and short USB cable on a known-working laptop, using the same Kucher version. Please include the Windows versions and whether the source run works on the affected laptop. That will help separate a packaged-executable problem from a wider host/driver issue.

There is no reason in this capture to reset ESC parameters or reflash firmware.

5

Hi Mammoth,

As per your instructions we tried the steps to execute kucher through cmd.

it worked in one of the laptop, whereas it does not work in another laptop.
here i am attaching the console for your reference of both the laptops.

kucher-console_not working.txt (64.1 KB)

kucher-console_working.txt (1.3 MB)

6

The new capture confirms the host-heartbeat timeout:

POPCOP IO WORKER: MASTER HEARTBEAT TIMEOUT

The difference between the laptops is the COM-port scan. On the failing laptop, PortDiscoverer.get_ports repeatedly takes 25.625–25.688 seconds. On the working laptop it reports 0.000 seconds, and the same ESC successfully returns all 312 registers.

In the failing attempt, the ESC initially answers normally. The next port scan blocks the application for about 25.6 seconds; during that pause, the I/O worker stops after missing its parent application’s heartbeat for 10 seconds. This is a PC-side interruption, not an ESC failing to answer.

The first suspect is the four “Standard Serial over Bluetooth link” ports: COM3, COM4, COM24 and COM25. Kucher checks every port with Qt’s isBusy(), which on Windows actually attempts to open the port. A Bluetooth serial connection can delay that call. The logs identify the long scan, but don’t yet establish which individual port or driver causes it.

Since you now have Kucher running from source, try this on the failing laptop. Close Kucher and open:

kucher/view/main_window/device_management_widget/port_discoverer.py

Comment out this one line by putting # before it:

ports = filter(lambda pi: not pi.isBusy(), ports)

Leave the rest unchanged, then run the same debug command and select the ESC’s USB port, COM21 in this capture. Close other applications using that port. This test skips the port-opening probes; occupied ports may remain in the list, but opening the selected port still reports an error if another application owns it. It does not change the watchdog or the ESC firmware.

If this removes the delay, the Windows-side follow-up is to disable unused Bluetooth serial ports under Device Manager → Ports (COM & LPT), then restore the commented line and repeat. Disable only those unused Bluetooth COM entries, not the ESC’s USB Serial Device. Your IT team can then check the Bluetooth driver or stale serial-port assignments.

Please report the new get_ports duration and whether register discovery completes. If the scan remains slow with the line commented out, attach that debug log; the delay is then elsewhere in port enumeration.