The question of VEXnet 2.0 debugging and data rates came up the other day. When VEXnet 2.0 was first released I did some benchmarking to see what upload and download speeds were, a year later I decided to repeat this tests and also see if any other residual issues were left now that firmware has been updated a couple of times. Results were pretty much as before
File transfer to/from cortex using command line flash tool.
to cortex 3154 bytes/sec
from cortex 1088 bytes/sec
The slow upload speed is probably due to long round trip time for packet ack, to get fast downloads I think there may be some cheating going on with acks being generated in the joystick, not going to dig into that any further, there’s no point, it works and that’s all that matters.
So compared to VEXnet 1.0 slightly faster to download the code to the cortex but reading back flash memory (which none of you do anyway) is slower.
With older firmware there was also a problem with the joystick crashing if too much data was sent from the cortex to the PC when debugging. The good news is that it looks like this has been fixed with latest firmware, I’m not going to go back and figure out when but 4.23 master firmware seems more stable.
Just out of interest I was also curious to see what the packet data rate the radios are using. We know the VEXnet key can operate in one of two distinct modes, normal “pit” mode and a special “download” mode. JVN posted information about this last year here.
Announcing VEXnet 2.0 - answers to my questions
This information is still valid. The VEXnet key can choose to use one of 81 available radio channels, 33 channels are reserved for “pit” mode, 8 robots can share a channel so 264 (8 x 33) robots can theoretically be in close proximity and be able to still operate. 12 channels are reserved for “download” mode, when using these only two robots can share a channel so 24 robots can be downloading code at the same time (again, this in the range of the radio signals). Of the remaining 36 channels, 28 are special competition channels and 8 are avoided for some reason.
(The following information is based on certain observations and may not be completely accurate)
In pit mode it looks like the radios communicate approximately every 25mS, data rate to the cortex is about 2500 bytes/second (mostly joystick data, 64 byte packets) and data back from the cortex is about 960 bytes/second (24 byte packets)
In download mode the radios communicate more often with larger packets (118 bytes), somewhere around every 14mS, communication data rate is symmetrical at about 8400 bytes/second. Not all of this bandwidth is available for user payload however.
A quick recap of the information in this thread.
Optimizing the debug stream
Information traveling from user code to the PC has a pretty long path to take.
Over a serial channel at 230K from user to master processors.
USB to the VEXnet radio from the master processor.
wireless between radios.
USB from joystick radio to joystick processor.
Another serial channel at 115k from joystick to the PC serial adapter (usually USB based)
USB into the PC.
It’s actually pretty cool that it works at all.
So we are back to the conclusion I came to two years ago, a good maximum data rate between cortex and PC is about 4K bytes/second. This is where I set the throttling in ConVEX. ConVEX uses some (subjectively) clever data throttling so these links are not overloaded by trying to send too much data to the debug terminal on a PC.
