My kids informed me yesterday that after they updated to firmware v1.0.4, their limit switch no longer work. Their limit switch on legacy ports used to work on 1.0.3 but now the same switch no longer work. They also tested with new limit switch and that didn’t work either.
Basically, firmware 1.0.4 update completely make legacy ports (A through H) useless. This includes limit switch, bumper and even gyro (yes, gyro no longer work too) no longer function.
Is there a way to put back firmware v1.0.3 until the legacy port issue on v1.0.4 is fixed?
This is the report I received from one of our teams…
“Has anyone with a gyro and/or bump switch upgraded to v1.04 yet? (or any other analog sensors) We upgraded today and our bump switch and gyro stopped working. We were able to get the bump switch working by switching it to digital mode in the brain settings. No such luck with the gyro. Seems stuck at -185 degrees regardless of which way we turn the robot.”
yes, everything gets tested. But it’s not practical to test every possible configuration at the same time. I personally tested ADI functionality this last weekend and everything was working ok. I’m testing here now with that configuration and everything is working ok, however, we have found a different configuration of other devices (radio, motor etc.) plugged into a different series of ports is having an impact on ADI performance, we are still studying and will release a workaround and/or a hotfix in the next few hours.
It is not practical to test every possible configuration at the same time, however it IS practical and expected to create testing equipment and programs that are robust enough to detect that some of the most common configurations do not cause failures.
Maybe some equipment which would physically plug in to every port of the device, then systematically use relays to simulate a wide variety of configurations. Then a program with some commands and sensor feed back could verify that most things DO still work. A switch box that will connect a motor with a separate encoder to each of the ports in turn, send a movement command, and verify that the motor moved, for instance.
Robust testing equipment is a vital part of any product development project, hardware or software. This is not being produced by one intern in a shed. This is being produced by an actual company. It is not unreasonable to expect better results than what has been delivered so far with the entire V5 launch.
But then again, wouldn’t MOST companies be on holiday break right now? If you had a firmware issue good luck until after the new year. Looks like this problem is being worked on within hours of being reported.
Nothing special about port 21.
We have tracked down and understand the issue.
For the time being please connect the radio to port 20 and leave port 21 empty. If that’s not convenient due to cabling etc. leave the port after the radio’s port empty. For example, if you connect the radio to port 2 then leave port 3 empty.
When I was laboring in the software world, we tried to do releases on Tuesday mornings. Lots of days to deal with panic, and Monday to get the last-second stuff done. This is also why the deadline for the Online Challenges used to be Tuesday or Wednesday at noon Pacific (not sure what the deadline is these days), because I live on the west coast and wanted to have a whole half-day (as in, from noon to midnight) to assist entrants who were having submission problems, and then the rest of the week to do the same.
I’ve also been having this issue since I have updated to 1.0.4. Changing the radio port has somewhat fixed this issue allowing my gyro to read. However my value is randomly going up by about 1 a second. Any ideas on how to fix