I am reaching out to ask a technical question regarding the wireless serial capabilities of the VEXnet system and V5 Controller.
I have been developing a custom path-planning and telemetry architecture called “Ghost OS” using PROS (C++) and a Python-based desktop application. A core feature of this project is Over-The-Air (OTA) path injection, where the Python app dynamically generates spline waypoints and sends them via serial to the robot’s RAM without needing to recompile.
Currently, my architecture works flawlessly when my PC is plugged directly into the V5 Brain’s USB port. The Brain reads the data via fgetc(stdin) and successfully parses our full waypoint strings.
However, we are running into a hard wall when trying to transmit this data wirelessly through the V5 Controller’s USB port. During our testing, we found the following:
The robot can successfully transmit high-frequency telemetry out to the PC via stdoutover the VEXnet radio.
However, sending strings in from the PC to the Brain (stdin) over the VEXnet radio consistently fails, drops packets, or is ignored completely.
We attempted to bypass potential hardware buffer limits by “drip-feeding” the data (sending 16-byte chunks with 20ms+ delays per character and forcing PTY flushes), but the V5 Brain still does not seem to receive the stdindata during runtime.
My questions for the engineering team are:
Does the VEXos firmware intentionally firewall or heavily throttle user stdin over the VEXnet wireless link during runtime to protect driving packets?
If it is supported, is there a specific baud rate, packet size limit, or specific protocol required to reliably send user serial data from the PC → Controller → Brain over the air?
I completely understand if this is a hard limitation to protect the integrity of the wireless control link. I just wanted to consult the experts before I pivot my team’s workflow to exclusively using the direct Brain USB tether for these transfers.
Thank you so much for your time, and thank you for making such a fantastic robotics platform!
I’m following up on some previous discussions regarding the reverse data link over the VEXnet radio. My team is currently building an OTA (Over-The-Air) path injection tool for Ghost OS that sends generated autonomous splines from a Python desktop app to the V5 Brain via stdin over the Controller’s USB port.
The Context & The Problem We’ve successfully bypassed the VEXos line-buffering constraints (using \r\n), but we are hitting a hard wall with radio saturation. If we send standard input into the Controller too quickly, the pros-cli (and the VEXcode terminal) throws the following error and crashes:
VEXCommError: CRC of message didn't match
Additionally, the terminal occasionally echoes truncated strings (e.g., IN;CLEA). It appears that overwhelming the Controller’s USB buffer is causing it to corrupt outbound VEXnet packets heading back to the PC.
Our Current Workaround Taking some previous advice, we aggressively rate-limited the data stream. We are currently dripping 8 bytes every 100ms. This works flawlessly and entirely prevents the CRC crashes! However, it restricts our transfer speeds to roughly ~80 bytes/second, which takes quite a while when transferring larger, dense autonomous routines.
Questions for the engineering team / community:
Buffer Limits: Is there a known hardware buffer limit on the V5 Controller’s USB CDC implementation that causes it to drop or corrupt packets when stdin is saturated?
Alternate Protocols: Are there any alternate protocols (such as raw VEXlink, a dedicated VEXos serial channel, or specific baud rates) that allow for faster PC-to-Brain transmission over the Controller? Or is ~150 bytes/second the absolute physical limit of the reverse radio link?
Any insight into the lower-level VEXos handling of this serial pipe would be hugely appreciated. Thanks for your time!
Not sure what you are looking for here, there is no magic solution.
The V5 controller only has a single serial port, this means that stdio data has to be wrapped and sent as control messages in a similar format to program download and other control messages.
Python desktop app to the V5 Brain
Not sure what you are using here, we provide a solution via VEXcode or the VSCode extension for stdio input and output. PROS has stdio access via their command line utility, that’s all we support.
There are many places that can reduce bandwidth, the USB connection to the controller, internal buffers within the controller moving data to the radio, the over the air communication etc. It’s not optimized for input to the V5, more for output.
perhaps that’s the best you will get.
Not really, VEXlink, which is a VEXnet radio to radio protocol, may achieve at best about 500 bytes/second, that’s about the theoretical max for over the air comms, but it’s not something you can use with a PC.
I had a quick look at this today just to see what I could achieve.
I could easily send an 8k file with no errors at approx 500 bytes/second without issue via the controller. Not sure what type of program you are using to either receive the data at the V5 end or send it from the PC, but I suspect one or other program is causing your issues.
Assuming this isn’t for VEX matches (and that this is a VEX comms issue, which we don’t know yet), you could also use a higher bandwidth wireless microUSB directly from your computer to the brain.
I’ve been doing this wireless with a radio. So my setup is (Computer → Controller → Vex Radio). I do realize PROS can wireless upload programs, but it seems like during runtime we are unable to use that line of events. Directly plugged in it works fine, however the point of that workflow is for OTA and quick autonomous testing. My Solution is to use a HC-05 wireless chip and connect that to the brain via soldering. This would only be allowed outside of tournaments for obvious reasons, but it should be perfectly fine and safe for testing and quickly iterating autons.