have you checke dthe installs, are these things mounted in the correct orientation?
On Wed, Jun 17, 2015 at 8:50 AM, Greg Osborn <[email protected]> wrote: > Yeah, it’s just the downlink that becomes a problem. All is good on what > we have below at the moment. I should have just waited to take a before > reboot and after screenshot. > > > > *From:* Af [mailto:[email protected]] *On Behalf Of *Eric Muehleisen > *Sent:* Wednesday, June 17, 2015 9:23 AM > *To:* [email protected] > *Subject:* Re: [AFMUG] Cambium 320 Poor CINR and mcs after awhile > > > > Uplink looks good. Does this only affect downlink? First thought would be > self-interference but that usually doesn't show up in the radio stats but > rather packet loss in the service flow stats. During a maintenance window, > shut down all your AP's and run a spectrum analysis one-by-one. I would > suspect the noise floor to increase during peak times. > > > > On Wed, Jun 17, 2015 at 7:57 AM, Greg Osborn <[email protected]> > wrote: > > We have 3 sites with Cambium 320 gear. 2 with Omni’s that don’t behave > oddly. The other has 4 AP’s and requires a reboot of the AP’s after a > while because the CINR values and modulations will tank. We are not using > a ABAB config. It doesn’t seem to be tied to sync or interference, as far > as I can tell. Yes there are some crappy installs here. We acquired them > through a failed startup. Below is what it will look like when good. When > it is bad, cut the CINR values to 12ish or less with a QPSK x/x. Signal > will still be good. Any ideas on the reasoning? > > > > > > > > *Parameters marked with (*) will display accurate values only when that > link is passing traffic. * > > *CPE MAC Address* > > *Uplink* > > *Downlink* > > > *RSSI 0* (in dBm)* > > > *RSSI 2* (in dBm)* > > > *CINR* (in dB)* > > *MCS** > > > *RSSI (in dBm)* > > > *Zone CINR (in dB)* > > *MIMO Type** > > *MCS** > > *64:ed:57:31:7f:e0* > > -83 > > -66 > > 28 > > QAM64 5/6 > > -69 > > 24 > > MIMO A > > QAM64 2/3 > > *64:ed:57:31:84:46* > > -69 > > -64 > > 34 > > QAM64 5/6 > > -74 > > 24 > > MIMO A > > QAM64 2/3 > > *64:ed:57:31:84:58* > > -95 > > -74 > > 23 > > QAM64 2/3 > > -88 > > 11 > > MIMO A > > QPSK 1/2 > > *64:ed:57:31:84:f6* > > -79 > > -61 > > 34 > > QAM64 5/6 > > -71 > > 26 > > MIMO A > > QAM64 3/4 > > *64:ed:57:31:86:52* > > -67 > > -58 > > 34 > > QAM64 5/6 > > -66 > > 28 > > MIMO B > > QAM64 5/6 > > *64:ed:57:31:87:30* > > -67 > > -58 > > 34 > > QAM64 5/6 > > -68 > > 28 > > MIMO A > > QAM64 5/6 > > *64:ed:57:31:87:ae* > > -93 > > -68 > > 29 > > QAM64 5/6 > > -80 > > 18 > > MIMO A > > QAM16 1/2 > > *64:ed:57:31:88:4c* > > -62 > > -87 > > 33 > > QAM64 5/6 > > -45 > > 28 > > MIMO B > > QAM64 5/6 > > *64:ed:57:31:8a:90* > > -75 > > -58 > > 34 > > QAM64 5/6 > > -68 > > 28 > > MIMO A > > QAM64 5/6 > > *64:ed:57:31:8c:f2* > > -77 > > -64 > > 29 > > QAM64 5/6 > > -88 > > 16 > > MIMO A > > QAM16 1/2 > > *64:ed:57:31:8d:70* > > -87 > > -64 > > 33 > > QAM64 5/6 > > -71 > > 27 > > MIMO A > > QAM64 5/6 > > *64:ed:57:31:8e:da* > > -78 > > -69 > > 29 > > QAM64 5/6 > > -81 > > 17 > > MIMO A > > QAM16 1/2 > > *64:ed:57:40:7c:16* > > -61 > > -79 > > 34 > > QAM64 5/6 > > -61 > > 28 > > MIMO B > > QAM64 5/6 > > > > > > -- > > Thank you, > > > Greg Osborn > Tech Support and Field Service Manager > OnlyInternet.Net > 1.800.363.0989 > [image: http://home.onlyinternet.net/images/social_facebook.png] > <http://www.facebook.com/onlyinternet> [image: > http://home.onlyinternet.net/images/social_twitter.png] > <http://www.twitter.com/oibw> [image: > https://dl.dropbox.com/u/12716696/OIlogo.jpg] > <http://www.onlyinternet.net/> > > > > > -- If you only see yourself as part of the team but you don't see your team as part of yourself you have already failed as part of the team.
