discuss-gnuradio
[Top][All Lists]
Advanced

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

[Discuss-gnuradio] Re: Discuss-gnuradio Digest, Vol 53, Issue 53


From: Jonas
Subject: [Discuss-gnuradio] Re: Discuss-gnuradio Digest, Vol 53, Issue 53
Date: Mon, 30 Apr 2007 13:18:18 +1200
User-agent: Thunderbird 1.5.0.10 (X11/20070306)


On Thu, Apr 26, 2007 at 02:48:34PM -0400, Kevin Rudd (Contractor) wrote:
Thanks for the suggestion.  I dove into the TCP code to try and figure out
what it was doing.  I found my problem.  I have to use the following read
command...

data  = pnet(con, 'read', 1000, 'SINGLE', 'NATIVE');

Now I notice that matlab seems to be lag behind the USRP.  So, maybe matlab
is not the best path to process the data in realtime.  I am curious what the
best data rate someone has sustained using a TCP connection.

TCP on GigE can do upwards of 100MB/s ;)

If I get it up and going, I will post my code and a howto so others can
stream data to and from MATLAB in real time.

Thanks.

Eric
Hi Kevin,

I'm never directly sending samples to and from Matlab (for my application Matlab is too slow and can't keep up with the USRP). Instead, in Matlab I generate my waveform first, and then use Matlab's built in FTP to send the file to the USRP server computer. To generate the file that I send, I use write_float_binary.m (gnuradio-core\src\utils\). The resulting ".dat" file can then be used directly with a regular GNU Radio file source.

I wouldn't be surprised if the USRP overflows that you are seeing are attributed to Matlab's inability to keep up (assuming you are going from the USRP to Matlab).

Jonas

=======================================================================
This email, including any attachments, is only for the intended
addressee.  It is subject to copyright, is confidential and may be
the subject of legal or other privilege, none of which is waived or
lost by reason of this transmission.
If the receiver is not the intended addressee, please accept our
apologies, notify us by return, delete all copies and perform no
other act on the email.
Unfortunately, we cannot warrant that the email has not been
altered or corrupted during transmission.
=======================================================================





reply via email to

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