Re: [Discuss-gnuradio] need help for digital.constellation_decoder_cb in release 3.5.0
Nella citazione in data Mon Mar 12 03:36:20 2012, Ben Reynwar ha scritto: On Sun, Mar 11, 2012 at 4:25 PM, Arturo Rinaldiarty.n...@gmail.com wrote: Nella citazione in data Sun Mar 11 02:30:43 2012, Arturo Rinaldi ha scritto: Nella citazione in data Fri Mar 9 19:50:05 2012, Ben Reynwar ha scritto: On Thu, Mar 8, 2012 at 8:19 PM, Arturo Rinaldiarty.n...@gmail.com wrote: Nella citazione in data ven 09 dic 2011 05:55:57 CET, Ben Reynwar ha scritto: On Thu, Dec 8, 2011 at 5:33 PM, Arturo Rinaldiarty.n...@gmail.com wrote: I noticed dramatic changes in the 3.5.0 release in the generation of the constellation points of digital modulations. So, if the easy part is to again modify the source code to match my needs, i need some help in using the new block : digital.constellation_decoder_cb(arg1) instead of gr.constellation_decoder(arg1,arg2) I usually used the last one where arg1 is a list containing the complex values of a generic digital modulation and arg2 is the symbol mapping (Gray Coding for instance). Which blocks do i need to put together to get the same result ? Regards, Arturo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Simplest solution is probably: constell = digital.digital_constellation(list_of_complex_points, [], 1, 1) decoder = digital.constellation_decoder_cb(constell) To get the symbol mapping you want, just choose the appropriate order of the complex points in the list. The 2nd, 3rd and 4th arguments to the constellation constructor while not relevant to this example are: - a mapping to be applied before differential encoding. - the rotational-symmetry of the constellation - the dimensionality of the constellation (i.e. number of complex points that together map to one symbol) Functions to simplify the creation of commonly used constellations can be found in digital.bpsk, digital.qpsk, digital.psk, and digital.qam. Ben i made some progress in simplyfing the creation of the constellations but i still need help in the decoding part. I'm trying to calculate the modulation BER by using this flow graph : http://imageshack.us/photo/my-images/819/bersimgrchomeartynetscr.png/ i removed all the unnecessary parameters to my study (excess bw , differential coding etc.) because i need only gray coding. and the decoding part is this one http://pastebin.com/wADRx7Hj could you please help me ? the grc blocks are made by invoking only the psk_new.py source http://pastebin.com/kawSfuPg modified by me. please help me. thx in advance Regards, Arturo. I'd be happy to help but I'm not quite sure what exactly your problem/question is. Maybe you could post the python generated by grc, along with the issue you're having? here it is http://pastebin.com/hQsPXbjJ my goal is to perform a baseband simulation for a simple BER estimation (modulator-channel-demodulator). when i posted the issue some time ago i used the block decoder = gr.constellation_decoder_cb($constellation_points,$symbol_value) i.e. for a qpsk modulation - constellation_points=[1+1j,-1+1j,-1-1j,1-1j] , symbol_value=[0,1,2,3] after that i un-grayed the symbols by connecting the map block gr.map_bb([0,1,3,2]) Since i'm usign the 3.5.2 tarball, the new block digital_swig.constellation_decoder_cb($constellation) (and not digital.constellation_decoder_cb) that you suggested me takes as argument a constellation object and not a constellation_bpsk, constellation_qpsk object and so on. So i think i'm unable to assign the right symbols to the decoded constellation and perform a correct BER estimation. I tried to use also with the object digital.constellation($constellation_points) as you suggested to build my own constellation but the log file says that it is an abstract class so it can't be used. I hope I explained myself well this time. Please help me because i need to update my work to the 3.5.x gnuradio version. PS : I also thought that I could take the old block gr.constellation_decoder_cb from the 3.4.2 tarball (.h , .i and .cc files) and build it with gr-how-to-make-a-block-3.5.2...would it be possible ? Best Regards, Arturo i forgot to mention that i deleted any block for RRC filtering and recovery. my goal is a simple baseband simulation. I attach again my new version (v2) of the source file generic_mod_demod and the grc image of the flow graph : http://imageshack.us/photo/my-images/838/bersimulationgrchomeart.png/ http://pastebin.com/i3nxY6u0 Regards, Arturo Hi Arturo, To generate a generic constellation use: constellation = digital.constellation_calcdist(complex_points, [], 1, 1).base() In my earlier email I forgot about the '_calcdist' and the '.base()'. Hopefully the above will work better for you. I'm also including an simple example that works for me, in case that doesn't fix your problem. Cheers, Ben import random from gnuradio import gr, digital def
Re: [Discuss-gnuradio] Sample audio from my FM stereo receiver
Marcus, Have you done any improvements to the good old RDS code in cgran? Best regards, Rafael Diniz On 03/11/2012 08:40 PM, Andrew Davis wrote: Wow, sounds good, I've got a bunch of 50KW stations about 2 miles away and I cannot get any to sound good at all. What receiver code are you using? The code that I put on on CGRAN yesterday: ** https://www.cgran.org/svn/projects/simple_fm_rcv And the supporting RDS code: ** https://www.cgran.org/svn/projects/radio_data_system I'm using a TVRX2 on a B100, and this was with 8-bit baseband samples at 320Ksps input rate to the FM demod. Your problem might actually be that you have a *bunch* of 50KW stations close by. Although with 70+ dB of dynamic range even at 12-bit ADC sampling, with the gain set right, you shouldn't have too many problems. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cmake destination on 64-bit machines
On Mon, 05 Mar 2012 14:39:54 -0800 Josh Blum j...@joshknows.com wrote: try -DREDHAT=TRUE, that seems like it should work, since the build system isnt otherwise setting REDHAT to false, its just undefined when not detected. On the other hand, here is a diff to detect slackware: http://pastebin.com/n2aXKJzz Thanks once again, Josh. Both solutions work fine. I applied the patch, and would suggest to include it to help other stray Slackware users ;) BTW, I also solved the png dependencies I had problems with. John ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] cmake destination on 64-bit machines
On Mon, Mar 12, 2012 at 09:38, John Coppens j...@jcoppens.com wrote: Both solutions work fine. I applied the patch, and would suggest to include it to help other stray Slackware users ;) This was done. Thanks, Josh. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Sample audio from my FM stereo receiver
Rafael: I added methods for resetting the state machines on the demodulator and the decoder, but apart from that, no. My code relies on those updates so I pushed the updates up to CGRAN for radio_data_system -Marcus On Mon, 12 Mar 2012 06:09:11 -0700, Rafael Diniz wrote: Marcus, Have you done any improvements to the good old RDS code in cgran? Best regards, Rafael Diniz On 03/11/2012 08:40 PM, Andrew Davis wrote: Wow, sounds good, I've got a bunch of 50KW stations about 2 miles away and I cannot get any to sound good at all. What receiver code are you using? The code that I put on on CGRAN yesterday: ** https://www.cgran.org/svn/projects/simple_fm_rcv [1] And the supporting RDS code: ** https://www.cgran.org/svn/projects/radio_data_system [2] I'm using a TVRX2 on a B100, and this was with 8-bit baseband samples at 320Ksps input rate to the FM demod. Your problem might actually be that you have a *bunch* of 50KW stations close by. Although with 70+ dB of dynamic range even at 12-bit ADC sampling, with the gain set right, you shouldn't have too many problems. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org [3] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio [4] Links: -- [1] https://www.cgran.org/svn/projects/simple_fm_rcv [2] https://www.cgran.org/svn/projects/radio_data_system [3] mailto:Discuss-gnuradio@gnu.org [4] 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] Using the private implementation (pimpl) pattern for GNU Radio API classes
On Fri, Mar 9, 2012 at 12:31, Tom Rondeau t...@trondeau.com wrote: Now, Josh uses a structure where there is a public API class and an implementation class (impl). There are some really good reasons to do this, such as it would help us in moving towards an application binary interface (ABI). However, it is significantly different than what we do now. Johnathan Corgan and I have talked about this and are in agreement that this is a good direction to take in the future, but we want to introduce the changes in a reasonable and more systematic manner. The private implementation (pimpl) C++ coding pattern hides all implementation details of classes from the users of those classes. By removing all private data members and methods from public GNU Radio block header files, we can achieve a few benefits: 1) Fewer changes in GNU Radio would trigger recompilation of users' applications. Essentially, only actual API changes affect users, and we only change those between second digit releases (3.1, 3.2, 3.3, 3.4, 3.5, etc.) 2) Include statements in block header files that only exist due to usage in private block members go away. Thus, user applications compile faster and in some cases might even reduce user compile time header file installation requirements. 3) SWIG interface files (.i) would simplify to just #including and %including the public header file to generate the Python glue for blocks. The would also generate simpler SWIG and Python glue code. 4) It would move us closer to implementing an actual ABI for GNU Radio, which would let GNU Radio users upgrade their binary installations without recompiling or relinking their own applications. 5) Documentation generation systems like Doxygen wouldn't contain as much implementation specific cruft, as they can point only at the public header files to document the API, making it more clear to users what their code should pay attention to and what irrelevant parts might arbitrarily change. Most of these benefit the users of GNU Radio, but they come at a price--more work for the GNU Radio developers. (One could argue that more freedom to fiddle with GNU Radio internals without affecting users benefits developers, though.) The pimpl pattern comes in several variations. Historically, GNU Radio has used a related form of this, such as hiding the details of inter-block communication by having a gr_block_detail class that gr_block holds an instance of. But the real benefits come from using a particular pimpl coding pattern that creates a pure virtual block class with API members, then having a (private, internal) derived class with all the implementation details. Josh Blum's implementation of gr-uhd created the first instance this pattern showed up in GNU Radio, followed by his consolidation of the various audio source/sink components into gr-audio. Tom Rondeau copied this pattern in creating gr-shd, and Tom Tsou and I used it for parts of gr-vocoder. So it has been creeping into GNU Radio already, and Tom and I think the project would benefit from formally implementing this project wide. However, some implementation details (sorry) we think need to change. Currently, the blocks following this pattern have a public header file based on the block class name, like gr_foo_ff.h, which contains the pure virtual class and nothing else. Secondly, there exists the implemention class, gr_foo_ff.cc, which contains both the gr_foo_ff_impl class declaration and gr_foo_ff_impl member implementations. Having a class header file inside a .cc file, and then having the name of the .cc file be different from the classes that are inside it, makes it less readable. Tom and I are proposing, if we do go to a project-wide pimpl pattern, to have: include/gr_foo_ff.h lib/gr_foo_impl_ff.h lib/gr_foo_impl_ff.cc ...as the implementation pattern for blocks inside GNU Radio. (There is a related, but orthogonal discussion, about directory layout which is not being addressed here, nor am I addressing the also orthogonal idea of using templates to eliminate the type suffixes, nor the idea of using C++ namespaces to eliminate the file name prefixes. One discussion at a time.) Also, making this change in no way would require GNU Radio users to adopt this coding pattern; in fact user code wouldn't need to change at all, and Python/GRC users would also remain unaffected. If we decided to go ahead with this, we'd want to do so in a way which creates the least disruption. We'd want to plan ahead of time when these things are changing, and do it in easily recognizable groups to not confuse users reading our code base with a haphazard mix of the two patterns. Finally, as we make the change, we'd want to preserve the other aspects of our coding style so the changes related to converting to the pimpl pattern stand alone in the commits. As the GNU Radio code base, its contributors, and user community grow larger, Tom and I are trying to focus on more consistency and readability
Re: [Discuss-gnuradio] Sample audio from my FM stereo receiver
On 03/12/2012 09:09 AM, Rafael Diniz wrote: Marcus, Have you done any improvements to the good old RDS code in cgran? Just updated the simple_fm_rcv code to use 250e3 sample rate, since that's a common rate between B100/USRP1/E1XX and N2XX family, and all the math works out. That will more lightly load the cpu as well, compared to 320e3. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Sample audio from my FM stereo receiver
On 03/12/2012 09:01 PM, Marcus D. Leech wrote: On 03/12/2012 09:09 AM, Rafael Diniz wrote: Marcus, Have you done any improvements to the good old RDS code in cgran? Just updated the simple_fm_rcv code to use 250e3 sample rate, since that's a common rate between B100/USRP1/E1XX and N2XX family, and all the math works out. That will more lightly load the cpu as well, compared to 320e3. And here's an audio sample using the new common sample rate: http://www.sbrac.org/files/fm_stereo_test2.ogg -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Sample audio from my FM stereo receiver
Doesn't sound as good to me, maybe it's just a bad sample. I for some reason ( I know the math tells me otherwise ) I find it sounds better the faster I sample, like 500M. I feel like it has something to do with more exact following of the FM signal curve or something. So how exactly does the software FM Demod work ( crossing detection )? And why can my $5 toy FM radio sound so much cleaner? On Mon, Mar 12, 2012 at 9:09 PM, Marcus D. Leech mle...@ripnet.com wrote: On 03/12/2012 09:01 PM, Marcus D. Leech wrote: On 03/12/2012 09:09 AM, Rafael Diniz wrote: Marcus, Have you done any improvements to the good old RDS code in cgran? Just updated the simple_fm_rcv code to use 250e3 sample rate, since that's a common rate between B100/USRP1/E1XX and N2XX family, and all the math works out. That will more lightly load the cpu as well, compared to 320e3. And here's an audio sample using the new common sample rate: http://www.sbrac.org/files/fm_stereo_test2.ogg -- 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
Re: [Discuss-gnuradio] Sample audio from my FM stereo receiver
On 12/03/12 10:08 PM, Andrew Davis wrote: Doesn't sound as good to me, maybe it's just a bad sample. I for some reason ( I know the math tells me otherwise ) I find it sounds better the faster I sample, like 500M. I feel like it has something to do with more exact following of the FM signal curve or something. I had the bass turned up, which matches my speakers well, but now that I'm listening to the Baba O'Reilly sample on my headphones, it's quite a bit too bassy. So how exactly does the software FM Demod work ( crossing detection )? And why can my $5 toy FM radio sound so much cleaner? It's a quadrature demodulator using ATAN2--not a simple crossing detector. It should be quite high fidelity. Some of these listening tests are notoriously subjective as well, and the source material varies wildly in quality. The other thing is this receiver doesn't do any deemphasis processing, choosing instead to have a 3-band equalizer with settable gains that allow you to tweak the audio spectrum of the output a bit. Some keener could make it more fine-grained to tune the resulting sound to suit personal preferences/room/etc. -- 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
