Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: time outs during Tx (Josh Blum)
2. Re: UHD simulation/loopback mode (Josh Blum)
3. Re: USRP N210 Matlab and Simulink demo error (Mike McLernon)
4. Re: UHD simulation/loopback mode (Nowlan, Sean)
5. Re: time outs during Tx (Nowlan, Sean)
6. Re: time outs during Tx (Josh Blum)
7. Re: UHD simulation/loopback mode (Andre Puschmann)
----------------------------------------------------------------------
Message: 1
Date: Mon, 23 Apr 2012 10:09:46 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] time outs during Tx
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 04/23/2012 04:48 AM, Sanat Gulvadi wrote:
> Greetings all,
>
> Actually I figured out that the usrp->get_time_now() was causing a lot of
> overhead. So I went another way. So for now it's all good.
>
usrp->get_time_now() takes a significant amount of time. It requires
several control packet transactions. You should not call it while
sending packets to the USRP.
-josh
> Thanks,
> Sanat
>
> On Thu, Apr 19, 2012 at 5:28 PM, Sanat Gulvadi <[email protected]>wrote:
>
>> Hi again Josh,
>>
>> Actually it looks like I spoke too soon.
>> I did look at both the examples you suggested. In my case I want to send
>> as long as it takes for a certain number of seconds to expire. During this
>> time, I loop over the samples contained in a file.
>> Right now for some reason, I am getting the 'U's showing up on stdout
>> along with my standard verbose output that says a packet was sent. I use
>> time spec only for the first packet and then make has_time_spec as false
>> for every subsequent packet to have it sent immediately.
>> I thought initially the underruns are being caused because of reading from
>> the disk. Preallocating the whole file contents to a buffer, didn't seem to
>> help.
>> Would you please allow me to take a little more of your time by asking you
>> to look at my code snippet ?
>>
>> http://pastebin.com/x1dB2B1u <http://pastebin.com/dADe48Pt>
>>
>> I am not very experienced with c++ and I apologize if my code looks clumsy.
>>
>> Thanks again !
>>
>> Best Regards,
>> Sanat
>>
>>
>>
>> On Thu, Apr 19, 2012 at 1:59 PM, Marc Epard <[email protected]> wrote:
>>
>>>
>>> On Apr 19, 2012, at 2:01 AM, Sanat Gulvadi wrote:
>>>
>>> I just found from one of Marc Epard's previous posts somewhere that one
>>> needs to issue_stream_cmd after every one SRAM full worth of samples. Is
>>> this applicable in my case as well ?
>>>
>>>
>>> That only applies when you are using the custom FPGA to do 100 Msps rx.
>>>
>>> -Marc
>>>
>>>
>>
>>
>> --
>>
>>
>
>
> --
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 2
Date: Mon, 23 Apr 2012 10:13:02 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] UHD simulation/loopback mode
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 04/23/2012 07:53 AM, Nowlan, Sean wrote:
> Hi all,
>
> Sorry if this has been asked before: is there a simulation or loopback mode
> for UHD? This would be useful for testing code without a radio.
>
There isnt. But if you take the USRP out of the loop, you can use blocks
like channel model in gnuradio, etc...
I think it would be neat to specify a virtual USRP with the device
args... and give it like a file source/sink to simulate the channels.
However, I would probably not want to develop/maintain a non existent
device :-)
-Josh
> Thanks!
> Sean
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 3
Date: Mon, 23 Apr 2012 18:05:47 +0000
From: Mike McLernon <[email protected]>
To: Huan Len <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP N210 Matlab and Simulink demo error
Message-ID:
<e3879be9a282cb45aab7ce258a9ae48f05ca8...@exmb-01-ah.ad.mathworks.com>
Content-Type: text/plain; charset="us-ascii"
Hi Huan,
Sorry I didn't see this sooner -- the UHD code is telling you that your Basic
RX hardware doesn't support the FM broadcast frequency of 102.5 MHz. The Ettus
spec sheet (at https://www.ettus.com/product/category/Daughterboards) states
that with a transformer, you can receive between 1 and 250 MHz. Please consult
with Ettus to get more details on how.
The Ettus daughterboard app notes page
(http://files.ettus.com/uhd_docs/manual/html/dboards.html) states that the
Basic RX and Basic TX boards have no tunable elements. Therefore, I suspect
that your FM signal is not getting downconverted to true baseband, which would
explain the poor sound quality.
Hth,
Mike
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Huan Len
Sent: Wednesday, April 18, 2012 11:32 PM
To: [email protected]
Subject: Re: [USRP-users] USRP N210 Matlab and Simulink demo error
Mike McLernon <Mike.McLernon@...> writes:
>
> Hi Huan,
>
> In all likelihood, your model is running fine. Note that the messages
> you're
getting are warnings, not
> errors. The Simulink model sdruFMStereo runs pretty quickly, even in
> normal
mode, so it wants to process
> data faster than the USRP hardware can give it. However, all the
> receiver
processing is enabled by the
> DataLen output of the SDRu Receiver block, so there are no gaps in
> processed
data.
>
> How is the sound quality from the model?
>
> Mike
>
> -----Original Message-----
> From: usrp-users-bounces@...
> [mailto:usrp-users-bounces@...] On Behalf Of Huan Len
> Sent: Wednesday, April 18, 2012 5:42 AM
> To: usrp-users@...
> Subject: [USRP-users] USRP N210 Matlab and Simulink demo error
>
> Dear All,
>
> I am working N210 in windows environment with Matlab and Simulink.
> I am really new to USRP, so I wish to get some advice from all of you.
> I have successfully compiled the demo, namely sdruFMStereo.mdl.
> I got this run-time error when i try to run the demo.
> I have no idea what went wrong.
> Is there any kind soul would help me? Thanks in advance!
>
> The hardware does not support the requested RX frequency:
> Target frequency: 102.500000 MHz
> Actual frequency: 2.500000 MHz
> ---------- end libuhd warning message output ----------
> Warning: Reported in 'sdruFMStereo/FM Receiver/48045Hz':
> The queue has underrun by 54400 samples.
> Try increasing queue duration, buffer size, or throughput rate.
> Warning: Reported in 'sdruFMStereo/FM Receiver/48045Hz': Th The queue
> has
underrun by 3136 samples.
> Try increasing queue duration, buffer size, or throughput rate.
> Warning: Reported in 'sdruFMStereo/FM Receiver/48045Hz':
> The queue has underrun by 960 samples.
> Try increasing queue duration, buffer size, or throughput rate.
>
> Regards,
> Huan Len
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@...
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
Hi Mike,
I am still yet to get any sound from the audio device. With spectrum scope
connected in the Simulink Model right before the 19n/6 resampler, all I get is
Noise like signal. Is there anything additional that I need to configure before
it is able to receive FM radio signals? The daughter board that I am using is
BasicRX by the way. Thanks for your help.
Huan Len
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 4
Date: Mon, 23 Apr 2012 18:11:05 +0000
From: "Nowlan, Sean" <[email protected]>
To: "[email protected]" <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] UHD simulation/loopback mode
Message-ID: <195933287DC65748BA7AE867BA8E430B621869BE@apatlisdmbx02>
Content-Type: text/plain; charset="us-ascii"
By simulate I merely mean dump samples on TX side to a null sink (or perhaps a
GUI FFT sink) and return "True"s, successful "tune_result_t"s, and valid sample
rate results (i.e., integer division of USRP system clock - USRP type would
need to be provided). Also useful would be get_time_now returning system time,
etc. In the RX side, maybe samples could come from a random stream.
I won't have time to look at this until mid-May but I'd be willing to take a
crack at it.
Sean
________________________________________
From: [email protected] [[email protected]]
on behalf of Josh Blum [[email protected]]
Sent: Monday, April 23, 2012 1:13 PM
To: [email protected]
Subject: Re: [USRP-users] UHD simulation/loopback mode
On 04/23/2012 07:53 AM, Nowlan, Sean wrote:
> Hi all,
>
> Sorry if this has been asked before: is there a simulation or loopback mode
> for UHD? This would be useful for testing code without a radio.
>
There isnt. But if you take the USRP out of the loop, you can use blocks
like channel model in gnuradio, etc...
I think it would be neat to specify a virtual USRP with the device
args... and give it like a file source/sink to simulate the channels.
However, I would probably not want to develop/maintain a non existent
device :-)
-Josh
> Thanks!
> Sean
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 5
Date: Mon, 23 Apr 2012 18:27:32 +0000
From: "Nowlan, Sean" <[email protected]>
To: "[email protected]" <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] time outs during Tx
Message-ID: <195933287DC65748BA7AE867BA8E430B621869D4@apatlisdmbx02>
Content-Type: text/plain; charset="us-ascii"
By the time get_time_now() returns, how out-of-date is the time returned? Does
the USRP opportunistically reply back with time at next PPS or anything like
that?
Would the following (pseudo)code risk being late?:
DELAY = 0.1
t_now = usrp.get_time_now(0)
metadata.time_spec = t_now
tx_stream.send(input_items, N, metadata)
How small can DELAY realistically get?
Thanks!
Sean
________________________________________
From: [email protected] [[email protected]]
on behalf of Josh Blum [[email protected]]
Sent: Monday, April 23, 2012 1:09 PM
To: [email protected]
Subject: Re: [USRP-users] time outs during Tx
On 04/23/2012 04:48 AM, Sanat Gulvadi wrote:
> Greetings all,
>
> Actually I figured out that the usrp->get_time_now() was causing a lot of
> overhead. So I went another way. So for now it's all good.
>
usrp->get_time_now() takes a significant amount of time. It requires
several control packet transactions. You should not call it while
sending packets to the USRP.
-josh
> Thanks,
> Sanat
>
> On Thu, Apr 19, 2012 at 5:28 PM, Sanat Gulvadi <[email protected]>wrote:
>
>> Hi again Josh,
>>
>> Actually it looks like I spoke too soon.
>> I did look at both the examples you suggested. In my case I want to send
>> as long as it takes for a certain number of seconds to expire. During this
>> time, I loop over the samples contained in a file.
>> Right now for some reason, I am getting the 'U's showing up on stdout
>> along with my standard verbose output that says a packet was sent. I use
>> time spec only for the first packet and then make has_time_spec as false
>> for every subsequent packet to have it sent immediately.
>> I thought initially the underruns are being caused because of reading from
>> the disk. Preallocating the whole file contents to a buffer, didn't seem to
>> help.
>> Would you please allow me to take a little more of your time by asking you
>> to look at my code snippet ?
>>
>> http://pastebin.com/x1dB2B1u <http://pastebin.com/dADe48Pt>
>>
>> I am not very experienced with c++ and I apologize if my code looks clumsy.
>>
>> Thanks again !
>>
>> Best Regards,
>> Sanat
>>
>>
>>
>> On Thu, Apr 19, 2012 at 1:59 PM, Marc Epard <[email protected]> wrote:
>>
>>>
>>> On Apr 19, 2012, at 2:01 AM, Sanat Gulvadi wrote:
>>>
>>> I just found from one of Marc Epard's previous posts somewhere that one
>>> needs to issue_stream_cmd after every one SRAM full worth of samples. Is
>>> this applicable in my case as well ?
>>>
>>>
>>> That only applies when you are using the custom FPGA to do 100 Msps rx.
>>>
>>> -Marc
>>>
>>>
>>
>>
>> --
>>
>>
>
>
> --
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 6
Date: Mon, 23 Apr 2012 11:40:48 -0700
From: Josh Blum <[email protected]>
To: "Nowlan, Sean" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] time outs during Tx
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 04/23/2012 11:27 AM, Nowlan, Sean wrote:
> By the time get_time_now() returns, how out-of-date is the time returned?
> Does the USRP opportunistically reply back with time at next PPS or anything
> like that?
>
> Would the following (pseudo)code risk being late?:
>
> DELAY = 0.1
> t_now = usrp.get_time_now(0)
at this point t_now is now a control packet RTT/2 late
> metadata.time_spec = t_now
> tx_stream.send(input_items, N, metadata)
>
when the usrp sees this time,
it will be ctrl packet RTT/2 + some overhead + gigE latency late
(assuming nothing else was already queued in its TX buffer)
> How small can DELAY realistically get?
>
A control packet RTT is about a millisecond for the network devices.
When timed commands feature gets merged, this will go down to a few
100us for the N2xx devices.
Basically, get_time_now() is just a check to see that you have correctly
configured the time or get a rough feel about the time. This lets you:
send a burst in the near future so packets can buffer up in the usrp, or
for example: verify that the time did sync over the MIMO cable, or to
the PPS.
Time is more meaningful to use when its associated with an event, like
get_time_last_pps() or recv metadata, or async metadata. Like most
things in life, its all relative.
-josh
> Thanks!
> Sean
> ________________________________________
> From: [email protected] [[email protected]]
> on behalf of Josh Blum [[email protected]]
> Sent: Monday, April 23, 2012 1:09 PM
> To: [email protected]
> Subject: Re: [USRP-users] time outs during Tx
>
> On 04/23/2012 04:48 AM, Sanat Gulvadi wrote:
>> Greetings all,
>>
>> Actually I figured out that the usrp->get_time_now() was causing a lot of
>> overhead. So I went another way. So for now it's all good.
>>
>
> usrp->get_time_now() takes a significant amount of time. It requires
> several control packet transactions. You should not call it while
> sending packets to the USRP.
>
> -josh
>
>> Thanks,
>> Sanat
>>
>> On Thu, Apr 19, 2012 at 5:28 PM, Sanat Gulvadi <[email protected]>wrote:
>>
>>> Hi again Josh,
>>>
>>> Actually it looks like I spoke too soon.
>>> I did look at both the examples you suggested. In my case I want to send
>>> as long as it takes for a certain number of seconds to expire. During this
>>> time, I loop over the samples contained in a file.
>>> Right now for some reason, I am getting the 'U's showing up on stdout
>>> along with my standard verbose output that says a packet was sent. I use
>>> time spec only for the first packet and then make has_time_spec as false
>>> for every subsequent packet to have it sent immediately.
>>> I thought initially the underruns are being caused because of reading from
>>> the disk. Preallocating the whole file contents to a buffer, didn't seem to
>>> help.
>>> Would you please allow me to take a little more of your time by asking you
>>> to look at my code snippet ?
>>>
>>> http://pastebin.com/x1dB2B1u <http://pastebin.com/dADe48Pt>
>>>
>>> I am not very experienced with c++ and I apologize if my code looks clumsy.
>>>
>>> Thanks again !
>>>
>>> Best Regards,
>>> Sanat
>>>
>>>
>>>
>>> On Thu, Apr 19, 2012 at 1:59 PM, Marc Epard <[email protected]> wrote:
>>>
>>>>
>>>> On Apr 19, 2012, at 2:01 AM, Sanat Gulvadi wrote:
>>>>
>>>> I just found from one of Marc Epard's previous posts somewhere that one
>>>> needs to issue_stream_cmd after every one SRAM full worth of samples. Is
>>>> this applicable in my case as well ?
>>>>
>>>>
>>>> That only applies when you are using the custom FPGA to do 100 Msps rx.
>>>>
>>>> -Marc
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>>
>>
>>
>> --
>>
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 7
Date: Mon, 23 Apr 2012 21:50:11 +0200
From: Andre Puschmann <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] UHD simulation/loopback mode
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 04/23/2012 08:11 PM, Nowlan, Sean wrote:
> By simulate I merely mean dump samples on TX side to a null sink (or
> perhaps a GUI FFT sink) and return "True"s, successful
> "tune_result_t"s, and valid sample rate results (i.e., integer
> division of USRP system clock - USRP type would need to be provided).
> Also useful would be get_time_now returning system time, etc. In the
> RX side, maybe samples could come from a random stream.
A dummy device would be nice indeed. I've implemented a logic to switch
between a file source and a real USRP source in some of my testing apps
just for developing algorithms. This is quite useful because I don't
need to have an USRP connected to the computer or powered on. A dummy
device which creates random samples or replays a captured file would
simplify this a lot.
> I won't have time to look at this until mid-May but I'd be willing to
> take a crack at it.
Nice. I'd be willing to test if you have something running.
Cheers
-Andre
>
> Sean ________________________________________ From:
> [email protected]
> [[email protected]] on behalf of Josh Blum
> [[email protected]] Sent: Monday, April 23, 2012 1:13 PM To:
> [email protected] Subject: Re: [USRP-users] UHD
> simulation/loopback mode
>
> On 04/23/2012 07:53 AM, Nowlan, Sean wrote:
>> Hi all,
>>
>> Sorry if this has been asked before: is there a simulation or
>> loopback mode for UHD? This would be useful for testing code
>> without a radio.
>>
>
> There isnt. But if you take the USRP out of the loop, you can use
> blocks like channel model in gnuradio, etc...
>
> I think it would be neat to specify a virtual USRP with the device
> args... and give it like a file source/sink to simulate the
> channels. However, I would probably not want to develop/maintain a
> non existent device :-)
>
> -Josh
>
>> Thanks! Sean
>>
>>
>>
>>
>> _______________________________________________ USRP-users mailing
>> list [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> _______________________________________________ USRP-users mailing
> list [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> _______________________________________________ USRP-users mailing
> list [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
--
Andre Puschmann
Ilmenau University of Technology, Integrated Communication Systems Group
Phone: +49 3677 69-4132, Fax: +49 3677 69-1614
Email: [email protected], Web: http://www.tu-ilmenau.de/ics
Office: Zuse Building, room 1071
------------------------------
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
End of USRP-users Digest, Vol 20, Issue 21
******************************************
