Nice map, saved for later reference, Thanks!
1 Like
I guess you missed my exact point...or I'm confused:
Can you explain what would be the "properly displayed channel" on the AP when set to 40, 80 and 160 MHz?
And how would it be "center"?
(Your graph shows the point.)
Im not sure i get your question. The bandplan is pretty clear on this.
I will try to explain a different way.
20mhz channels = 36,40,44,48,52,56,60,64,100,104,108,112,116,120,124,128,132,136,140,144,149,153,157,161,165
40Mhz channels = 38,46,54,62,102,110,118,126,134,142,151,159
80Mhz channels = 42,58,106,122,138,155
160Mhz channels = 50,114
You will notice that the same number does not show up in more than one list. This is how the bandplan was designed. If you select a channel it automatically corresponds to its bandwidth.
As far as "Center" goes look at the chart.
The center between 20mhz channels 36 and 40 is 38. There are 4 steps between 36 and 40 so 2 steps is the center aka 38 is the 40mhz channel.
Same goes for the next section The center between 38 and 46 is 42. so 42 is the 80mhz channel
I guess not.
(If the AP is set to e.g. ch. 155...we agree that's a "80 MHz" channel...I merely asked what channel is the proper display under your theory for a client with a 20 MHz radio...but you seem to miss that. No worries, most WiFi apps display/list them in that way I'm referencing - and so does OpenWrt. Inversely...if a 80 MHz AP lowers power/width into 40 or 20 MHz...what channel is it on? 
In OpenWrt, that answer is simple.)
I thought the graph was also clear that there was no "center"...but again perhaps I'm looking at numbers divisible by 2 differently on this chart.
I got that already...which is why you believe that you can just list the channels without bandwidth.
I'll look some more...perhaps I'm just missing this. Thanks for responding. 
1 Like
if the client is only 20Mhz than the client will show whichever one of the 20Mhz channels (within the 80Mhz band) it is connected to
on channel 155 you can connect to ANY of the lower channels in that set. So 151, 159 for 40Mhz or 149,153,157,161 for 20 Mhz.
None of that matters in the UI when selecting the channel though.
To find center just add the channels and divide by 2.
54+62= 116
116/2 = 58
Exactly how the chart is laid out in every case.
1 Like
That's how 160, 80 and 40 MHz APs work too. They may beacon the bandwidth; but it only uses it during traffic. You can see this on the wireless display page when you start a speedtest.
Under OpenWrt's method, I was merely noting you don't have to guess what channel the devices are using.
That would mean WiFi devices would have to be programed like this. They currently set a channel (and bandwidth). But im still not sure how it centers 20 on a 160 for example...
No biggie; your method is a good idea too. 
Wifi devices autonegotiate bandwidth and channel. The device does not get to decide channel, the AP does.
Channels are for human readability and bandplanning and therefore should be reflected PROPERLY in OpenWRT.
The way it stand OpenWRT is not in step with the rest of the industry in this regard. This should be changed, not defended.
I'm not defending...but I am confused how changing OpenWrt so the viewer doesn't know the actual frequency in use is better?
Centering 20 on a 460 is the same only there are slightly more steps as you are hopping levels.
adding 36,40,44,48,52,56,60,64 = 400
but we are 3 layers deep at that point.
400 /2 = 200
200 /2 = 100
100 /2 = Channel 50
If the AP was set to channel 50 and a 20mhz client connected, it could use any of the channels 36,40,44,48,52,56,60,64.
There is not "frequency in use" its not a frequency its a frequency RANGE. knowing the CENTER frequency in use would be more correct.
Knowing the CENTER FREQUENCY and the BANDWIDTH gives you the frequency range. This is how all radio communications are calculated. Of course there are also Sidebands but that does not apply here.
I am a radio operator with experience in bandplanning radio frequencies.
OpenWRT does this in a non standard way .
1 Like
As am I...and thank you for responding...it just seems quite standard to me (if you actually needed to know the true frequency on air with a meter, etc.). I do agree the display is different.
Thanks for the point of view.
Would it not be easier and cut out so much confusion if we just used the channels that are tied to bandwidth?
BTW this is a great exercise, discussing these concepts and opposing perspectives always makes for a good discussion.
The way this is implemented may seem kind of convoluted but in order to really understand the mindset you have to consider the underlying actual regulatory 5mhz channel spacing. When the 2.4ghz band was allocated, some geniuses decided that it would be stylish to put a bunch of 20mhz wide devices on 5mhz spacing with a 75% overlap. This led some users (a bunch in fact) to think that they had a large river of 11 channels.when in fact they really only have 3 that don't collide. When the 5ghz band was in its infancy a collective of affected parties said "overlap=bad, lets not do this again" and in the course of figuring out how to address overlap prevention they arrived at what we have today. The main point being that whatever you the consumer choose, we the radio guys know what is right for your asking for versus what it means to not enable overlap. This is the blending of an industries goals (radio providers, no overlap) with the regulatory stipulations of the FCC(5Mhz channel spacing, overlap schmoverlap, who cares). So the industry has followed the industry's path and here we are. Now to make it even more interesting, we have the conformance outliers. For example, Ubiquiti has a pretty big line of hardware, and one of the things they do is a hybrid blend of complying, and not complying. They support the standard channel/bandwidth model on standard channel and bandwidth combinations, but they also support their own view and implementation of the bands. What they do in the latter case complies with FCC regulations while essentially giving the middle finger to the industry goals. They do this by supporting 5mhz, 8mhz, 10mhz, 30mhz on any 5mhz boundary, centered on the actual center of the selected channel. They are just one example of the latitude many vendors have taken with these bands. This may or may not help you understand but I figured I would try to give you some of the background.
If I understand you, one just looses the ability to set the channel when the radio is in lower [power-saving] bandwidth.
Or in other words, one would have to guess what on-air frequency is being used.
I'm referencing which 20 MHz "ranges" are in use at any given time - if that phrasing is more clear. I'm guessing is difficult to see on some screens that e.g. a 40 MHz has 2 20 MHz channels. When it's power-saving, it uses one (it doesn't center, otherwise they'll be interference - and it has to be "center" on the 20 MHz "range" for a 20 MHz client). I'm sure you know that - but I'm not sure why the center term confuses you.
I'll also have to check with version 21 that is still the case.
One would lose the ability to set bandwith. The would select the channel and thats it. The bandwidth would be tied to the channel they selected. So if you listed the channels in a dropdown, with their bandwidths next to them, the user chooses one and it's done.
BTW mathematically or numerically the bandplan is already setup like this.
The whole add then divide thing works to find the center frequencies too.
5180(36)+5200(40) = 10380
10380/2 = 5190(38)
1 Like
Correct...so you agree the center on a 20 MHz client connected to a 40 MHz AP cannot be the center of the 40MHz range.
I think we all understand...
and have quirks about how OpenWrt lists the channels too, lol....because in OpenWrt...that is the displayed channel.
the center on the 20 mhz channel would be the width of the 40mhz channel divided by 2 and the take the center of that.
Also to be clear the bandplan uses center frequencies so 5180 is the center frequency of channel 36 not its lower bound.
ref: https://www.cablefree.net/wirelesstechnology/wireless-lan/wlan-frequency-bands-channels/
SO if we are already displaying center frequencies of all 20mhz channels, why not include the rest of the channels doing the same and make band width selection a moot point?
Perhaps I don't understand your phrasing...or that's what we don't agree on.
Example: I'm thinking you and the other poster are saying that a 20 Mhz client on a 40 MHz AP will lock into "the center of channel 38" (i.e. 5190)- and not "the center of 36 (5180) or the center of 40 (5200)."
I'll have to verify that (it's been a while) - but I understand the confusion now and thought we clarified.
Thanks for the convo...time to test on the bench when I have time!
If that's the case, I agree the channel listing are arbitrary using either method then - it's just that OpenWrt's method is least-used.
Lets give an example.
i set the channel to 42 on my AP (that's a 80mhz wide channel)
You try to connect to my AP using a device that can ONLY handle 20mhz.
Your center frequency could be 5180 (the center of 36) 5200 (the center of 40), 5220 (the center of 44) or 5240 (the center of 48)
How would the AP "know" this.
Well its actually simple.
The AP has 80 mhz bandwidth
you want 20mhz
it divides the 80 mhz bandwidth into 20 mhz chunks and center the client on one of those chunks.
Same goes for if you can only do 40mhz, it does 2 chunks and centers on one of those chunks.
This means there is never any overlap or interference.When the bandplan was created this was the point of grouping it the way it is. 180 mhz channel, = 240mhz channels = 4*20 mhz channels.
So when you select the channel number the rest is baked right in.
1 Like