[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Bluetooth Transmitter using GRC

From: Marcus Müller
Subject: Re: [Discuss-gnuradio] Bluetooth Transmitter using GRC
Date: Tue, 13 Jan 2015 15:16:02 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0

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,

On 01/13/2015 02:44 PM, Mostafa Alizadeh wrote:
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?


On Tue, Jan 13, 2015 at 3:02 PM, Jeff Long <address@hidden> wrote:

On 01/12/2015 01:07 PM, Mostafa Alizadeh 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.


On Mon, Jan 12, 2015 at 2:52 PM, Jeff Long <address@hidden
<mailto:address@hidden>> 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)
        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://gr-bluetooth.sourceforge.net/>), However it is not a
        complete stack and I guess it doesent include the Bluetooth
        I built it and checked but couldn't find one. Can you suggest any
        existing implementation of complete Bluetooth stack ?
        Any Help is appreciated.


        Discuss-gnuradio mailing list
        address@hidden <mailto:address@hidden>

    Discuss-gnuradio mailing list
    address@hidden <mailto:address@hidden>

Department of Electrical Engineering
Aboureyhan Building
Amirkabir University Of Technology
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

Discuss-gnuradio mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]