Re: Team 548 Einstein Statement
 

Brian,

Stop instigating more conflicts. It does not help your cause or your image which reflects back on your reliability as a source of information. Instigation and calling someone out does not help you earn respect from readers.

Eric is right, this thread is for one thing and one thing only. Leave it be.

Sincerely,
Akash

Re: Team 548 Einstein Statement
 

I've offered to exit already repeatedly as I just did and I shall. My image is irrelevant to any point. None of you has the ability to tarnish it with these tactics in any capacity. Just like I hope Team 548 understands that they should never let anyone else tell them who they are or dictate their abilities. I hope they move forward into a bright future.

As to the extra stuff you added the facts are the facts. I did not argue from my authority. I argued based on links and data I provided.
Anyone can not like me all they like but the facts are what the facts are. One can deal with evidence or accept risk.

Re: Team 548 Einstein Statement
 

Brian,
As I pointed out your statements that FIRST and the Einstein weekend experts don't know what the RF levels on the field are simply false. While it is true that logs on the 1252 were not retained from the actual Einstein event, there has been a lot of data collected in this area both prior to their initial use and after, most recently during the Einstein weekend. Experiments were performed in situ, with all robots and in various configurations and orientations. While RF levels vary on the field and while robots are moving, there was no specific and repeatable indication that RF levels on the field were or are a contributing factor to data throughput or loss of communications. While it is easy for you to state that there are many APs providing signal and interference on a FIRST field, the fact is that there are very few at 5GHz. In the event that there is an issue, FIRST has a solution to swap out the Dlinks with another device.
You stated that directive, high gain antennas should be used. These devices were discussed and are being evaluated. However, they carry significant issues when used for short distance communications. Side lobes, hot spots and excessive signal may not be able to be controlled through the adaptive processing used in 802.11 especially considering the amount of moving and stationary reflective surfaces on the playing field.
You state that RF levels should be made as high as possible. The 1252 is capable of signal levels in excess of +30 dBm per output. While the 1522 output is less, over the distances covered by these devices even with teams locating the radios inside a robot, the fade margins are greater than 30 dB and typically 50 dB.
You state that we need to take action on RF problems on FIRST fields when in fact RF is not the demon you state it is. You are stating the worse case scenarios that are used in system design in the harshest environments as the norm for a field that is less than 50 feet in actual signal path distance. The majority of the readers of this forum may take away from these statements that any problems they experience are caused by RF level issues when in fact they are not. If anything, the general reader should take away from this discussion that RF levels, maximum throughput, connectivity, reflections and multipath, changing RF environments and interference have all been thought through by the designers of the 802.11 specifications and associated hardware to make this a robust communications link.
Those that oppose your statements are not attacking you and I hope you realize I am not attacking you. We are merely opposing those statements that mislead, misinform and confuse the readers of this forum. I have seen the tests performed, and the equipment used. I sat in on discussions with the engineers at DEKA, Cisco and with other consultants where all of these things were discussed and some of those people were on the IEEE 802.11 committee. Participants communicated electronically both prior and following the Einstein weekend while we analyzed data collected during Einstein matches and at the test weekend. During the Einstein weekend we actually went as far to open a 1522 and measure antenna parameters while attempting to detune the antennas as a team might if it opened a Dlink to repair a connector.
While I am not an employee of FIRST, I am defending the organization in this area simply because I am aware of the work they have done and dedication they have shown in making sure the wireless communications work. It is my intent that teams should not immediately jump to the conclusion that the field is at fault and thereby fail to continue to check for other issues they have actually caused on their own robot. That is to say, teams should be checking that power, mounting, software and sensors are all working properly.

I have neglected to add the contributions of the Qualcom team input during Einstein testing and discussion. That is a major flaw on my part, sorry guys. The Qualcom input during field testing was invaluable and those people also were fluent in 802.11.

Re: Team 548 Einstein Statement
 

Al,

I don't really think that we are coming from all that different a place. I am not making excuses for teams that place their robot AP in a bad location. I am also not suggesting that a bad location for the robot AP should be accommodated.

I am merely suggesting a fully consistent monitored system for the field and robot APs that can detect both the optimal transmitter powers and any unusual cases system wide that cause collisions or congestion (the 2 being related).

