Re: [Discuss-gnuradio] Bluetooth Transmitter using GRC
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üller marcus.muel...@ettus.com wrote: 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 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? Best, Mostafa On Tue, Jan 13, 2015 at 3:02 PM, Jeff Long willco...@gmail.com willco...@gmail.com 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. Best, Mostafa On Mon, Jan 12, 2015 at 2:52 PM, Jeff Long willco...@gmail.commailto:willco...@gmail.com willco...@gmail.com 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://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 Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org Discuss-gnuradio@gnu.org 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 Discuss-gnuradio@gnu.org mailto:Discuss-gnuradio@gnu.org Discuss-gnuradio@gnu.org
Re: [Discuss-gnuradio] Bluetooth Transmitter using GRC
On 01/14/2015 02:29 PM, Mostafa Alizadeh 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. Best, Mostafa On Tue, Jan 13, 2015 at 5:46 PM, Marcus Müller marcus.muel...@ettus.com mailto:marcus.muel...@ettus.com wrote: 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 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? Best, Mostafa On Tue, Jan 13, 2015 at 3:02 PM, Jeff Longwillco...@gmail.com mailto:willco...@gmail.com 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. Best, Mostafa On Mon, Jan 12, 2015 at 2:52 PM, Jeff Long willco...@gmail.com mailto:willco...@gmail.com mailto:willco...@gmail.com mailto:willco...@gmail.com 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://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,
Re: [Discuss-gnuradio] Bluetooth Transmitter using GRC
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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FATAL: No supported device found
Hi Marcus Tom, yes, iam using the buil-gnuradio script. The process was interrupt when the gnuradio build process was working. I had to start cmake manualy like described on the gnuradio website for native compiling and it was ok. I know uninstalled the gr-osmso via make uninstall and the rtl-sdr via make uninstall. After them i have done a make and make install in rtl-sdr source directory and the librtlsdr was installed. After them i have done a make and make install in gr-osmo source directory. I also add the driver to the blacklist. Now the RTL stick is beeing recognized by gnuradio on the bananapi :-) Thanks a lot, Andreas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gr-cdma
Hello I dont understand how to use the gr-cdma. I have installed it via GitHub and am currently looking at the cdma_tx and cdma_rx files. I am having problems trying to figure out what I am supposed to be inputting in certain blocks such as the import block that states “import cdma.cdma_paramters as cp” and other fields like the Missing block “coma_tx_hier”. I have loaded all of the 6 heir blocks that you mentioned in the read me. I'm guessing that means simply just open it via the GRC which I have done and some blocks are red because they require certain information which I don't know where to acquire from. I have reloaded all the blocks as well. I have two USRPS one to serve as transmitter and other as receiver so I want to test the cdma transmission using the cdma_tx and cdma_rx ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Distorted QPSK Constellation
I believe that even with the MF you'll have ISI because you have 4 samples/symbol in this example. Only if you down sample at 1 sample/symbol (at the right epoch) will you get rid of the ISI and get a clean QPSK. best Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-cdma
Ok. First instruction that I do not know how to execute is import coma.cdma_parameters as cp. What exactly am I supposed to be replacing in this section On Wednesday, January 14, 2015 6:54 PM, Achilleas Anastasopoulos anas...@umich.edu wrote: Please follow the detailed instructions on the README.md file and let us know which of these does not work for you (or which of these instructions you don't know how to execute). best Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] PDU_to_tagged_stream consumes 100% CPU even though it is throttled!
Hi all, I have the following problem that is been bugging me for quite some time now, and I would like to solicit your help. I made a hier block in GRC (called test_pdu_to_tag) with: pad_source---pdu_to_tagged_stream--pad_sink (I also made the pad_source optional and the pad_sink required) After compiling this block, I test it using the following GRC test test_pdu_to_tag--throttle (at 100Hz!)--null_sink (observe that the test_pdu_to_tag does not have an input) == When I run this I get that the CPU load goes to 100%. can anyone help me figure out why this is happening? This is all with the latest master on a Fedora 19. Thanks Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr-cdma
Please follow the detailed instructions on the README.md file and let us know which of these does not work for you (or which of these instructions you don't know how to execute). best Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] First time user - fm radio tutorial has choppy audio
One could just try dial_tone.py example. That will exercise the audio subsystem. Output is some garbled noise, and python$ python dial_tone.py INFO: Audio sink arch: alsa aUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaU So my audio stuff is defective, good to know :) For alsa, in the device field in the audio sink, try something like hw:0,0 or plughw:0,0 Seems to be alsa already...hmm...so this comes later. Ralph. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] First time user - fm radio tutorial has choppy audio
On 01/15/2015 12:29 AM, Ralph A. Schmid, dk5ras wrote: One could just try dial_tone.py example. That will exercise the audio subsystem. Output is some garbled noise, and python$ python dial_tone.py INFO: Audio sink arch: alsa aUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaU So my audio stuff is defective, good to know :) For alsa, in the device field in the audio sink, try something like hw:0,0 or plughw:0,0 Seems to be alsa already...hmm...so this comes later. Ralph. It may just be that your audio-subsystem doesn't actually support the sample-rate that the graph is configuring it for. Here's the --help for dial_tone.py Usage: dial_tone.py [options] Options: -h, --helpshow this help message and exit -O AUDIO_OUTPUT, --audio-output=AUDIO_OUTPUT pcm output device name. E.g., hw:0,0 or /dev/dsp -r SAMPLE_RATE, --sample-rate=SAMPLE_RATE set sample rate to RATE (48000) Looks like the default is 48e3 Try other rates, like 44.1e3 or 32e3 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] PDU_to_tagged_stream consumes 100% CPU even though it is throttled!
Hi, On 01/14/2015 11:29 PM, Achilleas Anastasopoulos wrote: I have the following problem that is been bugging me for quite some time now, and I would like to solicit your help. I made a hier block in GRC (called test_pdu_to_tag) with: pad_source---pdu_to_tagged_stream--pad_sink (I also made the pad_source optional and the pad_sink required) After compiling this block, I test it using the following GRC test test_pdu_to_tag--throttle (at 100Hz!)--null_sink (observe that the test_pdu_to_tag does not have an input) == When I run this I get that the CPU load goes to 100%. can anyone help me figure out why this is happening? This is all with the latest master on a Fedora 19. AFAIK, pdu_to_tagged_stream is busy-waiting for new PDUs (at least in June 2013 it was) and always uses 100% CPU. http://lists.gnu.org/archive/html/discuss-gnuradio/2013-06/msg00552.html Best, Bastian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] First time user - fm radio tutorial has choppy audio
Only 44100 works, giving a clear dial tone. As DSD has fixed sampling rate 8k, a resampler should do the trick. Things could be so easy :) I hate this audio stuff... Ralph. -Original Message- From: Marcus D. Leech [mailto:mle...@ripnet.com] Sent: Thursday, January 15, 2015 06:41 To: Ralph A. Schmid, dk5ras; 'Tom Rondeau' Cc: 'GNURadio Discussion List' Subject: Re: [Discuss-gnuradio] First time user - fm radio tutorial has choppy audio On 01/15/2015 12:29 AM, Ralph A. Schmid, dk5ras wrote: One could just try dial_tone.py example. That will exercise the audio subsystem. Output is some garbled noise, and python$ python dial_tone.py INFO: Audio sink arch: alsa aUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaU So my audio stuff is defective, good to know :) For alsa, in the device field in the audio sink, try something like hw:0,0 or plughw:0,0 Seems to be alsa already...hmm...so this comes later. Ralph. It may just be that your audio-subsystem doesn't actually support the sample-rate that the graph is configuring it for. Here's the --help for dial_tone.py Usage: dial_tone.py [options] Options: -h, --helpshow this help message and exit -O AUDIO_OUTPUT, --audio-output=AUDIO_OUTPUT pcm output device name. E.g., hw:0,0 or /dev/dsp -r SAMPLE_RATE, --sample-rate=SAMPLE_RATE set sample rate to RATE (48000) Looks like the default is 48e3 Try other rates, like 44.1e3 or 32e3 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] First time user - fm radio tutorial has choppy audio
Hi, How would I change this, skipping PulseAudio and using Alsa? The only audio application I try with gnuradio at the moment behaves similar here. I try to decode DMR, and I get choppy audio although everything should be OK. I blamed gr-dsd, but maybe it is a common issue. Will have to try a simple FM RX to verify :) Ralph. You almost certainly have a sample-rate mismatch somewhere in the flow--likely, your audio sink is configured for a sample-rate other than what the hardware (or PulseAudio) can support. Sometimes also, PulseAudio gets into trouble and gets all under-runny. I'd go with Alsa direct if it were my problem, and skip Pulse entirely. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] First time user - fm radio tutorial has choppy audio
On 01/14/2015 11:28 PM, Ralph A. Schmid, dk5ras wrote: Hi, How would I change this, skipping PulseAudio and using Alsa? The only audio application I try with gnuradio at the moment behaves similar here. I try to decode DMR, and I get choppy audio although everything should be OK. I blamed gr-dsd, but maybe it is a common issue. Will have to try a simple FM RX to verify :) Ralph. You almost certainly have a sample-rate mismatch somewhere in the flow--likely, your audio sink is configured for a sample-rate other than what the hardware (or PulseAudio) can support. Sometimes also, PulseAudio gets into trouble and gets all under-runny. I'd go with Alsa direct if it were my problem, and skip Pulse entirely. One could just try dial_tone.py example. That will exercise the audio subsystem. For alsa, in the device field in the audio sink, try something like hw:0,0 or plughw:0,0 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] First time user - fm radio tutorial has choppy audio
It may just be that your audio-subsystem doesn't actually support the sample-rate that the graph is configuring it for. Maybe. At least the test audio from the audio control panel is clear. Here's the --help for dial_tone.py Usage: dial_tone.py [options] Options: -h, --helpshow this help message and exit -O AUDIO_OUTPUT, --audio-output=AUDIO_OUTPUT pcm output device name. E.g., hw:0,0 or /dev/dsp -r SAMPLE_RATE, --sample-rate=SAMPLE_RATE set sample rate to RATE (48000) Looks like the default is 48e3 Try other rates, like 44.1e3 or 32e3 I will test it and tell you :) Ralph. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Distorted QPSK Constellation
On Wed, Jan 14, 2015 at 8:50 AM, Brian Padalino bpadal...@gmail.com wrote: It's a constellation plot for sure - says it right on the block in the PNG, but it's all internally generated anyway. There should be 1 perfect phase, then 3 out of phase points. No noise - no phase/frequency offset. Timing shouldn't be an issue here even if it were a normal plot. I think the issue is no matched filter on the other side. RRC filtering won't look very appealing to the eye, but RC filtering should match what you expect. Try adding a matched RRC filter before you do the constellation. You should see the 4 samples/symbol and their trajectories as they converge onto the 4 nice points. Brian Yes, indeed, Brian is correct. The modulator block uses an RRC pulse-shaping filter that also interpolate to some number of samples/symbol. So what you are seeing is due to the ISI (inter-symbol interference) as a result of the RRC filter. Applying a matched RRC filter will remove (most of) the ISI. Tom On Wed, Jan 14, 2015 at 2:51 AM, Martin Braun martin.br...@ettus.com wrote: On 01/14/2015 04:56 AM, Salman Dinani wrote: Hi to all, I am a beginner in using GNU radio(GRC). I have made a DQPSK transmitter using the blocks of GNU radio (attached Figure QPSK_1). when I connected the constellation plot with it, It gave me the a very scattered Constellation Plot Instead of four Clean Constellation Dots (attached Figure QPSK_2). I have checked with all forms of signals but the constellation remains distorted.(i.e. vector source, signal source etc.) Is it normal plot or am I missing some thing? Kindly help. My guess is yes, it's a normal plot, and you have no time sync in there. M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FATAL: No supported device found
On 01/14/2015 07:54 AM, Andreas Ladanyi wrote: Hi, Bananapi / LUbuntu After building GNURadio with the build-script and compiling / installing with success i can start gnuradio-companion or any gnuradio based py application but i get the following error messages. === linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.008.001-52-gd9e7a42d Gtk-Message: Failed to load module canberra-gtk-module - I know the reason of this error. This is easy to fix. gr-osmosdr v0.1.4-9-g48045b59 (0.1.5git) gnuradio 3.7.6 built-in source types: file fcd rtl_tcp uhd rfspace FATAL: No supported devices found to pick from. Trying to fill up 1 missing channel(s) with null source(s). This is being done to prevent the application from crashing due to gnuradio bug #528. Source has no sample rates (wrong device arguments?). It seems that the USB RTL 2832U stick is not found by gnuradio. I could see the device with dmesg and the rtl_test / rtl-test -t is successfull. Any ideas ? Andreas ___ Discuss-gnuradio mailing list address@hidden https://lists.gnu.org/mailman/listinfo/discuss-gnuradio YOu don't have the rtl support compiled-in to gr-osmosdr--perhaps because you were missing librtlsdr Hi Marcus, ok, so the problem is that the build-script didnt compile gr-osmosdr with rtl support because the librtlsdr wasnt installed from the build-script before compiling gr-osmosdr ? What do i have to do now ? Should i uninstall gr-osmosdr and then compile and install gr-osmsosdr again ? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Which build script did you use? build-gnuradio? It definitely *does* build-and-install librtlsdr prior to build gr-osmosdr, but if that fails for some reason, gr-osmosdr will get built. If you re-run it with -v it will give you more verbose output. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] First time user - fm radio tutorial has choppy audio
On 01/15/2015 01:15 AM, Ralph A. Schmid, dk5ras wrote: Only 44100 works, giving a clear dial tone. As DSD has fixed sampling rate 8k, a resampler should do the trick. Things could be so easy :) I hate this audio stuff... Ralph. If you use plughw:0,0 as the hardware designator, it's often willing to do resampling to the actual hardware rate. -Original Message- From: Marcus D. Leech [mailto:mle...@ripnet.com] Sent: Thursday, January 15, 2015 06:41 To: Ralph A. Schmid, dk5ras; 'Tom Rondeau' Cc: 'GNURadio Discussion List' Subject: Re: [Discuss-gnuradio] First time user - fm radio tutorial has choppy audio On 01/15/2015 12:29 AM, Ralph A. Schmid, dk5ras wrote: One could just try dial_tone.py example. That will exercise the audio subsystem. Output is some garbled noise, and python$ python dial_tone.py INFO: Audio sink arch: alsa aUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaU So my audio stuff is defective, good to know :) For alsa, in the device field in the audio sink, try something like hw:0,0 or plughw:0,0 Seems to be alsa already...hmm...so this comes later. Ralph. It may just be that your audio-subsystem doesn't actually support the sample-rate that the graph is configuring it for. Here's the --help for dial_tone.py Usage: dial_tone.py [options] Options: -h, --helpshow this help message and exit -O AUDIO_OUTPUT, --audio-output=AUDIO_OUTPUT pcm output device name. E.g., hw:0,0 or /dev/dsp -r SAMPLE_RATE, --sample-rate=SAMPLE_RATE set sample rate to RATE (48000) Looks like the default is 48e3 Try other rates, like 44.1e3 or 32e3 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Bluetooth Transmitter using GRC
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 mle...@ripnet.com wrote: On 01/14/2015 02:29 PM, Mostafa Alizadeh 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. Best, Mostafa On Tue, Jan 13, 2015 at 5:46 PM, Marcus Müller marcus.muel...@ettus.com wrote: 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 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? Best, Mostafa On Tue, Jan 13, 2015 at 3:02 PM, Jeff Long willco...@gmail.com willco...@gmail.com 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. Best, Mostafa On Mon, Jan 12, 2015 at 2:52 PM, Jeff Long willco...@gmail.commailto:willco...@gmail.com willco...@gmail.com 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://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
Re: [Discuss-gnuradio] First time user - fm radio tutorial has choppy audio
Hi Marcus, If you use plughw:0,0 as the hardware designator, it's often willing to do resampling to the actual hardware rate. Yep, I will try this later. Made my tests this morning on my way to work by train, now it has to wait until lunch break :) Ralph. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] b210 overflows and huge usb buffer
I managed to find a solution to this. I create a ram filesystem (tmpfs) and dump fixed length files there with gnuradio. I then move the files when they are complete to a persistent drive using another script. I don't know why I didn't think of this before. juha Can you elaborate on this please? What do you mean by dump fixed length files there with gnuradio? Do you mean you use a file sink (connected to a RAM disk) with a set number of samples? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] First time user - fm radio tutorial has choppy audio
On 01/14/2015 12:44 PM, Chris Hallinan wrote: Greetings, I'm a first time user of gnuradio. Kudos to the developers, it only took me about a day to build gnuradio + gr-osmosdr (for my el-cheapo rtl2832 dongle) from source, including getting a basic FM broadcast receiver sort-of running. Host Ubuntu 14.04 on a very fast Dell 8-core server platform. I've prototyped an FM receiver as described in the tutorial at the bottom of this page: http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorial_Hardware_Considerations However, when I run it, and set the center frequency to a close-by FM station, although I can hear actual broadcast audio snippets, meaning that it's actually receiving a coherent signal, it is very choppy, with audio snippets being played in a very choppy, almost rhythmic fashion. The console window on gnuradio-companion shows a continuous series of aUaUaU, etc. I'm guessing this might be an underrun situation somewhere, but that is speculation. I'm using parameters provided by the tutorial including a sample rate 250K. I've tried moving the sample rate around, but without much improvement. Dropping it down significantly destroys all hints of intelligence in the signal ;) Am I overtaxing the capabilities of this rtl-sdr dongle? I have a reasonable (and growing) understand of the core concepts, but could use some help on the learning curve. Any advice appreciated. -Chris -- Life is like Linux - it never stands still. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio You almost certainly have a sample-rate mismatch somewhere in the flow--likely, your audio sink is configured for a sample-rate other than what the hardware (or PulseAudio) can support. Sometimes also, PulseAudio gets into trouble and gets all under-runny. I'd go with Alsa direct if it were my problem, and skip Pulse entirely. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FATAL: No supported device found
Hi Bananpi, On some Linux distributions the RTL dongle USB can be grabbed by other applications at boot time, leaving it not available when you use gnuradio. If that is your issue it may be resolved by blacklisting the RTL device. Modify or create a file: etc/modprobe.d/rtlsdr.conf and add: blacklist dvbusbrt128xxu blacklist e4000 blacklist rtl2832 Then reboot. -- Tom, N5EG On Wed, Jan 14, 2015 at 7:38 AM, Marcus D. Leech mle...@ripnet.com wrote: On 01/14/2015 07:54 AM, Andreas Ladanyi wrote: Hi, Bananapi / LUbuntu After building GNURadio with the build-script and compiling / installing with success i can start gnuradio-companion or any gnuradio based py application but i get the following error messages. === linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.008.001-52-gd9e7a42d Gtk-Message: Failed to load module canberra-gtk-module - I know the reason of this error. This is easy to fix. gr-osmosdr v0.1.4-9-g48045b59 (0.1.5git) gnuradio 3.7.6 built-in source types: file fcd rtl_tcp uhd rfspace FATAL: No supported devices found to pick from. Trying to fill up 1 missing channel(s) with null source(s). This is being done to prevent the application from crashing due to gnuradio bug #528. Source has no sample rates (wrong device arguments?). It seems that the USB RTL 2832U stick is not found by gnuradio. I could see the device with dmesg and the rtl_test / rtl-test -t is successfull. Any ideas ? Andreas ___ Discuss-gnuradio mailing list address@hiddenhttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio YOu don't have the rtl support compiled-in to gr-osmosdr--perhaps because you were missing librtlsdr Hi Marcus, ok, so the problem is that the build-script didnt compile gr-osmosdr with rtl support because the librtlsdr wasnt installed from the build-script before compiling gr-osmosdr ? What do i have to do now ? Should i uninstall gr-osmosdr and then compile and install gr-osmsosdr again ? ___ Discuss-gnuradio mailing listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio Which build script did you use? build-gnuradio? It definitely *does* build-and-install librtlsdr prior to build gr-osmosdr, but if that fails for some reason, gr-osmosdr will get built. If you re-run it with -v it will give you more verbose output. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] First time user - fm radio tutorial has choppy audio
Hi Chris, On 01/14/2015 06:44 PM, Chris Hallinan wrote: Greetings, I'm a first time user of gnuradio. Welcome! I've prototyped an FM receiver as described in the tutorial at the bottom of this page: http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorial_Hardware_Considerations However, when I run it, and set the center frequency to a close-by FM station, although I can hear actual broadcast audio snippets, meaning that it's actually receiving a coherent signal, it is very choppy, with audio snippets being played in a very choppy, almost rhythmic fashion. The console window on gnuradio-companion shows a continuous series of aUaUaU, etc. I'm guessing this might be an underrun situation somewhere, but that is speculation. But speculation that's probably correct :) aU is audio underrun, which means you're most probably supplying samples at a rate that's lower than the audio sink is configured to accept. I'm using parameters provided by the tutorial including a sample rate 250K. I've tried moving the sample rate around, but without much improvement. Dropping it down significantly destroys all hints of intelligence in the signal ;) Am I overtaxing the capabilities of this rtl-sdr dongle? Probably not, since you're doing so well this far! Basically, use a sampling rate that works, and decimate to exactly the sampling rate you need for your audio sink. I have a reasonable (and growing) understand of the core concepts, but could use some help on the learning curve. Any advice appreciated. see above :) Greetings, and happy hacking, Marcus ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] First time user - fm radio tutorial has choppy audio
On Wed, Jan 14, 2015 at 12:53 PM, Marcus D. Leech mle...@ripnet.com wrote: On 01/14/2015 12:44 PM, Chris Hallinan wrote: Greetings, I'm a first time user of gnuradio. Kudos to the developers, it only took me about a day to build gnuradio + gr-osmosdr (for my el-cheapo rtl2832 dongle) from source, including getting a basic FM broadcast receiver sort-of running. Host Ubuntu 14.04 on a very fast Dell 8-core server platform. I've prototyped an FM receiver as described in the tutorial at the bottom of this page: http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorial_Hardware_Considerations However, when I run it, and set the center frequency to a close-by FM station, although I can hear actual broadcast audio snippets, meaning that it's actually receiving a coherent signal, it is very choppy, with audio snippets being played in a very choppy, almost rhythmic fashion. The console window on gnuradio-companion shows a continuous series of aUaUaU, etc. I'm guessing this might be an underrun situation somewhere, but that is speculation. I'm using parameters provided by the tutorial including a sample rate 250K. I've tried moving the sample rate around, but without much improvement. Dropping it down significantly destroys all hints of intelligence in the signal ;) Am I overtaxing the capabilities of this rtl-sdr dongle? I have a reasonable (and growing) understand of the core concepts, but could use some help on the learning curve. Any advice appreciated. -Chris -- Life is like Linux - it never stands still. ___ Discuss-gnuradio mailing listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio You almost certainly have a sample-rate mismatch somewhere in the flow--likely, your audio sink is configured for a sample-rate other than what the hardware (or PulseAudio) can support. Sometimes also, PulseAudio gets into trouble and gets all under-runny. I'd go with Alsa direct if it were my problem, and skip Pulse entirely. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org The manual gives you a few hints for different possible device names you can try: http://gnuradio.org/doc/doxygen/classgr_1_1audio_1_1sink.html Unlike Marcus, I've always had better luck with pulse that direct alsa. But we have very different systems and use different Linux versions, so ymmv. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] First time user - fm radio tutorial has choppy audio
Greetings, I'm a first time user of gnuradio. Kudos to the developers, it only took me about a day to build gnuradio + gr-osmosdr (for my el-cheapo rtl2832 dongle) from source, including getting a basic FM broadcast receiver sort-of running. Host Ubuntu 14.04 on a very fast Dell 8-core server platform. I've prototyped an FM receiver as described in the tutorial at the bottom of this page: http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorial_Hardware_Considerations However, when I run it, and set the center frequency to a close-by FM station, although I can hear actual broadcast audio snippets, meaning that it's actually receiving a coherent signal, it is very choppy, with audio snippets being played in a very choppy, almost rhythmic fashion. The console window on gnuradio-companion shows a continuous series of aUaUaU, etc. I'm guessing this might be an underrun situation somewhere, but that is speculation. I'm using parameters provided by the tutorial including a sample rate 250K. I've tried moving the sample rate around, but without much improvement. Dropping it down significantly destroys all hints of intelligence in the signal ;) Am I overtaxing the capabilities of this rtl-sdr dongle? I have a reasonable (and growing) understand of the core concepts, but could use some help on the learning curve. Any advice appreciated. -Chris -- Life is like Linux - it never stands still. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Distorted QPSK Constellation
It's a constellation plot for sure - says it right on the block in the PNG, but it's all internally generated anyway. There should be 1 perfect phase, then 3 out of phase points. No noise - no phase/frequency offset. Timing shouldn't be an issue here even if it were a normal plot. I think the issue is no matched filter on the other side. RRC filtering won't look very appealing to the eye, but RC filtering should match what you expect. Try adding a matched RRC filter before you do the constellation. You should see the 4 samples/symbol and their trajectories as they converge onto the 4 nice points. Brian On Wed, Jan 14, 2015 at 2:51 AM, Martin Braun martin.br...@ettus.com wrote: On 01/14/2015 04:56 AM, Salman Dinani wrote: Hi to all, I am a beginner in using GNU radio(GRC). I have made a DQPSK transmitter using the blocks of GNU radio (attached Figure QPSK_1). when I connected the constellation plot with it, It gave me the a very scattered Constellation Plot Instead of four Clean Constellation Dots (attached Figure QPSK_2). I have checked with all forms of signals but the constellation remains distorted.(i.e. vector source, signal source etc.) Is it normal plot or am I missing some thing? Kindly help. My guess is yes, it's a normal plot, and you have no time sync in there. M ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FATAL: No supported device found
Hi, Bananapi / LUbuntu After building GNURadio with the build-script and compiling / installing with success i can start gnuradio-companion or any gnuradio based py application but i get the following error messages. === linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.008.001-52-gd9e7a42d Gtk-Message: Failed to load module canberra-gtk-module - I know the reason of this error. This is easy to fix. gr-osmosdr v0.1.4-9-g48045b59 (0.1.5git) gnuradio 3.7.6 built-in source types: file fcd rtl_tcp uhd rfspace FATAL: No supported devices found to pick from. Trying to fill up 1 missing channel(s) with null source(s). This is being done to prevent the application from crashing due to gnuradio bug #528. Source has no sample rates (wrong device arguments?). It seems that the USB RTL 2832U stick is not found by gnuradio. I could see the device with dmesg and the rtl_test / rtl-test -t is successfull. Any ideas ? Andreas ___ Discuss-gnuradio mailing list address@hidden https://lists.gnu.org/mailman/listinfo/discuss-gnuradio YOu dont have the rtl support compiled-in to gr-osmosdr--perhaps because you were missing librtlsdr Hi Marcus, ok, so the problem is that the build-script didnt compile gr-osmosdr with rtl support because the librtlsdr wasnt installed from the build-script before compiling gr-osmosdr ? What do i have to do now ? Should i uninstall gr-osmosdr and then compile and install gr-osmsosdr again ? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
