Intermittent connection on field only

[RyanN]

Originally Posted by Al Skierkiewicz

Okay Brian,
Since you don't know me or my skill set, let me explain. My real job is troubleshooting electronic failures down to the component level. A position at which I excel. I know that power can be a definitive issue with many problems that exist and I know both how to diagnose those issues, and how to correct them when they fail or are designed improperly. Power supply noise in digital systems is nothing compared to the noise generated in analog audio systems where microphone levels are in the -60 to -90 dBm (that's millwatt for those who are wondering) range, can require as little 4 microamps from the power supply and where noise is considered bad when it is only 20 db above the theoretical noise floor. I have been telling you for weeks that power is not the issue you have deemed it to be but you have failed to believe me or the others in this forum that are trying to get you to accept that fact. While there are problems (and they have yet to be diagnosed), power is not the greatest of these. How can you even think that those people who are researching every possible failure point have not considered looking at the power supply first? So to borrow from others, stop muddying the waters, perform your tests and bring us real data that can be duplicated in the lab or field and actually correlates to failures of the robot wireless link. Until that time I will only respond to others seeking real answers.

Edit:
Now that I have have seen your most recent post, let me assure you that Team 11 is a long time friend and a team I certainly respect. When at competitions, I would work as hard helping them compete as my own team and I expect all my inspectors to also do the same.

I agree with Al here, but I also agree with power being a contributing factor to some teams, but again, as Al pointed out, most teams do start from the ground up in the debugging process.

As I've mentioned many times before...
Team Fusion, at the Bayou Regional, could not run a single full match due to communication problems. Our first suspect was power, and sure enough, we did have a power issue.

The student that purchased the connector for the router purchased one that 'fit' but didn't fit properly, leaving us to have a potentially bad connection. We could pick up and drop, shake, etc... our robot, but it wouldn't drop, but if we put focus to abuse on the router, and picked up, dropped, shook, slammed the router, then we would cause a reset.

That was our first step. We had a spare router, with a spare power cable, so we took the OEM plug and used that. After replacing and gluing the plug in place, we could not brown out the router. We did stress testing to other power components of the router as well, including the 12-to-5 regulator, and the PD board. We replaced the 12-to-5 regulator for comfort, and we hit on the PD board a bit, but could not replicate the issue.

And again, as the title of this thread mentions, the teams with this issue had a "Intermittent connection on (the) field only." We worked great in the pits, on the practice field, during kickoff, practicing at home with our router, everywhere, but the dang Bayou field.

The only thing the FTA would tell us is that it was a robot problem. No specifics on what is failing, or why, just that it was an individual problem with us.

Here are the two things I cannot get around:

1. We were the only one at Bayou with this issue.
   
   CRyptonite had a match with us where they dropped out, but after Bayou, I was told that they were experiencing the CAN Autonomous-to-Teleop transition bug.
   
   Prometheus had an issue late Friday, but I think they determined it was an issue with their camera or something...
   
   Combustion had lag, but that was related to high CPU usage on the cRIO.
   
   
2. We packed up our broken robot, kept the same code, etc... to the Lone Star Regional, and pulled out a fully working, functional robot.
   
   The only thing we changed was reconfiguring our router to work with the LSR field. Greg McKaskle worked with us at LSR, but unfortunately for him, but fortunately for us, we never experienced a communication problem at Lone Star.
   

There's something external to the robot with the issue we experienced. With what I saw on Einstein, the issues experienced by all of those teams was the same issue we experienced at the Bayou Regional, a Week 3 regional.

As far as router placement, our original location isn't the best place, and is within a foot of some noisy shooter motors, but we relocated it during Bayou to a better location, obviously not fixing our issue.

As far as code goes... besides the fact that our code didn't change from Bayou and LSR, we went back to the basic framework code, no camera (unplugged), no CAN, no PID, nothing. We simply had solenoid and motor outputs, no sensor inputs at all.

Then comes the driver station. We had been using a Dell purchased this season as the DS, but during all the debugging, we switched to my laptop, a 2010 MacBook Pro (Core i5, 8GB RAM, SSD... a pretty powerful machine), and we kept on having the issues. Finally, when trying out the basic framework code, we switched to the Classmate PC, configured for this year and updated with the latest FRC updates, and no Windows Updates.

Basically, at the end of Bayou, we had a kitbot control system, but still couldn't maintain a connection, even sitting still.

All of this proving, in our case, to me, that this isn't an issue with Team Fusion 364's 2012 Robot, Aiminite. Our issue was not a robot issue. That's all I have concluded from the work I have done diagnosing the issues.

I'm not sure if we were the only one during the regionals to pack up a broken robot and pull out a working robot, but FIRST should look at our case for some good information. Team Fusion has concluded that the issue is not our robot.

Now to the big question that everyone would like to know... what is the issue? No one knows at this point. Everyone is just speculating.

Interference
I've been speculating that the issue is interference from the audience carrying hundreds of smart phones with WiFi enabled... but that even has errors in the hypothesis.

Lone Star had a much larger crowd than was at Bayou. It's much larger event. The Lone Star regional is also held in a bigger city (and actually in the city). Bayou was right next to the river, with just a small road leading up to it, not part of a major city arterie. It seems like LSR had the potential to be worse as far as interference goes. So interference seems to be a non-issue. And why would interference just target us? Things don't add up for this case. What about the WiFi channel used? What does happen with the Dlink is the 2.4GHz is left enabled?

Field Hardware Issues
Again, if it truly was FMS messing it, at Bayou, it would have affected everyone, not just Team Fusion. We had been placed in multiple spots on the field, but we had problems in all of them.

I'll be down on the Coast next week, and can test some things, but I need a list of things to test.

First off, I want to break communication. What can we do to break communication? We'll need to have two routers and use the same system FIRST uses.

I'm curious as to what will happen is we power up two of our robots, with the same IP address and everything. How will the system handle this? If it works, how do our logs look?

Then what happens if we run some noisy equipment next to the 'field' router. Can we run a Skil saw next to it and still maintain connection? How about running a FP motor at full speed next to it? What happens? How do the logs look with this?

Did Bayou have wireless lighting controls? Were their frequencies within the range of our channel provided? I can't tell.

Anyway, I want to help figure out this issue because it really messed us up in Bayou, and we have no explanation as to what happened.