We have an AP (5.8ghz) which is sited by itself fed by a single BH link (5.4ghz).
Both are running v7.3.6 in SWS mode at present.
A ping plot to the AP itself shows a perfect link 24/7. However, about a dozen times per day, the SM’s registered to it go blank.
A ping plot to 4/5 randomly selected SM’s show that they all fail to respond to ping requests for a period of 20 secs or so. These outages seem to be random and traffic does not pass in either direction.
- The SM’s do not de-register, but just fail to pass traffic
- I’ve been trying to find interference using the spectrum analyser on an SM - but this shows nothing.
- Moving frequency has not helped.
- An interesting thing is that when I log in to check an SM, all of them have a strange attribute. The Jitter seems to be very variable. A link rssi of 900, jit 2, can show jit7 or jit8 if you keep checking (1 bad jit8 after 5/6 Jit2)
- This base station does not have CMM or even a synch cable between AP and BH. Could this be a problem? The AP and BH are on different bands. This problem has been evident for a while now, from about 35 SM’s registered I’d guess.
Has anyone come across a similar problem to this ?
If an interfering signal is strong enough to knock out all SMs surely the SM analyzer should see it.
Has anyone has pointers ?? I’ve changed the AP and we don’t have access to a network analyser for this band.
Regards,
John Barry
Airwave Internet
www.airwaveinternet.net
Not have a CMM could be the problem, Is there other wireless providers in the area? How do you have the Ap and backhaul sync’ed together? How many Ap’s are you running.
- 7.3.6 in SWS is not very stable. Force to HWS or back up to 7.1.9.
2. As Clueless says, check for other AP’s in your area - Use an SM and look at the AP eval page. Drive around and poke the SM out the window and point it in various directions.
3. Is the problem the AP or the BH?
4. Are you feeding the AP from another AP cluster or is that your only AP?
If that is the only AP in the area, and there is only one, then a CMM is not totally necessary.
If you have more than one AP in the same band (your own, or someone elses), you definately want GPS Sync. If funds are tight, then look at http://www.packetflux.com/ for GPS devices compatable with Canopy.
Thanks for comments.
It is a single AP - connectorised with Omni antenna. There are no other providers operating nearby and the SM shows a clean, clear band other than our frequency.
The AP is feed directly by a BH. There are no issues across the BH.
I have been a little nervous about going to HWS due to this problem. It may make matters worse, but I guess its worth trying - can always go back.
Have either of you ever noticed the unstable jitter I mentioned before ?
Cheers - John
Yes, due to 7.3.6 in SWS. Switch it and you will see improvement. Use the Scheduling Tool Plugin for CNUT to do it in one motion.
You might consider getting a Sync Pipe (139.00 GPS Sync Generator), install it at the BH/AP end (make that BH the Master) and provide sync to the BH Master and AP to mitigate out of band interference.
So latest is not always greatest 
I have HWS on most AP’s now - cnut works well. I will change to HWS and see if this solves jitter problems.
Would you expect the Analyser to detect the interference if it was in-band? Can this tool detect carrier / noise or just signal it can decode.
It would be useful it this tool could be make cycle for a few hours and record its results.
If I sync this site site using GPS, will it propagate to the slave site of the BH ? I may need a Sync pipe there also.
I’m not sure what happened with 7.3.6 and SWS. I think the intent was that 7.3.6 would be used in conjunction with HWS but I don’t recall seeing anything that says that was the case. It was just my (as well as others) experience that performance went in the hole with 7.3.6+SWS.
GPS at AP propagates sync to all SM’s on that AP
GPS at BH Master propagates sync to BH Slave. In your case the Master would be at the AP and the slave would be at your head end where your pipe to the internet is.
To get a real understanding of the noise at the AP, turn the AP into an SM and then use the Spectrum Analyzer to look at the noise the AP actually sees. It’s difficult to get accurate readings with the AP running.
To do logging you need this bad boy: http://www.lessemf.com/rf.html#135
What I did last month is connect a standard SM also onto the BH. Its not registered to anything, it just sits on a tower leg.
I can access this via the BH, and operate the analyser function remotely.
Thanks for the tips - will try those and see if anything helps
John
I was thinking… there is no reason that you could not set the BHM to generate sync, and pass the sync to the AP (set to Receive Sync on Timing Port). Tie pins 5 and 6 from the BHM to the AP.
This will put the BH and the AP in sync and propagate the timing to the BH Slave and SM’s without any cost.
what is the problem with 7.3.6 in SWS? we’ve got several AP’s running 7.3.6, and so far I’ve not noticed anything different from 7.2.9.
We did, however, experience the problem that the original poster has. It turned out to be a broadcast storm, and using the Advanced Network Settings filter section on our SM’s, we’ve pretty much completely eliminated it.
The symptoms were the same - no reg or re-reg bump, just dead RF link for 15-20 seconds, usually happened to 10-25 SM’s at a time, predominantly on the busiest AP’s. We use PPPoE, so we blocked everything except it. Our upload rates actually went up just a touch on link tests, and overall stability improved.
Following the discussion here, I spent some time over sunday night/ monday morning to switch the AP to HWS.
There has been no outage since !!! The ping plot is running for 48hours now, and it hasn’t missed a beat.
Thanks very much for the help - especially Jerry !!
I intend to order a GPS unit and do some work on that soon.
okconnect - my AP was running v7.3.6 in SWS. All SM’s were also v7.3.6.
Cheers - John