I’m wondering if anyone has identified a toolset to use to test the Vex keys?
The idea of testing pairs by process of elimination doesn’t seem to solve the issue as it seems as though many keys fail intermittently. So, I’m hoping someone has seem a device that a pair of keys can be plugged into and you can see what’s going on between them.
I keep purchasing new Vex Keys for each meet since my teams keep running across this issue and they are getting expensive. We are treating them like robins eggs (carrying them in foam padded boxes, handing them with extreme care, static bracelets, etc.).
If you know of one that works, you can test them yourself one at a time by pairing them to the defiantly good one, and finding out which have connection issues. Of course this can be difficult if they only sometimes work like you said.
If you think some of your keys are bad, you can send them back to Vex to have them tested and replaced.
I’ve tried the “check pairs” solution. It eliminated a couple duds. However, the remaining ones get links - until competition time. They can run for a long time on the competition practice fields, floors, carpeting, etc. But on the completion field, the problems start. Never in the same exact way. but, the link gets lost.
Given my significant investment in Vex keys, I am hoping that I can find some hardware/software I can use to test them myself, rather than having to send them back to vex.
Vex must be using something to test these keys with.
Does anyone know what equipment/software they use to test with?
VEX has tools (code that runs under linux) but they are not publicly available.
I was fighting this issue at the weekend and the problem is not as straightforward as the VEXnet key is either good or bad. For example, I identified one of my keys as bad, I did this by rotating a number of keys through a joystick and allowing it to connect to an already powered and searching cortex. Four keys connected in less than 10 seconds on the first try, one keys takes perhaps 30 seconds to connect after several retries. This key has been giving me trouble for several weeks. I connected this “bad” key to a laptop (running fedora) and it successfully connects to the network at my home. I then tried some linux tools that show signal strength etc. and compared the “bad” key to the “good” keys, couldn’t find any differences, the bad key worked just fine. Tried the key on VEXnet, same disconnect issue, I have no idea what the problem is at this point so gave up. I could debug further but I’ve already got too many projects on the go.
When you plug into the field control system it provides a ground path whereas standalone is, well, standalone. If there’s a 5V power supply available at the field this too can sometimes have an effect on VEXnet performance if you connect it to your joystick.
Try testing with conditions as close as possible to an actual competition.
Bad/good VEXnet keys could be related to how consistent they are. Just a random thought, I have nothing to back this idea up, so don’t rip me apart too much if I’m wrong, but I think the packet loss rates may have something to do with it. Seeing how sensitive the robots are to WiFi interference, the firmware/software is probably not very robust, so a higher packet loss rate could cause disconnect issues not present when testing on a computer.
Thanks for the feedback. I have been doing some research. I’m thinking of opening a dud vex key and checking all the solder connections with a microscope. I have heard there might be issues with some of the connections (either as made or after some use). I’m not sure this will tell me much. But, the scientific method is the only tool I have to test the theory. I’ll let you know what I find. I don’t think I can capture pics of cold solder connections or cracked connections. But, if I find any - I’ll see what I can do.
That key was almost completely dead, didn’t even work on a PC unless you pushed on the main RT73 chip, a bad solder joint underneath the BGA. The USB connector solder joints do look a bit iffy on the key in the linked photo but were actually quite sound, I notice the board was version 1.1, I wonder if there are other versions around.
If your club hosts competitions, you may want to consider setting up a Tournament Manager tournament with all of the competition electronics to get as realistic as possible. I’ve found that sometimes a competition switch doesn’t cut it - although it should theoretically.
This seems obvious in retrospect, taking good care of your keys is vital!
Using the field control system forces VEXnet to use channel 1, usually VEXnet selects between channel 6 and 11, I guess it is possible that a VEXnet key could have different performance on different channels.
Looks like I may need to drag the new spectrum analyzer we just bought home and see if I can figure this out.
Both are important insights. Thank you for sharing them. Our school does not host. But I bought the tournament manager and field control setup from Vex yesterday.
It arrives tomorrow. So, this weekend we will be running the bots in our basement under as close to competition conditions as we can recreate. Hopefully, we can isolate the issue.
I’m now also looking into static field generation, testing, and abatement to see if that might also be a variable to manage. I tend to think this is a red herring, as other bots on the same field were not experiencing the issues as profoundly as our team. Ours was not the only team with the issues we experienced, it just seemed like we drew the biggest bad luck card in our last match.
OK, you have me hooked. What will the spectrum analyzer tell you? I am no engineer, but I got a good night sleep last night:). My humanities curiosity is forcing me to learn more about basic science - funny how that is working out.
Also, how would you hook it up? Would it be reading the spectrum that is being wirelessly broadcast by the key or is it reading the data after the key receives it and brings it through the male USB into the brain or controller?
Also, how do I tell which channel vexnet is using? Is that something my programmer can tell me by hooking up his laptop to the bot? Or is it something I need another piece of hardware to determine?
I know these probably seem like basic questions to you, but I am woefully ignorant and am trying to learn as fast as I can. Thanks for your help.
It allows analysis of the transmitted power at a range of frequencies. 803.11g (VEXnet WiFi) is working in the 2.4GHz band which is rather crowded. The spectrum analyzer may not really show anything useful as there’s going to be many other devices using the same spectrum.
In simple terms, an antenna is used to collect the signal that is then input to the analyzer. The analyzer has a display much like an oscilloscope but the x-axis is the frequency domain rather than time. They are difficult pieces of equipment to use and not something I have much experience with so it would just be an experiment to see what happens really.
You need a WiFi sniffer (could be software on a laptop) that can detect the ad-hoc network that VEXnet sets up between joystick and cortex. I’m not going to go into details on how to set all that up on the forums, there are many legitimate uses for this but also some that are questionable.
VEXnet isn’t something that you should really need to know much about, it should be plug and play and for the most part it is. Your VEXnet problems may not be bad keys, I once had a cordless phone that would kill any WiFi network in range.
So if the tournament manager wants you all on channel 1, can it get crowded with a 4 field tournament running fairly close together (like a gym)? That’s 8 robots on the same channel (OK, most likely scenario is that 4 robots may be in pre-auton not transmitting much while 4 more robots on the other 2 fields are active together). When is it too much?
Does Vexnet scan the channel to see if it works and move on or just pick one it deems OK and then try the next one?
Perhaps, but it’s better that competition robots are on their own channel rather than sharing with the other xx robots that are practicing or uploading code.
The state of the user code makes no difference as far as I know. Once the link is active I imagine data rate stays the same, the only difference that I see is that if your code was sending lots of data to the PC via a printToScreen function or something like that, the data is disabled unless the cortex receives a command from the PC.
I don’t know, there was a time when I did start reverse engineering VEXnet, I sort of figured out how the ad-hoc networks were setup and a small part of the protocol, but I refocused my energy elsewhere as there’s not much that could be done with the knowledge.
Well, my company has one of those crazy “use it or lose it” policies regarding capital spending and we were offered a good deal on a demo unit. It’s not something we even really wanted (long story) so we bought what’s called a mixed domain oscilloscope rather than a dedicated spectrum analyzer. It was still somewhere around $35k even as a demo unit.
I just got an email that states the Vex announced today a replacement vexnet key. It will be out in January and should address lots of this WiFi communications stuff.
As jPearman said. Vexnet should be plug and play and we shouldn’t have to worry about it working. Truer words have not been spoken. Unfortunately, until the new keys a re proven to work, I think we are all stuck trying to solve for the issues we experience. Hopefully, the new keys will resolve these issues and we can all get to focusing on mechanical engineering and learning how to write programming.