I do not deny that FIRST supplemented the logged data for Einstein with the evidence collected for that match or during the report nor do I question the integrity or skill of those people or yourself. I am saying that such data was not in the logs generated and as the reports suggest more logging should be done.

I recognize that having the availability of talent and tools to perform the Einstein analysis measurements was a special case. A unique experience for the teams at Einstein to be sure (upside one learns some things, down side one has to deal with this). I feel that's an experience in troubleshooting that could be somewhat distilled and offer value to other people.

The Aruba (ARM), Extreme Networks (DRM) and Cisco (RMM) technology would perform a similar quantitative system level analysis and radio transmit power management/control (TPM/TPC) continuously regardless of where the fields were setup or which robot is using them. This is not to say it has to be one of those technologies nor that any of them is a perfect fit for FIRST. I additionally suggested a cheaper alternative in DD-WRT. All of these technologies provide insight into the APs with the perspective to the data I would like everyone to be able to analyze.

I am perfectly willing to accept that if there's doubt of my concerns that other cheaper logging solutions like Greg seems to be offering are a fine compromise. I also don't want FIRST to waste resources fixing a problem they have no real life data on yet. My point was not to demand solutions immediately but to frame concerns leading to exploration of the critical aspects. One may not know what to look for if they don't consider what problems might exist. Even if the consensus is that the Einstein report indicates these problems do not exist on that field at that time with those robots. That does not make a very large test sample considering the growing size of FIRST.

In my opinion the goal is not to just keep turning up the maximum field AP transmit power. The goal is to use no more, and no less power than is required to achieve the field system communications at any time. Personally I suspect that all of the APs already have too high a maximum transmit power setting (that's my opinion). I previously linked a paper on the risks of raising the radio transmit power so I think it would be a bad idea to use the Cisco 1252 turned up to it's highest settings. That's a sledge hammer when you need a frequently calibrated and maintained instrument.

I also would like to clarify that I am not writing that there needed to be a bunch of extra 5GHz networks to consider the existence of these problems. There is sufficient network hardware with just the fields that one can generate interference (adjacent radio channel and hidden node). I did point out before that there is additional opportunity for someone to compound that at any event with a 5GHz capable laptop nearby.

I understand that the selection of directional antennas for the Cisco 1252 at 5GHz may be problematic at these distances. I merely offer that perhaps if MIMO antennas were used on the field AP the side lobes could be better minimized. I'm not sure what selection of MIMO antennas FIRST has for the Cisco 1252 under the circumstances. Perhaps other APs would broaden the available antenna options.


I would really like FIRST to be in a strong position to hand quantifiable measures of radio power and throughput issues to all teams. Having data like this would be a wonderful critical thinking exercise for the teams and reduce the feeling of trial and error. There's not a lot of time for trial and error during real matches I'd rather people relocate APs or fix software for a reason. I'm fine with approaching these matters methodically and I don't really think I've asked for significantly more than some slight input into things FIRST may soon monitor and log which is one of their published mitigations from the Einstein report. There's really nothing extreme about what I'm asking considering it would illuminate the real risks of what I've described if they actually exist in this system. If all that monitoring from all those fields and robots shows that these problems are not common then that's a great sample set and definitive.

I don't want people running around looking for ghosts or laying blame or suspicion when the Einstein reports clearly show there are plenty of issues to go around. On topic, I also rather not have extreme perspectives of people's participation clouding what might be otherwise easy process adjustments, team reputations, or FIRST's reputation. None of it is necessary or scientific.

Re: Team 548 Einstein Statement
 

Moderators: A request. I think I've seen it done in the past, if it's too labor-intensive, then disregard.

Can we please split this discussion in two separate threads, one discussing 548's involvement and remarks regarding Einstein 2012, and another thread discussing the non-human interactions, interferences, and possibilities ? I'm sure the Robostangs (as well as many other members of the community) wish to put this incident behind them, but it is hard to do so when this "Team 548"-titled thread is hovering near the top of the portal.

Re: Team 548 Einstein Statement
 

Split, or lock. Either way, I think it's time this thread disappeared into technical-land.

Brian, Eric, and to some extent, Al. You guys are using rather high-level terms; if you want to do that, that's great, but put it in, say, the control system forum. I don't think I could understand much of what you're saying unless I took extra time to sit down with a copy of "802.11 for Dummies", if such a publication exists, and decipher. Add to that your attacks on each other (and not each other's methods or theories), and if I were a mod I'd have locked or split this thread several pages ago because of the redirect and hostility shown on multiple occasions, as well as this forum rule:

