Since debug is apparently not supported yet, it will be darn near impossible to tune any type of autonomous routines, P, or PID controllers with the new Vexnet 2.0 keys until this is implemented.
Once we install the new keys, can you swap out to the old keys to debug the robot just between power cycles? Or will you have to forcibly downgrade the firmware with the Vexnet 1.0 keys using the firmware utility and then with the new keys re-flash the firmware for Vexnet 2.0?
We’re on Robot C v4.06 if that helps. Is that the correct firmware for the new keys?
Maybe a serially hooked up Arduino with Xbee or a memory card will be needed instead. (not ideal)
I tried master firmware V4 last night and it works with VEXnet 1.0, this was already explained by VEX.
ROBOTC V3.62 and V4.06 should (will) both work with master firmware V4, they will complain in the software inspection window that an older version is needed but you can ignore that.
I did some preliminary tests with ConVEX and so far see no problems (with VEXnet 1.0).
Hi Team80_Giraffes,
I’m sorry for the confusion. Let me try to help clarify.
As was mentioned by others in this thread:
The new 4.0 firmware (and all future versions) will support both the original VEXnet keys and VEXnet 2.0 Keys. The Cortex and VEXnet Joystick will recognize what key is plugged in and communicate appropriately. This should not affect anything else going on, so your programs should run the same either way.
I hope this answers your questions. Let us know if you need anything else.
Do we have an ETA for debug support? Any idea why it isn’t supported? while I don’t have any specific issues with the current key, its still frustrating that updating won’t be feasible for us as a full time solution.
We don’t know but, based on JVNs reply to my questions here, we can start to make some guesses.
John gives us some interesting numbers.
80 simultaneous cortex/joystick “competition” mode links.
264 simultaneous cortex/joystick “pit” mode links.
and some number (24 suggested) of “debug” links.
The 264 number is sort of odd, why not 256 ? 264 is a multiple of 8, as is 80. One method of using RF links is by utilizing time division multiplexing (TDM), lets suppose that 8 cortex/joystick connections share a single RF channel and use TDM. If the update rate (packets sent to cortex and packets returned) is 40 times per second (25mS update rate) then each link would have 3.125mS available to exchange data. In addition to the user data, there will be overhead associated with both the physical and radio parts of the link. At an overall data rate of 500kbit/sec you could probably have 32 bytes of user data flowing in each direction. Now this would be fine for joystick control and cortex status, but that data rate is really quite slow, 40 packets of 32 bytes in each direction, about 12kbit/sec. I would guess that perhaps download and debug did not work due to the slow data rate, the fact that this is now separated into a third connection category with fewer simultaneous links suggests that fewer cortex/joystick pairs will share a single channel and a different style of higher data rate protocol used.
Anyway, I’m really just thinking out loud so could be completely wrong, for all I know it uses frequency hopping like bluetooth or perhaps it’s some flavor of ZigBee.
