|
From: | Gold, Phillip W |
Subject: | [Discuss-gnuradio] Re: Matlab is too slow and can't keep up with the USRP |
Date: | Mon, 30 Apr 2007 10:03:39 -0600 |
Has anyone successfully used LabVIEW here? Is USRP interface code available for either Matlab OR LabVIEW?
Phil
-------------------------------
Message: 4
Date: Mon, 30 Apr 2007 13:18:18 +1200
From: Jonas <address@hidden>
Subject: [Discuss-gnuradio] Re: Discuss-gnuradio Digest, Vol 53, Issue
53
To: address@hidden
Message-ID: <address@hidden>
Content-Type: text/plain; format=flowed; charset=ISO-8859-1
> 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
[Prev in Thread] | Current Thread | [Next in Thread] |