Quote:
Originally Posted by Swampdude
We did cell phone tests tonight. BINGO! Make or recieve a call within 30 feet of the bot and it starts glitching bad (this distance may be greater but I was on the phone and walked away from it and it seemed to get better after I was in the next room). Then also just hold it near the bot (while not in use) and every 15 seconds or so it starts fluttering.
So whats the answer, ban cell phones from the competitions? Can someone get IFI to read this thread? Someone said if it is a cell phone issue, you can't fix it. Which I gather those frequencies can't be altered out of that range? I contacted the FIRST Florida rep (Charles Kennedy), and he's waiting to hear back from FIRST. The way I see it, this is a bigger issue than the banebot problem because we all need to use these radios.
|
This evening I implimented code to watch for packet loss, for more information see the details and example code in
this thread.
With a packet loss counter displayed on the operator interface, I had a couple of Cingular (i.e. GSM) phone users setup calls within proximity to the 2007 radios, and boy did the packet loss counter take off. This was not a difficult problem to reproduce at all, nor did the phones appear to need to be particularly close to the radios. We didn't do range testing to see how far away they would still cause problems.
With eWave radios, the problem could still be produced, but the phones had to be within about 12-18" before some minor packet loss was noted.
My CDMA phone affected neither.
I also tested with a /\/\otorola 450MHz 5W handheld and found that it was fairly difficult to disturb the 2007 radios, but when I did, they took quite a while to recover, and it seemed to be longer than it normally takes for the radios to sync in the first place.
When I tried the same test with the eWave radios, I found that they were actually more succeptable to interference from the commercial handheld radio than the 2007 radios were. However, the eWave radios never experienced anything more than a few packets being lost when the commercial radio was keyed, whereas the 2007 radios lost sync for up to 20 seconds as a result of a single transmission on the commercial handheld.
With regard to the V14a firmware, my test code seemed to indicate that the robot controller will disable the outputs when 8 consecutive packets are lost. My number could be off a bit, as I sometimes saw as many as 12 missing packets prior to the RC disabling the outputs, but its right in that area somewhere. In otherwords the outputs will be disabled 200-300ms after packet loss starts to occur.
With the packet loss counter displayed on the operator interface, over several minutes of operation, both the eWave and IFI radios showed occaional packet loss counts during the regular course of operation, however the packet loss rate was higher for the IFI radio than the eWave radio. I won't quote specific numbers nor quantify that statement as I wasn't making a specific expermient to instrument packet loss.
The environment that I was testing had no other 900MHz signals present, as verified with a spectrum analyzer.
Overall, the IFI radio design appears to be quite a bit more succeptable to cellular phone interference than the eWave design, however the eWave design was more succeptible to 450MHz two-way transmission.
From a design curiosity standpoint...
Additional testing shows that the IFI designed radios are FSK radios using channels spaced 150kHz apart. The RC radio channel 1 starts at 902.100MHz and works up from there. The OI radio channel assignments are less obvious, and not sequential, operating in the 922-928MHz portion of the band.
The eWave designs operate on 50kHz channels with the RC side transmitting on the lower frequency channels, just like the IFI design, and appear to be AFSK. Presumably the AFSK approach avoids needing to design the transmitter/receiver to be able to essentially pass/recover data down to DC. The latter results in a slightly more complicated synthesizer design because the PLL reference needs to be modulated in addition to modulating the VCO.
The IFI FSK signal appears to contain a ~3ms pre-amble prior to the data, which I presume is to center the recievers data-slicer, then sends the data, and then sends what appears to be a post-amble. Given that the data is true FSK, its not clear why a post-able burst could be helpful.
I also noted that the signals didn't appear to be properly pre-emphasised, so the higher frequency content of the signal didn't deviate as widely as the lower frequency data, nor was the signal necessarily well balanced. Depending upon the data-slicer design, this could certainly result in a reduction of performance.
While a bit hard to tell, the signal encoding didn't appear to particullarly try and place a limit on long strings of 1's or 0's as long periods of mark and space were evident, which again can make the design of the data slicer a bit more challenging.
Again, this last bit is offered just as insight into the radio's design. I have no reason to believe that the modulation methodology plays into the performance problems that I've noted, and believe are tied to power supply issues, nor should they play a great part in the receivers succeptablility to GSM/TDMA type transmissions... that is unless the succeptability problems are related to RF getting into post receiver circuitry.