# Bluetooth Transmitter using GRC **URL:** \ **Category:** GNU Radio\ **Created:** [January 10, 2015, 8:47pm UTC](https://www.ruby-forum.com/t/bluetooth-transmitter-using-grc/233775 "2015-01-10T20:47:29Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![addis\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c4cdca/32.png) [@addis\_a](https://www.ruby-forum.com/u/addis_a)\ **Post date:** [January 10, 2015, 8:47pm UTC](https://www.ruby-forum.com/t/bluetooth-transmitter-using-grc/233775/1 "2015-01-10T20:47:29Z")
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/](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 ---
**Author:** ![vaibhav\_kulkarni](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/v/5fc32e/32.png) [@vaibhav\_kulkarni](https://www.ruby-forum.com/u/vaibhav_kulkarni)\ **Post date:** [January 12, 2015, 12:23pm UTC](https://www.ruby-forum.com/t/bluetooth-transmitter-using-grc/233775/2 "2015-01-12T12:23:39Z")
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. ---
**Author:** ![vaibhav\_kulkarni](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/v/5fc32e/32.png) [@vaibhav\_kulkarni](https://www.ruby-forum.com/u/vaibhav_kulkarni)\ **Post date:** [January 12, 2015, 7:08pm UTC](https://www.ruby-forum.com/t/bluetooth-transmitter-using-grc/233775/3 "2015-01-12T19:08:38Z")
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](mailto:removed_email_address@domain.invalid) wrote: > requirements exceed what you can do with a N210. > > > > > [Discuss-gnuradio Info Page](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](http://ele.aut.ac.ir/~mmwcl/?page_id=411) Homepage: [http://ele.aut.ac.ir/~alizadeh/](http://ele.aut.ac.ir/~alizadeh/) * * * ---
**Author:** ![vaibhav\_kulkarni](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/v/5fc32e/32.png) [@vaibhav\_kulkarni](https://www.ruby-forum.com/u/vaibhav_kulkarni)\ **Post date:** [January 13, 2015, 2:45pm UTC](https://www.ruby-forum.com/t/bluetooth-transmitter-using-grc/233775/4 "2015-01-13T14:45:24Z")
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: > 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](mailto:removed_email_address@domain.invalid) > [Discuss-gnuradio Info Page](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](http://ele.aut.ac.ir/~mmwcl/?page_id=411) Homepage: [http://ele.aut.ac.ir/~alizadeh/](http://ele.aut.ac.ir/~alizadeh/) * * * ---
**Author:** ![vaibhav\_kulkarni](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/v/5fc32e/32.png) [@vaibhav\_kulkarni](https://www.ruby-forum.com/u/vaibhav_kulkarni)\ **Post date:** [January 13, 2015, 12:33pm UTC](https://www.ruby-forum.com/t/bluetooth-transmitter-using-grc/233775/5 "2015-01-13T12:33:36Z")
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. ---
**Author:** ![vaibhav\_kulkarni](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/v/5fc32e/32.png) [@vaibhav\_kulkarni](https://www.ruby-forum.com/u/vaibhav_kulkarni)\ **Post date:** [January 13, 2015, 3:18pm UTC](https://www.ruby-forum.com/t/bluetooth-transmitter-using-grc/233775/6 "2015-01-13T15:18:33Z")
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](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. \ 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. \\> 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://sourceforge.net/) [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 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](mailto:removed_email_address@domain.invalid) \> [https://lists.gnu.org/mailman/\_\_listinfo/discuss-gnuradio](https://lists.gnu.org/mailman/__listinfo/discuss-gnuradio) [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](mailto:removed_email_address@domain.invalid) \> [https://lists.gnu.org/mailman/\_\_listinfo/discuss-gnuradio](https://lists.gnu.org/mailman/__listinfo/discuss-gnuradio) [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](http://ele.aut.ac.ir/~mmwcl/?page_id=411) Homepage: [http://ele.aut.ac.ir/~alizadeh/](http://ele.aut.ac.ir/~alizadeh/) * * * * * * Discuss-gnuradio mailing list 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](http://ele.aut.ac.ir/~mmwcl/?page_id=411) Homepage: [http://ele.aut.ac.ir/~alizadeh/](http://ele.aut.ac.ir/~alizadeh/) * * * ---
**Author:** ![vaibhav\_kulkarni](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/v/5fc32e/32.png) [@vaibhav\_kulkarni](https://www.ruby-forum.com/u/vaibhav_kulkarni)\ **Post date:** [January 13, 2015, 3:20pm UTC](https://www.ruby-forum.com/t/bluetooth-transmitter-using-grc/233775/7 "2015-01-13T15:20:22Z")
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 ---
**Author:** ![vaibhav\_kulkarni](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/v/5fc32e/32.png) [@vaibhav\_kulkarni](https://www.ruby-forum.com/u/vaibhav_kulkarni)\ **Post date:** [January 14, 2015, 8:31pm UTC](https://www.ruby-forum.com/t/bluetooth-transmitter-using-grc/233775/8 "2015-01-14T20:31:10Z")
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](mailto: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) > [https://lists.gnu.org/mailman/listinfo/discuss-gnuradio](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio) > Tehran > > [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) > [Discuss-gnuradio Info Page](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](http://ele.aut.ac.ir/~mmwcl/?page_id=411) Homepage: [http://ele.aut.ac.ir/~alizadeh/](http://ele.aut.ac.ir/~alizadeh/) * * * ---
**Author:** ![vaibhav\_kulkarni](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/v/5fc32e/32.png) [@vaibhav\_kulkarni](https://www.ruby-forum.com/u/vaibhav_kulkarni)\ **Post date:** [January 14, 2015, 9:41pm UTC](https://www.ruby-forum.com/t/bluetooth-transmitter-using-grc/233775/9 "2015-01-14T21:41:45Z")
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. ---
**Author:** ![vaibhav\_kulkarni](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/v/5fc32e/32.png) [@vaibhav\_kulkarni](https://www.ruby-forum.com/u/vaibhav_kulkarni)\ **Post date:** [January 15, 2015, 7:51am UTC](https://www.ruby-forum.com/t/bluetooth-transmitter-using-grc/233775/10 "2015-01-15T07:51:19Z")
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](mailto: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](http://ele.aut.ac.ir/~mmwcl/?page_id=411) Homepage: [http://ele.aut.ac.ir/~alizadeh/](http://ele.aut.ac.ir/~alizadeh/) * * * ---
**Author:** ![vaibhav\_kulkarni](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/v/5fc32e/32.png) [@vaibhav\_kulkarni](https://www.ruby-forum.com/u/vaibhav_kulkarni)\ **Post date:** [January 14, 2015, 9:44pm UTC](https://www.ruby-forum.com/t/bluetooth-transmitter-using-grc/233775/11 "2015-01-14T21:44:11Z")
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](http://www.ettus.com/content/files/X300_X310_Spec_Sheet.pdf)