Hi Luca Remember you have to add 0.5 to both the real and the immaginary parts of the signal. self.gr_add_const_vxx_0 = gr.add_const_vcc((complex(.5, .5), ))
This line did the trick for me. Charles On Fri, Dec 10, 2010 at 15:00, Luca Pascale <pascale.luca...@gmail.com> wrote: > Hi, > > I have exactly the same problem. A spike at the center of FFT (I am using > USRP2 with BAsicRx). > Adding 0.5 to the signal I still have it (together with other spurious > signals that seems is not possible to eliminate them ). > > > > > 2010/12/8 <discuss-gnuradio-requ...@gnu.org> >> >> Send Discuss-gnuradio mailing list submissions to >> discuss-gnuradio@gnu.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> or, via email, send a message with subject or body 'help' to >> discuss-gnuradio-requ...@gnu.org >> >> You can reach the person managing the list at >> discuss-gnuradio-ow...@gnu.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of Discuss-gnuradio digest..." >> >> >> Today's Topics: >> >> 1. Re: TPB scheduler fills block buffers (Eric Blossom) >> 2. FSK4 Demodulation on the FPGA (Kevin Xu) >> 3. Re: Effect of samples_per_symbol on benchmark_qt_loopback2.py >> (Tom Rondeau) >> 4. Re: always a spike on the FFT at the center frequency (Matt >> Ettus) >> 5. question using signals in flowgraphs (Steve Mcmahon) >> 6. Re: RuntimeError: bad lexical cast: source type value could >> not be interpreted as target (Tobias Schmid) >> 7. Re: Using one USRP (adib_sairi) >> 8. Re: Effect of samples_per_symbol on benchmark_qt_loopback2.py >> (Ben Reynwar) >> 9. Re: FSK4 Demodulation on the FPGA (ikjtel) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Tue, 7 Dec 2010 09:24:34 -0800 >> From: Eric Blossom <e...@comsec.com> >> Subject: Re: [Discuss-gnuradio] TPB scheduler fills block buffers >> To: Anton Blad <ant...@isy.liu.se> >> Cc: discuss-gnuradio@gnu.org >> Message-ID: <20101207172434.gd7...@comsec.com> >> Content-Type: text/plain; charset=us-ascii >> >> On Tue, Dec 07, 2010 at 11:36:19AM +0100, Anton Blad wrote: >> > On Mon, 29 Nov 2010 09:30:11 -0800, Eric Blossom <e...@comsec.com> wrote: >> > > On Mon, Nov 29, 2010 at 08:42:14AM +0100, antonb wrote: >> > >> Hi, >> > >> >> > >> I am writing an application for which I want to keep the latency to a >> > >> minimum, and this involves trying to keep the buffers between the >> > blocks >> > >> as >> > >> empty as possible. Basically, I have a source block with an element >> > size >> > >> of >> > >> 512 bytes that accepts data through a public member function. If >> > >> there >> > is >> > >> no data to transmit it will produce one empty packet to keep the USRP >> > >> busy. >> > >> The scheduler keeps asking for 64 items and I give it one. This goes >> > >> on >> > >> until its write buffer is full. The processing latency (from the >> > >> source >> > >> block to the USRP) of the first items is a few ms, but this grows to >> > well >> > >> over a second due to the large amounts of buffered data. >> > >> >> > >> Looking at the behavior of the single threaded scheduler, it seems it >> > is >> > >> trying to keep the latency low by only requesting data from source >> > blocks >> > >> when the other blocks fail to produce anything. However, the thread >> > >> per >> > >> block scheduler does not seem to care about whether a block is a >> > >> source >> > >> block or not. Is there any way I can configure it to do this? Is >> > >> there >> > >> any >> > >> other approach for solving this problem? >> > >> >> > >> Thankful for any help, >> > >> Anton Blad >> > > >> > > Hi Anton, >> > > >> > > There's been some discussion about this over the past few months. >> > > Probably the easiest way to fix this problem is to limit the usable >> > > size of the buffers in the processing chain. This is a relatively >> > > small change, that would allow an application developer to control the >> > > worst case amount of buffering that is used in the graph. By default, >> > > we allocate buffers on the order of 32KiB, then double that size so >> > > that we can double buffer under the TPB scheduler. (Optimizing for >> > > throughput.) >> > > >> > > The current implementation requires that the physical size of the >> > > buffers be a multiple of the page size. The fix I'm proposing leaves >> > > that constraint in place (it's hard to remove for a variety of >> > > reasons), but allows the specification of a limit on the total number >> > > of samples allowed in the buffer. Thus, if want low latency, you >> > > could specify a limit of 512 bytes (or less for that matter), and the >> > > total buffering would be drastically reduced from what's currently >> > > used. >> > > >> > > I won't have time to look at this until after the new year, but if >> > > you're interested in looking at it, the primary place to look is >> > > gnuradio-core/src/lib/runtime/gr_buffer.{h,cc}. Basically you'd want >> > > to limit the amount of space that it reports is available for writing >> > > to min(<whats-physically-available>, <your-limit>) >> > > >> > > Eric >> > >> > Hi Eric, >> > >> > Thanks for your reply. There are two obvious drawbacks with the simple >> > fix: the latency will still be higher than necessary, and processing >> > large >> > chunks will not be possible. I have the following alternative >> > suggestion: >> > >> > * Create a new policy governing class (gr_tpb_policy_governor?) with the >> > purpose of keeping track of which blocks are making progress. The class >> > contains a condition variable that source blocks wait on in case the >> > scheduling policy disallows adding more samples to the flowgraph. >> > >> > * Create an instance of gr_tpb_policy_governor in the gr_scheduler_tpb >> > constructor and tell it the number of blocks in the flattened flowgraph. >> > >> > * Add a reference to the gr_tpb_policy_governor instance in the >> > gr_tpb_detail blocks. Update the states of the blocks in >> > gr_tpb_detail::set_{input,output}_changed and in >> > gr_tpb_thread_body::gr_tpb_thread_body depending on >> > gr_block_executor::state. >> > >> > The policies I can think of being useful are: >> > >> > * flooding: the current policy, for performance >> > >> > * active_blocks: block sources if more than a minimum number of blocks >> > are >> > processing concurrently, in order to reduce latency. Could be set to 1 >> > to >> > give the behavior of the single threaded scheduler. >> > >> > * num_samples: block sources if more than a minimum number of samples >> > are >> > processed currently, in order to reduce latency while still ensuring >> > acceptable performance. >> > >> > I guess that the main drawback of this proposal is that the >> > gr_tpb_policy_governor will contain a very heavily used mutex. >> > >> > Comments? If I do these changes, will the GNU Radio team be interested >> > in >> > a patch? >> >> If it can be done cleanly and simply in a way that doesn't reduce the >> performance too much (say 3%) for those who are using "flooding", then >> I think we'd consider it. The measure of performance should be total >> CPU time (== user + sys). >> >> I do have some questions about how you'd tune the "active_blocks" and >> "num_samples" cases... >> >> Eric >> >> >> >> ------------------------------ >> >> Message: 2 >> Date: Tue, 07 Dec 2010 16:29:42 -0500 >> From: Kevin Xu <sirmacke...@gmail.com> >> Subject: [Discuss-gnuradio] FSK4 Demodulation on the FPGA >> To: discuss-gnuradio@gnu.org >> Message-ID: <4cfea746.3090...@gmail.com> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> >> Hey all, >> >> Has anyone attempted to implement a C4FM demodulator on the Altera >> Cyclone in the USRP1? Right now I'm hoping to do this to read P25 >> encrypted packets on the FPGA instead of on the CPU, and I wanted to >> know if it was possible. If so, could anyone could point me to any sort >> of examples or tutorials I could learn from to accomplish this? It would >> be greatly appreciated. >> >> Much obliged, >> Kevin >> >> >> >> ------------------------------ >> >> Message: 3 >> Date: Tue, 7 Dec 2010 23:27:54 -0500 >> From: Tom Rondeau <trondeau1...@gmail.com> >> Subject: Re: [Discuss-gnuradio] Effect of samples_per_symbol on >> benchmark_qt_loopback2.py >> To: Ben Reynwar <b...@reynwar.net> >> Cc: discuss-gnuradio@gnu.org >> Message-ID: >> <AANLkTimzcasqT6w+DSbyrb5EWtSzHKW=m4rjqtfjr...@mail.gmail.com> >> Content-Type: text/plain; charset=ISO-8859-1 >> >> On Tue, Dec 7, 2010 at 12:42 AM, Ben Reynwar <b...@reynwar.net> wrote: >> > When I run >> > gnuradio/gnuradio-examples/python/digital/benchmark_qt_loopback2.py >> > I get a strange dependence on samples_per_symbol. >> > >> > I would naively have expected that the more samples per symbol the >> > better, however: >> > >> > python benchmark_qt_loopback2.py --samples_per_symbol 10 >> > produces no errors >> > >> > whereas >> > python benchmark_qt_loopback2.py --samples_per_symbol 11 >> > produces lots of errors >> > >> > Does anyone have any idea what's going on here? >> > >> > Cheers, >> > Ben >> >> That's a very large number of samples per symbol. I know I tested up >> to 10, but more than that's pretty excessive. Ok, more than 2 is >> excessive, really. Off the top of my head, I can't think of exactly >> what might be going wrong here, but you should really never need to >> use that many samples per symbol, anyway. >> >> Tom >> >> >> >> ------------------------------ >> >> Message: 4 >> Date: Tue, 07 Dec 2010 21:44:03 -0800 >> From: Matt Ettus <m...@ettus.com> >> Subject: Re: [Discuss-gnuradio] always a spike on the FFT at the >> center frequency >> To: adib_sairi <adib_sa...@yahoo.com> >> Cc: Discuss-gnuradio@gnu.org >> Message-ID: <4cff1b23.9000...@ettus.com> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> >> On 12/05/2010 11:22 PM, adib_sairi wrote: >> > >> > >> > >> > Matt Ettus wrote: >> >> >> >> >> >> This is due to truncation in the USRP. If you add 0.5 to the signal, >> >> it >> >> should go away. >> >> >> >> Matt >> >> >> >> >> >> >> > >> > Dear Matt, >> > how and where does the truncation is done? is it in the FPGA (DDC) ? >> >> >> At the output of the DDC. >> >> Matt >> >> >> >> ------------------------------ >> >> Message: 5 >> Date: Tue, 7 Dec 2010 22:56:15 -0800 (PST) >> From: Steve Mcmahon <steve.mcmaho...@yahoo.com> >> Subject: [Discuss-gnuradio] question using signals in flowgraphs >> To: GNR <discuss-gnuradio@gnu.org> >> Message-ID: <123989.96406...@web120412.mail.ne1.yahoo.com> >> Content-Type: text/plain; charset=us-ascii >> >> Hello: >> >> I have a USRP2 + WBX running with GNU Radio 3.3.0 on openSUSE 11.2. >> >> I created a simple flowgraph using GRC, a Signal Source connected into a >> USRP2 Sink, used to generate a tone. I'm trying to setup a timer in the >> flowgraph so that every 2 seconds, the tone flip-flops between 3 kHz and 6 >> kHz. When I run it, I get a tone at 1 kHz that never changes (the default >> tone freq from the parameter list). It seems that my signal handler is never >> getting called. I copied my code below. Could anyone tell me why is my >> signal handler never getting called? What am I doing wrong here? >> >> Thanks for your help. >> >> >> >> #!/usr/bin/env python >> ################################################## >> # Gnuradio Python Flow Graph >> # Title: Tst Generate Tone >> # Generated: Mon Dec 6 01:19:50 2010 >> ################################################## >> >> from gnuradio import eng_notation >> from gnuradio import gr >> from gnuradio import usrp2 >> 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 >> >> import signal >> import time >> import datetime >> timer_tick_cnt = 0 >> timer_interval = 2.0 >> >> class tst_generate_tone(grc_wxgui.top_block_gui): >> >> def __init__(self, p_eth="eth1", p_freq_carrier=900.0e6, >> p_freq_tone=1.0e3, p_interp=500): >> grc_wxgui.top_block_gui.__init__(self, title="Tst Generate >> Tone") >> >> ################################################## >> # Parameters >> ################################################## >> self.p_eth = p_eth >> self.p_freq_carrier = p_freq_carrier >> self.p_freq_tone = p_freq_tone >> self.p_interp = p_interp >> >> ################################################## >> # Variables >> ################################################## >> self.samp_rate = samp_rate = 100000000/p_interp >> >> ################################################## >> # Blocks >> ################################################## >> self.gr_sig_source_x_0 = gr.sig_source_c(samp_rate, >> gr.GR_COS_WAVE, p_freq_tone, 0.4, 0) >> self.usrp2_sink_xxxx_0 = usrp2.sink_32fc(p_eth) >> self.usrp2_sink_xxxx_0.set_interp(p_interp) >> self.usrp2_sink_xxxx_0.set_center_freq(p_freq_carrier) >> self.usrp2_sink_xxxx_0.set_gain(0) >> self.usrp2_sink_xxxx_0.config_mimo(usrp2.MC_WE_LOCK_TO_SMA) >> >> ################################################## >> # Connections >> ################################################## >> self.connect((self.gr_sig_source_x_0, 0), >> (self.usrp2_sink_xxxx_0, 0)) >> >> def set_p_eth(self, p_eth): >> self.p_eth = p_eth >> >> def set_p_freq_carrier(self, p_freq_carrier): >> self.p_freq_carrier = p_freq_carrier >> self.usrp2_sink_xxxx_0.set_center_freq(self.p_freq_carrier) >> >> def set_p_freq_tone(self, p_freq_tone): >> self.p_freq_tone = p_freq_tone >> self.gr_sig_source_x_0.set_frequency(self.p_freq_tone) >> >> def set_p_interp(self, p_interp): >> self.p_interp = p_interp >> self.set_samp_rate(100000000/self.p_interp) >> self.usrp2_sink_xxxx_0.set_interp(self.p_interp) >> >> def set_samp_rate(self, samp_rate): >> self.samp_rate = samp_rate >> self.gr_sig_source_x_0.set_sampling_freq(self.samp_rate) >> >> def alarm_handler(signo, frame): >> global timer_tick_cnt >> print "timer tick count is ", timer_tick_cnt >> timer_tick_cnt = timer_tick_cnt + 1 >> new_freq = ((timer_tick_cnt % 2) + 1) * 3000.0 >> tst_generate_tone.gr_sig_source_x_0.set_ffrequency(new_freq) >> >> if __name__ == '__main__': >> parser = OptionParser(option_class=eng_option, usage="%prog: >> [options]") >> parser.add_option("", "--p-eth", dest="p_eth", type="string", >> default="eth1", >> help="Set p_eth [default=%default]") >> parser.add_option("", "--p-freq-carrier", dest="p_freq_carrier", >> type="eng_float", default=eng_notation.num_to_str(900.0e6), >> help="Set p_freq_carrier [default=%default]") >> parser.add_option("", "--p-freq-tone", dest="p_freq_tone", >> type="eng_float", default=eng_notation.num_to_str(1.0e3), >> help="Set p_freq_tone [default=%default]") >> parser.add_option("", "--p-interp", dest="p_interp", type="intx", >> default=500, >> help="Set p_interp [default=%default]") >> (options, args) = parser.parse_args() >> if gr.enable_realtime_scheduling() != gr.RT_OK: >> print "Error: failed to enable realtime scheduling." >> >> signal.signal(signal.SIGALRM, alarm_handler) >> signal.setitimer(signal.ITIMER_REAL, timer_interval, >> timer_interval) >> >> tb = tst_generate_tone(p_eth=options.p_eth, >> p_freq_carrier=options.p_freq_carrier, p_freq_tone=options.p_freq_tone, >> p_interp=options.p_interp) >> tb.Run(True) >> >> >> >> >> >> >> >> >> ------------------------------ >> >> Message: 6 >> Date: Wed, 8 Dec 2010 09:20:36 +0100 (CET) >> From: "Tobias Schmid" <tobiasschmid22...@web.de> >> Subject: Re: [Discuss-gnuradio] RuntimeError: bad lexical cast: source >> type value could not be interpreted as target >> To: j...@joshknows.com, discuss-gnuradio@gnu.org, "Tobias Schmid" >> <tobiasschmid22...@web.de> >> Message-ID: >> <1775527706.3270038.1291796436550.JavaMail.fmail@mwmweb027> >> Content-Type: text/plain; charset=UTF-8 >> >> I now rebuild uhd and gnuradio. >> But the error still occurs. >> >> Running uhd_find_devices I get the following outputs: >> >> linux; GNU C++ version 4.4.1 [gcc-4_4-branch revision 150839]; >> Boost_103900; UHD_0001.20101204162446.a51fb2e >> >> >> Warning: >> Could not locate USRP1 firmware. >> Please install the images package. >> >> -------------------------------------------------- >> -- UHD Device 0 >> -------------------------------------------------- >> Device Address: >> type: usrp2 >> addr: 192.168.10.2 >> name: >> serial: 00:50:c2:85:32:6b >> >> >> :/home/gnuradio/gnuradio/uhd/host/utils> uhd_find_devices >> linux; GNU C++ version 4.4.1 [gcc-4_4-branch revision 150839]; >> Boost_103900; UHD_0001.20101204162446.a51fb2e >> >> >> Warning: >> Could not locate USRP1 firmware. >> Please install the images package. >> >> -------------------------------------------------- >> -- UHD Device 0 >> -------------------------------------------------- >> Device Address: >> type: usrp2 >> addr: 192.168.10.3 >> name: >> serial: 00:50:c2:85:32:66 >> >> Should I assign another IP address to the devices? >> It's also posslible to build up a SIS0 transmission with both USRPs. >> >> But if I use the uhd_multi_usrp_source block, I get the same error as >> before: >> >> >> Generating: >> "/home/tobias/Diplomarbeit/Implementierung/Blocktest/uhd_test.py" >> >> Generating: >> "/home/tobias/Diplomarbeit/Implementierung/Blocktest/uhd_test.py" >> >> Executing: >> "/home/tobias/Diplomarbeit/Implementierung/Blocktest/uhd_test.py" >> >> linux; GNU C++ version 4.4.1 [gcc-4_4-branch revision 150839]; >> Boost_103900; UHD_0001.20101204162446.a51fb2e >> >> Current recv sock buff size: 50000000 bytes >> >> Warning: >> error in pthread_setschedparam >> Failed to set thread priority 0.5 (realtime): >> Performance may be negatively affected. >> See the general application notes. >> >> >> >>> Done >> >> Generating: >> "/home/tobias/Diplomarbeit/Implementierung/Blocktest/uhd_test.py" >> >> Generating: >> "/home/tobias/Diplomarbeit/Implementierung/Blocktest/uhd_test.py" >> >> Executing: >> "/home/tobias/Diplomarbeit/Implementierung/Blocktest/uhd_test.py" >> >> linux; GNU C++ version 4.4.1 [gcc-4_4-branch revision 150839]; >> Boost_103900; UHD_0001.20101204162446.a51fb2e >> >> Current recv sock buff size: 50000000 bytes >> Current recv sock buff size: 50000000 bytes >> Traceback (most recent call last): >> File "/home/tobias/Diplomarbeit/Implementierung/Blocktest/uhd_test.py", >> line 96, in <module> >> tb = uhd_test() >> File "/home/tobias/Diplomarbeit/Implementierung/Blocktest/uhd_test.py", >> line 36, in __init__ >> num_channels=2, >> File "/usr/local/lib/python2.6/site-packages/gnuradio/uhd/uhd_swig.py", >> line 1031, in multi_usrp_source >> return _uhd_swig.multi_usrp_source(*args, **kwargs) >> RuntimeError: bad lexical cast: source type value could not be interpreted >> as target >> >> >>> Done >> >> I hope I didn't ignore anything important. >> >> Tobias >> >> >> >> >> -----Ursprüngliche Nachricht----- >> Von: "Tobias Schmid" <tobiasschmid22...@web.de> >> Gesendet: 07.12.2010 16:04:22 >> An: j...@joshknows.com, discuss-gnuradio@gnu.org >> Betreff: Re: [Discuss-gnuradio] RuntimeError: bad lexical cast: source >> type value could not be interpreted as target >> >> >I tried to rebuild gnuradio, but now the uhd module is not found anymore. >> >So how do I rebuild my enviroment correctly? >> > >> >What I did is: >> > >> >In the uhd directory /host/build/ I did: >> > >> >make unistall >> >make clean >> >cd .. >> >cd .. >> >git pull >> >cd /host/build/ >> >make >> >make test (all tests passed) >> >make install >> > >> >In the gburadio directory I did: >> > >> >make unistall >> >make clean >> >make distclean >> >git pull >> >git checkout next >> >git pull >> >git checkout master >> >./configure >> >make >> >make check >> >make install >> > >> > >> >Is that right so far? >> > >> >Or is it necessary to delete some files by hand? >> > Futhermore I do not have the same uhd blocks availible in grc. >> >I have just the older uhd blocks. >> > >> >I am able to probe both usrp individually. >> >The device arguments are 192.168.10.2 and 192.168.10.3. >> >Is that correct so far. >> > >> >I guess, that I have some older versions of symbolic links in my >> > pythonpath. >> >Do you think that might be a possible reason? >> >If so, which directories can be deleted? >> > >> >Thanks, >> > >> >Tobias >> > >> >Am 02.12.2010 20:42, schrieb Josh Blum: >> >> I could not replicate the problem with the uhd_multi_usrp_source block. >> >> I only had a single usrp to test with, I can try out multiple next week >> >> when I get back to the office. >> >> >> >> Is it possible you have some weird device address arguments? My only >> >> two >> >> guesses are eeprom map parsing or some weird device address. When you >> >> ran the probe app, were you able to probe both usrps individually? That >> >> would let me know that the eeprom parsing works fine on both boards. >> >> >> >> Can you rebuilt gnuradio after rebuilding UHD just to be sure were not >> >> looking at some ABI change. >> >> >> >> -Josh >> >> >> >> On 12/01/2010 03:00 AM, Tobias Schmid wrote: >> >> >> >>> Hello, >> >>> >> >>> sorry I had been out of office for some days. >> >>> >> >>> When I run uhd_usrp_probe the error doesn't occur. >> >>> And using uhd.single_usrp_source doesn't occur either. >> >>> >> >>> The complete output of the terminal is: >> >>> >> >>> linux; GNU C++ version 4.4.1 [gcc-4_4-branch revision 150839]; >> >>> Boost_103900; UHD_0001.20101124180824.2568efd >> >>> >> >>> Current recv sock buff size: 50000000 bytes >> >>> Current recv sock buff size: 50000000 bytes >> >>> Traceback (most recent call last): >> >>> File "/home/gnuradio/Desktop/top_block.py", line 95, in<module> >> >>> tb = top_block() >> >>> File "/home/gnuradio/Desktop/top_block.py", line 35, in __init__ >> >>> num_channels=2, >> >>> File >> >>> "/usr/local/lib/python2.6/site-packages/gnuradio/uhd/uhd_swig.py", >> >>> line >> >>> 1023, in multi_usrp_source >> >>> return _uhd_swig.multi_usrp_source(*args, **kwargs) >> >>> RuntimeError: bad lexical cast: source type value could not be >> >>> interpreted as target >> >>> >> >>> The error also occurs when using udh.multi_usrp_sink. >> >>> Maybe that could be another hint. >> >>> >> >>> By the way, what do I have to do to run a discontinous data >> >>> transmission >> >>> using uhd.single_usrp_source. >> >>> I implemented some ARQ-protocols using USRP driver. Now I wanted to >> >>> upgreade these applications, but it doesn't work well. >> >>> >> >>> Thanks, >> >>> >> >>> Tobias >> >>> >> >>> Am 26.11.2010 17:53, schrieb Josh Blum: >> >>> >> >>>> boost lexical cast doesnt have a very telling error does it... >> >>>> >> >>>> Can you send me the complete verbose? >> >>>> >> >>>> Does the error happen when you run uhd_usrp_probe? >> >>>> >> >>>> Howabout uhd.single_usrp_source? >> >>>> >> >>>> Does GDB give any hint as to where the exception is thrown? >> >>>> >> >>>> Thanks, >> >>>> -Josh >> >>>> >> >>>> On 11/26/2010 04:05 AM, Tobias Schmid wrote: >> >>>> >> >>>> >> >>>>> Hello, >> >>>>> >> >>>>> I'm trying to use 2 USRP2 using the UHD Driver. >> >>>>> My version is the git version of yesterday. >> >>>>> >> >>>>> But when I'm trying to build a flowgraph using grc, >> >>>>> gnuradio isn't able to run the generated code. >> >>>>> >> >>>>> The following error occurs: >> >>>>> >> >>>>> RuntimeError: bad lexical cast: source type value could not be >> >>>>> interpreted as target >> >>>>> >> >>>>> And this is the generated code: >> >>>>> >> >>>>> self.uhd_multi_usrp_source_0 = uhd.multi_usrp_source( >> >>>>> device_addr="addr=192.168.10.2 192.168.10.3", >> >>>>> io_type=uhd.io_type_t.COMPLEX_FLOAT32, >> >>>>> num_channels=2, >> >>>>> ) >> >>>>> _clk_cfg = uhd.clock_config_t() >> >>>>> _clk_cfg.ref_source = uhd.clock_config_t.REF_SMA >> >>>>> _clk_cfg.pps_source = uhd.clock_config_t.PPS_SMA >> >>>>> _clk_cfg.pps_polarity = uhd.clock_config_t.PPS_POS >> >>>>> self.uhd_multi_usrp_source_0.set_clock_config(_clk_cfg, >> >>>>> uhd.ALL_MBOARDS); >> >>>>> self.uhd_multi_usrp_source_0.set_time_unknown_pps(uhd.time_spec_t()) >> >>>>> self.uhd_multi_usrp_source_0.set_samp_rate(1000000) >> >>>>> self.uhd_multi_usrp_source_0.set_center_freq(2450000000, 0) >> >>>>> self.uhd_multi_usrp_source_0.set_gain(20, 0) >> >>>>> self.uhd_multi_usrp_source_0.set_center_freq(2450000000, 1) >> >>>>> self.uhd_multi_usrp_source_0.set_gain(20, 1) >> >>>>> >> >>>>> Can someone help me solving this problem? >> >>>>> >> >>>>> Best regards, >> >>>>> >> >>>>> Tobias >> >>>>> >> >>>>> >> >>>>> >> >>>>> Neu: WEB.DE De-Mail - Einfach wie E-Mail, sicher wie ein Brief! >> >>>>> Jetzt De-Mail-Adresse reservieren: >> >>>>> https://produkte.web.de/go/demail02 >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> _______________________________________________ >> >>>>> Discuss-gnuradio mailing list >> >>>>> Discuss-gnuradio@gnu.org >> >>>>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >>>>> >> >>>>> >> >>>> _______________________________________________ >> >>>> Discuss-gnuradio mailing list >> >>>> Discuss-gnuradio@gnu.org >> >>>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >>>> >> >>>> >> >>>> >> >>> >> > >> > >> >_______________________________________________ >> >Discuss-gnuradio mailing list >> >Discuss-gnuradio@gnu.org >> >http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> ___________________________________________________________ >> WEB.DE DSL Doppel-Flat ab 19,99 €/mtl.! Jetzt auch mit >> gratis Notebook-Flat! http://produkte.web.de/go/DSL_Doppel_Flatrate/2 >> >> >> >> ------------------------------ >> >> Message: 7 >> Date: Wed, 8 Dec 2010 02:59:24 -0800 (PST) >> From: adib_sairi <adib_sa...@yahoo.com> >> Subject: Re: [Discuss-gnuradio] Using one USRP >> To: Discuss-gnuradio@gnu.org >> Message-ID: <30404283.p...@talk.nabble.com> >> Content-Type: text/plain; charset=us-ascii >> >> >> >> >> Michael Dickens-3 wrote: >> > >> > Hi Raj - Alice Crohas' MS thesis sounds similar to yours. She used 2 >> > USRP1's, one doing RX-audio, and the other doing the RX-sample and the >> > TX-audio. We discussed trying to do simultaneous RX/TX using the same >> > daughtercard on a given USRP, or different daughtercards on the same >> > USRP, but decided against either for various reasons. Her eventual >> > setup used just two USRPs: two antennas and two daughtercards -- one >> > each per USRP. The RX-audio was not smooth (it had gaps where the TX- >> > audio was stopped to do RX-sample), but listening was not unpleasant; >> > with a little added buffering on RX, she could have made the RX-audio >> > smooth (but added in a small latency to the transmission, which for >> > the purposes of what she was doing would have been just fine) -- this >> > wasn't necessary for the MS, but it would have been nice for our >> > demos. Good luck on your projects. - MLD >> > >> > >> > >> >> regarding the thesis by Alice Crohas, in page 32. do anyone know how she >> manage to obtain the ROC graph? how the experiment is done is not really >> clear explained. >> >> in spectrum sensing with experimental work, how do we obtain the >> probability >> of false alarm and probability of detection graph? what is the proper >> method >> and how do we plot the ROC curve. thanks. >> >> Adib >> >> ----- >> Mohd Adib Sarijari >> Universiti Teknologi Malaysia >> www.fke.utm.my >> www.utm.my >> -- >> View this message in context: >> http://old.nabble.com/Using-one-USRP-tp22614442p30404283.html >> Sent from the GnuRadio mailing list archive at Nabble.com. >> >> >> >> >> ------------------------------ >> >> Message: 8 >> Date: Wed, 8 Dec 2010 07:10:30 -0700 >> From: Ben Reynwar <b...@reynwar.net> >> Subject: Re: [Discuss-gnuradio] Effect of samples_per_symbol on >> benchmark_qt_loopback2.py >> To: Tom Rondeau <trondeau1...@gmail.com>, discuss-gnuradio@gnu.org >> Message-ID: >> <AANLkTi=rpwhczpjve34tr7hch8nao_ghcal8ps6by...@mail.gmail.com> >> Content-Type: text/plain; charset=ISO-8859-1 >> >> I was using that many so I could see how it all worked better (plots >> with two samples per symbol are a little less intuitive to look at). >> I realize it's not of practical importance but I thought it was >> interesting. >> >> Cheers, >> Ben >> >> On Tue, Dec 7, 2010 at 9:27 PM, Tom Rondeau <trondeau1...@gmail.com> >> wrote: >> > On Tue, Dec 7, 2010 at 12:42 AM, Ben Reynwar <b...@reynwar.net> wrote: >> >> When I run >> >> gnuradio/gnuradio-examples/python/digital/benchmark_qt_loopback2.py >> >> I get a strange dependence on samples_per_symbol. >> >> >> >> I would naively have expected that the more samples per symbol the >> >> better, however: >> >> >> >> python benchmark_qt_loopback2.py --samples_per_symbol 10 >> >> produces no errors >> >> >> >> whereas >> >> python benchmark_qt_loopback2.py --samples_per_symbol 11 >> >> produces lots of errors >> >> >> >> Does anyone have any idea what's going on here? >> >> >> >> Cheers, >> >> Ben >> > >> > That's a very large number of samples per symbol. I know I tested up >> > to 10, but more than that's pretty excessive. Ok, more than 2 is >> > excessive, really. Off the top of my head, I can't think of exactly >> > what might be going wrong here, but you should really never need to >> > use that many samples per symbol, anyway. >> > >> > Tom >> > >> >> >> >> ------------------------------ >> >> Message: 9 >> Date: Wed, 8 Dec 2010 06:11:17 -0800 (PST) >> From: ikjtel <ikj12...@yahoo.com> >> Subject: [Discuss-gnuradio] Re: FSK4 Demodulation on the FPGA >> To: discuss-gnuradio@gnu.org >> Cc: op25-...@yahoogroups.com >> Message-ID: <403131.14997...@web51604.mail.re2.yahoo.com> >> Content-Type: text/plain; charset=us-ascii >> >> > Hey all, >> > Has anyone attempted to implement a C4FM demodulator on the Altera >> > Cyclone in the USRP1? Right now I'm hoping to do this to read >> > P25 encrypted packets on the FPGA instead of on the CPU, and I >> > wanted to know if it was possible. If so, could anyone could >> > point me to any sort of examples or tutorials I could learn >> > from to accomplish this? It would be greatly appreciated. >> >> Kevin >> >> We've got this working - although at present the code runs in the PC as a >> GNU Radio application. >> >> Assuming you want a receiver implementation that's entirely USRP based, >> you would also need some other blocks in addition to the C4FM demod block - >> - channel selection, downconversion to zero IF >> - decimation >> - FM demod >> - post-demod filtering (i.e., RRC filter) >> >> No idea if there is sufficient gate array capacity in the FPGA to >> implement all this, or not. >> >> Anyway, here are a few links to get you started >> - http://sites.google.com/site/radiorausch/ >> - http://sedition.org.au/op25/ >> - op25-dev yahoogroup >> The RadioRausch pages do not load properly for me. Nonetheless, you want >> to go to the "four level FSK" page. >> >> You would be most welcome to join the op25-dev group also. >> >> Best of luck >> >> Max >> >> >> >> >> >> >> ------------------------------ >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> >> End of Discuss-gnuradio Digest, Vol 97, Issue 8 >> *********************************************** > > > > -- > Ing. Luca Pascale > LOG.IN S.r.l > Via Aurelia, 714 > 00165 ROMA - ITALY > Phone: +39-06-66417044 > Fax: +39-06-66411155 > Web: www.log-in.it > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
