Re: [Discuss-gnuradio] [USRP-users] Audio Source configuration
Thanks for reaching out, all input is appreciated. The file in use is from files.ettus.com/tutorials/Lab_5.grc. The gross mismatch in sample rates comes about when you set the Rational resampler output rate to be exactly what the UHD:USRP Sink is expecting ... in this case 250K. The incidence of UUU's is reduced when you introduce the fudge factor suggested at 1.1 in that there is only a short string of approximately 30 U's on startup, but the delay between speaking and transmitting grows from nearly instantaneous at the start of a test to countable numbers of seconds within a short period of time, presumably because there is a buffer involved that is being drained more slowly than it is being filled The OK to Block setting in the Audio Block seems to have no influence (this is as expected since it is noted in the text of the tutorial that ALSA is unaffected by this setting). Least anyone think that delays on the order of a few seconds are not a problem, I note that in applications intended to improve indoor coverage, delays between the direct path of the outdoor signal and the enhanced path from the regenerative equipment are critical to operation and need to be on the order of 10s of microseconds for the equipment to function correctly. Any thoughts on how to troubleshoot the Audio Source or determine alternates to ALSA would be much appreciated. Thanks again, 73 LVDJ On Tue, Mar 17, 2015 at 10:48 AM, mle...@ripnet.com wrote: If you're getting long strings of 'U', this means a *gross* sample-rate mis-match somewhere in your flow-graph, rather than the more-subtle two clock problem. Make sure that everything agrees internal to the graph about sample-rates, and, perhaps more importantly, that your audio *hardware* is capable of delivering the desired rates. On 2015-03-17 10:30, Larry Van Der Jagt via USRP-users wrote: Hello: Can anyone point me to some color on how to work with the Audio Source. I am working examples to transmit FM Audio and have problems with Underruns on the UHD:USRP Sink. The examples (from files.ettus.com/tutorials/Lab_5.grc and others) I am running select Audio Source Arch:alsa and this seems to be a problem. I have tried to replace the Device name with plughw:0,0 as suggested in the documetnation, but this does not seem to have an impact on the choice of Audio arch: alsa If I replace the audio source with a signal source at the same sample rate all is well, but the Audio Source implements . Using the suggestion of having the USRP expect a bit lower rate than the audio can deliver seems to implement nearly limitless delay the voice is received but only after a very long ... many seconds delay ... At this time I am using a B210 connected via USB3 to an I7 with plenty of memory running Ubuntu 12.04 I have similar issues trying to use an E310 as the transmitter ... Any direction would be appreciated. LVDJ ___ USRP-users mailing listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Audio Source configuration
Maybe watch your CPU utilization with htop when you're recording with terminal command to /dev/null, and compare it to gnuradio with a null source. If you take out or disable the audio source, the underflows should go away. On Tue, Mar 17, 2015 at 5:14 PM, Marcus Müller marcus.muel...@ettus.com wrote: Hi Larry, if I understand correctly, then you're using the audio source as input to your usrp_sink-terminated flow graph. In that case, the Underruns come from UHD, not the audio source; the flow graph is not supplying samples fast enough. The problem might be systematic, for example if the rate change in your flow graph does not reflect the actual rate ratio between your audio device and the USRP -- e.g. the your audio device generates samples at 48kS/s, and your USRP consumes them with 5MS/s, but you have an interpolation rate of 100 (leading to a rate at which samples arrive at the USRP sink of 4.8MS/s; these are all just exemplary numbers). Also possible, though, is that this is simply an extreme case of clock mismatch: For example, assume the reference clock in your USRP is of by 2ppm, making the sample consume rate (1+2e-6) times higher than it should be, according to an imaginary exact clock. Now, assume your sound card is a bit slower than it should be, so let these should-be 48kS/s be (1-500e-6) times that what it should be. That means that for every a USRP sampling rate of let's say 5MS/s, you'd have around 2500 samples too little per second, which (there's around 250 samples transportable per USB packet) is around 10 sample packets less than the USRP consumes. Greetings, Marcus [1] I pulled up the first sound chip datasheet I could find (TI PCM2903), and it demanded +-500 ppm. On 03/17/2015 03:30 PM, Larry Van Der Jagt wrote: Hello: Can anyone point me to some color on how to work with the Audio Source. I am working examples to transmit FM Audio and have problems with Underruns on the UHD:USRP Sink. The examples (from files.ettus.com/tutorials/Lab_5.grc and others) I am running select Audio Source Arch:alsa and this seems to be a problem. I have tried to replace the Device name with plughw:0,0 as suggested in the documetnation, but this does not seem to have an impact on the choice of Audio arch: alsa If I replace the audio source with a signal source at the same sample rate all is well, but the Audio Source implements . Using the suggestion of having the USRP expect a bit lower rate than the audio can deliver seems to implement nearly limitless delay the voice is received but only after a very long ... many seconds delay ... At this time I am using a B210 connected via USB3 to an I7 with plenty of memory running Ubuntu 12.04 I have similar issues trying to use an E310 as the transmitter ... Any direction would be appreciated. LVDJ ___ Discuss-gnuradio mailing listDiscuss-gnuradio@gnu.orghttps://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] Phase locked loop
On 17/03/15 15:08, Marcus Müller wrote: Hi Daniele, Also, I don't see why you cannot combine other blocks to realize your own PLL implementation. Where did you read that you can’t use companion to add and drop the current available blocks to construct a phase locked loop? Wai Yee has a point here -- you can't have a circle in your (sample stream) flow graph -- GNU Radio doesn't allow that for reasons of causality. You can have a loose loop with feedback done with message ports, but that's not the same as a control loop (since there's no defined delay between the sample for which a error was estimated and the sample where the error correction is applied when using the asynchronous messages). Thus, you can't drag'n'drop together a proper control loop from discrete things like adders and integrators that you could design and analyze theoretically. Hello Marcus, I realized this while having my coffee this morning. I should avoid to reply to emails before assuming the right amount of caffeine :) In effect, GNU Radio's control loops are monolithic blocks -- that's somewhat sad from a modularity perspective, but then again, there's the control loop base class that allows you to implement arbitrary control loops rather easily Last time I looked into it, this base class is not that generic: it can be easily used to implement phase-lock loops, but it did not seem designed to control other quantities, like amplitude for example. But I may have had a too quick loot at it. Cheers, Daniele ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Audio Source configuration
Hi Larry, if I understand correctly, then you're using the audio source as input to your usrp_sink-terminated flow graph. In that case, the Underruns come from UHD, not the audio source; the flow graph is not supplying samples fast enough. The problem might be systematic, for example if the rate change in your flow graph does not reflect the actual rate ratio between your audio device and the USRP -- e.g. the your audio device generates samples at 48kS/s, and your USRP consumes them with 5MS/s, but you have an interpolation rate of 100 (leading to a rate at which samples arrive at the USRP sink of 4.8MS/s; these are all just exemplary numbers). Also possible, though, is that this is simply an extreme case of clock mismatch: For example, assume the reference clock in your USRP is of by 2ppm, making the sample consume rate (1+2e-6) times higher than it should be, according to an imaginary exact clock. Now, assume your sound card is a bit slower than it should be, so let these should-be 48kS/s be (1-500e-6) times that what it should be. That means that for every a USRP sampling rate of let's say 5MS/s, you'd have around 2500 samples too little per second, which (there's around 250 samples transportable per USB packet) is around 10 sample packets less than the USRP consumes. Greetings, Marcus [1] I pulled up the first sound chip datasheet I could find (TI PCM2903), and it demanded +-500 ppm. On 03/17/2015 03:30 PM, Larry Van Der Jagt wrote: Hello: Can anyone point me to some color on how to work with the Audio Source. I am working examples to transmit FM Audio and have problems with Underruns on the UHD:USRP Sink. The examples (from files.ettus.com/tutorials/Lab_5.grc http://files.ettus.com/tutorials/Lab_5.grc and others) I am running select Audio Source Arch:alsa and this seems to be a problem. I have tried to replace the Device name with plughw:0,0 as suggested in the documetnation, but this does not seem to have an impact on the choice of Audio arch: alsa If I replace the audio source with a signal source at the same sample rate all is well, but the Audio Source implements . Using the suggestion of having the USRP expect a bit lower rate than the audio can deliver seems to implement nearly limitless delay the voice is received but only after a very long ... many seconds delay ... At this time I am using a B210 connected via USB3 to an I7 with plenty of memory running Ubuntu 12.04 I have similar issues trying to use an E310 as the transmitter ... Any direction would be appreciated. LVDJ ___ 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] Phase locked loop
Hi Yee, Oh I did forget to put the link of the book, sorry!!! Here is the book: http://www.amazon.com/Digital-Communications-A-Discrete-Time-Approach/dp/0130304972 If you want to implement a PLL by yourself, I prefer to see an example of QPSK Tx/Rx in Matlab: http://www.mathworks.com/help/comm/examples/qpsk-transmitter-and-receiver.html However, it's convenient to use available blocks in GNURadio. Best, Mostafa On Wed, Mar 18, 2015 at 4:11 AM, yee_yy1992 yee_yy1...@hotmail.co.uk wrote: Dear Mostafa, Thank you very much on your reply. May I know where can I find the link for chapter 8 and 7 of [2] for the description and implementation of PLL? Appreciate your kind help. Best regards, Wai Yee Original message From: Mostafa Alizadeh Date:18/03/2015 01:07 (GMT+08:00) To: yee_yy1992 Subject: Re: [Discuss-gnuradio] Phase locked loop Hi Yee, If you want to have a loop within GNURadio, you must have a delay within the loop to force zero initial state in the loop (here PLL loop). So in the costas loop of [1], there is a delay between phase difference calculation and the loop (which is )called advance_loop). If you're going to write your own OOT, take look at chapter 8 and 7 of [2]. It has a complete description of PLL and its implementation. [1] https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/costas_loop_cc_impl.cc On Tue, Mar 17, 2015 at 4:35 AM, yee_yy1992 yee_yy1...@hotmail.co.uk wrote: Hi, Currently I am doing my Final Year Project to develop a phase measurement using Phase Locked Loop theory. I am using *USRP N210* for the hardware and I have installed *Gnuradio Companion* in *Ubuntu 12.04 LTS* (running in VMplayer). I have studied online that I can't use companion to add and drop the current available blocks to construct a phase locked loop. I managed to locate gr_pll_carriertracking_cc.cc and gr_pll_carriertracking_cc.h file from gnuradio source archive. I also know that I can use gr_modtool to construct my own OOT module. But I am having some difficulties in using gr_modtool. There are many functions is the gr_pll_carriertracking_cc.cc. My question are (a)What should I include for the valid argument list during the gr_modtool add process? reference link : http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorial_GNU_Radio_in_C++#432-Specific-block-categories (4.2.3 Step 2) (b) Am I putting the whole code (gr_pll_carriertracking_cc.cc) and generate it as *ONE* OOT module with few functions inside or should I separate the functions to become more OOT module and connect them using wire in companion? (c)How can I include all the header file into the make process? There are few header files being used in the code such as gr_io_signature.h , gr_sincos.h I would really appreciate your help in guiding me. Thank you very much. Best regards, Wai Yee. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org 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/ *** -- *** 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 Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] (no subject)
Hi all, I'm trying to get the constellation of 16QAM. How to use constellation receiver block for 16QAM? thanks in advance ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Phase locked loop
On 17/03/15 02:05, yee_yy1992 wrote: Hi, Currently I am doing my Final Year Project to develop a phase measurement using Phase Locked Loop theory. I am using *USRP N210* for the hardware and I have installed *Gnuradio Companion* in *Ubuntu 12.04 LTS* (running in VMplayer). I have studied online that I can’t use companion to add and drop the current available blocks to construct a phase locked loop. Hello, what to you mean by that last sentence? GNURadio comes with PLL blocks in a few different fashions that can be used from the companion just fine. Also, I don't see why you cannot combine other blocks to realize your own PLL implementation. Where did you read that you can’t use companion to add and drop the current available blocks to construct a phase locked loop? Cheers, Daniele ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Requesting help with HPD block
On 17.03.2015 14:14, Richard Bell wrote: Martin, Thanks for your detailed response. I need some clarification on a few points. I also need to clarify something. I am using the HPD on demodulated detected data. There are no floats at this point. Everything is binary. The data type of all blocks is byte. My bad, my mind colour-mapped the type wrongly to floats. I am adding artificial zeros in myself, after I form the packets, to simulate a burst transmission. I send a packet, dead time (0's), I send another packet, so on. That is the source of the zeros coming out of the payload port. OK, with that in mind, if my packet is setup accordingly: packet_structure: [32 bit header | 128 byte = 1024 bit payload] what are you calling an item here? 'Item' is GNU Radio nomenclature here. In your case, one item is one byte from the input buffer. Question is, how many bits are in one byte in your input buffer? Is your 1024 bit payload really 128 bytes long on the input buffer? Also, have you used the message debug block to see what your parser returns? M I am looking for the unit tests your mentioned. I was not aware of them. v/r, Rich On Tue, Mar 17, 2015 at 1:52 PM, Martin Braun martin.br...@ettus.com mailto:martin.br...@ettus.com wrote: On 17.03.2015 11:48, Richard Bell wrote: [...] My issue might stem from a misunderstanding of the HPD parameters. This block seems to have been written for OFDM, but I'm using it for single carrier QPSK. If someone wouldn't mind looking over my parameters with singe carrier in mind to confirm I've set it up correct, I would be grateful. My header is 32 bits long and the payload is 160 bytes or 1280 bits long. The documentation for this block is not very clear on how the parameters relate to the system. Richard, the block has some added features to handle OFDM, but it wasn't written specifically for it. If you haven't read the unit tests for this code, you should definitely go there for some input. (The reason OFDM was considered as a special case is because this makes a CP remover block unnecessary, but that's another story). The output of the header port is perfect. It is the exactly what I expect. I'm showing 3 headers worth of samples in the sink plot, and we see exactly 3 headers with tags on the first sample of each header. In the payload length portion of the header, the value 160 exists for the payload length. My second question is, when generating the header using packet_header_default, is the payload represented in bytes or bits? Whatever your payload parser generates should be the number of *items* read through the HPD. What are bits, bytes? The HPD doesn't know any of this. It can only relate to the item size you've given it. Now if you look at the payload out sink plot, you will see payloads separated by zeros. Each payload portion (the non-zero portion) is the exact length as my payload should be, 160 bytes or 1280 bits. But you can see zeros are allowed through after the 1280th bit and a second payload shows up without a tag. This leads me to believe the HPD block is interpreting the payload length to be 4 times larger then I intend it to be. What parameters am I mixing up to create this? Yeah, I can see how that's happening. Your payload is being (probably correctly) interpreted as 160 bytes, then the HPD is given the number 160 as a payload length. However, the HPD needs to know the number of *items* per payload. 4 == sizeof(float), which you are using. The reason the OFDM code has no issues here is because it uses its own packet header parser, which returns the number of OFDM symbols. That really was the intention of the packet header parser architecture. Now, how come the packet header parser is reporting 160? Is that actually correct? It seems that if your payload is 40 floats, 160 bytes seems a lot. You'd be storing 4 bytes per float, when typically, you have 1 or 2 bits. However, as a quick hack, edit the packet_header_default to add a scaling factor (or just divide by 4 before sending the packet). That should fix it temporarily. A more long-term solution would be to add a scaling factor to the packet_header_default for these cases -- maybe you want to write and upstream this? I've played with the ofdm_tx/rx.grc example and confirmed that it will keep the zeros from showing up at the payload out port. This confirms my misuse of the block. The hard part is porting the OFDM example parameters to a single carrier use. Am I correct in setting symbol to 1 since there are no OFDM symbols?
Re: [Discuss-gnuradio] Requesting help with HPD block
On 17.03.2015 11:48, Richard Bell wrote: [...] My issue might stem from a misunderstanding of the HPD parameters. This block seems to have been written for OFDM, but I'm using it for single carrier QPSK. If someone wouldn't mind looking over my parameters with singe carrier in mind to confirm I've set it up correct, I would be grateful. My header is 32 bits long and the payload is 160 bytes or 1280 bits long. The documentation for this block is not very clear on how the parameters relate to the system. Richard, the block has some added features to handle OFDM, but it wasn't written specifically for it. If you haven't read the unit tests for this code, you should definitely go there for some input. (The reason OFDM was considered as a special case is because this makes a CP remover block unnecessary, but that's another story). The output of the header port is perfect. It is the exactly what I expect. I'm showing 3 headers worth of samples in the sink plot, and we see exactly 3 headers with tags on the first sample of each header. In the payload length portion of the header, the value 160 exists for the payload length. My second question is, when generating the header using packet_header_default, is the payload represented in bytes or bits? Whatever your payload parser generates should be the number of *items* read through the HPD. What are bits, bytes? The HPD doesn't know any of this. It can only relate to the item size you've given it. Now if you look at the payload out sink plot, you will see payloads separated by zeros. Each payload portion (the non-zero portion) is the exact length as my payload should be, 160 bytes or 1280 bits. But you can see zeros are allowed through after the 1280th bit and a second payload shows up without a tag. This leads me to believe the HPD block is interpreting the payload length to be 4 times larger then I intend it to be. What parameters am I mixing up to create this? Yeah, I can see how that's happening. Your payload is being (probably correctly) interpreted as 160 bytes, then the HPD is given the number 160 as a payload length. However, the HPD needs to know the number of *items* per payload. 4 == sizeof(float), which you are using. The reason the OFDM code has no issues here is because it uses its own packet header parser, which returns the number of OFDM symbols. That really was the intention of the packet header parser architecture. Now, how come the packet header parser is reporting 160? Is that actually correct? It seems that if your payload is 40 floats, 160 bytes seems a lot. You'd be storing 4 bytes per float, when typically, you have 1 or 2 bits. However, as a quick hack, edit the packet_header_default to add a scaling factor (or just divide by 4 before sending the packet). That should fix it temporarily. A more long-term solution would be to add a scaling factor to the packet_header_default for these cases -- maybe you want to write and upstream this? I've played with the ofdm_tx/rx.grc example and confirmed that it will keep the zeros from showing up at the payload out port. This confirms my misuse of the block. The hard part is porting the OFDM example parameters to a single carrier use. Am I correct in setting symbol to 1 since there are no OFDM symbols? Here's what should work: header length: Whatever you have now items per symbol: gi: 0 output format: items Now make sure the header_parser tells the HPD the number of floats it needs to consume per payload. The value reported by the payload is the same unit as the header length. M PS: The reason you see zeros between packets is because the ringbuffers get initialized with zeros to start with. Eventually, you might see residue from other packets. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problems to create a new OOT module using gr_modtool in a pybombs instalation of Gnuradio
On Tue, Mar 17, 2015 at 4:27 PM, Luiz Silva lfssa...@hotmail.com wrote: Hello, I tried to create a module in the Gnuradio v3.7.6.1 installed by pybombs using gr_modtool. But the module didn't appear in the gnuradio module list. I verified if something it was wrong during the creation of the block, but it wasn't. So after a long time, I noticed that the .xml files of the new module it was created in a different folder. In my case I install gnuradio in the folder: //usr/local/src, where I put the pybombs files and install, and the .xml files usually are located in: //usr/local/src/target/share/gnuradio/grc/blocks. But the new module .xml files was created in: //usr/local/share/gnuradio/grc/blocks. Because of that, my new module didn't appear in the gnuradio module list. So, I copy the .xml files to the correctly folder and n more problems with that. But, I would like if there are another solution to that. Do you have any idea ? Thanks, You've set two different prefixes for GNU Radio and your OOT project, so they were installed into different locations. That's fine, but you'll need to setup your system to handle it. For the GRC problem, you can take a look here: http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioCompanion#Installing-the-XML-Block-Definition That gives you different ways to tell GRC where to find blocks. You might find yourself needing to add to your PATH, PYTHONPATH, and LD_LIBRARY_PATH env. variables (you can find this in the environmental setup script generated from pybombs' 'env' command). Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] cannot find gnuradio companion
Hello ALL, I encountered one problem during installing GNU Radio on ubuntu 14.04 . I attached the whole installation log . Could someone help me with this? Thanks in advance. I used the script from the link below to install Gnuradio : http://gnuradio.org/redmine/projects/gnuradio/wiki/InstallingGRFromSource#Using-the-build-gnuradio-script Following is the log installing GNU Radio, I set the PYTHONPATH , but still cannot find gnuradio companion. echodtx@echodtx-VirtualBox:~$ export PYTHONPATH=/usr/local/lib/python2.7/dist-packages echodtx@echodtx-VirtualBox:~/gnuradio$ gnuradio-companion bash: /usr/bin/gnuradio-companion: No such file or directory % .Installing Done building and installing Gnu Radio GRC freedesktop icons install ...Done Done function gnuradio_build at: di mrt 17 16:31:11 CET 2015 Starting function rtl_build at: di mrt 17 16:31:11 CET 2015 Building rtl-sdr...Done building rtl-sdr Building hackrf...Done building hackrf Building gr-iqbal...gr-iqbal build apparently failed Exiting gr-iqbal build Building gr-osmosdr...Done building gr-osmosdr Done building/installing rtl-sdr/gr-osmosdr Done function rtl_build at: di mrt 17 16:34:24 CET 2015 Starting function extras at: di mrt 17 16:34:24 CET 2015 Doing GIT checkout for extra module gr-baz Building extra module gr-baz Doing GIT checkout for extra module grextras Building extra module grextras Done function extras at: di mrt 17 16:34:38 CET 2015 Starting function mod_groups at: di mrt 17 16:34:38 CET 2015 Group 'usrp' already in /etc/group User echodtx already in group 'usrp' Done function mod_groups at: di mrt 17 16:34:38 CET 2015 Starting function mod_udev at: di mrt 17 16:34:38 CET 2015 udevd: no process found Done function mod_udev at: di mrt 17 16:34:39 CET 2015 Starting function mod_sysctl at: di mrt 17 16:34:39 CET 2015 Required updates to /etc/sysctl.conf already in place usrp group already has real-time scheduling privilege Done function mod_sysctl at: di mrt 17 16:34:39 CET 2015 Starting function pythonpath at: di mrt 17 16:34:39 CET 2015 You should probably set your PYTHONPATH to: /usr/local/lib/python2.7/dist-packages Using: export PYTHONPATH=/usr/local/lib/python2.7/dist-packages in your .bashrc or equivalent file prior to attempting to run any Gnu Radio applications or Gnu Radio Companion. * Done function pythonpath at: di mrt 17 16:34:39 CET 2015 Done all functions at: di mrt 17 16:34:39 CET 2015 All Done === If you have found this script useful and time-saving, consider a donation to help me keep build-gnuradio, simple_ra, SIDsuite, meteor_detector, simple_fm_rcv, and multimode maintained and up to date. A simple paypal transfer to mle...@ripnet.com is all you need to do. == Send success/fail info to sbrac.org?echodtx@echodtx-VirtualBox:~$ error log.odt Description: error log.odt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem in creating an OOT module
On Tue, Mar 17, 2015 at 8:10 PM, Ali Riaz ari...@hawk.iit.edu wrote: Hello everyone, I was wondering if anyone can help me with a small issue. I want to use the tagged_file_sink block in gnuradio companion, but with a couple of additional features suitable for my application needs. So I decide to create an OOT module, and as a start simply copy-pasted the original code for the tagged_file_sink (adjusting the name of the block of course) just to see if it works before I start editing it with my own adjustments. But I get a compilation error when I use the make command. The errors are something like: tagged_file_sink_v2_impl.cc: error: 'perror' was not declared in this scope perror(filename.str().c_str()); The rest of the errors I'm getting are similar to this: 'something' was not declared in this scope. Up till now I've only used gnuradio companion, never got to delve into actual coding or making my own blocks, so more of a beginner in this area, and I'm pretty sure that I'm missing something very basic, so I hope someone can help me figure this out. Thank you, Best, Ali This is basically a C/C++ question, not GNU Radio. You're missing include files in your code. For instance, take a look at: $ man 3 perror It tells you that it needs #include stdio.h. You'll find similar things for the other errors your having. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem in creating an OOT module
Well, it was definitely something simple :) Thank you for your help Tom! Best, Ali On Tue, Mar 17, 2015 at 7:21 PM, Tom Rondeau t...@trondeau.com wrote: On Tue, Mar 17, 2015 at 8:10 PM, Ali Riaz ari...@hawk.iit.edu wrote: Hello everyone, I was wondering if anyone can help me with a small issue. I want to use the tagged_file_sink block in gnuradio companion, but with a couple of additional features suitable for my application needs. So I decide to create an OOT module, and as a start simply copy-pasted the original code for the tagged_file_sink (adjusting the name of the block of course) just to see if it works before I start editing it with my own adjustments. But I get a compilation error when I use the make command. The errors are something like: tagged_file_sink_v2_impl.cc: error: 'perror' was not declared in this scope perror(filename.str().c_str()); The rest of the errors I'm getting are similar to this: 'something' was not declared in this scope. Up till now I've only used gnuradio companion, never got to delve into actual coding or making my own blocks, so more of a beginner in this area, and I'm pretty sure that I'm missing something very basic, so I hope someone can help me figure this out. Thank you, Best, Ali This is basically a C/C++ question, not GNU Radio. You're missing include files in your code. For instance, take a look at: $ man 3 perror It tells you that it needs #include stdio.h. You'll find similar things for the other errors your having. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Which block is causing dropped samples?
Hi all, I just finished writing a flowgraph with a few custom C++ blocks, but when I connect it to a USRP N210 at about 25MS/s it's not too hard to find a combo of parameters that will cause a sea of DDs to come flooding into the term. I think there are some areas I can improve in my blocks but I want to make sure I'm focusing on the worst-performing areas first. So my question is, is there an easy (or hard, I don't really care) way to figure out which block in a flowgraph is causing the dropped samples? I already checked that it's not an internet issue. Thanks in advance! -Doug ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Which block is causing dropped samples?
On 03/17/2015 07:06 PM, Anderson, Douglas J. wrote: Hi all, I just finished writing a flowgraph with a few custom C++ blocks, but when I connect it to a USRP N210 at about 25MS/s it's not too hard to find a combo of parameters that will cause a sea of DDs to come flooding into the term. I think there are some areas I can improve in my blocks but I want to make sure I'm focusing on the worst-performing areas first. So my question is, is there an easy (or hard, I don't really care) way to figure out which block in a flowgraph is causing the dropped samples? I already checked that it's not an internet issue. Thanks in advance! -Doug ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio The 'D' message is coming from the UHD driver itself--long before it gets to the guts of your flow-graph. That happens, though, when the app layer cannot keep up with the sample stream coming from the kernel, because its average offered load is higher than the average available compute and memory bandwidth. If you're on Linux have you set the recommended buffering parameters in the network stack: http://files.ettus.com/manual/page_transport.html#transport_udp ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Problem in creating an OOT module
Hello everyone, I was wondering if anyone can help me with a small issue. I want to use the tagged_file_sink block in gnuradio companion, but with a couple of additional features suitable for my application needs. So I decide to create an OOT module, and as a start simply copy-pasted the original code for the tagged_file_sink (adjusting the name of the block of course) just to see if it works before I start editing it with my own adjustments. But I get a compilation error when I use the make command. The errors are something like: tagged_file_sink_v2_impl.cc: error: 'perror' was not declared in this scope perror(filename.str().c_str()); The rest of the errors I'm getting are similar to this: 'something' was not declared in this scope. Up till now I've only used gnuradio companion, never got to delve into actual coding or making my own blocks, so more of a beginner in this area, and I'm pretty sure that I'm missing something very basic, so I hope someone can help me figure this out. Thank you, Best, Ali ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Problems to create a new OOT module using gr_modtool in a pybombs instalation of Gnuradio
Hello, I tried to create a module in the Gnuradio v3.7.6.1 installed by pybombs using gr_modtool. But the module didn't appear in the gnuradio module list. I verified if something it was wrong during the creation of the block, but it wasn't. So after a long time, I noticed that the .xml files of the new module it was created in a different folder. In my case I install gnuradio in the folder: //usr/local/src, where I put the pybombs files and install, and the .xml files usually are located in: //usr/local/src/target/share/gnuradio/grc/blocks. But the new module .xml files was created in: //usr/local/share/gnuradio/grc/blocks. Because of that, my new module didn't appear in the gnuradio module list. So, I copy the .xml files to the correctly folder and n more problems with that. But, I would like if there are another solution to that. Do you have any idea ? Thanks, ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cannot find gnuradio companion
I'm going to guess that you have leftover stuff from a different attempt to install Gnu Radio, because there's a file in /usr/bin/gnuradio-companion that is either a symlink-to-nowhere, or it's pointing to a Python install that doesn't exist. Now, normally, build-gnuradio uninstalls (via your package manager) any existing Gnu Radio install, but if the package manager doesn't know about some file (like the /usr/bin/gnuradio-companion) that is apparently installed, it has no way of removing it. On 2015-03-17 13:33, Tianxiao Dong wrote: Hello ALL, I encountered one problem during installing GNU Radio on ubuntu 14.04 . I attached the whole installation log . Could someone help me with this? Thanks in advance. I used the script from the link below to install Gnuradio : http://gnuradio.org/redmine/projects/gnuradio/wiki/InstallingGRFromSource#Using-the-build-gnuradio-script Following is the log installing GNU Radio, I set the PYTHONPATH , but still cannot find gnuradio companion. echodtx@echodtx-VirtualBox:~$ export PYTHONPATH=/usr/local/lib/python2.7/dist-packages echodtx@echodtx-VirtualBox:~/gnuradio$ gnuradio-companion bash: /usr/bin/gnuradio-companion: No such file or directory % .Installing Done building and installing Gnu Radio GRC freedesktop icons install ...Done Done function gnuradio_build at: di mrt 17 16:31:11 CET 2015 Starting function rtl_build at: di mrt 17 16:31:11 CET 2015 Building rtl-sdr...Done building rtl-sdr Building hackrf...Done building hackrf Building gr-iqbal...gr-iqbal build apparently failed Exiting gr-iqbal build Building gr-osmosdr...Done building gr-osmosdr Done building/installing rtl-sdr/gr-osmosdr Done function rtl_build at: di mrt 17 16:34:24 CET 2015 Starting function extras at: di mrt 17 16:34:24 CET 2015 Doing GIT checkout for extra module gr-baz Building extra module gr-baz Doing GIT checkout for extra module grextras Building extra module grextras Done function extras at: di mrt 17 16:34:38 CET 2015 Starting function mod_groups at: di mrt 17 16:34:38 CET 2015 Group 'usrp' already in /etc/group User echodtx already in group 'usrp' Done function mod_groups at: di mrt 17 16:34:38 CET 2015 Starting function mod_udev at: di mrt 17 16:34:38 CET 2015 udevd: no process found Done function mod_udev at: di mrt 17 16:34:39 CET 2015 Starting function mod_sysctl at: di mrt 17 16:34:39 CET 2015 Required updates to /etc/sysctl.conf already in place usrp group already has real-time scheduling privilege Done function mod_sysctl at: di mrt 17 16:34:39 CET 2015 Starting function pythonpath at: di mrt 17 16:34:39 CET 2015 You should probably set your PYTHONPATH to: /usr/local/lib/python2.7/dist-packages Using: export PYTHONPATH=/usr/local/lib/python2.7/dist-packages in your .bashrc or equivalent file prior to attempting to run any Gnu Radio applications or Gnu Radio Companion. * Done function pythonpath at: di mrt 17 16:34:39 CET 2015 Done all functions at: di mrt 17 16:34:39 CET 2015 All Done === If you have found this script useful and time-saving, consider a donation to help me keep build-gnuradio, simple_ra, SIDsuite, meteor_detector, simple_fm_rcv, and multimode maintained and up to date. A simple paypal transfer to mle...@ripnet.com is all you need to do. == Send success/fail info to sbrac.org?echodtx@echodtx-VirtualBox:~$ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [1] Links: -- [1] 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] cannot find gnuradio companion
Dear Dong Tian Xiao, Still the best solution (for me) was to install to a clean OS otherwise you might run endlessly about it. Instalation to a clean Ubuntu 14.04 via Pybombs was fast and smooth. I might have a more detail description, if needed, let me know. Best regards, Iluta On Tuesday, March 17, 2015, mle...@ripnet.com wrote: I'm going to guess that you have leftover stuff from a different attempt to install Gnu Radio, because there's a file in /usr/bin/gnuradio-companion that is either a symlink-to-nowhere, or it's pointing to a Python install that doesn't exist. Now, normally, build-gnuradio uninstalls (via your package manager) any existing Gnu Radio install, but if the package manager doesn't know about some file (like the /usr/bin/gnuradio-companion) that is apparently installed, it has no way of removing it. On 2015-03-17 13:33, Tianxiao Dong wrote: Hello ALL, I encountered one problem during installing GNU Radio on ubuntu 14.04 . I attached the whole installation log . Could someone help me with this? Thanks in advance. I used the script from the link below to install Gnuradio : http://gnuradio.org/redmine/projects/gnc uradio/wiki/InstallingGRFromSource#Using-the-build-gnuradio-script Following is the log installing GNU Radio, I set the PYTHONPATH , but still cannot find gnuradio companion. echodtx@echodtx-VirtualBox:~$ export PYTHONPATH=/usr/local/lib/python2.7/dist-packages echodtx@echodtx-VirtualBox:~/gnuradio$ gnuradio-companion bash: /usr/bin/gnuradio-companion: No such file or directory % .Installing Done building and installing Gnu Radio GRC freedesktop icons install ...Done Done function gnuradio_build at: di mrt 17 16:31:11 CET 2015 Starting function rtl_build at: di mrt 17 16:31:11 CET 2015 Building rtl-sdr...Done building rtl-sdr Building hackrf...Done building hackrf Building gr-iqbal...gr-iqbal build apparently failed Exiting gr-iqbal build Building gr-osmosdr...Done building gr-osmosdr Done building/installing rtl-sdr/gr-osmosdr Done function rtl_build at: di mrt 17 16:34:24 CET 2015 Starting function extras at: di mrt 17 16:34:24 CET 2015 Doing GIT checkout for extra module gr-baz Building extra module gr-baz Doing GIT checkout for extra module grextras Building extra module grextras Done function extras at: di mrt 17 16:34:38 CET 2015 Starting function mod_groups at: di mrt 17 16:34:38 CET 2015 Group 'usrp' already in /etc/group User echodtx already in group 'usrp' Done function mod_groups at: di mrt 17 16:34:38 CET 2015 Starting function mod_udev at: di mrt 17 16:34:38 CET 2015 udevd: no process found Done function mod_udev at: di mrt 17 16:34:39 CET 2015 Starting function mod_sysctl at: di mrt 17 16:34:39 CET 2015 Required updates to /etc/sysctl.conf already in place usrp group already has real-time scheduling privilege Done function mod_sysctl at: di mrt 17 16:34:39 CET 2015 Starting function pythonpath at: di mrt 17 16:34:39 CET 2015 You should probably set your PYTHONPATH to: /usr/local/lib/python2.7/dist-packages Using: export PYTHONPATH=/usr/local/lib/python2.7/dist-packages in your .bashrc or equivalent file prior to attempting to run any Gnu Radio applications or Gnu Radio Companion. * Done function pythonpath at: di mrt 17 16:34:39 CET 2015 Done all functions at: di mrt 17 16:34:39 CET 2015 All Done === If you have found this script useful and time-saving, consider a donation to help me keep build-gnuradio, simple_ra, SIDsuite, meteor_detector, simple_fm_rcv, and multimode maintained and up to date. A simple paypal transfer to mle...@ripnet.com is all you need to do. == Send success/fail info to sbrac.org?echodtx@echodtx-VirtualBox:~$ ___ 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] Phase locked loop
Hi Daniele, Also, I don't see why you cannot combine other blocks to realize your own PLL implementation. Where did you read that you can’t use companion to add and drop the current available blocks to construct a phase locked loop? Wai Yee has a point here -- you can't have a circle in your (sample stream) flow graph -- GNU Radio doesn't allow that for reasons of causality. You can have a loose loop with feedback done with message ports, but that's not the same as a control loop (since there's no defined delay between the sample for which a error was estimated and the sample where the error correction is applied when using the asynchronous messages). Thus, you can't drag'n'drop together a proper control loop from discrete things like adders and integrators that you could design and analyze theoretically. In effect, GNU Radio's control loops are monolithic blocks -- that's somewhat sad from a modularity perspective, but then again, there's the control loop base class that allows you to implement arbitrary control loops rather easily, so Wai Yee, I recommend looking at the documentation [1], the referenced paper and the source code[2] of the existing costas loop. Best regards, Marcus Müller PS: I am using *USRP N210* for the hardware and I have installed *Gnuradio Companion* in *Ubuntu 12.04 LTS* (running in VMplayer). as a side note, I don't recommend running your digital signal processing for a high-rate capable device inside a VM, unless you know what you're doing -- the additional overhead in network packet handling might prove to be a problem. At lower rates, it should work fine. Also, why are you using a three years old Ubuntu? There's a new LTS release, almost a year old now, 14.04; I recommend using a modern platform. [1] http://gnuradio.org/doc/doxygen/classgr_1_1digital_1_1costas__loop__cc.html [2] https://github.com/gnuradio/gnuradio/blob/master/gr-digital/lib/costas_loop_cc_impl.cc On 03/17/2015 09:12 AM, Daniele Nicolodi wrote: On 17/03/15 02:05, yee_yy1992 wrote: Hi, Currently I am doing my Final Year Project to develop a phase measurement using Phase Locked Loop theory. I am using *USRP N210* for the hardware and I have installed *Gnuradio Companion* in *Ubuntu 12.04 LTS* (running in VMplayer). I have studied online that I can’t use companion to add and drop the current available blocks to construct a phase locked loop. Hello, what to you mean by that last sentence? GNURadio comes with PLL blocks in a few different fashions that can be used from the companion just fine. Also, I don't see why you cannot combine other blocks to realize your own PLL implementation. Where did you read that you can’t use companion to add and drop the current available blocks to construct a phase locked loop? Cheers, Daniele ___ 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] GNU Radio on Android
On Tue, Mar 17, 2015 at 12:10 AM, Vijay Galbaransingh vij...@sfu.ca wrote: Thanks Tom, that sorted it out. My audio output is a bit choppy but no matter – time to move on to some more complex flowgraphs in my Android app. Thanks again, Vijay Yes, the skipping in the audio output is a known bug, and apparently known to be difficult in Android. It's going to take some kind of double buffering to fix it at this level. I did not experience any problems with the audio source, though; I just saved it to a file, brought it back to my computer, and played it there and it sounded fine. Tom From: trond...@trondeau.com [mailto:trond...@trondeau.com] On Behalf Of Tom Rondeau Sent: March-16-15 06:37 To: Vijay Galbaransingh Cc: GNURadio Discussion List Subject: Re: [Discuss-gnuradio] GNU Radio on Android On Mon, Mar 16, 2015 at 3:28 AM, Vijay Galbaransingh vij...@sfu.ca wrote: Hi Tom, I have been following your notes on the wiki in an attempt to build a test app (a dial tone flowgraph.) I'm hitting a snag on the ndk-build step though -- when I use your example Android.mk listing, the linker isn't finding any of the static libraries we built (gnuradio, grand, boost, fftw.) Instead I'm getting a pile of undefined reference errors. I tried editing the example Android.mk file by adding the following before the shared library build: include $(CLEAR_VARS) LOCAL_MODULE := grand_static_lib #for example LOCAL_SRC_FILES := /opt/grandroid/lib/libgnuradio-grand.a include $(PREBUILT_STATIC_LIBRARY) However I quickly realised that while there are only a few gnuradio libraries to add this way, there are a ton of boost libraries... Is there a smarter way to add all the prebuilt .a libraries at once? Or am I headed in the wrong direction entirely? Any tips appreciated, Vijay Yep, you have to add all of the libraries into the Android.mk file. I've updated the wiki: http://gnuradio.org/redmine/projects/gnuradio/wiki/GRAndApps You can go there and simply download GrAndroid.mk that does all of this for you and include it in your Android.mk file. Just follow the instructions. Hope that helps, Tom From: trond...@trondeau.com [mailto:trond...@trondeau.com] On Behalf Of Tom Rondeau Sent: March-13-15 14:41 To: Vijay Galbaransingh Cc: GNURadio Discussion List Subject: Re: [Discuss-gnuradio] GNU Radio on Android On Fri, Mar 13, 2015 at 5:04 PM, Vijay Galbaransingh vij...@sfu.ca wrote: Hi, Has a patched version of GNU Radio which runs on Android been released? I'm working on a project where I'm transmitting information over audio from a desktop system to an Android device, and since setting up the transmitter end with GNU Radio was such a snap I would love to leverage the GNU Radio system to build the receiver as well. Thanks, Vijay Just yesterday, in fact: http://gnuradio.org/redmine/projects/gnuradio/wiki/Android I'll try to release some of my apps soon. One of them captures from the audio device, even. It's not too hard since there's the gr-grand opensl audio source block to talk to the audio system. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] 16QAM (was: Re: (no subject))
Dear Vishwanatha, have a look at the constellation_soft_receiver.grc example, which usually get's installed somewhere like /usr/[local/]/share/gnuradio/examples/digital . You'd add a constellation object, and use that in the constellation receiver block. Have you had a look at the documentation [1]? Also, an introduction into rather comprehensive digital transmission system is done in our guided tutorials[2], which I really recommend reading from first to last. By the way: You forgot to add a subject; since it's hard to keep track of emails if you don't, I added one. For future list mails, I'd like to ask you to have quick look at the principles in [3]. In this case, it especially be interesting to know where you've already looked and what you've already tried, as we constantly try to improve usability as well as to encourage users to constructively take part in discussion and development: There should not necessarily be a gap between core developers that know everything and beginner users that can't solve problems without asking. Best regards, and happy hacking, Marcus [1] http://gnuradio.org/doc/doxygen/ , search for constellation_receiver [2] https://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorials [3] http://gnuradio.org/redmine/projects/gnuradio/wiki/ReportingErrors On 03/17/2015 08:22 AM, Vishwanatha H G wrote: Hi all, I'm trying to get the constellation of 16QAM. How to use constellation receiver block for 16QAM? thanks in advance ___ 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] Audio Source configuration
Hello: Can anyone point me to some color on how to work with the Audio Source. I am working examples to transmit FM Audio and have problems with Underruns on the UHD:USRP Sink. The examples (from files.ettus.com/tutorials/Lab_5.grc and others) I am running select Audio Source Arch:alsa and this seems to be a problem. I have tried to replace the Device name with plughw:0,0 as suggested in the documetnation, but this does not seem to have an impact on the choice of Audio arch: alsa If I replace the audio source with a signal source at the same sample rate all is well, but the Audio Source implements . Using the suggestion of having the USRP expect a bit lower rate than the audio can deliver seems to implement nearly limitless delay the voice is received but only after a very long ... many seconds delay ... At this time I am using a B210 connected via USB3 to an I7 with plenty of memory running Ubuntu 12.04 I have similar issues trying to use an E310 as the transmitter ... Any direction would be appreciated. LVDJ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [USRP-users] Audio Source configuration
If you're getting long strings of 'U', this means a *gross* sample-rate mis-match somewhere in your flow-graph, rather than the more-subtle two clock problem. Make sure that everything agrees internal to the graph about sample-rates, and, perhaps more importantly, that your audio *hardware* is capable of delivering the desired rates. On 2015-03-17 10:30, Larry Van Der Jagt via USRP-users wrote: Hello: Can anyone point me to some color on how to work with the Audio Source. I am working examples to transmit FM Audio and have problems with Underruns on the UHD:USRP Sink. The examples (from files.ettus.com/tutorials/Lab_5.grc [2] and others) I am running select Audio Source Arch:alsa and this seems to be a problem. I have tried to replace the Device name with plughw:0,0 as suggested in the documetnation, but this does not seem to have an impact on the choice of Audio arch: alsa If I replace the audio source with a signal source at the same sample rate all is well, but the Audio Source implements . Using the suggestion of having the USRP expect a bit lower rate than the audio can deliver seems to implement nearly limitless delay the voice is received but only after a very long ... many seconds delay ... At this time I am using a B210 connected via USB3 to an I7 with plenty of memory running Ubuntu 12.04 I have similar issues trying to use an E310 as the transmitter ... Any direction would be appreciated. LVDJ ___ USRP-users mailing list usrp-us...@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [1] Links: -- [1] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [2] http://files.ettus.com/tutorials/Lab_5.grc ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Phase locked loop
Hi Daniele, On 03/17/2015 03:38 PM, Daniele Nicolodi wrote: I realized this while having my coffee this morning. I should avoid to reply to emails before assuming the right amount of caffeine :) oh... I know that feeling! In effect, GNU Radio's control loops are monolithic blocks -- that's somewhat sad from a modularity perspective, but then again, there's the control loop base class that allows you to implement arbitrary control loops rather easily Last time I looked into it, this base class is not that generic: it can be easily used to implement phase-lock loops, but it did not seem designed to control other quantities, like amplitude for example. But I may have had a too quick loot at it. I'd have to admit, you're right. I'm not quite sure, but I think Wai Yee really just wants a PLL -- so that would be fine. Greetings, Marcus ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio on Android
Tom,
What kind of sample rate / setup are you using for your opensl_source? I've
set up a flowgraph that is just an opensl_source (sampling at 48kHz)
connected to a file sink, and when I play back the file through GRC on my
desktop my audio is coming out pretty garbled, as if samples are being
dropped. I've also tried a couple other sampling rates (44.1kHz, 32kHz,
16kHz to name a few.) I'm using a Nexus 4 running Android 5.0.1. Pasted
below is some of my code.
Vijay
Flowgraph code:
JNIEXPORT void JNICALL
Java_com_example_grrecordmic_GrRecordMic_InitFlowgraph(JNIEnv* env, jobject
thiz, jstring jsinkfilename)
{
int rate = 48000;
const char *sinkfilename = env-GetStringUTFChars(jsinkfilename, 0);
global_tb = gr::make_top_block(Record_Mic);
gr::grand::opensl_source::sptr micSource =
gr::grand::opensl_source::make(rate);
gr::blocks::file_sink::sptr fileSink =
gr::blocks::file_sink::make(sizeof(float), sinkfilename, false);
global_tb-connect(micSource, 0, fileSink, 0);
env-ReleaseStringUTFChars(jsinkfilename, sinkfilename);
}
From: trond...@trondeau.com [mailto:trond...@trondeau.com] On Behalf Of Tom
Rondeau
Sent: March-17-15 07:37
To: Vijay Galbaransingh
Cc: GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] GNU Radio on Android
On Tue, Mar 17, 2015 at 12:10 AM, Vijay Galbaransingh vij...@sfu.ca wrote:
Thanks Tom, that sorted it out. My audio output is a bit choppy but no
matter – time to move on to some more complex flowgraphs in my Android app.
Thanks again,
Vijay
Yes, the skipping in the audio output is a known bug, and apparently known
to be difficult in Android. It's going to take some kind of double buffering
to fix it at this level. I did not experience any problems with the audio
source, though; I just saved it to a file, brought it back to my computer,
and played it there and it sounded fine.
Tom
From: trond...@trondeau.com [mailto:trond...@trondeau.com] On Behalf Of Tom
Rondeau
Sent: March-16-15 06:37
To: Vijay Galbaransingh
Cc: GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] GNU Radio on Android
On Mon, Mar 16, 2015 at 3:28 AM, Vijay Galbaransingh vij...@sfu.ca wrote:
Hi Tom,
I have been following your notes on the wiki in an attempt to build a test
app (a dial tone flowgraph.) I'm hitting a snag on the ndk-build step
though -- when I use your example Android.mk listing, the linker isn't
finding any of the static libraries we built (gnuradio, grand, boost, fftw.)
Instead I'm getting a pile of undefined reference errors.
I tried editing the example Android.mk file by adding the following before
the shared library build:
include $(CLEAR_VARS)
LOCAL_MODULE := grand_static_lib #for example
LOCAL_SRC_FILES := /opt/grandroid/lib/libgnuradio-grand.a
include $(PREBUILT_STATIC_LIBRARY)
However I quickly realised that while there are only a few gnuradio
libraries to add this way, there are a ton of boost libraries... Is there a
smarter way to add all the prebuilt .a libraries at once? Or am I headed in
the wrong direction entirely?
Any tips appreciated,
Vijay
Yep, you have to add all of the libraries into the Android.mk file. I've
updated the wiki:
http://gnuradio.org/redmine/projects/gnuradio/wiki/GRAndApps
You can go there and simply download GrAndroid.mk that does all of this for
you and include it in your Android.mk file. Just follow the instructions.
Hope that helps,
Tom
From: trond...@trondeau.com [mailto:trond...@trondeau.com] On Behalf Of Tom
Rondeau
Sent: March-13-15 14:41
To: Vijay Galbaransingh
Cc: GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] GNU Radio on Android
On Fri, Mar 13, 2015 at 5:04 PM, Vijay Galbaransingh vij...@sfu.ca wrote:
Hi,
Has a patched version of GNU Radio which runs on Android been released?
I'm working on a project where I'm transmitting information over audio
from a desktop system to an Android device, and since setting up the
transmitter end with GNU Radio was such a snap I would love to leverage
the GNU Radio system to build the receiver as well.
Thanks,
Vijay
Just yesterday, in fact:
http://gnuradio.org/redmine/projects/gnuradio/wiki/Android
I'll try to release some of my apps soon. One of them captures from the
audio device, even. It's not too hard since there's the gr-grand opensl
audio source block to talk to the audio system.
Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
