I was cruising around the AREDN html map looking at the beta nodes that are running. I see a few nodes that have channel and bandwidth settings that I believe put them out of band. For example, running 20MHz bandwidth on 5GHz channel 184 will put you out of the ham allocation. (5920 is the center of 184, 10MHz on the high side puts a signal up to 5930)
My first question...the channel frequencies....those are center frequencies, right?
Second question...Is it true that the ubiquty or tp-link hardware doesn't know anything about the ham band limits, and so setting a channel of 184 with anything higher than a 10MHz bandwidth will cause emissions out of band?
And third question...Would it be beneficial to add some javascript to the UI that warns the user when a combination is selected that will result in out of band transmissions?
Thanks,
Mike
My first question...the channel frequencies....those are center frequencies, right?
Second question...Is it true that the ubiquty or tp-link hardware doesn't know anything about the ham band limits, and so setting a channel of 184 with anything higher than a 10MHz bandwidth will cause emissions out of band?
And third question...Would it be beneficial to add some javascript to the UI that warns the user when a combination is selected that will result in out of band transmissions?
Thanks,
Mike
Much like an HF radio one needs to look at the frequency being used and the width of transmission and ensure they leave ample band edge clearance as to not spill out of band.
Regarding warning Java text, The main concern I have with that is the fact every country is different, and while majority of development is done in the US the software is intended to be used internationally. There has been a specific avoidance to date of trying to force any "US Only" localization to the operations of the node which a bandplan warning would likely fall under. With ever changing laws it would be pretty hard to make this feature for every country and keep it up to date.
I'll routinely comment if I hear an out band signal combination being proposed (there have been a few in forum) but ultimately the HAM deploying should know the regulations for their area better than we would.
I had made a suggestion, a couple of months ago, to display the actual upper and lower frequency edges resulting from the menu choices. That way everybody can evaluate where they are relative to their country's band plan. This is exactly what Ubiquiti does in their OEM firmware. The code for it is probably already there somewhere....
And nope it would be new code, wifi runs on a channelized system, it has no concept of a frequency so most items are calculated from channel (which creates some interesting items in the lower protocols) so showing of frequency is currently extrapolated. That said it is based on simple math so makes it much easier to do, just have to take the center and the bandwidth and display. The User interface non interactive updating method is the main limiter at moment, this may be helped by AREDN->ticket:159
Here is what the OEM looks like
and here are some some bits of display code
var g=parseFloat(d.frequency); var k=parseFloat(f)/2; var p=setExtendedChannel(d.opmode); if (p==1){$("#freqstart").text(g-k/2);$("#freqstop").text(g+k+k/2+" MHz")} else {if(p==-1){$("#freqstart").text(g-k-k/2);$("#freqstop").text(g+k/2+" MHz")} else {$("#freqstart").text(g-k);$("#freqstop").text(g+k+" MHz")}}} else {$("#wd").text("-");$("#freqstart").text("-");$("#freqstop").text("-")}} else {$("#wd").text("-");$("#ext_chan").hide()}$("#freqwidthinfo").toggle(e.enabled);I am making a legal channel/bandwidth chart for my own local use and wanted to make sure I get things right.
It's a bit difficult for me to find what I'm looking for as there are so many hits for searches like "wifi channel bandwidth", and they all say pretty much the same, non-technical, info.
These are truly X MHz (or less) wide channels, yes?
As the original post mentioned 5GHz channel 184, I'll use it as the example.
Would using a 10MHz channel here be legal? 5920+5=5925; this is completely to the edge of the band.
I'm thinking in comparison to operating at, say, 14.348MHz USB. The "carrier" would be in band, but typical SSB filters would potentially put part of your signal out of band.
What about the accuracy and stability of the oscillator? Is Ubiquiti actually able to get the channel center at exactly 5,920,000,000Hz? For every unit? Can each unit maintain that frequency precisely?
If not, how far off are they, and does this give us out of band signals?
Based on some of what I'm seeing, if you're using 802.11n at at 20MHz channel, it actually uses subcarriers to a width of +- 8.125MHz, and then the roll off keeps it within the 20MHz bandwidth. (Ref : https://en.wikipedia.org/wiki/List_of_WLAN_channels#United_States)
Is this the case and is there enough roll off to keep the channel legal?
A number of variables here, with potential pitfalls to unintentionally put us out of band.
Cheers.
Technically no, 802.11n mode yes, but the devices also run 802.11b mode which a 20MHz channel is actually 22Mhz (a 10MHz would be 11MHz, and a 5MHz would be 5.5MHz) so you need to add a little bit to calculate.
>I'm thinking in comparison to operating at, say, 14.348MHz USB. The "carrier" would be in band, but typical SSB filters would potentially put part of your signal out of band.
These are a fair bit different than SSB transmitters, they don't generate a full wave carrier and filter it out, they actually much closer to SDR's in that the signals are directly generated, Its more like a number of very very narrow bandwidth pulses packed into the bandwidth (oversimplifying it) but yes you do have noise that rolls off from transmitter switching pulses on and off constantly that should be accounted for.
>What about the accuracy and stability of the oscillator? Is Ubiquiti actually able to get the channel center at exactly 5,920,000,000Hz? For every unit? Can
>each unit maintain that frequency precisely?
>If not, how far off are they, and does this give us out of band signals?
This isn't specified, but its a PLL circuit internally. The accuracy on this part is going to be decent as it has to be to stay locked on so many signals, but its obviously not going to be precise, honestly though this gets swamped by the noise from the previous question about roll off which will be MUCH wider than the possible frequency drift to stay locked in 802.11 modes.
> Is this the case and is there enough roll off to keep the channel legal?
Going to need to calculate off the full width (as noted above) since 802.11b mode is used for beacons. And then apply some roll off after that for good measure.
That said these devices did have to original meet the specifications of Part 15 for accuracy and roll off, so you can compare Part 97 vs Part 15 and see which is stricter.
> this is completely to the edge of the band.
It is never wise to touch the band edge ever, even if one is sure they can keep the signals inside the band.
Personal Opinion:
No one has ever lost their license for avoiding the band edge.
Allow at least a reasonable gap (MHz not Khz) from the band edge for good measure. The wider the signal the more you will want to leave vacant as a precaution.
That's the answer I expected, thanks for the confirmation.
I knew the SSB example wasn't an exact comparison, but the general principle was the same.
So, long story short (too late!) a 10MHz bandwidth on channel 184 is not legal for us in the US.