D-link dropping out

[Al Skierkiewicz]

There is a failure mode on the 5 volt convertor that will send 7 volts to the radio on full battery voltage and then as the battery goes down so to does the output of the convertor. It acts just a like a resistor. I believe that the failure mode is caused by a reverse electrical connection at some point. Double check the output voltage of the convertor.
Blackflame, the camera body is connected to the negative lead of the power supply. If you have other frame shorts, it is possible to shutdown the power supplies in the PD as reported by it's designer.

[Peck]

Depending on the model of wireless adapter in use, the proximity of speed controllers to the wireless may have play in the issue. My teem found a few years back that when the speed controllers are running at a high voltage, the EM radiation produced can mess with wireless if the wireless is only a few inches away. An easy way to test to see if this is an issue is getting your wireless as far from your jags as possible (even just duck-taping it at max cord length works). Keep in mind that moving it may also solve other issues.

[MichaelBick]

We were having this problem at LA also. First of all, if you see that your bridge turns off during a match, check the power wire to the bridge, to check for any breaks in the wire. Also, any soldered connections should be resoldered. If this still doesn't work, just replace the whole wire. Also, it could be a problem with the DC to AC converter. If you are getting power to the bridge, but are still having problems, you may want to check your ethernet cable.

[dbarr4011]

We have also been getting D-Link drop outs. During our competition at Traverse City and at Western Michigan District we had several communications drop outs. Our robot was not driving hard and no major current draws on the battery. The Field controls personal said our radio reset. I am questioning this answer because I see the radio takes about 1 minute to power-up and starts its wireless communications. We loss communications for about 40 seconds. After 40 seconds we are off and running again. My thoughts are we having a wireless network access point/network problem on the field control access point. We saw several other teams with the same problem at these two events.

[Peck]

Originally Posted by dbarr4011

We have also been getting D-Link drop outs. During our competition at Traverse City and at Western Michigan District we had several communications drop outs. Our robot was not driving hard and no major current draws on the battery. The Field controls personal said our radio reset. I am questioning this answer because I see the radio takes about 1 minute to power-up and starts its wireless communications. We loss communications for about 40 seconds. After 40 seconds we are off and running again. My thoughts are we having a wireless network access point/network problem on the field control access point. We saw several other teams with the same problem at these two events.

part of getting connection at startup is the c-rio getting started up. It takes less time for a router to just reset since the c-rio isn't starting up again.

[baronep]

I realize that this issue has been resolved but for any other teams that might be experiencing problems:

Last year we had a problem losing communication and it turned out to be a zip-tie that we used to secure our router to the robot was flipping the AP-AUTO-BRIDGE switch, causing the router to power-cycle during a match.

Solution: Remove the Ziptie

[rsisk]

Saw the exact same "zip-tie" problem at LA.

[beiju]

I have a few more obvious-in-retrospect tips for anyone who has problems like this in the future:

Check that you're using the right cable. When FIRST switched from a Linksys to the D-Link, we forgot to make a new cable. The old one almost worked, but didn't fit snugly, so it jiggled out when we drove the robot.

If you have the parts, replace each element in the chain one at a time and see if the problem goes away. We thought we had a problem with the wiring to the signal light, but discovered it was a damaged Digital Sidecar.

[Steven Donow]

We've also been having a bridge issue in our tests, and we think it was solved. Basically, when we'd enable, our robot would keep constantly "losing communication". I say that in quotes, because on the Driver Station of things, it doesn't show that, it still says the robot is enabled, battery voltage still shows, etc... Just we lose split second connection, almost as if our robot is constantly disabling itself, while the DS shows it as enabled. Our compressor basically goes on and off, as do motors and everything. The only errors we were getting on our DS were Watchdog errors, reaching numbers as high as the 200s, and each watchdog error would coincide with "loss of communication"

We swapped out our bridge (both were RevA) and reset it and it seemed to keep working, but this issue just appeared all of a sudden.

[Greg McKaskle]

The watchdog and communications are related, but let me dig a bit deeper in your symptoms.

If your robot loses communications with the DS, the FPGA System watchdog will disable the robot outputs. This is the same as the disable mode of the DS, but the DS doesn't have to send it. Incoming packets allow the robot to be a mode other than disabled. Your Diagnostics should contain a message each time this happens with the total times the FPGA disables it.

If you are using a User watchdog in your code and you don't feed it, your robot will be disabled even though it still has communications. This is useful for debugging code, for runaway code without a runaway robot, etc. The Diagnostic window will get a printout and the User number should be the one that is increasing.

Can you say which was causing your issue?

Greg McKaskle

[helpme]

thanks everyone, i think we must have just set it up wrong.

It worked fine at competition.

[Peck]

Hey, my team had some wireless problems at the CO reg. and After going through every possible solution we (and the volunteers and every person we could think to call) could think of, one of our mentors looked at the detailed info for the wirelesses in the area and found one (completely illegal by competition rules) that was running on the same frequency as the field. After a little searching, we found them (detailed signal strength readings helped a lot) and asked them to turn off their wireless (which they promptly did and apologized for having up). The next match (our first quarter final match), we were fine. It took us Friday and Saturday to get it to run. only reason we got into the elims was a team picking us in hopes that we would be able to beat everyone like we had Thursday even though our drivers had essentially spent 2 days doing no driving (tx for giving us the shot).

some may ask why it was only us, we figured that out fast: our robot had the highest bandwidth usage there thanks to all the live data we were almost constantly pulling.

moral of this story:
1. check to make sure nobody is running wireless in the field area BEFORE you rebuild your robot trying to fix connection issues.

2. Don't make wirelesses and make sure others don't too (the source doesn't madder, wireless hotshots are going to hurt the competition). The rule on not making wireless networks is there for a reason. All those robots use alot of bandwith and any active network can take some away.