A Nice Discussion :
The answer is no.
The bandwidth is too large for the system to currently handle.
If you tune the GNU Radio to the center frequency of an 802.11 channel, you'll see what looks like a rise in the noise floor (and, under these conditions, it really is a rise in the noise) when there is a transmission.
Bluetooth signals hop from 2.402 - 2.480 MHz
79 1 MHz channels at a rate of 1600 hops per second.
The GNU Radio cannot look a the entire band all at once
If you look at a particular slice (~4 MHz) of spectrum, you might catch a glimpse of a signal every now and then, unless you can plug in the right frequency hopping sequence
If you have some 1 or 2 Mbps 802.11 devices to use, the BBN guys have done
work on receiving those. Here is the link.
Reference : http://gnuradio.4.n7.nabble.com/802-11-and-Bluetooth tc8615.html#a8618
usrp_spectrum_sense.py application can sense a large bandwidth, but not in real time! It can do a sweep over a very large frequency range, but it will very likely not be able to detect bluetooth (since it is frequency hopping) nor 802.11b/g since this will most likely just look like noise.
Anyway, it is difficult to just detect wi-fi without trying to decode it, since it is not a continuous signal, i.e., packet oriented. Therefore, you won't have a
nice peak in your fft, compared to a radio broadcast channel.
Normally an AP will send beacons at 1 Mbps even if it is a b/g AP.
Here Eric says :
Actually, I think you should be able to detect Bluetooth without too
much trouble. If you just stare at a single point in the spectrum you
should be able to reliably detect 7 1 MHz channel's worth of data.
IIRC the hopping sequence is known, and thus you should be able to
determine if what you are seeing is bluetooth or not, even though you
are seeing only 7 out of 79 channels.
Eric
Bandpass sampling says :
Bluetooth is only about 1 Mb/s data rate, so you should be able to decode it with only a few MSPS of sampling.
The answer is no.
The bandwidth is too large for the system to currently handle.
If you tune the GNU Radio to the center frequency of an 802.11 channel, you'll see what looks like a rise in the noise floor (and, under these conditions, it really is a rise in the noise) when there is a transmission.
Bluetooth signals hop from 2.402 - 2.480 MHz
79 1 MHz channels at a rate of 1600 hops per second.
The GNU Radio cannot look a the entire band all at once
If you look at a particular slice (~4 MHz) of spectrum, you might catch a glimpse of a signal every now and then, unless you can plug in the right frequency hopping sequence
If you have some 1 or 2 Mbps 802.11 devices to use, the BBN guys have done
work on receiving those. Here is the link.
Reference : http://gnuradio.4.n7.nabble.com/802-11-and-Bluetooth tc8615.html#a8618
usrp_spectrum_sense.py application can sense a large bandwidth, but not in real time! It can do a sweep over a very large frequency range, but it will very likely not be able to detect bluetooth (since it is frequency hopping) nor 802.11b/g since this will most likely just look like noise.
Anyway, it is difficult to just detect wi-fi without trying to decode it, since it is not a continuous signal, i.e., packet oriented. Therefore, you won't have a
nice peak in your fft, compared to a radio broadcast channel.
Normally an AP will send beacons at 1 Mbps even if it is a b/g AP.
Here Eric says :
Actually, I think you should be able to detect Bluetooth without too
much trouble. If you just stare at a single point in the spectrum you
should be able to reliably detect 7 1 MHz channel's worth of data.
IIRC the hopping sequence is known, and thus you should be able to
determine if what you are seeing is bluetooth or not, even though you
are seeing only 7 out of 79 channels.
Eric
Bandpass sampling says :
Bluetooth is only about 1 Mb/s data rate, so you should be able to decode it with only a few MSPS of sampling.
No comments:
Post a Comment