Odd behavior with new vexNet keys and firmware

We had a few odd results last weekend with the new firmware that I thought I should inform you about. We started the two day New England regional on Saturday with the black vexNet keys, I think firmware 3.2.8, and easyC (a combination that worked fine for us all year with minimal issues). In the morning we had a few issues disconnecting on the field experienced by many teams and discovered the next day to be caused by a wifi router next to the field, but things generally seemed normal. Later in the day, I was programming the robot, and accidentally disconnected the cord while easyC was downloading code. Because the robot was behaving understandably oddly, I held down the config button for 30 seconds then tried to download the firmware that was previously on the robot, but it would hit an error in all of my many attempts to download firmware 3.2.8 from three different computers. After losing one match (which we thankfully had no chance of winning against the top team), we asked another team for assistance. They couldn’t get it to work with the old firmware, but it had no issue with v4.0. Team 40 (who helped us out) kindly lent us two keys for the competition and we made no effort to change the system that was working for us while we were competing. The new system normally worked fine and never disconnected during a match, but there were these two other issues.

1: Our first match with the new system was fine, and we had a successful robot skills run before our next match. Without changing any of the code on our robot, we went to the next match and had a problem I have never seen before. Our autonomous triggered normally with the competition switch, driving forward as prompted, but not stopping when it should have (and did the other 10 matches that competition) so we were disabled for running into our opponent’s starting tile. While it hadn’t happened before, I guessed some key sensor must not be plugged in, but was really confused when the wheel kept spinning as they counted the score after autonomous. We put down our joystick as prompted, but the robot kept driving our opponents into the wall. In case some autonomous function was running, I suggested that we press our disablement joystick button that ends all autonomous functions and disables all motors during teleop, but the reffs suggested we instead turn off our joystick instead. Our robot still kept driving even with the joystick off until a reff switched it off after the match. I don’t know if this is an issue with easyC, the firmware, the competition switch, or vexNet, but as it happened with newly released parts/firmware, I thought it should come to the attention of vex. I should note that we didn’t change anything (download code, change parts…) between our skills run on the competition switch the match and when we tested on a competition switch immediately after the match, and the problem never happened to us again.

2: This is a slightly less obscure problem, but it is a problem none the less so I thought I would add it in as well because it could easily have lost us a qualification to worlds. Often when we tried to download code with easyC (verify system disabled for the new firmware), we would get the confirmation that the code had downloaded, and connect a joystick with all green lights (with or without a competition switch) but no code would run (tele-op or auton). If we tried again it would normally be fine, but the issue was dangerous because there was no indication that there was an issue until you tried to run the robot. This never was an issue in a match, but because our judging interview was behind schedule we didn’t have much time left to run programming skills, we were rushed and didn’t have time / think to test code before our last run. In our first run we accidentally started the robot on the wrong tile, so we got only the 16 points before it turned in the wrong direction when it was supposed to knock down the three large balls. While we were waiting in line for our last run before they closed, I changed one small encoder distance (as I had been used to doing with old firmware) and never tested it, so we connected to the field fine, but our code never ran. This situation was partly my error, but whether it is easyC or the firmware, it has the fatal flaw of being undetectable until it matters and thus it would be appreciated if it were fixed asap.

Sorry for the extremely long post, I just wanted to provide as much information as possible so that people who know the system better than I can get a better idea of what might have caused the issue.