Controller Briefly Disconnecting After Upload

VEX V5 Technical Support
1

For over a year, I have had an issue where, immediately after running “build and upload” on PROS while wirelessly uploading through the controller, the controller disconnects from the robot (radio turns solid red and the red disconnect message appears on the controller) for around five seconds, then reconnects. This has happened with different brains, radios, upload cables, controllers, PROS projects, and PROS versions; the only thing that stayed the same is the computer I have used (before and after a software update). This still happens even when the radio is high up, unobstructed, and mounted on rubber links. Sometimes the controller also disconnects when I start uploading code. When the controller disconnects, the brain terminal also disconnects and gives some errors*. I am pretty sure those are the same errors given when I unplug the controller though, so it is probably unrelated to the cause of the disconnect. This problem the same as in Controller Disconnecting (not the main problem in that post, but I mentioned this problem in it too), but it also happens when experimental features are disabled. It really slows down the speed of my programming by forcing me to wait a few seconds after each upload, so if anyone knows the cause of this problem and/or how to fix it, please let me know.

Computer: MacBook Air M1 2020 running macOS Sequoia 15.1.1
PROS version: 4.1.1 with CLI 3.5.4, but the problem also occurred in PROS 3
VSCode version 1.96.4 (Universal)
“Upload: Action After Upload” is set to Display Program Screen.

* (errors in the brain terminal when controller disconnects) 
ERROR - pros.serial.terminal.terminal:reader - Couldn't find the response header in the device response after 2.0 s. Got  but was expecting aa55 - pros-cli version:3.5.4
  File "pros/serial/devices/vex/vex_device.py", line 115, in _txrx_packet
  File "pros/serial/devices/vex/vex_device.py", line 75, in _rx_packet
OSError: Couldn't find the response header in the device response after 2.0 s. Got  but was expecting aa55
WARNING - pros.serial.terminal.terminal:stop - Stopping terminal - pros-cli version:3.5.4
Exception in thread serial-rx-term:
Traceback (most recent call last):
  File "pros/common/utils.py", line 50, in retries_wrapper
  File "pros/serial/devices/vex/v5_device.py", line 871, in user_fifo_read
  File "pros/serial/devices/vex/v5_device.py", line 1018, in _txrx_ext_packet
  File "pros/serial/devices/vex/vex_device.py", line 115, in _txrx_packet
  File "pros/serial/devices/vex/vex_device.py", line 75, in _rx_packet
OSError: Couldn't find the response header in the device response after 2.0 s. Got  but was expecting aa55

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "pros/common/utils.py", line 50, in retries_wrapper
  File "pros/serial/devices/vex/v5_device.py", line 871, in user_fifo_read
  File "pros/serial/devices/vex/v5_device.py", line 1018, in _txrx_ext_packet
  File "pros/serial/devices/vex/vex_device.py", line 115, in _txrx_packet
  File "pros/serial/devices/vex/vex_device.py", line 75, in _rx_packet
OSError: Couldn't find the response header in the device response after 2.0 s. Got  but was expecting aa55

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "pros/common/utils.py", line 50, in retries_wrapper
  File "pros/serial/devices/vex/v5_device.py", line 871, in user_fifo_read
  File "pros/serial/devices/vex/v5_device.py", line 1018, in _txrx_ext_packet
  File "pros/serial/devices/vex/vex_device.py", line 115, in _txrx_packet
  File "pros/serial/devices/vex/vex_device.py", line 75, in _rx_packet
OSError: Couldn't find the response header in the device response after 2.0 s. Got  but was expecting aa55

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "pros/serial/terminal/terminal.py", line 221, in reader
  File "pros/serial/devices/vex/v5_user_device.py", line 39, in read
  File "pros/serial/ports/v5_wireless_port.py", line 29, in read
  File "pros/common/utils.py", line 53, in retries_wrapper
  File "pros/common/utils.py", line 53, in retries_wrapper
  File "pros/common/utils.py", line 53, in retries_wrapper
  File "pros/common/utils.py", line 55, in retries_wrapper
  File "pros/common/utils.py", line 50, in retries_wrapper
  File "pros/serial/devices/vex/v5_device.py", line 871, in user_fifo_read
  File "pros/serial/devices/vex/v5_device.py", line 1018, in _txrx_ext_packet
  File "pros/serial/devices/vex/vex_device.py", line 115, in _txrx_packet
  File "pros/serial/devices/vex/vex_device.py", line 75, in _rx_packet
OSError: Couldn't find the response header in the device response after 2.0 s. Got  but was expecting aa55

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "pros/common/utils.py", line 50, in retries_wrapper
  File "pros/serial/devices/vex/v5_device.py", line 645, in ft_transfer_channel
  File "pros/serial/devices/vex/v5_device.py", line 1018, in _txrx_ext_packet
  File "pros/serial/devices/vex/vex_device.py", line 114, in _txrx_packet
  File "pros/serial/devices/vex/vex_device.py", line 98, in _tx_packet
  File "pros/serial/ports/base_port.py", line 12, in read_all
  File "pros/serial/ports/direct_port.py", line 39, in read
  File "serial/serialutil.py", line 652, in read_all
  File "serial/serialposix.py", line 549, in in_waiting
