Tom, For the radar identification, I found that the Trango survey tool wasn't able to see the extremely short RF bursts that the radar sends out. They are only a few microseconds long. I have only been able to see them using a "real" spectrum analyzer. I use a Tektronics 492 that I snagged off of ebay. It's old and generates a fair amount of internal thermal noise, but it does the trick. Also helpful is to check the FCC database for licenses in the 5300-5700 MHz area- that will tell you what frequencies and power levels the weather radars in the area are using, and give you transmitter coordinates. Does that one in Tyson's corner give you guys any trouble?
The way I understand the radar detection mechanism in the Atlas radios from the FCC filing documents and test lab comments is this. There is a separate receiver circuit from the main data receiver that pulls off the active antenna (H, V). It simply looks at the incoming power level at the selected frequency and compares it to a setpoint, which is -46 dBm for the integrated 23 dBi model I think. I don't know any of the filter specs, but in my case it was detecting radar on channels that were not actually occupied by radar, so it must be affected by noise on nearby channels. If I were deploying at this site again, I'd be using external drum antennas to cut down on interference from that weather radar, which would also let me put external filters in place. Also, the radar detection is only performed on the MU side, so switching the MU to the far side of the link helped as well. My radios must have come with short u-bolts. I got some new longer ones from Home Depot that worked on a 2 or 2.5" pole but I'm still 99% sure they wouldn't work on a 3" pole. For the Cisco issue, they work great with Catalyst 2924XL switches, which 3 of the radios are attached to. The 3548 that gave the Atlas fits is installed in a datacenter where I buy bandwidth and could not be changed out for other hardware. Putting an unmanaged netgear switch between the Cisco and the Trango fixed the problem. Errors were only occuring on the Trango end of the ethernet link, none on the Cisco end. Both sides had claimed to negotiate to 100/Full, but kept getting packet loss on the way from the Cisco to the Trango. I don't like having one more point of failure (the netgear switch) in the mix, but that was the only solution I saw, and that's what redundant paths are for. Patrick Tom DeReggi wrote: > Patrick, > > We have been very happy with our Tlink45s. > > I felt you gave some excellent feedback i nyour review. A couple comments... > > >> Do a thorough >> spectrum analysis before deploying these radios or be prepared to >> spend a lot of time troubleshooting later. >> > > How do you do your through analysis for tracking things like Radars that Hop > arround? > Other than generic advice like "buy a real analyzer", and special > techniques? > Did you find the Trango Spectrum analyzer tool accurate enough to give you > what you need to find? > > >> Anything coming into the receiver port over that >> >>> threshold is >>> considered a radar event and initiates a channel change. >>> > > That could use a bit more clarification. Are you saying that anything that > comes in loudenough on your used channel creates an event? > Or are you saying "anything". I'm mentioning that jsut because Trangos have > pretty good filters built-in, so I would assume that maybe just noise over a > certain level near the 5.x band could do it? > > >> This is a problem because it makes it >> >>> difficult to hold the radio in place and hand-tighten the nuts during >>> installation. >>> > > Yes, I agree that is a pain. But incomparision, that is a design flaw shared > by many common brand radios and antennas. > > >>> but there is no way it will work on anything over 2". >>> > > Not sure why you say that. All our Tlinks are mounted to poles that are > wider diameter than 2". > (Are yours shipping with short ubolts or something?) > > >> Cisco Catalyst 3548 switch. This was difficult to track >> down because there are no CRC error counters available in these radios >> and there is no way to hard-set Ethernet speed and duplex settings. >> Putting a cheapo netgear unmanaged switch between the Cisco and the >> Trango eliminated the errors. >> According to Trango, they cannot >> implement manual speed and duplex settings due to hardware limitations >> (wtf?). >> > > I agree, its disappointing that the Tlink don't have manually setable ports > and error stats, and it would be useful to have that for many > troubleshooting reasons... > The flaw is actually in the Cisco hardware. Cisco is known for its common > failure to function with other ANEG third party routers. > With Cisco, its not always fixable by putting a cheap unmanaged switch in > between either. We just ran into it with a 3550 this week. After trying, 1 > managed swithes hard set, and 4 brands of auto-neg unmanaged switches, we > finally had to ditch the idea, and connect the Cisco to a Linux box. Our > solution is not to use Cisco Switches, the Atlases are one of a kind, and a > value we are not willing to give up. This is also solvable by having access > to the Cisco switch, to check teh CRCs from the Cisco side. OF course that > only works if you are in control of the Cisco to acces it. > That experience above was not related to connecting a Trango. > > Were you able to get the Tlink to work with the Cisco, by hard setting the > Cisco to a specific configuration? Its not a big deal IF a workign > configuration can be discovered. Whats a problem is a solution that won't > survive a reboot. For example with the ViaRhine MT cards, after a Atlas > reboots, the Rhine NIC needs to be reset to autoneg the appropriate speed. > Again a problem with the NIC not the radio. But it was annoying. But if I > can hard set a port, and that will work, after a reboot all is good, then it > jsut becomes a documentation issue. > > Tom DeReggi > RapidDSL & Wireless, Inc > IntAirNet- Fixed Wireless Broadband > > > ----- Original Message ----- > From: "Marty Dougherty" <[EMAIL PROTECTED]> > To: "WISPA General List" <wireless@wispa.org> > Sent: Thursday, March 13, 2008 10:08 PM > Subject: Re: [WISPA] TrangoLink-45 Review > > > >> Thanks for the review Patrick. >> >> This message was sent from my Iphone >> -------------------------------- >> >> Marty Dougherty >> CEO >> Roadstar Internet Inc. >> 703-554-6620 (office) >> [EMAIL PROTECTED] >> >> On Mar 13, 2008, at 10:11 PM, Patrick Shoemaker >> <[EMAIL PROTECTED] >> >>> wrote: >>> >>> A few weeks back I asked for opinions of the TrangoLink-45 radios. >>> Since >>> then I've installed two pairs and figured I'd share my experiences >>> with >>> the list. >>> >>> Physical design. The antenna and radio housing are solidly built and >>> look like they will last. However, the mounting system is not as well >>> designed as the rest of the radio. First, it is made of zinc plated >>> steel, which I suspect will rust after a while. The mount uses a U- >>> bolt >>> to attach the radio to a pole. This is a problem because it makes it >>> difficult to hold the radio in place and hand-tighten the nuts during >>> installation. Since there is no hoist loop in the radio housing, you >>> can't tie the radio off to the tower and use both hands to tighten the >>> u-bolt. Also, the mount is specced to work with up to 3" diameter >>> poles, >>> but there is no way it will work on anything over 2". >>> >>> The telnet interface for radio configuration is simple and effective. >>> Never having used a Trango radio before, it took me about 30 minutes >>> to >>> be completely comfortable with the radio setup and management >>> interface. >>> SNMP support looks good but I haven't gotten this set up on my >>> network yet. >>> >>> One little plus is the PoE pinout and voltage is compatible with >>> Canopy >>> gear- this radio plugged right into a CTM-1m once the timing pulse was >>> switched off. >>> >>> DFS. The radar avoidance DFS on these radios works by using a separate >>> receiver circuit to compare the instantaneous received power level >>> to a >>> threshold. Anything coming into the receiver port over that >>> threshold is >>> considered a radar event and initiates a channel change. In my case, I >>> had a weather radar tower less than a mile from one of the radios. The >>> tower transmits with an EIRP of 6.9 GW (yes, gigawatts) at 5500 MHz. >>> Emissions outside of the radar's licensed band were enough to trigger >>> DFS sporadically throughout the 5.3 and 5.4 bands. Do a thorough >>> spectrum analysis before deploying these radios or be prepared to >>> spend >>> a lot of time troubleshooting later. >>> >>> Performance. I haven't done thorough testing yet but I'm getting >>> almost >>> zero ARQ retransmissions and the highest modulation mode on my 1/2 >>> mile >>> link, so about 35 Mbps of TCP throughput sounds reasonable. >>> >>> Network issues. #1 is that there appears to be a bug with the new VLAN >>> implementation for the radio's management interfaces. The radios won't >>> respond to any traffic not originating outside of its subnet. My >>> packet >>> sniffer shows pings going into the unit from a machine on the local >>> network segment and one on another network, and replies are only >>> generated for the machine on the local network. Trango engineering is >>> working on the problem. Second, I was getting ethernet errors when >>> connected to a Cisco Catalyst 3548 switch. This was difficult to track >>> down because there are no CRC error counters available in these radios >>> and there is no way to hard-set Ethernet speed and duplex settings. >>> Putting a cheapo netgear unmanaged switch between the Cisco and the >>> Trango eliminated the errors. According to Trango, they cannot >>> implement >>> manual speed and duplex settings due to hardware limitations (wtf?). >>> >>> Anyway, sorry for the manuscript. All in all, decent set of radios for >>> $2000. A little rough around the edges compared to the Orthogons I am >>> used to, but the performance is better and you can't beat the price. >>> >>> Patrick >>> >>> >>> >>> --- >>> --- >>> --- >>> --- >>> -------------------------------------------------------------------- >>> WISPA Wants You! Join today! >>> http://signup.wispa.org/ >>> --- >>> --- >>> --- >>> --- >>> -------------------------------------------------------------------- >>> >>> WISPA Wireless List: wireless@wispa.org >>> >>> Subscribe/Unsubscribe: >>> http://lists.wispa.org/mailman/listinfo/wireless >>> >>> Archives: http://lists.wispa.org/pipermail/wireless/ >>> >>> >> -------------------------------------------------------------------------------- >> WISPA Wants You! Join today! >> http://signup.wispa.org/ >> -------------------------------------------------------------------------------- >> >> WISPA Wireless List: wireless@wispa.org >> >> Subscribe/Unsubscribe: >> http://lists.wispa.org/mailman/listinfo/wireless >> >> Archives: http://lists.wispa.org/pipermail/wireless/ >> >> >> -- >> No virus found in this incoming message. >> Checked by AVG. >> Version: 7.5.519 / Virus Database: 269.21.7/1327 - Release Date: 3/12/2008 >> 1:27 PM >> >> >> > > > > -------------------------------------------------------------------------------- > WISPA Wants You! Join today! > http://signup.wispa.org/ > -------------------------------------------------------------------------------- > > WISPA Wireless List: wireless@wispa.org > > Subscribe/Unsubscribe: > http://lists.wispa.org/mailman/listinfo/wireless > > Archives: http://lists.wispa.org/pipermail/wireless/ > -------------------------------------------------------------------------------- WISPA Wants You! Join today! http://signup.wispa.org/ -------------------------------------------------------------------------------- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
