Bluetooth Transmitter using GRC

GNU Radio
1

Hi All,

I am searching for an implementation of a complete Bluetooth stack on
GRC
3.7 ( Including the Bluetooth Transmitter and Receiver) preferably
working
with USRP N210. So far I got this “gr-Bluetooth, Bluetooth for GNU
Radio” (
http://gr-bluetooth.sourceforge.net/), However it is not a complete
stack
and I guess it doesent include the Bluetooth Transmitter. I built it and
checked but couldn’t find one. Can you suggest any existing
implementation
of complete Bluetooth stack ?
Any Help is appreciated.

Regards,
Vaibhav

2

On 01/10/2015 02:46 PM, vaibhav kulkarni wrote:

Hi All,

I am searching for an implementation of a complete Bluetooth stack on
GRC 3.7 ( Including the Bluetooth Transmitter and Receiver) preferably
working with USRP N210. So far I got this "gr-Bluetooth, Bluetooth for

You could build one in the FPGA of an X-series box. Latency and tuning
requirements exceed what you can do with a N210.

3

Hi Jeff,

What is your reason for saying: “Latency and tuning” of the N210 device
isn’t appropriate???

Best,
Mostafa

On Mon, Jan 12, 2015 at 2:52 PM, Jeff L. removed_email_address@domain.invalid wrote:

requirements exceed what you can do with a N210.

Discuss-gnuradio Info Page

–

Department of Electrical Engineering
Aboureyhan Building
MMWCL LAB
Amirkabir University Of Technology
Tehran
IRAN
Tel: +98 (919) 158-7730
LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411
Homepage: http://ele.aut.ac.ir/~alizadeh/

4

Yeah I have had a look at Bluetooth PHY. The hop rate of Bluetooth in
paging substate increases as 3200 hop/sec too. So you mean the N210 USRP
can’t support 1600 (or 3200) hop/sec?
What do you mean by “latency”? Is that the latency of the USB or
Ethernet?
Jeff, please clarify your stance. Why the latency problem doesn’t matter
X-series USRP?

Best,
Mostafa

On Tue, Jan 13, 2015 at 3:02 PM, Jeff L. removed_email_address@domain.invalid wrote:

hops/sec. Take a look at the Bluetooth physical layer spec for more info.

    Hi All,
tuning requirements exceed what you can do with a N210.
    Vaibhav
_________________________________________________

Department of Electrical Engineering

Discuss-gnuradio mailing list
removed_email_address@domain.invalid
Discuss-gnuradio Info Page

–

Department of Electrical Engineering
Aboureyhan Building
MMWCL LAB
Amirkabir University Of Technology
Tehran
IRAN
Tel: +98 (919) 158-7730
LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411
Homepage: http://ele.aut.ac.ir/~alizadeh/

5

On 01/12/2015 01:07 PM, Mostafa A. wrote:

Hi Jeff,

What is your reason for saying: “Latency and tuning” of the N210 device
isn’t appropriate???

I should have said that, with either USB or Ethernet, and with a
non-real-time O/S, the latency to too great. Hop rate is generally 1600
hops/sec. Take a look at the Bluetooth physical layer spec for more
info.

6

The latency is an issue when action of one side is dependent on reaction
of
the other side. Usually there are narrow time limits that have to be
considered, and the time an action travels over USB or Ethernet may
simply
be to long. The other thing may be jitter, many protocols do not like
variations in the timing, but those are more or less normal for USB or
Ethernet. The closest binding between hardware and controller is doing
it
all in the FPGA, what could be considered as a real time system.

Ralph.

From: discuss-gnuradio-bounces+ralph=removed_email_address@domain.invalid
[mailto:discuss-gnuradio-bounces+ralph=removed_email_address@domain.invalid] On Behalf Of
Mostafa A.
Sent: Tuesday, January 13, 2015 2:44 PM
To: Jeff L.
Cc: removed_email_address@domain.invalid
Subject: Re: [Discuss-gnuradio] Bluetooth Transmitter using GRC

Yeah I have had a look at Bluetooth PHY. The hop rate of Bluetooth in
paging
substate increases as 3200 hop/sec too. So you mean the N210 USRP can’t
support 1600 (or 3200) hop/sec?

What do you mean by “latency”? Is that the latency of the USB or
Ethernet?

Jeff, please clarify your stance. Why the latency problem doesn’t matter
X-series USRP?

Best,

Mostafa

On Tue, Jan 13, 2015 at 3:02 PM, Jeff L. <removed_email_address@domain.invalid
mailto:removed_email_address@domain.invalid > wrote:

On 01/12/2015 01:07 PM, Mostafa A. wrote:

Hi Jeff,

What is your reason for saying: “Latency and tuning” of the N210 device
isn’t appropriate???

I should have said that, with either USB or Ethernet, and with a
non-real-time O/S, the latency to too great. Hop rate is generally 1600
hops/sec. Take a look at the Bluetooth physical layer spec for more
info.

Best,
Mostafa

On Mon, Jan 12, 2015 at 2:52 PM, Jeff L. <removed_email_address@domain.invalid
mailto:removed_email_address@domain.invalid
<mailto:removed_email_address@domain.invalid mailto:removed_email_address@domain.invalid >> wrote:

On 01/10/2015 02:46 PM, vaibhav kulkarni wrote:

    Hi All,

    I am searching for an implementation of a complete Bluetooth
    stack on
    GRC 3.7 ( Including the Bluetooth Transmitter and Receiver)
    preferably
    working with USRP N210. So far I got this "gr-Bluetooth,
    Bluetooth for


You could build one in the FPGA of an X-series box. Latency and
tuning requirements exceed what you can do with a N210.

    GNU Radio" (http://gr-bluetooth.__sourceforge.net/

http://sourceforge.net/
http://gr-bluetooth.sourceforge.net/), However it is not a
complete stack and I guess it doesent include the Bluetooth
Transmitter.
I built it and checked but couldn’t find one. Can you suggest
any
existing implementation of complete Bluetooth stack ?
Any Help is appreciated.

    Regards,
    Vaibhav


    _________________________________________________
    Discuss-gnuradio mailing list
    removed_email_address@domain.invalid <mailto:removed_email_address@domain.invalid>

<mailto:removed_email_address@domain.invalid mailto:removed_email_address@domain.invalid >
https://lists.gnu.org/mailman/__listinfo/discuss-gnuradio
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_________________________________________________
Discuss-gnuradio mailing list
removed_email_address@domain.invalid <mailto:removed_email_address@domain.invalid>

<mailto:removed_email_address@domain.invalid mailto:removed_email_address@domain.invalid >
https://lists.gnu.org/mailman/__listinfo/discuss-gnuradio
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

–

Department of Electrical Engineering
Aboureyhan Building
MMWCL LAB
Amirkabir University Of Technology
Tehran
IRAN
Tel: +98 (919) 158-7730
LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411
Homepage: http://ele.aut.ac.ir/~alizadeh/

Discuss-gnuradio mailing list
removed_email_address@domain.invalid mailto:removed_email_address@domain.invalid
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

–

Department of Electrical Engineering

Aboureyhan Building

MMWCL LAB

Amirkabir University Of Technology

Tehran

IRAN

Tel: +98 (919) 158-7730

LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411

Homepage: http://ele.aut.ac.ir/~alizadeh/

7

The architecture itself can basically deal at arbitrary sample
boundaries; however, as soon as you tune a physical thing like an LO,
you need some time, especially since the LOs generated on USRP
daughterboards discipline the LOs to the high-quality reference clock
using PLLs. Depending on the frequency, the frequency delta, the
daughterboard, environmental situations as well as individual component
variances, the time from tune to stable oscillator changes; these times
are in the order of multiple milliseconds, in most cases.

You could avoid analog tuning by only doing frequency shifting in the
DSP on the N210’s FPGA; however, the N210-compatible daughterboards have
a bandwidth of 40MHz, so this is not possible for Bluetooth (which is
spread over 80MHz).

With the X3x0, you can use 120MHz daughterboards, which would enable you
to do purely digital tuning.

I am, however, not familiar enough with the Bluetooth PHY to assess
whether there are latency constraints that prohibit control by a PC –
if the hop sequence is known sufficiently before transmission starts,
one could try to generate timed commands that tune the DSP on specific
samples. However, that might get a bit ugly, because the on-device
command queue has a limited length, so you might need to send timed
commands at high rates.

Alternatively, the 80 MHz bandwidth comfortably fits into the sampling
rate you can get in and out of the X3x0 via 10GigEthernet – but then,
your PC will be burdened with the task of continously generating more
than 80MS/s – for 2 MHz of instantaneous bandwidth.

Best regards,
Marcus

8

Hi Marcus,

You pointed out important notes. The first one is that there is two
possible solution for implementing such wideband system:

1- Bringing the whole bandwidth to the baseband.
2- Using timed command for tuning to the desired center frequency.

The second point is that the instantaneous bandwidth of the system, or
better to say, the bandwidth of the modulated signal is a few portion of
the whole bandwidth, so the first scheme isn’t appropriate in the sense
of
wideband digitalization.

However, there is another point needed to be noticed and that’s the LO
(local oscillator) capability of the daughterboard. I mean, does have
the
X-series enough ppm (lower than 3 ppm)? The LO also shall have suitable
switching time too.

Best,
Mostafa

On Tue, Jan 13, 2015 at 5:46 PM, Marcus M. removed_email_address@domain.invalid
wrote:

on the N210’s FPGA; however, the N210-compatible daughterboards have a
However, that might get a bit ugly, because the on-device command queue has

Best,

Best,
GRC 3.7 ( Including the Bluetooth Transmitter and Receiver)
complete stack and I guess it doesent include the Bluetooth
Discuss-gnuradio mailing list
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Tehran

removed_email_address@domain.invalid
Discuss-gnuradio Info Page

–

Department of Electrical Engineering
Aboureyhan Building
MMWCL LAB
Amirkabir University Of Technology
Tehran
IRAN
Tel: +98 (919) 158-7730
LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411
Homepage: http://ele.aut.ac.ir/~alizadeh/

9

On 01/14/2015 02:29 PM, Mostafa A. wrote:

Hi

However, there is another point needed to be noticed and that’s the LO
(local oscillator) capability of the daughterboard. I mean, does
have the X-series enough ppm (lower than 3 ppm)? The LO also shall
have suitable switching time too.
The X3xx series uses a 2.5PPM TCXO, just like the N2xx series. If that
isn’t accurate enough, you can always use an external, higher-accuacy
reference.

You use the same daughtercards in the X3xx as the N2xx, except that with
the -120 cards (designed specifically for X3xx), they have a wider
analog baseband, to “match” the ADC sample rate. So, the LO
switching times would be the same–on the order of a few milliseconds.
LO architectures for wideband frequency hopping need to be explicitly
engineered for that particular application, and it looks like BlueTooth
hop-rates are sub-millisecond, so you can’t hop the LO fast enough,
but as Marcus Mueller points out, you can hop within a wide baseband.

10

Thank you for providing enough information about USRPs.
So as a conclusion, if one needs to implement a Bluetooth device, he
shall
use X3xx USRP.

Best,
Mostafa

On Thu, Jan 15, 2015 at 12:10 AM, Marcus D. Leech removed_email_address@domain.invalid
wrote:

The X3xx series uses a 2.5PPM TCXO, just like the N2xx series. If that
as Marcus Mueller points out, you can hop within a wide baseband.
Mostafa

Depending on the frequency, the frequency delta, the daughterboard,
to do purely digital tuning.
PC will be burdened with the task of continously generating more than
paging substate increases as 3200 hop/sec too. So you mean the N210 USRP

I should have said that, with either USB or Ethernet, and with a
On 01/10/2015 02:46 PM, vaibhav kulkarni wrote:

–

–

Department of Electrical Engineering
Aboureyhan Building
MMWCL LAB
Amirkabir University Of Technology
Tehran
IRAN
Tel: +98 (919) 158-7730
LAB: http://ele.aut.ac.ir/~mmwcl/?page_id=411
Homepage: http://ele.aut.ac.ir/~alizadeh/

11

Hello Mostafa,

However, there is another point needed to be noticed and that’s the LO
(local oscillator) capability of the daughterboard. I mean, does
have the X-series enough ppm (lower than 3 ppm)?
4 bluetooth dongles don’t have 3ppm accuracy, because real world
systems either are much more forgiving with respects to frequency
offsets and drifts, or because correction takes place all the time.
In the case of a half-duplex system, the transmitter can usually do
nothing but do its best to be stable (a 4 price tag might make that
hard) in frequency, and let the receiver figure out the necessary offset
correction; often in RF communications, that’s already necessary to
account for the doppler effect.

That being said, the X300 has a specification [1] that exceeds 3ppm
oscillator accuracy.

The LO also shall have suitable switching time too.
That would contradict what I wrote in my first mail: It doesn’t have to
tune at all. If you have a device such as the X3x0 which can cover the
whole band with its physical sampling rate, you can just shift around
your band using the DSP chain, without any intervention of analog parts,
and especially without retuning the LO.

Best regards,
Marcus

[1] http://www.ettus.com/content/files/X300_X310_Spec_Sheet.pdf