Re: Team 548 Einstein Statement
 

To what end? Radio output power is not an issue and teams cannot modify the radio to make changes if it were an issue.

The antennas in use are MIMO antennas per the 802.11 standards and produce the least side lobing of any antenna available from Cisco for this radio. They are vertical dipoles and essentially have a uniform horizontal dispersion. Higher gain antennas do have side lobes and could prove problematic if for no other reason than the deep nulls between lobes. The antennas mount on standard TNC connectors and the 1252 is designed such that the case of the box becomes the ground plane for the antennas.

Re: Team 548 Einstein Statement
 

For the simple reason of finding the optimal placement of the robot AP.
Not to adjust the radio output power levels themselves.

Cisco refers to the transmit power control technology I'm describing as dynamic transmit power control (DTPC). It's part of the features of Cisco's CCX in their product line. Link to save space. This is the same CCX technology that offers protection from the WiFi management frame hacks and I mentioned previously in this topic.

Thanks for the information on the antennas but these are omnidirectional antennas you are describing correct?
I thought the discussion was about a more directional antenna with a reduced side lobe.
I was thinking more along the lines of a MIMO panel antenna or are you describing the inside of a panel antenna?

Re: Team 548 Einstein Statement
 

Is there any doubt that the optimal location for the robot AP is going to be high up, away from metal frame components, and away from motors?

Speaking for a team entering its 7th year... we've followed that general guideline as much as possible, and have never had problems with field connection. Is there anything more that is really needed for teams? We don't need to make this more complicated than it absolutely needs to be...

Re: Team 548 Einstein Statement
 

The only remedial option a team might have is to improve their AP placement and connect it properly.
The reason for my concerns is more than just merely to serve that purpose.
It's one benefit.

Also, 2012 is a prime example that putting the D-Link AP near a rotating assembly with metal in it for say a shooter, might not be a great idea. That might be the top of the robot and the D-Link AP might be far away from motors.

The other benefit is to have a log of more information about the field should someone have any concerns. Such information about a wide variety of robots and fields could be used to find strange AP behavior or determine if there was any other source of interference (just examples).

Re: Team 548 Einstein Statement
 

Now I'm confused... those seem like two contradictory statements to me. The only thing teams have the ability to influence is their radio placement and wiring on the robot, and it seems to me that they already have enough information to optimize that as best they can. As for your other concerns... I think you've explained them, and I think others with more insight into the inner workings of FIRST have pretty clearly indicated that those concerns are things that FIRST is or has looked at.

Playing chicken little with the wireless setup as you've been doing here on CD doesn't really help. All it can do is get teams worried and concerned, with no useful way to alleviate those concerns. It's clear that you're a knowledgeable and passionate person from your posts here, and I would encourage you to direct that passion in a constructive way with the appropriate audience.

Re: Team 548 Einstein Statement
 

While it's true there's nothing more a team can do than move their robot AP to improve it's radio signal quality. Besides perhaps limit the robot's range of movement on the field (that would be a really worst case).

Pages ago (page 11 first post from me at the top) I suggested teams use the GPIO and I2C to flash status information with LEDs while on the field. That would help teams find problems even if they can't communicate to the robot. Obviously the Einstein reports make it clear that a fair amount of problems this could help diagnose remain.

Pages ago I suggested getting better control over TCP/UDP communications and being more careful about how it is used.
With QoS next year the bandwidth limits will be better controlled by the fields. However that might impact how robots perform if teams do not consider those limits. This also implies being careful about network links to IP devices like COTS devices and network congestion. Further the additional bandwidth issues I've been writing about may spawn logged entries that well help teams find these issues.

Pages ago I also suggested testing the robots for a variety of things that are well within the scope of what a team should do. Such as loosing a camera feed to the driver's station. Loosing enable for short periods of time.

