We just received our first PMP 450 equipment yesterday. We will be installing two APs on a congested PMP 100 900 MHz tower. We have had some good results from the PMP 320’s, so we are hopeful about the 450’s.
I intend this to be a sort of play-by-play of our experience with it, and how it ends up performing. I hope this will be helpful to folks like me who have tried searching for this sort of thing and haven’t found it outside of case study marketing material.
So far I have set up the software for the two APs and an SM. One of the first things I noticed is that there is no selectable 1x/2x (or 4x/6x/8x). While the PMP 100 platform still seems to need that in my experience, the PMP 320 platform seems very good at automatic selection, so hopefully this will be, as well.
Set up of the AP and SM is otherwise basically the same as on the PMP 100 platform except for a couple of things regarding the Radio and an additional tab, the Custom Frequencies section. When the radio first comes neither the AP nor the SM is configured with any selectable or scannable frequencies; these must all be configured during initial setup. The custom frequencies allow you to include frequencies outside your region, but you won’t be able to select them in the AP, and they will be crossed out on the selection page in the SM.
Since we are going to shoot for 10 MHz channels that should give us 5 non-overlapping frequencies (the documentation says 3 but I do not know why, as I have been informed that there does not need to be a guard channel between them, and even if you had a guard channel you should still be able to achieve 4). So in the Custom Frequencies tab I manually type in and add 3655, 3665, 3675, 3685, and 3695.
On the SM the Radio page is then basically the same, populated with the frequencies you have manually added. On the AP page things are a bit different. There is no sector ID. The biggest change though for the 3.65’s are the “alternate frequencies.” These are included to be compliant with FCC guidelines, specifically “Listen Before Talk,” or LBT. You can set up to two of these alternate frequencies. If the AP hits a certain outside noise threshold it will stop transmitting on its current frequency and switch to the next, listening before beginning transmission.
Gotta run. We intend to run some conduit today and see how far along we get, since we want to pretty up the tower and get some things in order during the upgrade process.
Sounds Great! Do you have any photos that you can share?
So far there is one thing I am quite disappointed in. When these do the WiMAX “listen before talk” thing, apparently there is no mechanism to differentiate between interference from outside and interference from our own AP’s. Since our own AP’s are synced, “interference” from them should not matter, but with the 3.65’s it does. What this means is that, even if the equipment is, as Cambium says, very good at adjacent channel rejection, you still need plenty of guard band on the 3.65 because otherwise it will listen before talk and detect “inteference” from your own AP’s. As I said, very disappointing since I was expecting 5 non-overlapping frequencies but am now limited to 3.
On to the good news. These things have impressive range. The best one so far is an 8.1-mile line of sight installation that was installed without a dish. When we first put it up it was getting an aggregate throughput of between 18 and 21 Mbps. That’s just the SM with its 8 dBi integrated antenna. I’m not used to that with the PMP 100 5.7’s. Now it is getting about 12 Mbps. I suspect the customer-installed pole has twisted a little; we will likely be putting a dish on that one sometime soon, but if it had kept hitting 18+ Mbps we would probably have left it alone. This is with the 10 MHz channel, which is rated for a max aggregate throughput of about 50 Mbps.
Overcoming LoS issues has proven to be a challenge since currently the only way to increase the gain is to use a dish (we have not bought any connectorized so far). The fact that they work so well by themselves helps, but there have been some instances where it probably would work if we could get a dish on the pole but vertical alignment is a bit of a problem when using a pole. Maybe we will figure it out by and by, but if anyone has any pointers in the regard then feel free to point. The one time I’ve really been able to do some good testing in non-LoS conditions is for someone who has a 900 MHz 3’ yagi on a pole on top of his house. With the 900 it is getting -64 receive signal at 2.2 miles firing through the tops of some trees that are basically in his back yard. When I tried a 3.65 without a dish it got -93 or so iirc. Using a dish may have got him to a modulation level I could live with. Bear in mind that these trees are close by. If they had been farther away the multipathing probably would have fared better.
So far the 3.65 space in my area (rural south-central Oklahoma) seems to be staying clear. I can post more later. Here is a photo (Range01) with a link test for that 8.1 mile link: https://www.dropbox.com/sh/m35pnjgaud6wqtt/ullQk693hx
David,
A recommendation would be to sign up for our PMP 450 Beta software program. We have address a few concerns regarding the “listen before talk” issue in the 3.65GHz band, and we have tweaked the interference portion of our software. Software 13.1.3 is currently in beta.
We have quite a few of these deployed, now. We went to 20 MHz channels at the recommendation of Seth Poche from Cambium and we love it. For some reason the FCC lets you bump your power up further with bigger channels, so it actually does better at NLOS now.
Line of sight? Forgetaboutit. One of our techs just put in an LOS at 1.3 miles away with a link test of about 114 Mbps aggregate without a dish. He did another LOS at 2 miles away with a link test of about 79 Mbps without a dish. And I already mentioned the one at 8.1 miles without a dish, which did better when we moved to 20 MHz channels; I did eventually put a dish on his, though, just to save on link budget, and it is now getting over 70 Mbps aggregate.
We've also had pretty reasonable success w/ non-line-of-sight scenarios, I would say. We've got one NLOS up at 2.5 miles without a dish that is getting about 50 Mbps if I remember right. Another at about 3.6 miles with a dish is getting a little under 30 Mbps aggregate. The most impressive NLOS, though, is the one with a dish at 9.2 miles that is getting about 47 Mbps aggregate. Nice!
So far we are liking it. There is one housing addition that seems to have some sort of interference. The two we have deployed there are NLOS but are getting great received power numbers, yet we can't seem to get them over about 12 Mbps aggregate. The SNR on these sometimes hit 9. We are not quite sure what is going on here, but it probably has something to do with signal interference. The thing is, the trajectory for the 8.1 mile link (which is further away and had worse receive signal) that we were running without a dish is literally right through that housing addition.
Anxiously awaiting the next firmware release, which should introduce SISO. Thank you for the replies, Cambium. The firmware updates are great. It also helped to be told (also by Seth Poche) that your three LBT frequencies only need a separation of 0.5 MHz.
I had big plans of one day living off the grid. Now I can't. My name is on the inter-webs now. I guess I need to get a Facebook account now too.
Plainsnet, thank you for sharing your experience here.
I'd be really interested to know what you think of PMP320 vs PMP450 as you have both deployed (Pro's and Con's).
Our goal is to get the PMP450 to the point where it is better than the PMP320 in every area. Do you feel we have done that? What do we need to work on?
Thanks,
Seth
I've read articles by People Who Know that the cool kids don't like Facebook anymore. Apparently Instagram and Twitter are the way to go, now. Just because you work for a tech company doesn't instantly ensure that you are with The Times (as I myself can attest).
The biggest improvement between the 320 and the 450 is the UI. We don't run a provisioning server, so all our provisioning is done at the SM level on most Cambium stuff. On the 320 it is at the AP level, and the mechanisms for doing it are horrible. It only displays 5 SMs at a time in the authorized CPE and service flow lists, and every time we add an SM to it we have to save and reboot the AP or our changes eventually get lost somehow and the SM goes back to the default provisioning level. There are other pain points, but suffice it to say that the UI on the 450 is definitely much better.
Performance is also quite a bit better on the 450, and it's great that adding a dish does not require a connectorized unit. Link budget has more breathing room. Latency on the 450 is a HUGE improvement over the 320; the 320 had latency of around 50 to 60 ms.
We use Cacti as our monitoring solution and supplement that with The Dude when we have to. Neither one of those will monitor true bandwidth on the PMP 320. My network admin tells me that the 320 does not have the necessary OIDs. The 450 is not a problem, however.
Installation and maintenance is generally easier. Easier at the AP side because of the better AP mounting solution. Easier at the SM side because we don't have to use a cable gland.
The range options were very limited with the 320, presumably because it was trying to conform to WiMAX standards. Sometimes this has been annoying. The 450 can be set to any range no matter what channel width is chosen.
The one place that the 320 outdoes the 450 is in its 14.5 dBi integrated antenna vs the 450's 8 dBi. Where this becomes important is pole installations. Generally, putting a dish high on a telescoping pole ranks somewhere between difficult and impossible. This means that with the 320 I was about to get 6.5 more dB of gain on a pole. Sometimes that means the difference between a PMP 320 3.65 and a PMP 100 900 MHz. Which is why I will ask again for a...
CLIP accessory (a.k.a. stinger)! It might be bigger than the 5.7 GHz stingers, but I highly doubt that it will be as heavy and unwieldly as a dish on a pole. Also, WB came out with a 2.4 GHz "super stinger". We've never used 2.4 GHz, but I am using it now... as another argument for a 3.65 GHz CLIP accessory!
The pmp320 puts out 44.5dBm (25watts) transmit power, while the pmp450 only puts out 23dbm (200mw) transmit power.
Even though the 3.65ghz range allows for higher output power than the unliscened 2.4ghz/5.8ghz band, it appears the pmp450 is built to only output 23dbm across all bands with no way of increasing power output via region/custom keys.
The lack of extra power made a huge difference between the pmp320 and pmp450 to Near Line of Sight and Fringe customers I found. In reality all the fancy pants modulation technquies in the world wont help you if the RF propergation is simply not reaching the client.
So the 44.5dBm power rating found on the Spec Sheet for the PMP320 is EIRP. It doesn't represent the Max Tx Power or what is legal.
Actual transmit power per chain is 25dBm for PMP320 and 22dBm for PMP450. So there's only a 3dB difference in Tx Power.
Additionally on PMP320 for the FCC it is illegal to turn the power up past 19.91dBm (per chain) with our 3.65GHz sector antenna, but with the PMP450 the power can be turned up to the full 22dBm (per chain) with the same sector antenna.
So, worst case the PMP450 is only ever 3dB weaker than the PMP320. And for the FCC (because of the larger channels) it is actually more powerful than PMP320.
Can any of you elaborate at all about any problems with the ethernet ports on the PMP 450 3.65Ghz APs dropping out ? We are dealing with a 4 pack of APs on an FM tower. We've used Copper Clad Cat 6a cabling. We put our CMM4 inside a metal box with everything well grounded. 3 of our APs cleared up at that point and seem to be working well. One did not. It will start dropping packets to it's ethernet port even with no traffic going through it. The drops will continue to get worse until it finalliy stops communicating altogether ( you get an error from your own NIC at that point..not just a timeout ). Power cycle it....bam...it comes up and works fine again for who knows how long... a week...a month...2 hours....
It's a weird isue. Just wondering if any one has seen anything like that ??
You should probably start a new topic for this, but no, we have not experienced that problem. The questions I would ask are:
- How long is the total cable run?
- Are you on the latest firmware revision (13.2.1)?
- Were the other APs experiencing this exact problem before you upgraded the cabling?
- Have you tried switching a cable from one of the working APs to the non-working one to see if that fixes it? If you have it on a surge suppressor you would switch to a different surge suppressor, as well.