discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Simultaneously send data and store it in file wit


From: Martin Luelf
Subject: Re: [Discuss-gnuradio] Simultaneously send data and store it in file with high sample rate
Date: Mon, 25 Mar 2013 10:11:23 +0100
User-agent: SquirrelMail/1.4.22

> Hi Martin,
> Thanks a lot. I am using gr-digital narrowband examples,with little bit of
> changes in the code.I am still not able to get full sample rate of
> 25MHz.At
> max i am getting 2MHz sample rate.
> I attached my code ,can you please let me know what might be the reason.Is
> it because of processing time or some other reason.
>
> parameters i am passing from terminal
> sudo python test.py -f 5.825e9 --rx-freq 5.825e9 --tx-gain 31.5 --rx-gain
> 31.5  -m dbpsk -a="serial=ECR13W5UP" -r 1e6
>
> if i try to change -r(bit rate)   to  >2e6  i am getting overflow.
>
> Thanks.
>
>
> On Fri, Mar 22, 2013 at 7:07 PM, Martin Luelf <address@hidden> wrote:
>
>> > Hi Martin,
>> >
>> > Can you please show me an example.. How to write connect statement?
>> >
>> > Thanks
>> >
>> >
>> > On Thu, Mar 21, 2013 at 6:26 PM, Martin Luelf <address@hidden> wrote:
>> >
>> >> > Hi,
>> >> > How to simultaneously transmit data to usrp and also store it in a
>> >> file.?
>> >> > I
>> >> > ran two separate flow graphs.But i want to have a sample rate of
>> >> 25Mhz.Is
>> >> > it possible to do it.
>> >> >
>> >> > I want the same thing in receiver side also(simultaneously detect
>> the
>> >> > packet  and store the data)
>> >> >
>> >> > I am using USRPN210 and Ubuntu 12.04
>> >> >
>> >> > Thanks.
>> >>
>> >> Hi,
>> >>
>> >> you can connect a block's output to as many inputs as you want. So
>> take
>> >> tha last block in your chain that generates your signal and connect
>> it
>> >> both to a uhd sink (which will make the USRP transmitt the signal)
>> and a
>> >> file sink (which will write the same samples to a file).
>> >>
>> >> Same goes for the receiver side. If you use GRC just add another
>> >> connection from a block's out port to another ones in port and the
>> >> output
>> >> will be send to both blocks.
>> >>
>> >> Yours
>> >> Martin
>> >>
>>
>> Hi,
>>
>> first of all please make sure that you reply to the list rather than to
>> the individual persons, or CC the list so that answers are also
>> available
>> for anyone who might have a similar question in the future.
>>
>> The question how to do a block connect is confusing me a bit. Maybe
>> there
>> is a misunderstanding? You should already have done block connections
>> when
>> setting up your flowgraphs.
>>
>> Anyway what I mean is a standard connection of two GNURadio blocks, so
>> in
>> GRC it might look like this (I know I am not an ASCII artist, sorry)
>>
>>                  |---->(Your signal processing block)
>> (UHD Source)-----|
>>                  |---->(File Sink)
>>
>> This should lead to python code like this
>>
>> ##################################################
>> # Blocks
>> ##################################################
>> self.uhd_usrp_source_0 = uhd.usrp_source(...)
>> self.yourblock_0 = yourmodule.yourblock(...)
>> self.file_sink_0 = gr.file_sink(gr.sizeof_gr_complex*1, ...)
>> ##################################################
>> # Connections
>> ##################################################
>> self.connect((self.uhd_usrp_source_0, 0), (self.file_sink_0, 0))
>> self.connect((self.uhd_usrp_source_0, 0), (self.yourblock_0, 0))
>>
>> Yours
>> Martin
>>
>>
>

Hi,

you are passing a serial and not an IP address as argument, that makes me
assume you have a USB based USRP like the USRP1? I don't know the exact
number but I think the rate limit you can achieve over the USB is
somewhere around 2MSamples/sec, but definitely below 25MSamples/sec. For
that you would need a Gigabit Ethernet USRP. Even if the connection for
the USRP is fast enough for higher rates you can still run into overflows
if your code is to slow to follow up with the signal processing. In this
case either optimize your code, get a better system (mainly RAM and CPU)
or simplify your flow graph to do less processing overall.

Martin




reply via email to

[Prev in Thread] Current Thread [Next in Thread]