@UBNT-James @UBNT-SNK @UBNT-sriram
I've read through some past threads (one of which appears to be locked). That being said, it appears the main reason why is because the topic had trailed off in several directions, with many questions being asked multiple times. That being said, from what I have read I see 2 potential reasons this hasn't happened:
1. Possible issue with processing power of rocket not able to support 80MHz and PTMP
2. It being determined that the bphz will not be efficeint enough to justify such a use.
Can you confirm if there is a restriction in the processing power?
As for the 2nd, I think this is a massive mistake. I can understand in UNII-1 and UNII-3 where there is so much competition for bandwidth that it's unlikely to ever be beneficial to run a larger beamwidth antenna (sector) that is needed for an AP. However, UNII-2a and 2c are very clean in a lot of rural markets. In ours it's as good as licensed in the whole of those 2 parts of the spectrum. If the devices could support it, it would be awesome to be able to get the increase in capacity. I am aware that it won't likely double, as receive sensitivities are much more strict, but we have plenty of clients with exceptional signal quality (-40s) that would benefit. Also, since the regulations are more strict in the DFS range, transmit power is already reduced a signifigant amount to help gauruntee reliable transmission at these modulations.
Regarding 80MHz PTMP (2) is the main reason. (1) is also a reason especially for 'WA' chipset.
But there is also a reason for spectrum abuse. Using a traditional sector and spraying energy in a wider direction on 80MHz would become common and bring down the quality for other operators in the area also.
@UBNT-sriramHave you considered enabling it only for the XC chipset (can WA clients support it?) and locking it to UNII-2A and 2C specifically? There is a lot of open space, and the decreased transmit power helps a lot to! You could even force Check EIRP.
WA clients use same radio as XC so they will be able to connect. Just that they will not get the full speeds.
With all this being said, we are planning on releasing 80MHz FLEXIBLE NEW based option at the beginning for PTP only i.e. it will allow only one client to connect.
We can easily enable this to support PTMP later as the under pinnings will be there.
As a side note, we will not be able to support Fixed Frame though on 80MHz and the options will be limited to FLEXIBLE NEW only.
Wednesday - last edited Wednesday
@UBNT-sriramI'm assuming this is the CPU limitation coming into play preventing fixed frame from working in 80MHz? The additional cpu load from managing the GPS syncronization?
Yeah it is CPU and also memory on the coprocessor. Right now we cannot go below 5ms for fixed frame and hence for the same amount of time i.e. 5ms for 80MHz we pottentially send double the number of packets and for this we need more memory for that and also more memory for some state information.
But for FLEXIBLE-NEW (which is based on FIXED FRAME and runs the same code), simply because we do not need to maintain a fixed frame it makes it possible.