|
| From: | Luca Pascale |
| Subject: | [Discuss-gnuradio] Re: always a spike on the FFT at the center frequency (Matt Ettus) |
| Date: | Fri, 10 Dec 2010 18:00:04 +0100 |
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:
<AANLkTimzcasqT6w+DSbyrb5EWtSzHKW=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 €/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:
<AANLkTi=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
***********************************************
| [Prev in Thread] | Current Thread | [Next in Thread] |