Mesh/Spectrum - Revision history

Juul: /* Non-DFS channels */

2014-04-18T12:29:26Z

Non-DFS channels

← Older revision		Revision as of 05:29, 18 April 2014
Line 28:		Line 28:
	*157 - 5785 MHz (5765-5805)		*157 - 5785 MHz (5765-5805)
	*161 - 5805 MHz (5785-5825)		*161 - 5805 MHz (5785-5825)
			:Beware that [https://dev.openwrt.org/ticket/10136 you cannot use channel 165 as part of a HT40+/- channel]

	Maximum power output for these channels at 20 or 40 mhz is [http://louise.hallikainen.org/FCC/FccRules/2011/15/407/ 1 watt], with the following caveats:		Maximum power output for these channels at 20 or 40 mhz is [http://louise.hallikainen.org/FCC/FccRules/2011/15/407/ 1 watt], with the following caveats:

Juul: /* 5 GHz */

2014-01-02T21:53:25Z

5 GHz

← Older revision		Revision as of 14:53, 2 January 2014
Line 149:		Line 149:
	== 5 GHz ==		== 5 GHz ==

	Here are some reasonable settings for a point to point or point to multi-point 5 GHz rooftop node:		Here are some (possibly?) reasonable settings for a point to point or point to multi-point 5 GHz rooftop node:

	<pre>		<pre>
Line 157:		Line 157:
	chanbw 20		chanbw 20
	txpower 20		txpower 20
			noscan 1 (?)
	</pre>		</pre>

			These OpenWRT settings are documented [http://wiki.openwrt.org/doc/uci/wireless#common.options1 here].

			I'm not actually sure what the noscan feature does or whether it's a good idea. There's a warning that it will violate regulatory requirements, but I'm not sure if it's related to DFS or if it's something else. - ([[User:Juul\|Juul]] ([[User talk:Juul\|talk]]))

	The ath9k driver does not yet have support for a 802.11n-only mode (also known as greenfield). The closest is 802.11n+a. Apparently you can prevent 802.11a nodes from associating somehow. [http://comments.gmane.org/gmane.linux.drivers.ath9k.devel/10735 source].		The ath9k driver does not yet have support for a 802.11n-only mode (also known as greenfield). The closest is 802.11n+a. Apparently you can prevent 802.11a nodes from associating somehow. [http://comments.gmane.org/gmane.linux.drivers.ath9k.devel/10735 source].

Juul: /* 5 GHz */

2014-01-02T21:19:58Z

5 GHz

← Older revision		Revision as of 14:19, 2 January 2014
Line 156:		Line 156:
	htmode HT40		htmode HT40
	chanbw 20		chanbw 20
	txpower		txpower 20
	</pre>		</pre>

Juul at 21:19, 2 January 2014

2014-01-02T21:19:09Z

← Older revision		Revision as of 14:19, 2 January 2014
Line 144:		Line 144:

	Using a frequency analyzer or software-defined radio with a wide frequency range, it's possible to scan the actual frequency usage across the entire range of interest. Elonics 4000 can scan from 64 mhz to 2.2 ghz and only costs about $25.		Using a frequency analyzer or software-defined radio with a wide frequency range, it's possible to scan the actual frequency usage across the entire range of interest. Elonics 4000 can scan from 64 mhz to 2.2 ghz and only costs about $25.

			= OpenWRT setup =

			== 5 GHz ==

			Here are some reasonable settings for a point to point or point to multi-point 5 GHz rooftop node:

			<pre>
			channel 149
			hwmode 11na
			htmode HT40
			chanbw 20
			txpower
			</pre>

			The ath9k driver does not yet have support for a 802.11n-only mode (also known as greenfield). The closest is 802.11n+a. Apparently you can prevent 802.11a nodes from associating somehow. [http://comments.gmane.org/gmane.linux.drivers.ath9k.devel/10735 source].

			I'm not sure how to set the guard interval. The default is likely 800 ns, which we may want to lower for shorter links or heighten for longer links.

			= Hardware capabilities =

			== 5 GHz ==

			Data rates for various settings can be looked up in [http://en.wikipedia.org/wiki/IEEE_802.11n-2009#Data_rates this table].

			=== Nanostation M5 ===

			Assuming 40 MHz channel and 800 ns guard interval:

			<pre>
			Setting \| Speed \| Modulation \| Tx power \| Rx sensitivity \|
			------------------------------------------------------------------------
			MCS12 \| 162 Mbit/sec \| 16-QAM \| 22 dBm / 157 mW \| -84 dBm \|
			MCS13 \| 216 Mbit/sec \| 64-QAM \| 20 dBm / 100 mW \| -79 dBm \|
			MCS14 \| 243 Mbit/sec \| 64-QAM \| 18 dBm / 63 mW \| -78 dBm \|
			MCS15 \| 270 Mbit/sec \| 64-QAM \| 17 dBm / 50 mW \| -75 dBm \|
			</pre>

Juul at 20:37, 2 January 2014

2014-01-02T20:37:49Z

← Older revision		Revision as of 13:37, 2 January 2014
Line 73:		Line 73:
	</blockquote>		</blockquote>

	=== DFS channels ==		=== DFS channels ===

	None of the DFS channels allow more than 250 mW output power. The TPC requirement only applies if the EIRP is more than 500 mW.		None of the DFS channels allow more than 250 mW output power. The TPC requirement only applies if the EIRP is more than 500 mW.

Juul: Added info on FCC wifi channel rules

2014-01-02T20:37:06Z

Added info on FCC wifi channel rules

@@ Line 1: / Line 1: @@
 We use three different methods to map out spectrum usage.
-= Wifi channel usage scan =
+== Wifi channel usage scan ==
 Most wifi chipsets are capable of reporting:
@@ Line 12: / Line 127: @@
 See the [[Mesh/Software_tools|software tools]] page for suggestions on using this type of scan.
-= Atheros spectral scan =
+== Atheros spectral scan ==
 The Atheros AR92xx and AR93xx chipsets have a spectral scan mode that outputs FFT data for the entire range of the chip.

Juul: Created page with "We use three different methods to map out spectrum usage. = Wifi channel usage scan = Most wifi chipsets are capable of reporting: *How many access points are on each chann..."

2013-12-13T10:19:18Z

Created page with "We use three different methods to map out spectrum usage. = Wifi channel usage scan = Most wifi chipsets are capable of reporting: *How many access points are on each chann..."

New page

We use three different methods to map out spectrum usage.

= Wifi channel usage scan =

Most wifi chipsets are capable of reporting:

*How many access points are on each channel
*With how much power each access point is being received

These measurements don't account for how many clients are using the APs how much of the time and with how much power. There can be several high-powered access points all operating on the same channel in one area, but if they are unused then they will only minimally interfere with other nodes. This type of scan cannot detect if the access points are in use.

See the [[Mesh/Software_tools|software tools]] page for suggestions on using this type of scan.

= Atheros spectral scan =

The Atheros AR92xx and AR93xx chipsets have a spectral scan mode that outputs FFT data for the entire range of the chip.

Ubiquiti AirOS has a [[Mesh/Software_tools#AirView_Spectrum_Analyzer|built-in java applet]] that visualizes the spectral scan output. Unfortunately it does not provide any kind of documented API.

Support for atheros spectral scan has as far as we know not yet been implemented into the open source Linux kernel driver, but there is an effort to support this functionality. Here are some resources:

*[https://github.com/simonwunderlich/ath_spectral A kernel driver patch adding spectral scan support + gui]
**[https://github.com/LorenzoBianconi/ath_spectral Looks like an updated version of the above]
*[https://github.com/simonwunderlich/FFT_eval A GUI for visualizing the spectral scans]
*[https://wiki.freebsd.org/dev/ath_hal(4)/SpectralScan Adrian's information]
*[http://wireless.kernel.org/en/users/Drivers/ath9k/spectral_scan/ Some general info]

= Frequency analyzer scan =

Using a frequency analyzer or software-defined radio with a wide frequency range, it's possible to scan the actual frequency usage across the entire range of interest. Elonics 4000 can scan from 64 mhz to 2.2 ghz and only costs about $25.