Re: [Discuss-gnuradio] Re: always a spike on the FFT at the center frequency (Matt Ettus)

[Charles Alberton Herdt]

 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 <address@hidden> 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 <address@hidden>
>>
>> Send Discuss-gnuradio mailing list submissions to
>>       address@hidden
>>
>> 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
>>       address@hidden
>>
>> You can reach the person managing the list at
>>       address@hidden
>>
>> 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 <address@hidden>
>> Subject: Re: [Discuss-gnuradio] TPB scheduler fills block buffers
>> To: Anton Blad <address@hidden>
>> Cc: address@hidden
>> Message-ID: <address@hidden>
>> 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 <address@hidden> 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 <address@hidden>
>> Subject: [Discuss-gnuradio] FSK4 Demodulation on the FPGA
>> To: address@hidden
>> Message-ID: <address@hidden>
>> 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 <address@hidden>
>> Subject: Re: [Discuss-gnuradio] Effect of samples_per_symbol on
>>        benchmark_qt_loopback2.py
>> To: Ben Reynwar <address@hidden>
>> Cc: address@hidden
>> Message-ID:
>>        <address@hidden>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>> On Tue, Dec 7, 2010 at 12:42 AM, Ben Reynwar <address@hidden> 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 <address@hidden>
>> Subject: Re: [Discuss-gnuradio] always a spike on the FFT at the
>>        center  frequency
>> To: adib_sairi <address@hidden>
>> Cc: address@hidden
>> Message-ID: <address@hidden>
>> 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 <address@hidden>
>> Subject: [Discuss-gnuradio] question using signals in flowgraphs
>> To: GNR <address@hidden>
>> Message-ID: <address@hidden>
>> 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" <address@hidden>
>> Subject: Re: [Discuss-gnuradio] RuntimeError: bad lexical cast: source
>>        type    value could not be interpreted as target
>> To: address@hidden, address@hidden, "Tobias Schmid"
>>        <address@hidden>
>> Message-ID:
>>        <address@hidden>
>> 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" <address@hidden>
>> Gesendet: 07.12.2010 16:04:22
>> An: address@hidden, address@hidden
>> 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
>> >>>>> address@hidden
>> >>>>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> >>>>>
>> >>>>>
>> >>>> _______________________________________________
>> >>>> Discuss-gnuradio mailing list
>> >>>> address@hidden
>> >>>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> >>>>
>> >>>>
>> >>>>
>> >>>
>> >
>> >
>> >_______________________________________________
>> >Discuss-gnuradio mailing list
>> >address@hidden
>> >http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> ___________________________________________________________
>> WEB.DE DSL Doppel-Flat ab 19,99 &euro;/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 <address@hidden>
>> Subject: Re: [Discuss-gnuradio] Using one USRP
>> To: address@hidden
>> Message-ID: <address@hidden>
>> 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 <address@hidden>
>> Subject: Re: [Discuss-gnuradio] Effect of samples_per_symbol on
>>        benchmark_qt_loopback2.py
>> To: Tom Rondeau <address@hidden>, address@hidden
>> Message-ID:
>>        <address@hidden>
>> 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 <address@hidden>
>> wrote:
>> > On Tue, Dec 7, 2010 at 12:42 AM, Ben Reynwar <address@hidden> 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 <address@hidden>
>> Subject: [Discuss-gnuradio] Re: FSK4 Demodulation on the FPGA
>> To: address@hidden
>> Cc: address@hidden
>> Message-ID: <address@hidden>
>> 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
>> address@hidden
>> 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
> address@hidden
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>