We have a tower with 2 AP and 2 BH(Master). All of them are synced with a CMM. Both AP’s and BHM’s are using a downlink data of 75%.
I thought that it should be a problem-free situation, but unfortunately one link is loosing packet: in the synced BH(Slave) we have such a situation on radio side:
inoctects Count 2982395379
inucastpkts Count 18693937
Innucastpkts Count 26229
indiscards Count 0
inerrors Count 0
inunknownprotos Count 0
outoctets Count 285652339
outucastpktsCount 16412936
outnucastpkts Count 4607
outdiscards Count 1786553
outerrors Count 0
and even if the link test told us that we have a 100%uplink and 100% downlink, we start having outdiscards count increase as soon as we use more than 2Mb/s upstream ( from BHS to BHM ).
with this situation we have IP packet loss, and everything degrades.
AP are 7.3.6, BH are 7.2.9.
aiming is correct
between AP and BH there is also a vertical separation of about 8 meters.
today I tried to correct a bit the downlink data of the problematic link and now i’m using 65%, and it seems better, even if it isn’t solved at all.
any idea?
thanks!
Are you using different freq’s for the Ap and sm
same band, 5,4GHz, but different channel, lower end for AP’s and upper end for BH’s
please post the following for BHM and APs
freqs
max range
control slots
downlink ratios
AP1
Freq: 5495
MaxRange: 8
ControlSlot: 1
DownRatio: 75
AP2
Freq: 5530
MaxRange: 6
ControlSlot: 1
DownRatio: 75
BHM1
Freq: 5670
MaxRange: na
ControlSlot: na
DownRatio: 75
BHM2 (<- the problematic one )
Freq: 5695
MaxRange: na
ControlSlot: na
DownRatio: 75
Other than the AP’s having different Max Ranges, it looks OK.
Look at the Ethernet Stats - any CRC errors?
no crc in any ethernet 
I am starting to suspect interference.
Flip the BHM to a BH slave and do a spectrum analysis to confirm the frequency you are using is actually clear.
If it looks OK at the BHM side, then you might want to turn off the BHM and drive out the BHS and do an analysis there as well to confirm the problem isn’t interference at the BHS side.
done as you suggested: it seems that there was something else near, so I flipped the freq on the two link in order to see if it solves.
I’ll know in about an hour, I think
thanks
no effect, same problem.
I’ve been suggested to use a 50% downlink ratio, and I tried also this. Now it seems much better, and that’s almost incredible, considering that every other canopy is using 75%.
Now I’m trying to understand what outdiscards in rf control block means: is it the number of rf packet sended but not received correctly or the number of rf packet non sended? if it’s the second one, what can cause this error?
thanks
Unless, 5.4 is different. Moto support told me not too use the same freq, backhaul as AP, unless there was a large seperation between the two.
I would try switching the freq’s around until I found the one’s that would work. switch the freq of Ap1 and BHM-2 see what happens
where I can find some technical info about all the info we have on canopy? User manual is a bit generic.
thanks
Training…
Next one is in Atlanta in Jan
Jerry Richardson wrote: I am starting to suspect interference.
Flip the BHM to a BH slave and do a spectrum analysis to confirm the frequency you are using is actually clear.
I wouldnt do this. You have two AP's and another BH on the same tower in the same band. If you turn this BHM's spectrum analyzer on then it is going to see the other three radios. If you are going to do this then turn on the spectrum analyzer on all 4 radios at once.
In addition you will want to run the frame calculator to match the frame structure of the AP's and BH's similar to what we had to do when collocating HWS and SWS AP's. If you can get the frames close, increase frequency separation, then you should be okay. There are 11 non-overlapping channels in 5.4 .
See page 21 of the 7.2 release notes on using the frame calculator....
http://motorola.canopywireless.com/fp/d ... bf1e0565e8
How much physical separation is there between the AP's and BH's?
I think your issue may be more of a bandwidth issue with your backhauls, assuming that this tower is not at your head end.
If you have the master backhaul that feeds the tower set to 75% download, it means that from the slave you will see 75% download, this means that at the tower you will only have a 25% download to feed that tower with, so you may be running out of bandwidth going to the tower. Remember I am just going off of the assumption that this tower is being fed an internet feed via one of the backhauls that is on it. Change the master backhauls download percentage to 25%, if it is at the tower.
This could also explain some of the out discards. Basically your master backhaul can does not have a big enough pipe for recieving traffic from the slave, causing errors when the slave tries to send data out.
Hopefully this makes sense.