TypeError: argument must be an int, or have a fileno() method.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "pros/common/utils.py", line 50, in retries_wrapper
  File "pros/serial/devices/vex/v5_device.py", line 645, in ft_transfer_channel
  File "pros/serial/devices/vex/v5_device.py", line 1018, in _txrx_ext_packet
  File "pros/serial/devices/vex/vex_device.py", line 114, in _txrx_packet
  File "pros/serial/devices/vex/vex_device.py", line 98, in _tx_packet
  File "pros/serial/ports/base_port.py", line 12, in read_all
  File "pros/serial/ports/direct_port.py", line 39, in read
  File "serial/serialutil.py", line 652, in read_all
  File "serial/serialposix.py", line 549, in in_waiting
TypeError: argument must be an int, or have a fileno() method.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "pros/common/utils.py", line 50, in retries_wrapper
  File "pros/serial/devices/vex/v5_device.py", line 645, in ft_transfer_channel
  File "pros/serial/devices/vex/v5_device.py", line 1018, in _txrx_ext_packet
  File "pros/serial/devices/vex/vex_device.py", line 114, in _txrx_packet
  File "pros/serial/devices/vex/vex_device.py", line 98, in _tx_packet
  File "pros/serial/ports/base_port.py", line 12, in read_all
  File "pros/serial/ports/direct_port.py", line 39, in read
  File "serial/serialutil.py", line 652, in read_all
  File "serial/serialposix.py", line 549, in in_waiting
TypeError: argument must be an int, or have a fileno() method.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "threading.py", line 1016, in _bootstrap_inner
  File "sentry_sdk/integrations/threading.py", line 99, in run
  File "sentry_sdk/integrations/threading.py", line 94, in _run_old_run_func
  File "sentry_sdk/utils.py", line 1640, in reraise
  File "sentry_sdk/integrations/threading.py", line 92, in _run_old_run_func
  File "threading.py", line 953, in run
  File "pros/serial/terminal/terminal.py", line 248, in reader
  File "pros/serial/terminal/terminal.py", line 289, in stop
  File "pros/serial/devices/generic_device.py", line 9, in destroy
  File "pros/serial/ports/v5_wireless_port.py", line 18, in destroy
  File "pros/serial/devices/vex/v5_device.py", line 214, in __exit__
  File "pros/common/utils.py", line 53, in retries_wrapper
  File "pros/common/utils.py", line 53, in retries_wrapper
  File "pros/common/utils.py", line 53, in retries_wrapper
  File "pros/common/utils.py", line 55, in retries_wrapper
  File "pros/common/utils.py", line 50, in retries_wrapper
  File "pros/serial/devices/vex/v5_device.py", line 645, in ft_transfer_channel
  File "pros/serial/devices/vex/v5_device.py", line 1018, in _txrx_ext_packet
  File "pros/serial/devices/vex/vex_device.py", line 114, in _txrx_packet
  File "pros/serial/devices/vex/vex_device.py", line 98, in _tx_packet
  File "pros/serial/ports/base_port.py", line 12, in read_all
  File "pros/serial/ports/direct_port.py", line 39, in read
  File "serial/serialutil.py", line 652, in read_all
  File "serial/serialposix.py", line 549, in in_waiting
TypeError: argument must be an int, or have a fileno() method.
2

Just sounds like the controller is switching back to a pit channel from a download channel.

5 Likes
3

Thank you for the response. Is there any way to make it take less time? I forgot to mention this, but if I remember correctly (this was 2 years ago), VEXCode didn’t seem to have this problem (same controller, brain, etc). Also, I remember that this didn’t happen until at least a few months after I started using PROS, so that’s why I thought it might be a bug. I don’t really care about it that much though, as it is more of a slight nuisance, but I am just wondering if there is a way to improve the speed of the reconnection.

4

There isn’t, although from my testing, the pros-cli implementation of download channel switching might have some room for improvement regarding waiting for the radio to reconnect after switching. That wouldn’t significantly improve how long you would have to wait, though.

The download channel has significantly more bandwidth than the pit channel, and is much more reliable with regards to how many packets it drops, but the radio will automatically switch back to the pit channel after 10 seconds without USB communication. VEXcode avoids this by constantly keeping the USB connection with the brain open when the editor is running, preventing the radio from timing out. PROS does not do this.

At some point, the bottleneck with upload times will eventually become the actual size of your compiled program, which is where PROS saves you time (mostly…) For larger or more complex projects, hot/cold linking can significantly improve upload times over VEXcode, which opts to reupload your entire program every time.

2 Likes