Re: [Discuss-gnuradio] To implement WiMAX with GnuRadio or not?
On Mon, May 23, 2011 at 11:50:52PM +0400, Alexander Chemeris wrote: Hi community, Hi Alex, Our WiMAX Scanner project (http://code.google.com/p/wimax-scanner/) approaches the moment when we should start writing C/C++ code - our Matlab model decodes broadcast messages from all recordings we have on hands. That's great. I think GNU Radio would benefit from having big, cool projects. Here's my thoughts and experiences: At this point we have to make a choice - rely on GnuRadio or create our own framework. Until recently I was sure would create our own framework, but recent discussions on this list made me think GnuRadio may be an option. So, I'm looking for the community help with the the following questions: 1) How well is GnuRadio suited for packet data processing? WiMAX is essentially a packet-oriented system. What you're writing is receiver-only, right? In that case, GNU Radio will be able to handle all your data just fine. It gets tricky when you have a transceiver with timing-sensitive operations, but it seems your project would work well. GNU Radio is pretty agnostic of the data moved between blocks. 2) We don't want to use Python. Is there anything we can't do without it? And where can we find examples of C++-only flowgraphs? There are some examples in gnuradio-examples/c++. It's really not that hard, and I've done some C++-only projects with great success. However, let me ask why you don't want to use Python. Is it because you want a final product that works without Python, or do you have a real 'allergy'? Because I recommend that *even* for a C++-only project, you still use Python for unit tests. Also, this gives you the opportunity to quickly click together tests using GRC. This will make development a *lot* easier. Side note: Porting from Matlab to Python is much simpler than going from Matlab to C++ (for porting your unit tests). 3) Right now all our code is open-source, but we must leave an option for proprietary plugins. How can we make this possible? 4) Related to (3) - how can we make sure our protocol stack can be embedded into a closed-source application/system? IANAL, TINLA. I'm guessing your best bet would be to separate the actual DSP code from the GNU Radio bindings and have very lean GNU Radio blocks (being GPL) which only call your module. Still, I don't know how or if you may link code across licenses. You will have to get legal help here, I would not rely on anything said on this list. Good luck with your project! 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 pgpGqd3gIeZ4h.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] To implement WiMAX with GnuRadio or not?
On Tue, May 24, 2011 at 7:04 AM, Martin Braun martin.br...@kit.edu wrote: On Mon, May 23, 2011 at 11:50:52PM +0400, Alexander Chemeris wrote: Hi community, Hi Alex, Our WiMAX Scanner project (http://code.google.com/p/wimax-scanner/) approaches the moment when we should start writing C/C++ code - our Matlab model decodes broadcast messages from all recordings we have on hands. That's great. I think GNU Radio would benefit from having big, cool projects. Here's my thoughts and experiences: At this point we have to make a choice - rely on GnuRadio or create our own framework. Until recently I was sure would create our own framework, but recent discussions on this list made me think GnuRadio may be an option. So, I'm looking for the community help with the the following questions: 1) How well is GnuRadio suited for packet data processing? WiMAX is essentially a packet-oriented system. What you're writing is receiver-only, right? In that case, GNU Radio will be able to handle all your data just fine. It gets tricky when you have a transceiver with timing-sensitive operations, but it seems your project would work well. GNU Radio is pretty agnostic of the data moved between blocks. I know I might be slightly biased here, but, yes, I think you'd be fine handling the receiver code in GNU Radio. You are going to have to work a bit on the receiver side packet handling, though, because I know WiMax has the concept of the downlink map that you have to properly separate. I'd look into the stream tagging infrastructure that we have now to handling passing around the necessary information. 2) We don't want to use Python. Is there anything we can't do without it? And where can we find examples of C++-only flowgraphs? There are some examples in gnuradio-examples/c++. It's really not that hard, and I've done some C++-only projects with great success. However, let me ask why you don't want to use Python. Is it because you want a final product that works without Python, or do you have a real 'allergy'? Because I recommend that *even* for a C++-only project, you still use Python for unit tests. Also, this gives you the opportunity to quickly click together tests using GRC. This will make development a *lot* easier. Side note: Porting from Matlab to Python is much simpler than going from Matlab to C++ (for porting your unit tests). What Martin said. C++ is definitely doable, but you might want to start in Python, anyway. I've done a handful of C++-based flowgraphs, and it's relatively trivial to take a flowgraph in Python and convert it to C++, as long as you recognize anything that you did that is Pythonic in nature. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] QAM demod Error in GRC
On Mon, May 23, 2011 at 10:37 PM, Ben Reynwar b...@reynwar.net wrote: On Mon, May 23, 2011 at 12:09 PM, Josh Blum j...@joshknows.com wrote: On 05/23/2011 03:29 AM, Vlad Stoianovici wrote: Dear Marcus and Bob, I did understand that the block was hollow, but this thread is kindda old, so I thought that in the mean time maybe someone implemented the code and functionality you are referring to. I'm using GRC, but I don't have time to start learning python with the sole purpose of being able to write the QAM block. It would probably be easier to use Simulink, which I'd rather not do. This is a motivating example for a new gr-digital component that can make use of tags: the QAM deframer block. :-) -josh In the psk8 branch of my github repo (www.github.com/benreynwar/gnuradio/) there is QAM modulation and demodulation within the digital category of GRC. I haven't tested it recently though. Let me know if you try it and it doesn't work. Cheers, Ben Ben's branch is based off of my 8psk branch in github, too. I still need to pull in his changes. I have a feeling we might be going back and forth a bit in the development of the gr-digital top-level directory. This will make it into the upcoming 'next' branch for the 3.5 release. Currently, it includes a more robust version of the Costas loop (you specify the natural freq and damping factor instead of the gains; it sets the gains properly so that the system is more tolerant and locks better) as well as a reworking of the CMA equalizer. I have yet to use this equalizer on a real signal, only simulated multipath channels, so more experience would be good. Note that if you are using this branch you should --disable-gr-trellis. I banged up the API that is used in gr-trellis and haven't got back to fix it, yet. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] About gr_buffer_add_reader
On 05/24/2011 01:26 AM, Eddie Sun wrote: Hi list, I have a USRP N210, running on Ubuntu-10.04, when I try to use the Gnuradio-Companion to make a fm_receiver, I success generate the python code, but when i try to run it, it shows --- terminate called after throwing an instance of 'std::invalid_argument' what(): gr_buffer_add_reader: nzero_preload must be = 0 --- what is that mean? Not sure, would have to see your GRC flow-graph. PS I would like to ask an additional question: If I only have DBSRX RFX1200 RFX1800 these three daughterboards, is that means I can't receive the 100MHz FM Radio Signal by my fm_receiver through the USRP N210 (bandwidth not right)? or there is some other ways ? thanks, The DBSRX covers about 800MHz to 2.3GHz, the RFX1200 covers 1.15GHz to 1.45GHz, the RFX1800 covers from 1.5GHz to 2.05GHz. I don't see 100MHz anywhere in there. If you want good coverage of the FM radio band (88MHz to 108MHz in North America), you would need a TV_RX2 card or WBX card. -- 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] (no subject)
Hello, I am trying to connect my USRP2 with simulink. I am struggling to find proper communication between the two. I have downloaded the communication toolbox, DSP toolbox, and signal processing toolbox. When I click on the tranmitter USRP2 block in simulink I am asked to provide the USRP2 IP address, the Host data port, and host control port. I followed the online instructions on how to change my IP address. However, I still get the message 'No USRP found at specified IP address'. Does anyone have detailed instructions on how to establish proper communication between the USRP2 and simulink? Also, does the default host data port of 3 and default host control port of 30001 work? Thanks! -Camden Mendiola ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] (no subject)
http://code.ettus.com/redmine/ettus/projects/uhd/wiki#Help-and-Support On 05/24/2011 07:28 AM, Camden Mendiola wrote: Hello, I am trying to connect my USRP2 with simulink. I am struggling to find proper communication between the two. I have downloaded the communication toolbox, DSP toolbox, and signal processing toolbox. When I click on the tranmitter USRP2 block in simulink I am asked to provide the USRP2 IP address, the Host data port, and host control port. I followed the online instructions on how to change my IP address. However, I still get the message 'No USRP found at specified IP address'. Does anyone have detailed instructions on how to establish proper communication between the USRP2 and simulink? Also, does the default host data port of 3 and default host control port of 30001 work? Thanks! -Camden Mendiola ___ 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] How to delete and create a new top_block?
My conclusion from these small tests is that the ERROR_CODE_TIMEOUT occurs when the USRP2s are synchronized. I don't see the reason why it works with the HEAD block and not without it. Do you have any clue? I attach my test file for testcase 2. We have done some more tests and found out that it is the call to set_time_unknown_pps() from the GNU Radio that triggers this behavior. If we do not sync the time between the USRP2s there is no problem to delete and create a new top_block. Our solution to this problem is to increase the timeout for the uhd_source block as it takes at least 1 second to synch the time over the USRPs, see this diff: http://pastebin.com/4Lfr6ft2 Can anyone see any problems with increasing the timeout? BR, Patrik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] QAM demod Error in GRC
On Tue, May 24, 2011 at 3:13 AM, Tom Rondeau trondeau1...@gmail.com wrote: On Mon, May 23, 2011 at 10:37 PM, Ben Reynwar b...@reynwar.net wrote: On Mon, May 23, 2011 at 12:09 PM, Josh Blum j...@joshknows.com wrote: On 05/23/2011 03:29 AM, Vlad Stoianovici wrote: Dear Marcus and Bob, I did understand that the block was hollow, but this thread is kindda old, so I thought that in the mean time maybe someone implemented the code and functionality you are referring to. I'm using GRC, but I don't have time to start learning python with the sole purpose of being able to write the QAM block. It would probably be easier to use Simulink, which I'd rather not do. This is a motivating example for a new gr-digital component that can make use of tags: the QAM deframer block. :-) -josh In the psk8 branch of my github repo (www.github.com/benreynwar/gnuradio/) there is QAM modulation and demodulation within the digital category of GRC. I haven't tested it recently though. Let me know if you try it and it doesn't work. Cheers, Ben Ben's branch is based off of my 8psk branch in github, too. I still need to pull in his changes. I have a feeling we might be going back and forth a bit in the development of the gr-digital top-level directory. This will make it into the upcoming 'next' branch for the 3.5 release. Currently, it includes a more robust version of the Costas loop (you specify the natural freq and damping factor instead of the gains; it sets the gains properly so that the system is more tolerant and locks better) as well as a reworking of the CMA equalizer. I have yet to use this equalizer on a real signal, only simulated multipath channels, so more experience would be good. Note that if you are using this branch you should --disable-gr-trellis. I banged up the API that is used in gr-trellis and haven't got back to fix it, yet. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio Tom, somewhat related. In the next week or so (when I have time), I will be contribute a Gardner timing sync block to GNURadio. It should be a nice addition for the DxPSK blocks, as it is carrier phase independent. --Colby ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] UHD with TVRX Rev 1
Hi guys,
I am playing with the UHD and my TVRX rev 1 is not recognised.
Below is the output of uhd_usrp_probe. It looks as though my TVRX rev 1* (*ID:
Unknown 0x0003) is not a recognised daughterboard in the current UHD code:
$ uhd_usrp_probe
Mac OS; GNU C++ version 4.2.1 (Apple Inc. build 5666) (dot 3); Boost_104601;
UHD_003.001.000-0aff497
-- Opening a USRP1 device...
_
/
| Device: usrp1 device
| _
|/
| | Mboard: usrp1 mboard -
| | _
| |/
| | | RX DSP: usrp1 ddc0 + hb
| | | Codec Rate: 64.00 Msps
| | _
| |/
| | | RX DSP: usrp1 ddc1 + hb
| | | Codec Rate: 64.00 Msps
| | _
| |/
| | | RX Dboard: usrp1 dboard (rx unit) - A
| | | ID: DBSRX (0x0002)
| | | _
| | |/
| | | | RX Subdev: DBSRX (0x0002)
| | | | Antennas: J3
| | | | Freq range: 800.000 to 2400.000 Mhz
| | | | Gain range GC1: 0.0 to 56.0 step 0.5 dB
| | | | Gain range GC2: 0.0 to 24.0 step 1.0 dB
| | | | Connection Type: C
| | | | Uses LO offset: No
| | | _
| | |/
| | | | RX Codec: usrp1 adc - ad9862 - slot A
| | | | Gain range PGA: 0.0 to 20.0 step 1.0 dB
| | _
| |/
| | | RX Dboard: usrp1 dboard (rx unit) - B
| | | *ID: Unknown (0x0003)*
| | | _
| | |/
| | | | RX Subdev: Unknown - Unknown (0x0003)
| | | | Antennas:
| | | | Freq range: 0.000 to 0.000 Mhz
| | | | Gain Elements: None
| | | | Connection Type: C
| | | | Uses LO offset: No
| | | _
| | |/
| | | | RX Codec: usrp1 adc - ad9862 - slot B
| | | | Gain range PGA: 0.0 to 20.0 step 1.0 dB
| | _
| |/
| | | TX DSP: usrp1 duc0
| | | Codec Rate: 64.00 Msps
| | _
| |/
| | | TX DSP: usrp1 duc1
| | | Codec Rate: 64.00 Msps
| | _
| |/
| | | TX Dboard: usrp1 dboard (tx unit) - A
| | | _
| | |/
| | | | TX Subdev: Unknown - Unknown (0x)
| | | | Antennas:
| | | | Freq range: 0.000 to 0.000 Mhz
| | | | Gain Elements: None
| | | | Connection Type: C
| | | | Uses LO offset: No
| | | _
| | |/
| | | | TX Codec: usrp1 dac - ad9862 - slot A
| | | | Gain range PGA: -20.0 to 0.0 step 0.1 dB
| | _
| |/
| | | TX Dboard: usrp1 dboard (tx unit) - B
| | | _
| | |/
| | | | TX Subdev: Unknown - Unknown (0x)
| | | | Antennas:
| | | | Freq range: 0.000 to 0.000 Mhz
| | | | Gain Elements: None
| | | | Connection Type: C
| | | | Uses LO offset: No
| | | _
| | |/
| | | | TX Codec: usrp1 dac - ad9862 - slot B
| | | | Gain range PGA: -20.0 to 0.0 step 0.1 dB
I have tried altering the following function in db_tvrx.cpp located in the
UHD code (uhd/host/lib/usrp/dboard) by changing the TVRX dbid to 0x0003:
UHD_STATIC_BLOCK(reg_tvrx_dboard){
//register the factory function for the rx dbid
dboard_manager::register_dboard(0x0040, make_tvrx, TVRX);
}
This change did allow the TVRX rev1 to be recognised by uhd_usrp_probe but I
was still unable to tune it correctly.
Please could you point me in the right direction?
Thanks,
Mike
M0MIK
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] how to trigger dynamic reconfiguration with lock/disconnect
Hello Guys, I am working on a cognitive radio application and I need to dynamically reconfigure my receiver, switching between a detector and the core receiver. I found lock, unlock, connect, disconnect functions but it seems to be almost impossible to find some documentation or a working examples to understand how to use it. I need to find a way to trigger the disconnect and connect. Do you have any suggestions like some kind of callback? Maybe you can point me to some example code. That would be nice. Another question is: Is it possible to reconnect only parts of the program in some hierarchical block or is it only possible from the top block? Regards, Johannes ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] how to trigger dynamic reconfiguration with lock/disconnect
On Tue, May 24, 2011 at 7:38 PM, Johannes Schmitz jsem...@gmx.de wrote: Hello Guys, I am working on a cognitive radio application and I need to dynamically reconfigure my receiver, switching between a detector and the core receiver. I found lock, unlock, connect, disconnect functions but it seems to be almost impossible to find some documentation or a working examples to understand how to use it. I need to find a way to trigger the disconnect and connect. Do you have any suggestions like some kind of callback? Maybe you can point me to some example code. That would be nice. Another question is: Is it possible to reconnect only parts of the program in some hierarchical block or is it only possible from the top block? Hi Johannes, What documentation was possible to find? Was this part of it: http://gnuradio.org/redmine/wiki/gnuradio/TutorialsWritePythonApplications#Controlling-flow-graphs Anyway, I have attached a slightly modified dial_tone.py which runs for 5 seconds, then replaces one tone with noise then runs for 5 more seconds. As for how to trigger it, that depends entirely on the context, but the reconf method can be called by timeout, user interaction, external signal, As far as I know you can disconnect and reconnect at any level, and even hier_block has lock and unlock methods, but I don't know if it makes sense to lock a flow graph anywhere else than at the top block level. Alex #!/usr/bin/env python # # Copyright 2004,2005,2007 Free Software Foundation, Inc. # # This file is part of GNU Radio # # GNU Radio is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; either version 3, or (at your option) # any later version. # # GNU Radio is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with GNU Radio; see the file COPYING. If not, write to # the Free Software Foundation, Inc., 51 Franklin Street, # Boston, MA 02110-1301, USA. # from gnuradio import gr from gnuradio import audio from gnuradio.eng_option import eng_option from optparse import OptionParser import time class my_top_block(gr.top_block): def __init__(self): gr.top_block.__init__(self) parser = OptionParser(option_class=eng_option) parser.add_option(-O, --audio-output, type=string, default=, help=pcm output device name. E.g., hw:0,0 or /dev/dsp) parser.add_option(-r, --sample-rate, type=eng_float, default=48000, help=set sample rate to RATE (48000)) (options, args) = parser.parse_args () if len(args) != 0: parser.print_help() raise SystemExit, 1 sample_rate = int(options.sample_rate) ampl = 0.1 self.src0 = gr.sig_source_f (sample_rate, gr.GR_SIN_WAVE, 350, ampl) self.src1 = gr.sig_source_f (sample_rate, gr.GR_SIN_WAVE, 440, ampl) self.src2 = gr.noise_source_f(gr.GR_GAUSSIAN, 0.1) self.dst = audio.sink (sample_rate, options.audio_output) self.connect (self.src0, (self.dst, 0)) self.connect (self.src1, (self.dst, 1)) def reconf(self): self.disconnect(self.src0, (self.dst, 0)) self.connect(self.src2, (self.dst, 0)) if __name__ == '__main__': tb = my_top_block() tb.start() time.sleep(5) tb.lock() tb.reconf() tb.unlock() time.sleep(5) tb.stop() ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Simulink and USRP
Hi, There is some information on the mathworks site for this http://www.mathworks.com/help/toolbox/comm/ref/a1083164701.html#bsnml9_ http://www.mathworks.com/help/toolbox/comm/ref/usrp2receiver.html http://www.mathworks.com/support/solutions/en/data/1-CUN7JZ/?solution=1-CUN7JZ http://www.mathworks.com/support/solutions/en/data/1-D2KBPZ/index.html?solution=1-D2KBPZ The above information mentions some UDP firmware, I was under the impression that you could use the USRP2 UHD drivers and firmware located here, with Simulink: http://www.ettus.com/downloads/uhd_releases/003_001_000/images-only/ Elvis Dowson ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Simulink and USRP
Hi, There is some information on the mathworks site for this http://www.mathworks.com/help/toolbox/comm/ref/a1083164701.html#bsnml9_ http://www.mathworks.com/help/toolbox/comm/ref/usrp2receiver.html http://www.mathworks.com/support/solutions/en/data/1-CUN7JZ/?solution=1-CUN7JZ http://www.mathworks.com/support/solutions/en/data/1-D2KBPZ/index.html?solution=1-D2KBPZ The above information mentions some UDP firmware, I was under the impression that you could use the USRP2 UHD drivers and firmware located here, with Simulink: http://www.ettus.com/downloads/uhd_releases/003_001_000/images-only/ Elvis Dowson Unless the Mathworks folks have *very recently* updated their stuff to use UHD, you can't use the UHD images for Simulink. Simulink used (and continues to, as far as I know) a firmware/FPGA image that used UDP encapsulation, but it's totally incompatible with UHD--it was very beta and that line of development was never maintained, but that's what the SimuLink people standardized on. -- 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