All other partial solutions require cooperation and communications with people involved in the fields and FIRST. I did send 2 e-mails to FIRST which still haven't received an acknowledgement. Those 2 e-mails are still relevant (as are the other students and Mentors that I know sent e-mails). Since then Al has clearly stated that while I might not get an acknowledgement they should be listening to this topic and elsewhere.

Clearly Greg's posts in this topic mark some interest in possible improvements in the logging in relation to my concerns. I appreciate his patience. Just going over all the possible points of interest to bring some of these concerns to that sort of attention was the reason for doing it. This way the detail is there to reference and perhaps at a later date reconsider.

I have no control over how powerless teams may feel in the face of this technical information and I'm trying to help them feel less powerless when things go wrong and they want to dig (I did twice frame the arguments in plain simple examples minus all the acronyms and abbreviations). I offered repeatedly to take this private or take it elsewhere. If that was the concern I would have done so without a hesitation as long as someone can be bothered to facilitate it. I have no ability to open new topics on this forum. I have no interest in being saddled with another forum just to discuss this right now.

This is all relevant to this topic because it shows how one gets a response when they have concerns.
One of my key points remains that this is a confusing and inefficient way to facilitate this.

Re: Team 548 Einstein Statement
 

Brian,
Also checked during the Einstein weekend. While placing the radio deep inside the robot, behind metallic parts, behind the the bumper, on the floor of the chassis pan or behind an arm are all very bad locations, the orientation of the radio with respect to the field, the Cisco router or other robots varied the received signal level by less than 10dB. Even if the radio was located low on the robot and on the outside, turning the robot so that the radio was facing away from the Cisco router only made about a 10 dB difference, far less than I would have thought knowing the interior construction of the radio and placement of the PIFA antennas. In fact nearby objects only started to affect signal strength when within 2" of the top or sides of the radio.
So for teams, in general, mount the radio where it is protected from contact with other robots and mounted so that the LEDs are visible. The radio should not be mounted near high noise devices like the leads to CIM motors or FP motors or near the 5 volt regulator. The bottom of the radio already has shielding so mounting it on metal should not be a problem but if mounted vertically, perf stock or lexan would be the preferred backing material. There didn't seem to be a vast difference in signal between horizontal and vertical mounting although horizontal will likely give the best overall coverage. When looking at the face of the radio, there is an antenna on both the left and right sides so don't mount the sides against robot frame. Both antennas are used all of the time for both receive and transmit to achieve the highest throughput per 802.11 specifications. Secure the power lead in some fashion so that it won't wiggle. A simple stick on tie point mounted on the top of the radio, with a wire tie securing a loop of the power cord is the best option. I do not recommend hot glue as this makes repairs almost impossible when applied correctly. When not done correctly, the glue will give you false hope, likely mis-align the connector or damage the jack on the radio and the connector will fall out when you need it the most. If you choose to use a Radio Shack connector, insure it is the right dimensions. Often teams will use a connector meant for a larger diameter center pin. The result is noise on the power line during robot movement. Over time, as the connection becomes dirty, radio reset will be the result. If you are placing the radio near moving parts check clearances for all positions of the moving part. The metal of the moving part should not cover the radio when at rest or fixed position and it should not pass within two inches of the top or sides of the radio. Do not make severe bends in the ethernet cables, the max spec as I remember is 1" minimum bend radius for full bandwidth. Secure the ethernet cables near the radio so that they do not put strain on the jacks on the radio or pull out with robot movement. Putting a small loop in the cable will prevent any strain on cable or radio. Above all, make sure the 5 volt regulator is connected to the radio output on the PD and all wires are secure and insulated. Mount the regulator where it will be protected and does not move within the robot.

Re: Team 548 Einstein Statement
 

I have additional questions about some of this.
This is not to say that I doubt the skill of the testers.
I still foresee other interactions but they are not issues teams can solve.

I think the last 2 posts (Al's and mine) summarize the basics of what a team might get from this topic. I suspect the other points are of only minor value compared to the posts for the last 2 pages before this which are more general. So I think I'll leave this here and see if I can find another place to discuss those details.

My hope is that what is already here will impact the available logged data decisions at the least. I am perfectly fine with that as a compromise. If problems such as those I touched on do appear at least this will serve as something to review.