Re: [Discuss-gnuradio] Citation of GNUradio codes
On Fri, Feb 24, 2012 at 07:16:17PM -0500, Nazmul Islam wrote: > I apologize in advance if a similar question has already been asked here. I > searched for similar questions in the mailing list but could not find one. I think this is a great question, and I'll post Michael's answer to the FAQ. MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgpE2WwuVXfhi.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] "Related Pages" and left-over docs
Hi, I really like the "Related Pages" section that was introduced in the Doxygen-generated docs. Wouldn't this be a great place to put an updated version of "Exploring GNU Radio" and a reincarnation of the docs for gr-howto-write-a-block? I realise the Doxygen stuff is very C++-centric, but right now these pieces of documentation are rotting away and are of no real use. MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgpSNfi7DMeQd.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Measuring signal parameters in the receiver
Hi all, I am working to compare the performance of an ofdm single transceiver and a mimo-ofdm 2x1 one. For this purpose, I would like to measure parameters at the receiver side such as snr, goodput, ber, to see the improvement that the mimo implementation should provide...So far, I've been trying it by changing how the packet is built, specifically, I am adding a field with a packet number so I can check in the receiver side how many corrects packets are received. With this method I think I can measure in a reliable way the goodput and the ber, but I still don't know how to measure the snr. I would like to know if anybody has any advice on how to do all these measurements. I am working with GNU C++ version 4.4.1 [gcc-4_4-branch revision 150839]; Boost_103900; UHD_003.004.000-122b947, because I couldn't merge the mimo branch with the latest version of gnuradio. Thanks in advance. Jorge Hernandez ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] question about the sampling rate
hi all, the usrp final samling rate coming out from the codec is 128 Msps so i think that you should follow this equation : sample rate* interpolation =128 msps you can set the sampling rate =1 msps and the interpolation rate =128 try it and inform me of the result yours, osama riad > Date: Sun, 26 Feb 2012 13:09:28 -0500 > From: mle...@ripnet.com > To: ahmedalsawi2...@gmail.com; Discuss-gnuradio@gnu.org > Subject: Re: [Discuss-gnuradio] question about the sampling rate > > On 02/26/2012 12:11 PM, Ahmed Alsawi wrote: > > Hi all, > > I am new to gnuradio and i am trying to make simple transmission and > > reception. > > I want to understand the sampling rate of the uhd sink and source and > > how to choose it > > and the sampling rate of the blocks in the flow graph. > > > > when running on sine of 100 kHZ and sampling rate of 0.5 MHz and same > > sampling rate for uhd > > I get UU ,it means under sampling,Right? > > How to avoid it ??? > > Thanks > > > Sample rate is really only relevant at the edges, and when calling the > filter synthesis modules, most interior blocks have no concept of >sample rate. > > 'U' means under-run the producer (in this case, your program) can't keep > up with the consumer--the UHD device. > > > -- > 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USPR2 set freq.Offset
hallo list, i'd like to setup an OFDM System using 2 USRP2. while this i getting two Questions. ( currently there is no external 10MHz generator connected. however, hope it will be working) 1. To achieve my goal,first i want to compensate the freq.offset and figure out (with usrp2_fft.py) a ~40kHz difference. Now i want to set this in my GRC workspace but it is not working.Using the GRC USRP2 wrapper and modified the LO Offset option with 40e3 and generate, i can't see any response. Does "set_lo_offset" work, i'm sure? What is the problem? 2. Second, to figure out the offset i transmit a simple 1k sinus with amp 0.8, decimation 200 and TX/RX Gain 0. On RX Side i see a main peak(~-44dB) with freq.offset and some additional small peaks(~-68dB) while noise is ~98dB. reducing the sinus amp to 0.1, only the main peak with ~-60dB exist. When i raise the RX Gain(amp=0.1) the same effect occurs by around 15dB, peak is ~-51dB. Is this a normal behavior or is something wrong with my Daugherboard/USRP2 amplifiers. My Setup: 2xUSRP2(hw=0x0400) with RFX2400 , Gnuradio is latest from tom branch dig_ofdm thanks for any hints lars -- View this message in context: http://old.nabble.com/USPR2-set-freq.Offset-tp33399521p33399521.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] help with QAM demodulation
Does anyone know if the QAM demodulator code is working properly? I would like to get a QAM demodulator working for a symbol rate of 300ksym/s. I don't know whether I am just using the wrong parameters or if the blocks do not work properly, but I am not getting the results I expect. To test the code out I am using the GRC. I have a vector source with a known data sequence running into the qam mod block and then the output of that into a QAM demod block. The output of the QAM demod is running into a Uchar to Float, and I am plotting the results on a WX GUI Scope. I have the exact same settings on both the QAM mod and demod blocks. The output I am seeing on the scope looks completely random. (I also tried other vector source data: When the input is 0x0F, repeating, the output I see is 1010 repeating. But when I use 0x0E, the results are random again.) I have also tried demodulating a real QAM signal with a known data sequence, also to no avail. I have been working on this for about a month now and haven't had any success. I have examined the underlying QAM.py and generic_mod, generic_demod codes, and they seem to be written properly. But I am not getting the expected results. Any help with this problem or advice you can give will be greatly appreciated, and I will return the favor by helping out in any way that I can. Thank you very much in advance, Jeff ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] help with QAM demodulation
On Mon, Feb 27, 2012 at 9:36 AM, Jeff Hodges wrote: > Does anyone know if the QAM demodulator code is working properly? I would > like to get a QAM demodulator working for a symbol rate of 300ksym/s. I > don't know whether I am just using the wrong parameters or if the blocks do > not work properly, but I am not getting the results I expect. > > To test the code out I am using the GRC. I have a vector source with a > known data sequence running into the qam mod block and then the output of > that into a QAM demod block. The output of the QAM demod is running into a > Uchar to Float, and I am plotting the results on a WX GUI Scope. I have > the exact same settings on both the QAM mod and demod blocks. The output I > am seeing on the scope looks completely random. (I also tried other vector > source data: When the input is 0x0F, repeating, the output I see is > 1010 repeating. But when I use 0x0E, the results are random again.) > > I have also tried demodulating a real QAM signal with a known data > sequence, also to no avail. > > I have been working on this for about a month now and haven't had any > success. I have examined the underlying QAM.py and generic_mod, > generic_demod codes, and they seem to be written properly. But I am not > getting the expected results. > > Any help with this problem or advice you can give will be greatly > appreciated, and I will return the favor by helping out in any way that I > can. > > Thank you very much in advance, > > Jeff > Jeff, It's been a while since I used the QAM mod/demod blocks. They are definitely not complete since there's no synchronization for them, yet, but since you are just working in simulation, this shouldn't be a problem. What alphabet (M) size are you using with the QAM module? And the results for 0x0F look like the data is differentially encoded, so that might just be your problem there. Have you looked at the constellation? Does it look ok? Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] "Related Pages" and left-over docs
On Mon, Feb 27, 2012 at 4:52 AM, Martin Braun wrote: > Hi, > > I really like the "Related Pages" section that was introduced in the > Doxygen-generated docs. Wouldn't this be a great place to put an updated > version of "Exploring GNU Radio" and a reincarnation of the docs for > gr-howto-write-a-block? I realise the Doxygen stuff is very C++-centric, > but right now these pieces of documentation are rotting away and are of > no real use. > > MB > Martin, Yes, it would be a great place to put that. I started doing these pages to keep a lot of information available within the code itself and would like to see them expanded. The main page itself in the manual now points to a number of different pages to explain various aspects of GNU Radio, so adding more to this would be useful. Thanks, Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Using volk in Mac: test report
On Thu, Feb 23, 2012 at 9:08 PM, Nowlan, Sean wrote: > Hi Tom, > > ** ** > > I tested with your merged branch. No segfault and same tests fail as > expected. > > ** ** > > I noticed several weird numbers in the orc results. Some of them > correspond to the failed cases. Do you know what is causing these? Printf > formatting issue? Hitting bounds of float type and wrapping around? > Relevant output: > So these test results are really interesting. The time results are one thing, but it might be that the numerical results you pointed out are hopefully easy to fix. In the volk_32fc_s32f_magnitude_16i_a block, it could be an issue with rounding. At first, I was thinking it was the direction of the rounding operation, but the documents from ARM say that the only mode is to round to nearest neighbor and that other modes are disabled (which is what we've set the SSE to, as well). Perhaps instead of truncation when converting to 16-bit shorts it rounds first. The 32fc_x2_multiply_32fc_a kernel looks like all of the numbers are correct. This is probably just a precision thing and we're asking for the numbers to be exact for way too many decimal places. Hopefully I'll get access to an E100 soon to look into this more. Tom > RUN_VOLK_TESTS: volk_16ic_deinterleave_16i_x2_a > > generic completed in 42.47s > > orc completed in 3.10883e-39s > > Best arch: orc > > -- > > RUN_VOLK_TESTS: volk_16ic_s32f_deinterleave_32f_x2_a > > generic completed in 17.28s > > orc completed in -3.90577e+11s > > Best arch: orc > > -- > > RUN_VOLK_TESTS: volk_32fc_s32f_magnitude_16i_a > > generic completed in 4.37s > > orc completed in 1.35136e+09s > > offset 1107 in1: 29281 in2: 29282 > > offset 1187 in1: -27601 in2: -27600 > > offset 1522 in1: -31248 in2: -31249 > > offset 2396 in1: 26146 in2: 26145 > > offset 2486 in1: 25394 in2: 25393 > > offset 4084 in1: 16452 in2: 16451 > > offset 5052 in1: 28692 in2: 28691 > > offset 5296 in1: 30869 in2: 30868 > > offset 5467 in1: -32706 in2: -32705 > > offset 6388 in1: 19556 in2: 19557 > > volk_32fc_s32f_magnitude_16i_a: fail on arch orc > > Best arch: generic > > -- > > RUN_VOLK_TESTS: volk_32fc_magnitude_32f_a > > generic completed in 35.24s > > orc completed in 6.93125e+10s > > Best arch: generic > > -- > > RUN_VOLK_TESTS: volk_32fc_x2_multiply_32fc_a > > generic completed in 52.66s > > orc completed in -3.4978e+12s > > offset 3 in1: 0.382086 in2: 0.382086 > > offset 4 in1: 0.496706 in2: 0.496706 > > offset 8 in1: 0.170967 in2: 0.170967 > > offset 10 in1: 0.165878 in2: 0.165878 > > offset 14 in1: 0.398192 in2: 0.398192 > > offset 15 in1: 0.492358 in2: 0.492358 > > offset 17 in1: 0.568251 in2: 0.568251 > > offset 19 in1: 0.0630723 in2: 0.0630723 > > offset 20 in1: 0.251459 in2: 0.251459 > > offset 22 in1: 0.348539 in2: 0.348539 > > volk_32fc_x2_multiply_32fc_a: fail on arch orc > > offset 0 in1: 0.140486 in2: 0.140486 > > offset 1 in1: 0.691375 in2: 0.691375 > > offset 5 in1: 0.63745 in2: 0.63745 > > offset 11 in1: 0.644697 in2: 0.644697 > > offset 14 in1: 0.858205 in2: 0.858205 > > offset 15 in1: 0.94011 in2: 0.94011 > > offset 16 in1: 0.490713 in2: 0.490713 > > offset 18 in1: 0.190573 in2: 0.190573 > > offset 19 in1: 0.0226408 in2: 0.0226408 > > offset 20 in1: 0.895774 in2: 0.895774 > > volk_32fc_x2_multiply_32fc_a: fail on arch orc > > offset 1 in1: 0.524585 in2: 0.524585 > > offset 2 in1: 0.236218 in2: 0.236218 > > offset 6 in1: 0.733853 in2: 0.733853 > > offset 9 in1: 0.290247 in2: 0.290247 > > offset 11 in1: 0.529422 in2: 0.529422 > > offset 12 in1: 0.180218 in2: 0.180218 > > offset 14 in1: 0.496568 in2: 0.496568 > > offset 15 in1: 0.0297472 in2: 0.0297472 > > offset 19 in1: 0.351138 in2: 0.351138 > > offset 20 in1: 0.300737 in2: 0.300737 > > volk_32fc_x2_multiply_32fc_a: fail on arch orc > > Best arch: generic > > ** ** > > Sean > > ** ** > > *From:* trond...@trondeau.com [mailto:trond...@trondeau.com] *On Behalf > Of *Tom Rondeau > *Sent:* Thursday, February 23, 2012 11:18 AM > > *To:* Nowlan, Sean > *Cc:* Nick Foster; discuss-gnuradio@gnu.org > *Subject:* Re: [Discuss-gnuradio] Using volk in Mac: test report > > ** ** > > On Wed, Feb 22, 2012 at 10:19 PM, Nowlan, Sean < > sean.now...@gtri.gatech.edu> wrote: > > I confirmed this works on E100 insofar as I no longer get a segfault on > volk_32fc_s32fc_multiple_32fc_a. But volk_32fc_s32f_magnitude_16i_a and > volk_32fc_x2_multiply_32fc_a still fail as expected. > > > > Sean > > ** ** > > ** ** > > Sean, > > I just merged Nick's branch into my safe_align branch. Can you check that > one out and test when you get a chance? I just want to make sure we're all > on the same branch here. And please post the output of 'ctest -V -R volk'.
Re: [Discuss-gnuradio] Feature #394
On Fri, Feb 24, 2012 at 9:48 PM, Andrew Davis wrote: > Ok, I've got a branch on github: > https://github.com/glneo/gnuradio-davisaf/tree/optfir with optfir > ported and working in C++, it's part of gr ( gr.optfir ) like firdes. > This keeps the filter design tools together and allows the old optfir > to still be imported and used until I can get all the examples ported > ( which will just be changing "optfir" to "gr.optfir" ) > > This is kinda just an update, it will probably not be ready for > merging until I finish porting the blks2 hier to C++. Then all the > examples can be done in both python and C++, hopefully this opens up > the API a bit. Andrew, Thanks. It might be easier to handle these in stages from a merge standpoint. Since you're just adding stuff, it's easy to add bits and pieces. If the optfir is ready, we can look into merging it while you make another branch for other conversions to C++. Thanks! Tom > On Wed, Feb 8, 2012 at 11:27 PM, Andrew Davis > wrote: > > Thanks, I think i'll work on QA too while i'm at it then. > > > > > > On Wed, Feb 8, 2012 at 10:32 PM, Tom Rondeau wrote: > >> > >> On Tue, Feb 7, 2012 at 9:52 PM, Andrew Davis > >> wrote: > >>> > >>> Hello all, > >>> > >>> I would like to help expand the C++ API, so I'm attempting to work on > >>> Feature #394 or "Re-implement hierarchical blocks currently living in > blks2 > >>> in C++ and put into gnuradio-core/src/lib/hier." I've started on > am_demod.py > >>> but this requires optfir, which is also in python, I think this should > also > >>> be available to us C++ users, so i'm converting it too. I'm new to > GnuRadio > >>> and would like to know if i'm on the right track before I get to far. > The > >>> files so far are included. > >>> > >>> Thank you. > >> > >> > >> > >> Hi Andrew, > >> It looks to me like you're on the right track! Thanks for making a go at > >> it. > >> > >> So you seem to have the general style correct in the files that I looked > >> at. Once it's coded, the ultimate test is, obviously, to make sure that > the > >> data produced by any of these guys is the same as is produced by the > Python > >> versions. This is a good case where the QA code would be useful, so we > would > >> have a set of tests with known output that you could compare against > the new > >> implementations. Unfortunately, I don't see an QA for the optfir, but it > >> would probably be good to have one. > >> > >> Tom > >> > > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] help with QAM demodulation
On Mon, Feb 27, 2012 at 7:36 AM, Jeff Hodges wrote: > Does anyone know if the QAM demodulator code is working properly? I would > like to get a QAM demodulator working for a symbol rate of 300ksym/s. I > don't know whether I am just using the wrong parameters or if the blocks do > not work properly, but I am not getting the results I expect. > > To test the code out I am using the GRC. I have a vector source with a known > data sequence running into the qam mod block and then the output of that > into a QAM demod block. The output of the QAM demod is running into a Uchar > to Float, and I am plotting the results on a WX GUI Scope. I have the exact > same settings on both the QAM mod and demod blocks. The output I am seeing > on the scope looks completely random. (I also tried other vector source > data: When the input is 0x0F, repeating, the output I see is 1010 > repeating. But when I use 0x0E, the results are random again.) > > I have also tried demodulating a real QAM signal with a known data sequence, > also to no avail. > > I have been working on this for about a month now and haven't had any > success. I have examined the underlying QAM.py and generic_mod, > generic_demod codes, and they seem to be written properly. But I am not > getting the expected results. > > Any help with this problem or advice you can give will be greatly > appreciated, and I will return the favor by helping out in any way that I > can. > > Thank you very much in advance, > > Jeff > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > If it's not working it's probably my fault, so I'll do some tests myself today and get back to you. Cheers, Ben ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] help with QAM demodulation
On Mon, Feb 27, 2012 at 10:00 AM, Ben Reynwar wrote: > On Mon, Feb 27, 2012 at 7:36 AM, Jeff Hodges wrote: >> Does anyone know if the QAM demodulator code is working properly? I would >> like to get a QAM demodulator working for a symbol rate of 300ksym/s. I >> don't know whether I am just using the wrong parameters or if the blocks do >> not work properly, but I am not getting the results I expect. >> >> To test the code out I am using the GRC. I have a vector source with a known >> data sequence running into the qam mod block and then the output of that >> into a QAM demod block. The output of the QAM demod is running into a Uchar >> to Float, and I am plotting the results on a WX GUI Scope. I have the exact >> same settings on both the QAM mod and demod blocks. The output I am seeing >> on the scope looks completely random. (I also tried other vector source >> data: When the input is 0x0F, repeating, the output I see is 1010 >> repeating. But when I use 0x0E, the results are random again.) >> >> I have also tried demodulating a real QAM signal with a known data sequence, >> also to no avail. >> >> I have been working on this for about a month now and haven't had any >> success. I have examined the underlying QAM.py and generic_mod, >> generic_demod codes, and they seem to be written properly. But I am not >> getting the expected results. >> >> Any help with this problem or advice you can give will be greatly >> appreciated, and I will return the favor by helping out in any way that I >> can. >> >> Thank you very much in advance, >> >> Jeff >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > > If it's not working it's probably my fault, so I'll do some tests > myself today and get back to you. > > Cheers, > Ben I found a bug in the xml file for the demodulator that would cause problems if you requested no gray-coding. It cause gnuradio-companion to pass an incorrect parameter name. A fix is at https://github.com/benreynwar/gnuradio/commit/e68ab8589ca235563f8c061fbb79d13793d1f21f In case that wasn't your problem I'll post an example that works for me: from gnuradio import gr, digital class qam_mod_demod(gr.top_block): def __init__(self): super(qam_mod_demod, self).__init__() src = gr.vector_source_b([1, 1, 1, 0, 1, 0, 0, 1, 1, 0, 1, 0, 0, 0]*1000) packer = gr.unpacked_to_packed_bb(1, gr.GR_MSB_FIRST) self.snk = gr.vector_sink_b() mod = digital.qam.qam_mod(constellation_points=16, mod_code="gray", differential=True, samples_per_symbol=2, excess_bw=0.35) demod = digital.qam.qam_demod(constellation_points=16, mod_code="gray", differential=True, samples_per_symbol=2, excess_bw=0.35, freq_bw=6.28/100.0, timing_bw=6.28/100.0, phase_bw=6.28/100.0) unpacker = gr.packed_to_unpacked_bb(8, gr.GR_MSB_FIRST) self.connect(src, packer, mod, demod, unpacker, self.snk) if __name__ == '__main__': qmd = qam_mod_demod() qmd.run() data = qmd.snk.data() print(data) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD Error - UDP transport problem
On 02/26/2012 08:27 PM, Ahmad Zaki Yaacob wrote: > Hi, > > I'm running on Debian 5.0 Lenny. My device is USRP2. I have installed UHD > 003.003.001. Boost 10400. GNU C++ version 4.6.2. I'm having problem to get > uhd_find_devices working. > > The error message is > UHD Error: > Cannot open UDP transport on192.168.10.2 > epoll: Function not implemented > No UHD Devices Found > > I'm able to ping the USRP2. There is no firewall. It's a fresh install of > Debian 5.0. Previously, there is no problem with Ubuntu 10.04. > > I installed the UHD first before installing gnuradio. After I installed > gnuradio, I got the same response. > > Could this be the problem of UHD installation/dependencies? > > This is probably a boost bug. I bet that the compile-time feature detection - aka the processor macros have decided that your system should be using epoll. You might have to search the include/boost/asio/*.hpp files looking for a definition you can pass to force the right polling method. https://answers.launchpad.net/adchpp/+question/182015 So, you might try this: http://pastebin.com/y5umvDzV Anyways, thats my best educated guess. Let us know if you figure it out. -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GMSK Over the Air
Hello group, I am helping a group of students at my University design a basic GMSK waveform. I have some experience in GNU Radio, but most of what I do is in GRC only. The setup: I have designed a GMSK waveform that consists of a file souce=>packet encoder=>GMSK Mod=>GMSK Demod=>packet decoder=>file source. The files from input to output are not exactly the same. The end of the output file seems to be lost during the loopback. I have speculations as to why this is, but it's not important. Now when I try to take this same waveform and perform GMSK transmission over the air, nothing is received at the output of the decoder block. The waveform is as follows: Tx: file source=>packet encoder=>GMSK mod=>UHD: USRP Sink (USRP 1 with an RFX 2400) Rx: UHD: USRP source=>GMSK Demod=>Packet decoder=>file sink. The Problem: Although I can see the GMSK signal on the Rx end off of the USRP, nothing is produced at the output of the packet decoder. The BT param on the GMSK mod block is ~1, the samples per symbol is 8, and almost everything else is default. Is there something I'm missing, or does this block just not work in an over-the-air scenario? -- View this message in context: http://old.nabble.com/GMSK-Over-the-Air-tp33402373p33402373.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] help with QAM demodulation
Thanks Ben and Tom, you two have been very helpful. The code Ben provided does work, and adjusting my GRC program to use the same parameters, I was able to achieve the expected results. However, it appears there are two issues: (1) When differential encoding is set to off for both mod/demod blocks, the output data becomes invalid (2) When the samples per symbol is above 10 the output also becomes invalid. Any ideas on what may be causing these discrepancies? In response to Tom's questions, I am using 16-QAM and the constellation does look very noisy (both phase and amplitude) coming out of the QAM mod and being observed on the WX GUI Constellation Sink. But then again, there a lot of parameters on that signal processing block, so maybe I do not have the proper values set. Thanks, Jeff On Mon, Feb 27, 2012 at 12:50 PM, Ben Reynwar wrote: > On Mon, Feb 27, 2012 at 10:00 AM, Ben Reynwar wrote: > > On Mon, Feb 27, 2012 at 7:36 AM, Jeff Hodges > wrote: > >> Does anyone know if the QAM demodulator code is working properly? I > would > >> like to get a QAM demodulator working for a symbol rate of 300ksym/s. I > >> don't know whether I am just using the wrong parameters or if the > blocks do > >> not work properly, but I am not getting the results I expect. > >> > >> To test the code out I am using the GRC. I have a vector source with a > known > >> data sequence running into the qam mod block and then the output of that > >> into a QAM demod block. The output of the QAM demod is running into a > Uchar > >> to Float, and I am plotting the results on a WX GUI Scope. I have the > exact > >> same settings on both the QAM mod and demod blocks. The output I am > seeing > >> on the scope looks completely random. (I also tried other vector source > >> data: When the input is 0x0F, repeating, the output I see is 1010 > >> repeating. But when I use 0x0E, the results are random again.) > >> > >> I have also tried demodulating a real QAM signal with a known data > sequence, > >> also to no avail. > >> > >> I have been working on this for about a month now and haven't had any > >> success. I have examined the underlying QAM.py and generic_mod, > >> generic_demod codes, and they seem to be written properly. But I am not > >> getting the expected results. > >> > >> Any help with this problem or advice you can give will be greatly > >> appreciated, and I will return the favor by helping out in any way that > I > >> can. > >> > >> Thank you very much in advance, > >> > >> Jeff > >> > >> ___ > >> Discuss-gnuradio mailing list > >> Discuss-gnuradio@gnu.org > >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >> > > > > If it's not working it's probably my fault, so I'll do some tests > > myself today and get back to you. > > > > Cheers, > > Ben > > I found a bug in the xml file for the demodulator that would cause > problems if you requested no gray-coding. > It cause gnuradio-companion to pass an incorrect parameter name. > A fix is at > https://github.com/benreynwar/gnuradio/commit/e68ab8589ca235563f8c061fbb79d13793d1f21f > > In case that wasn't your problem I'll post an example that works for me: > > from gnuradio import gr, digital > > class qam_mod_demod(gr.top_block): > >def __init__(self): >super(qam_mod_demod, self).__init__() >src = gr.vector_source_b([1, 1, 1, 0, 1, 0, 0, 1, 1, 0, 1, 0, > 0, 0]*1000) >packer = gr.unpacked_to_packed_bb(1, gr.GR_MSB_FIRST) >self.snk = gr.vector_sink_b() >mod = digital.qam.qam_mod(constellation_points=16, > mod_code="gray", > differential=True, > samples_per_symbol=2, > excess_bw=0.35) >demod = digital.qam.qam_demod(constellation_points=16, > mod_code="gray", > differential=True, > samples_per_symbol=2, > excess_bw=0.35, > freq_bw=6.28/100.0, > timing_bw=6.28/100.0, > phase_bw=6.28/100.0) >unpacker = gr.packed_to_unpacked_bb(8, gr.GR_MSB_FIRST) >self.connect(src, packer, mod, demod, unpacker, self.snk) > > if __name__ == '__main__': >qmd = qam_mod_demod() >qmd.run() >data = qmd.snk.data() >print(data) > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] help with QAM demodulation
On Mon, Feb 27, 2012 at 4:51 PM, Jeff Hodges wrote: > Thanks Ben and Tom, you two have been very helpful. > > The code Ben provided does work, and adjusting my GRC program to use the > same parameters, I was able to achieve the expected results. > > However, it appears there are two issues: > > (1) When differential encoding is set to off for both mod/demod blocks, > the output data becomes invalid > I'm not sure the differential en/decoder works for QAM. I suggested it before because of the bits that you sent us, but the gray coding was the problem, which makes more sense. > (2) When the samples per symbol is above 10 the output also becomes > invalid. > I'm not sure why you would want to run it with that many sps, anyway. I'd probably have to dive back into the code to see what might be the problem there. Theoretically, it should be doable, but since I've never run it with that many, it's probably never been exercised. > Any ideas on what may be causing these discrepancies? > > In response to Tom's questions, I am using 16-QAM and the constellation > does look very noisy (both phase and amplitude) coming out of the QAM mod > and being observed on the WX GUI Constellation Sink. But then again, there > a lot of parameters on that signal processing block, so maybe I do not have > the proper values set. > > Thanks, > > Jeff The noise might be due to ISI since you're just coming out of a RRC filter at that point. Unless the constellation sink has another RRC in it. Also, that sink tries to do some synchronization designed for PSK signals, so it won't work great and might be causing some of your error. Try just using an oscope and plottng x verus y. Tom > On Mon, Feb 27, 2012 at 12:50 PM, Ben Reynwar wrote: > >> On Mon, Feb 27, 2012 at 10:00 AM, Ben Reynwar wrote: >> > On Mon, Feb 27, 2012 at 7:36 AM, Jeff Hodges >> wrote: >> >> Does anyone know if the QAM demodulator code is working properly? I >> would >> >> like to get a QAM demodulator working for a symbol rate of 300ksym/s. I >> >> don't know whether I am just using the wrong parameters or if the >> blocks do >> >> not work properly, but I am not getting the results I expect. >> >> >> >> To test the code out I am using the GRC. I have a vector source with a >> known >> >> data sequence running into the qam mod block and then the output of >> that >> >> into a QAM demod block. The output of the QAM demod is running into a >> Uchar >> >> to Float, and I am plotting the results on a WX GUI Scope. I have the >> exact >> >> same settings on both the QAM mod and demod blocks. The output I am >> seeing >> >> on the scope looks completely random. (I also tried other vector source >> >> data: When the input is 0x0F, repeating, the output I see is 1010 >> >> repeating. But when I use 0x0E, the results are random again.) >> >> >> >> I have also tried demodulating a real QAM signal with a known data >> sequence, >> >> also to no avail. >> >> >> >> I have been working on this for about a month now and haven't had any >> >> success. I have examined the underlying QAM.py and generic_mod, >> >> generic_demod codes, and they seem to be written properly. But I am not >> >> getting the expected results. >> >> >> >> Any help with this problem or advice you can give will be greatly >> >> appreciated, and I will return the favor by helping out in any way >> that I >> >> can. >> >> >> >> Thank you very much in advance, >> >> >> >> Jeff >> >> >> >> ___ >> >> Discuss-gnuradio mailing list >> >> Discuss-gnuradio@gnu.org >> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> >> > >> > If it's not working it's probably my fault, so I'll do some tests >> > myself today and get back to you. >> > >> > Cheers, >> > Ben >> >> I found a bug in the xml file for the demodulator that would cause >> problems if you requested no gray-coding. >> It cause gnuradio-companion to pass an incorrect parameter name. >> A fix is at >> https://github.com/benreynwar/gnuradio/commit/e68ab8589ca235563f8c061fbb79d13793d1f21f >> >> In case that wasn't your problem I'll post an example that works for me: >> >> from gnuradio import gr, digital >> >> class qam_mod_demod(gr.top_block): >> >>def __init__(self): >>super(qam_mod_demod, self).__init__() >>src = gr.vector_source_b([1, 1, 1, 0, 1, 0, 0, 1, 1, 0, 1, 0, >> 0, 0]*1000) >>packer = gr.unpacked_to_packed_bb(1, gr.GR_MSB_FIRST) >>self.snk = gr.vector_sink_b() >>mod = digital.qam.qam_mod(constellation_points=16, >> mod_code="gray", >> differential=True, >> samples_per_symbol=2, >> excess_bw=0.35) >>demod = digital.qam.qam_demod(constellation_points=16, >> mod_code="gray", >> differential=True, >> samples_per_symbol=2, >> excess_bw=0.35, >> freq_bw=6.28/100.0, >>
[Discuss-gnuradio] Audio Issues
I was able to get gnuradio to successfully compile using the script available at (http://gnuradio.org/redmine/projects/gnuradio/wiki/InstallingGR) and I updated my PYTHONPATH as the script instructed. However, none of the audio examples are working. They run without returning any errors, but I don't hear anything. As far as I can tell, I have ALSA installed (I'm using Ubuntu 10.04 with kernel 2.6.32-38, all updates installed). I tried updating gr-audio.conf to use alsa and tried changing gr-audio-alsa.conf to use plughw:0,0 instead of hw:0,0 - all to no avail. I don't believe oss is installed on this system. Can anyone suggest a solutions? Thanks ahead of time! Edit: Sorry if this message is a repost, I'm having some trouble getting registered through Nabble. -- View this message in context: http://old.nabble.com/Audio-Issues-tp33402959p33402959.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] uhd running parallel tx/rx flowgraphs
It's be good if you can chime in here, Josh :) It seems like this is something that should be fixed about tunnel.py in future GNU Radio releases for use with UHD. I'm trying to do my fair share of research here and tackle it. If what you say is true, Marcus, the control I need is over the TX chain. I did a bunch of reading through the UHD docs here: http://files.ettus.com/uhd_docs/doxygen/html/annotated.html I see various controls using tx_streamer and tx_metadata_t to use tags to control samples to be part of a burst. Like, marking the start and end of my TX burst of samples which can construct a packet. No prob, I can do that. But it seems like there needs to be some sort of UHD stream command which turns the TX chain in to an "on-demand" chain and not continuously streaming. On the other hand, I would like RX to be continuous. I see the RX control to specify stream controls here: http://files.ettus.com/uhd_docs/doxygen/html/structuhd_1_1stream__cmd__t.html That is clearly documented as control of samples to the host to be continuous or not. However, I don't see that same control for the TX stream. Tx_metadata_t and t_streamer control the bursts, but don't seem to control the overall stream? Maybe I am missing something. On Sunday, February 26, 2012, Marcus D. Leech wrote: > ** > On 02/26/2012 08:54 PM, George Nychis wrote: > > > > On Sun, Feb 26, 2012 at 5:01 PM, Marcus D. Leech > > > wrote: > >> On 02/26/2012 02:29 PM, Apurv Bhartia wrote: >> >> Its an XCVR2450, but I do *not* start any 'packet' transmissions. All I >> do, is to start both the flowgraphs, and just listen for packets. >> >> In which case, the TX side is running--even if you aren't sending any >> *data* bits, it's still transmitting, and blocking the receiver. >> >> You'll have to get more sophisticated about half-duplex flow management, >> using tagging to tell UHD to turn on/off the TX side. >> >> Josh probably has better words of wisdom on this than I. >> > > Hi Marcus, > > I'm working with Apurv, so I'm going to chime in here :) > > I tried doing some searching on the mailing list, but I wasn't really > able to find much on this. I also thought that auto tr would handle this. > I found a post from Josh on the mailing list that said Auto TR is always > enabled in UHD. > > http://www.ruby-forum.com/topic/1527488 > > > Yes, it is enabled in UHD. But since Gnu Radio is a *streaming* model, > you need to take special measures to control TX from within a > Gnu Radio flow-graph. YOu need to insert a tag in the stream to control > the transmitter, otherwise, you'll be continuously streaming. > > What you do is insert a burst-tagger into your stream, and set it to send > the appropriate tags for UHD into the stream using the trigger > input. I just can't off the top of my head, remember what those stream > tags are at the moment. But the basic issue is that Gnu Radio > uses a streaming model, and while UHD itself (at the C++ level) has > fine-grianed control over transmitter functions, etc, gr-uhd doesn't > directly expose any of that, because there's just not mechanism within > Gnu Radio to expose that stuff. The stream tagging, however, > does allow you to control the transmitter state. In the particular case > of the XCVR2450, the hardware is physically incapable of > TX and RX at the same time. > > > -- > 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
Re: [Discuss-gnuradio] uhd running parallel tx/rx flowgraphs
On 27/02/12 08:30 PM, George Nychis wrote: > It's be good if you can chime in here, Josh :) > > It seems like this is something that should be fixed about tunnel.py > in future GNU Radio releases for use with UHD. I've attached a skeletal piece of GRC that uses the "Burst Tagger" block with a 10Hz trigger input to insert tx_eob/tx_sob tags into the stream. I'm not sure whether this will have the desired effect or not, but at least in theory it should. > > > I'm trying to do my fair share of research here and tackle it. If what > you say is true, Marcus, the control I need is over the TX chain. > > I did a bunch of reading through the UHD docs here: > http://files.ettus.com/uhd_docs/doxygen/html/annotated.html > > I see various controls using tx_streamer and tx_metadata_t to use tags > to control samples to be part of a burst. Like, marking the start and > end of my TX burst of samples which can construct a packet. > > No prob, I can do that. But it seems like there needs to be some sort > of UHD stream command which turns the TX chain in to an "on-demand" > chain and not continuously streaming. On the other hand, I would like > RX to be continuous. > > I see the RX control to specify stream controls here: > http://files.ettus.com/uhd_docs/doxygen/html/structuhd_1_1stream__cmd__t.html > > > That is clearly documented as control of samples to the host to be > continuous or not. > > However, I don't see that same control for the TX stream. > Tx_metadata_t and t_streamer control the bursts, but don't seem to > control the overall stream? Maybe I am missing something. > > On Sunday, February 26, 2012, Marcus D. Leech wrote: > > On 02/26/2012 08:54 PM, George Nychis wrote: >> >> >> On Sun, Feb 26, 2012 at 5:01 PM, Marcus D. Leech >> > 'mle...@ripnet.com');>> wrote: >> >> On 02/26/2012 02:29 PM, Apurv Bhartia wrote: >>> Its an XCVR2450, but I do *not* start any 'packet' >>> transmissions. All I do, is to start both the flowgraphs, >>> and just listen for packets. >>> >> In which case, the TX side is running--even if you aren't >> sending any *data* bits, it's still transmitting, and >> blocking the receiver. >> >> You'll have to get more sophisticated about half-duplex flow >> management, using tagging to tell UHD to turn on/off the TX side. >> >> Josh probably has better words of wisdom on this than I. >> >> >> Hi Marcus, >> >> I'm working with Apurv, so I'm going to chime in here :) >> >> I tried doing some searching on the mailing list, but I wasn't >> really able to find much on this. I also thought that auto tr >> would handle this. I found a post from Josh on the mailing list >> that said Auto TR is always enabled in UHD. >> >> http://www.ruby-forum.com/topic/1527488 >> >> > Yes, it is enabled in UHD. But since Gnu Radio is a *streaming* > model, you need to take special measures to control TX from within a > Gnu Radio flow-graph. YOu need to insert a tag in the stream to > control the transmitter, otherwise, you'll be continuously streaming. > > What you do is insert a burst-tagger into your stream, and set it > to send the appropriate tags for UHD into the stream using the trigger > input. I just can't off the top of my head, remember what those > stream tags are at the moment. But the basic issue is that Gnu Radio > uses a streaming model, and while UHD itself (at the C++ level) > has fine-grianed control over transmitter functions, etc, gr-uhd > doesn't > directly expose any of that, because there's just not mechanism > within Gnu Radio to expose that stuff. The stream tagging, however, > does allow you to control the transmitter state. In the > particular case of the XCVR2450, the hardware is physically > incapable of > TX and RX at the same time. > > > -- > Marcus Leech > Principal Investigator > Shirleys Bay Radio Astronomy Consortium > http://www.sbrac.org > > -- Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org burst_tagger_uhd.grc Description: application/gnuradio-grc #!/usr/bin/env python ## # Gnuradio Python Flow Graph # Title: Burst Tagger Uhd # Generated: Mon Feb 27 20:52:20 2012 ## from gnuradio import eng_notation from gnuradio import gr from gnuradio import uhd from gnuradio.eng_option import eng_option from gnuradio.gr import firdes from grc_gnuradio import wxgui as grc_wxgui from optparse import OptionParser import wx class burst_tagger_uhd(grc_wxgui.top_block_gui): def __init__(self): grc_wxgui.top_block_gui.__init__(self, title="Burst Tagger Uhd") _icon_path = "/usr/share/icons/hicolor/32x32/apps/gnuradio-grc.png" self.SetIcon(wx.Icon(_icon_path, wx.BITMAP_TYPE_ANY)) #
Re: [Discuss-gnuradio] help with QAM demodulation
On Mon, Feb 27, 2012 at 2:57 PM, Tom Rondeau wrote: > On Mon, Feb 27, 2012 at 4:51 PM, Jeff Hodges wrote: >> >> Thanks Ben and Tom, you two have been very helpful. >> >> The code Ben provided does work, and adjusting my GRC program to use the >> same parameters, I was able to achieve the expected results. >> >> However, it appears there are two issues: >> >> (1) When differential encoding is set to off for both mod/demod blocks, >> the output data becomes invalid > > > I'm not sure the differential en/decoder works for QAM. I suggested it > before because of the bits that you sent us, but the gray coding was the > problem, which makes more sense. > Could this be simply because of the rotational symmetry of the QAM constellation. There's only a 25% chance that the receiver will lock onto the constellation in the correct orientation so unless you're using differential encoding it'll only work one quarter of the time. >> >> (2) When the samples per symbol is above 10 the output also becomes >> invalid. > > > I'm not sure why you would want to run it with that many sps, anyway. I'd > probably have to dive back into the code to see what might be the problem > there. Theoretically, it should be doable, but since I've never run it with > that many, it's probably never been exercised. > I had this same problem a while back and found that for high values of samples-per-symbol I needed different parameters. Try twiddling with freq_bw. >> >> Any ideas on what may be causing these discrepancies? >> >> In response to Tom's questions, I am using 16-QAM and the constellation >> does look very noisy (both phase and amplitude) coming out of the QAM mod >> and being observed on the WX GUI Constellation Sink. But then again, there a >> lot of parameters on that signal processing block, so maybe I do not have >> the proper values set. >> >> Thanks, >> >> Jeff > > > The noise might be due to ISI since you're just coming out of a RRC filter > at that point. Unless the constellation sink has another RRC in it. Also, > that sink tries to do some synchronization designed for PSK signals, so it > won't work great and might be causing some of your error. Try just using an > oscope and plottng x verus y. > > Tom > > >> >> On Mon, Feb 27, 2012 at 12:50 PM, Ben Reynwar wrote: >>> >>> On Mon, Feb 27, 2012 at 10:00 AM, Ben Reynwar wrote: >>> > On Mon, Feb 27, 2012 at 7:36 AM, Jeff Hodges >>> > wrote: >>> >> Does anyone know if the QAM demodulator code is working properly? I >>> >> would >>> >> like to get a QAM demodulator working for a symbol rate of 300ksym/s. >>> >> I >>> >> don't know whether I am just using the wrong parameters or if the >>> >> blocks do >>> >> not work properly, but I am not getting the results I expect. >>> >> >>> >> To test the code out I am using the GRC. I have a vector source with a >>> >> known >>> >> data sequence running into the qam mod block and then the output of >>> >> that >>> >> into a QAM demod block. The output of the QAM demod is running into a >>> >> Uchar >>> >> to Float, and I am plotting the results on a WX GUI Scope. I have the >>> >> exact >>> >> same settings on both the QAM mod and demod blocks. The output I am >>> >> seeing >>> >> on the scope looks completely random. (I also tried other vector >>> >> source >>> >> data: When the input is 0x0F, repeating, the output I see is 1010 >>> >> repeating. But when I use 0x0E, the results are random again.) >>> >> >>> >> I have also tried demodulating a real QAM signal with a known data >>> >> sequence, >>> >> also to no avail. >>> >> >>> >> I have been working on this for about a month now and haven't had any >>> >> success. I have examined the underlying QAM.py and generic_mod, >>> >> generic_demod codes, and they seem to be written properly. But I am >>> >> not >>> >> getting the expected results. >>> >> >>> >> Any help with this problem or advice you can give will be greatly >>> >> appreciated, and I will return the favor by helping out in any way >>> >> that I >>> >> can. >>> >> >>> >> Thank you very much in advance, >>> >> >>> >> Jeff >>> >> >>> >> ___ >>> >> Discuss-gnuradio mailing list >>> >> Discuss-gnuradio@gnu.org >>> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >> >>> > >>> > If it's not working it's probably my fault, so I'll do some tests >>> > myself today and get back to you. >>> > >>> > Cheers, >>> > Ben >>> >>> I found a bug in the xml file for the demodulator that would cause >>> problems if you requested no gray-coding. >>> It cause gnuradio-companion to pass an incorrect parameter name. >>> A fix is at >>> https://github.com/benreynwar/gnuradio/commit/e68ab8589ca235563f8c061fbb79d13793d1f21f >>> >>> In case that wasn't your problem I'll post an example that works for me: >>> >>> from gnuradio import gr, digital >>> >>> class qam_mod_demod(gr.top_block): >>> >>> def __init__(self): >>> super(qam_mod_demod, self).__init__() >>> src =
Re: [Discuss-gnuradio] Audio Issues
Have you tried playing audio from a different source? If you go to youtube.com, and watch a video, can you hear the sound? Cheers, Ben On Mon, Feb 27, 2012 at 5:21 PM, labarowski wrote: > > I was able to get gnuradio to successfully compile using the script > available > at (http://gnuradio.org/redmine/projects/gnuradio/wiki/InstallingGR) and I > updated my PYTHONPATH as the script instructed. However, none of the audio > examples are working. They run without returning any errors, but I don't > hear anything. As far as I can tell, I have ALSA installed (I'm using > Ubuntu > 10.04 with kernel 2.6.32-38, all updates installed). I tried updating > gr-audio.conf to use alsa and tried changing gr-audio-alsa.conf to use > plughw:0,0 instead of hw:0,0 - all to no avail. I don't believe oss is > installed on this system. Can anyone suggest a solutions? Thanks ahead of > time! > > Edit: Sorry if this message is a repost, I'm having some trouble getting > registered through Nabble. > -- > View this message in context: > http://old.nabble.com/Audio-Issues-tp33402959p33402959.html > Sent from the GnuRadio mailing list archive at Nabble.com. > > > ___ > 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] Audio Issues
On Mon, Feb 27, 2012 at 8:21 PM, labarowski wrote: > > I was able to get gnuradio to successfully compile using the script > available > at (http://gnuradio.org/redmine/projects/gnuradio/wiki/InstallingGR) and I > updated my PYTHONPATH as the script instructed. However, none of the audio > examples are working. They run without returning any errors, but I don't > hear anything. As far as I can tell, I have ALSA installed (I'm using > Ubuntu > 10.04 with kernel 2.6.32-38, all updates installed). I tried updating > gr-audio.conf to use alsa and tried changing gr-audio-alsa.conf to use > plughw:0,0 instead of hw:0,0 - all to no avail. I don't believe oss is > installed on this system. Can anyone suggest a solutions? Thanks ahead of > time! > Try passing the device string "-O pulse" to use pulseaudio, instead. You might have to install libpulse0, though. I've found this to be a more flexible and reliable sound system. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Audio Issues
On 27/02/12 08:59 PM, Tom Rondeau wrote: > > Try passing the device string "-O pulse" to use pulseaudio, instead. > You might have to install libpulse0, though. I've found this to be a > more flexible and reliable sound system. > > Tom > I've never found *any* sound subsystem on Linux to be "reliable and flexible". And when you have a system with *both* Pulse and Alsa-backwards-compat-mode, it's a frikken nightmare. The problem seems to be that for over a decade, everybody wanted *their* Kewl sound subsystem to be incorporated into Linux distributions. So everyone go their wish, and there are no standards. Bleh. -- 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] Audio Issues
On Mon, Feb 27, 2012 at 9:03 PM, Marcus D. Leech wrote: > On 27/02/12 08:59 PM, Tom Rondeau wrote: > > > > Try passing the device string "-O pulse" to use pulseaudio, instead. > > You might have to install libpulse0, though. I've found this to be a > > more flexible and reliable sound system. > > > > Tom > > > I've never found *any* sound subsystem on Linux to be "reliable and > flexible". And when you have a system > with *both* Pulse and Alsa-backwards-compat-mode, it's a frikken > nightmare. The problem seems to be that > for over a decade, everybody wanted *their* Kewl sound subsystem to be > incorporated into Linux distributions. > So everyone go their wish, and there are no standards. > > Bleh. All I'm saying is that pulseaudio on Ubuntu seems to just work these days. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] uhd running parallel tx/rx flowgraphs
On 02/27/2012 05:30 PM, George Nychis wrote: > It's be good if you can chime in here, Josh :) > > It seems like this is something that should be fixed about tunnel.py in > future GNU Radio releases for use with UHD. > Like removing it altogether :-) > That is clearly documented as control of samples to the host to be > continuous or not. > Basically, RX is intended to work on a continuous streaming model, which is why stream command inst swigged up. The start()/stop() methods are actually the ones issuing the command. When and if the pmt based message passing gets merged, i was going to implement control messages to deal with streaming, possibly other things. This lets you tie the uhd source block into a control plane. As is stands now, i guess someone could just forward the stream command stuff, so long as the work() function knew to block when there is definitely not supposed to be samples. That way you avoid the scheduler marking the block done on a timeout. > However, I don't see that same control for the TX stream. Tx_metadata_t and > t_streamer control the bursts, but don't seem to control the overall > stream? Maybe I am missing something. > You can use stream tags to control start/stop of burst and transmit times. See the usrp sink header or the tags demo in gr-uhd. Now that being said, the framer blocks in tunnel.py could be more intelligent and properly shutoff streaming (aka end a burst) when there is no data. That way you avoid underflow when there isnt a continuous supply of data to modulate. -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Audio Issues
On 27/02/12 09:10 PM, Tom Rondeau wrote: > > > All I'm saying is that pulseaudio on Ubuntu seems to just work these > days. > > Tom Well, I should perhaps re-visit Pulse sometime in the coming year or so. I currently just use Alsa nomenclature, and that seems to work. -- 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] Audio Issues
Thanks for the replies everyone! Tom, I'm not entirely sure how to "pass "-O pulse"", but I did change gr-audio.conf to use pulse and that seems to have done the trick. Thanks! +1 for pulse! labarowski wrote: > > I was able to get gnuradio to successfully compile using the script > available at > (http://gnuradio.org/redmine/projects/gnuradio/wiki/InstallingGR) and I > updated my PYTHONPATH as the script instructed. However, none of the audio > examples are working. They run without returning any errors, but I don't > hear anything. As far as I can tell, I have ALSA installed (I'm using > Ubuntu 10.04 with kernel 2.6.32-38, all updates installed). I tried > updating gr-audio.conf to use alsa and tried changing gr-audio-alsa.conf > to use plughw:0,0 instead of hw:0,0 - all to no avail. I don't believe oss > is installed on this system. Can anyone suggest a solutions? Thanks ahead > of time! > > Edit: Sorry if this message is a repost, I'm having some trouble getting > registered through Nabble. > -- View this message in context: http://old.nabble.com/Audio-Issues-tp33402959p33404169.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Audio Issues
On Mon, Feb 27, 2012 at 9:24 PM, labarowski wrote: > > Thanks for the replies everyone! Tom, I'm not entirely sure how to "pass > "-O > pulse"", but I did change gr-audio.conf to use pulse and that seems to have > done the trick. Thanks! +1 for pulse! Most audio examples have a command-line option to specify the audio device. For output scripts, this is -O, when coming from a mic input, it's -I. Instead of specifying it in the config file, you could just put these on the command line. But it's probably better to have it permanently put into the config file so you don't have to keep typing it in all the time. Tom > labarowski wrote: > > > > I was able to get gnuradio to successfully compile using the script > > available at > > (http://gnuradio.org/redmine/projects/gnuradio/wiki/InstallingGR) and I > > updated my PYTHONPATH as the script instructed. However, none of the > audio > > examples are working. They run without returning any errors, but I don't > > hear anything. As far as I can tell, I have ALSA installed (I'm using > > Ubuntu 10.04 with kernel 2.6.32-38, all updates installed). I tried > > updating gr-audio.conf to use alsa and tried changing gr-audio-alsa.conf > > to use plughw:0,0 instead of hw:0,0 - all to no avail. I don't believe > oss > > is installed on this system. Can anyone suggest a solutions? Thanks ahead > > of time! > > > > Edit: Sorry if this message is a repost, I'm having some trouble getting > > registered through Nabble. > > > > -- > View this message in context: > http://old.nabble.com/Audio-Issues-tp33402959p33404169.html > Sent from the GnuRadio mailing list archive at Nabble.com. > > > ___ > 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] passing a block output as parameter to another block
Is there a way so that one can pass the output of a custom gnuradio block as parameter to another block? Thanks, J.___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] passing a block output as parameter to another block
On 02/27/2012 08:48 PM, Jon Phil wrote: > Is there a way so that one can pass the output of a custom gnuradio block as > parameter to another block? > > Take a look at the function probe block in gnuradio companion (and using it with the probe signal block). Periodically probe a function and set its value to this variable. Set the values for block ID, function name, and function args appropriately: Block ID should be the ID of another block in this flow graph. Function name should be the name of a class method on that block. Function args are the parameters passed into that function. For a function with no arguments, leave function args blank. When passing a string for the function arguments, quote the string literal: '"arg"'. The values will used literally, and generated into the following form: self.block_id.function_name(function_args) To poll a stream for a level, use this with the probe signal block. -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
