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: UHD absolute time (Josh Blum)
2. Re: set_time_next_pps and get_time_last_pps (Josh Blum)
3. Re: UHD absolute time (raboteauo)
4. Re: set_time_next_pps and get_time_last_pps (raboteauo)
5. Re: Simulink and USRP2 (Mike McLernon)
6. Multiple Channels, Different Rates to one stream? (Joseph Payton)
7. Re: Multiple Channels, Different Rates to one stream? (Josh Blum)
8. Re: set_time_next_pps and get_time_last_pps (Josh Blum)
----------------------------------------------------------------------
Message: 1
Date: Mon, 10 Dec 2012 01:59:25 -0600
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] UHD absolute time
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 12/08/2012 05:30 AM, raboteauo wrote:
> Hi usrp folks,
>
> The uhd::time_spec_t can give absolute time / date. But if we compare
> uhd::get_system_time()
> to the python function time.time() , the result is not the same. So my
> question is :
>
Perhaps thats just a local time vs GMT/
> what is the definition for absolute time in uhd library ?
Basically, there is none. Its important what the time is on the device
(which is configurable) and how you relate this time to events like:
transmit, receive, control operations.
-josh
>
> thanks.
>
> Olivier
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 2
Date: Mon, 10 Dec 2012 02:13:40 -0600
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] set_time_next_pps and get_time_last_pps
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 12/09/2012 02:53 AM, raboteauo wrote:
> Hi,
>
> Two questions about setting time is the usrp2 :
>
> first question: I set the time using set_time_next_pps and then
> (after a second) test this time using get_time_last_pps. I call the
> set_time_next_pps with a time_spec_t(xxx, 0.0). It should tell that
> at the next pps edge, the time is xxx.0. But when I test the time
> using get_time_last_pps it returns a time_spec_t object with interger
> part yyy and seconds part 0.99999486000. It is about 5 ms from 0. I
> thought it should be 0. Is it normal ?
>
Perhaps the time latched into the registers for time @ last pps was the
"old" registers. Typically, the call is used to determine when the PPS
edge had occurred.
Perhaps if you call get_time_last_pps a second later, it will be as
expected.
> second problem: I use a second usrp which is configured to "mimo" for
> both clock and time. If I don't call set_time_next_pps on this
> device, the get_time_now is not consistent with the first usrp. Even
> if I call set_time_next_pps, the get_time_last_pps always returns 0
> 0.0.
>
The device set to "mimo" time source will automatically sync the time. I
dont think you can call set_time_next_pps get_time_last_pps when there
is no PPS.
-josh
> If semobody can help me... Thanks.
>
> Olivier
>
>
>
>
> _______________________________________________ USRP-users mailing
> list [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 3
Date: Mon, 10 Dec 2012 09:30:33 +0100
From: raboteauo <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] UHD absolute time
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Le 10/12/2012 08:59, Josh Blum a ?crit :
>
> On 12/08/2012 05:30 AM, raboteauo wrote:
>> Hi usrp folks,
>>
>> The uhd::time_spec_t can give absolute time / date. But if we compare
>> uhd::get_system_time()
>> to the python function time.time() , the result is not the same. So my
>> question is :
>>
> Perhaps thats just a local time vs GMT/
>
>> what is the definition for absolute time in uhd library ?
> Basically, there is none. Its important what the time is on the device
> (which is configurable) and how you relate this time to events like:
> transmit, receive, control operations.
>
> -josh
ok, thanks.
>
>
>> thanks.
>>
>> Olivier
>>
>>
>> _______________________________________________
>> 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: 4
Date: Mon, 10 Dec 2012 10:14:30 +0100
From: raboteauo <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] set_time_next_pps and get_time_last_pps
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Le 10/12/2012 09:13, Josh Blum a ?crit :
>
> On 12/09/2012 02:53 AM, raboteauo wrote:
>> Hi,
>>
>> Two questions about setting time is the usrp2 :
>>
>> first question: I set the time using set_time_next_pps and then
>> (after a second) test this time using get_time_last_pps. I call the
>> set_time_next_pps with a time_spec_t(xxx, 0.0). It should tell that
>> at the next pps edge, the time is xxx.0. But when I test the time
>> using get_time_last_pps it returns a time_spec_t object with interger
>> part yyy and seconds part 0.99999486000. It is about 5 ms from 0. I
>> thought it should be 0. Is it normal ?
>>
> Perhaps the time latched into the registers for time @ last pps was the
> "old" registers. Typically, the call is used to determine when the PPS
> edge had occurred.
>
> Perhaps if you call get_time_last_pps a second later, it will be as
> expected.
The re was a mistake in my last analysis : the clock was not configured as
"external" at
the time
where set_time_next_pps was done. here is the result with the correct config.
I make a call to get_time_last_pps each second after set_time_next_pps and I
have always the
same result :
set time source : external
set clock source : external
set time next pps : 1345982 , 0.000000000000000
set time next PPS ok.
(python) time= 1355129438.99 get time last PPS(C): 1345982 , 0.999999980000000
(python) time= 1355129441.0 get time last PPS(C): 1345984 , 0.999999980000000
(python) time= 1355129443.02 get time last PPS(C): 1345986 , 0.999999980000000
(python) time= 1355129445.05 get time last PPS(C): 1345988 , 0.999999980000000
(python) time= 1355129447.07 get time last PPS(C): 1345990 , 0.999999980000000
(python) time= 1355129449.09 get time last PPS(C): 1345992 , 0.999999980000000
(python) time= 1355129451.1 get time last PPS(C): 1345994 , 0.999999980000000
(python) time= 1355129453.12 get time last PPS(C): 1345996 , 0.999999980000000
(python) time= 1355129455.14 get time last PPS(C): 1345998 , 0.999999980000000
(python) time= 1355129457.15 get time last PPS(C): 1346000 , 0.999999980000000
(python) time= 1355129459.17 get time last PPS(C): 1346002 , 0.999999980000000
(python) time= 1355129461.19 get time last PPS(C): 1346004 , 0.999999980000000
(python) time= 1355129463.2 get time last PPS(C): 1346006 , 0.999999980000000
(python) time= 1355129465.21 get time last PPS(C): 1346008 , 0.999999980000000
So the is 20 ns from zero, but never 0...
>> second problem: I use a second usrp which is configured to "mimo" for
>> both clock and time. If I don't call set_time_next_pps on this
>> device, the get_time_now is not consistent with the first usrp. Even
>> if I call set_time_next_pps, the get_time_last_pps always returns 0
>> 0.0.
>>
> The device set to "mimo" time source will automatically sync the time. I
> dont think you can call set_time_next_pps get_time_last_pps when there
> is no PPS.
I thought that it should work like this but if I don't call the
set_time_next_pps on the
slave device,
the streamer metadata timestamp is not the same than the master device (the
integer part
of the
time_spec_t on the slave is near 0 when it starts).
>
> -josh
>
>> If semobody can help me... Thanks.
>>
>> Olivier
>>
>>
>>
>>
>> _______________________________________________ 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, 10 Dec 2012 13:42:09 +0000
From: Mike McLernon <[email protected]>
To: Amith Khandakar <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Simulink and USRP2
Message-ID:
<e3879be9a282cb45aab7ce258a9ae48f2182d...@exmb-01-ah.ad.mathworks.com>
Content-Type: text/plain; charset="windows-1256"
Hi Amit,
Do you need to use time as the quantity that controls the activity of the QPSK
transmitter and receiver? Can you trigger their operation on an event, like
the reception of a certain amount of data? I think you will better control the
model that way, since there are tx/rx transmission delays in this link that are
difficult to quantify without running the model on your particular computer.
Hth,
Mike
From: Amith Khandakar [mailto:[email protected]]
Sent: Saturday, December 08, 2012 4:15 PM
To: Mike McLernon
Cc: [email protected]
Subject: RE: Simulink and USRP2
Importance: High
Dear Mike
Thank you so much for your reply and It is really helpful I must say.
Dear mike , can you please help me with the below implementation where I have
one Simulink model with both the QPSK transmitter and QPSK receiver .
The Simulink model will run for an infinite amount of time in which the QPSK
transmitter will run for 5 unit of time and then the QPSK receiver block will
be active waiting for reception for a particular period of time and if receives
proper signal in that time , It will then change to transmitter block else will
stay in receiver block for some more time until a specified timeout.
Simulink Model
QPSK
Transmitter Block
QPSK
Receiver Block
The issue is how to specify time for each block to run without affecting the
run time for the whole Simulink model.
I hope I could make you understand and hopefully you can help me with the above
implementation.
Regards
Amith
From: Mike McLernon [mailto:[email protected]]
Sent: Monday, December 03, 2012 5:32 PM
To: Amith Khandakar
Cc: [email protected]
Subject: RE: Simulink and USRP2
Hi Amith,
The Comms System Toolbox (CST) does not have any examples of real time image
streaming, but it does have examples of text message streaming. In R2012a, the
CST shipped a Simulink-based example called ?commqpsktxrx? that streams data
using QPSK modulation, an AWGN channel, open-loop frequency correction,
closed-loop frequency and phase recovery, closed-loop symbol timing recovery,
and correlation-based frame synchronization. The model displays the text
message at the MATLAB command prompt when the simulation finishes.
Also in R2012a, the USRP support package shipped two USRP-based examples that
perform the same function as commqpsktxrx. The first, sdruqpsktx, implements
the QPSK transmitter and sends data into an SDRu Transmitter block. The
second, sdruqpskrx, receives the data with an SDRu Receiver block, then
performs the demodulation described in the paragraph above.
The type or source of data has no bearing on the modulation/demodulation
scheme. If you use the QPSK models as your starting point, you should be able
to use image data as your source and make the necessary adaptations to the
model(s) to reconstruct it at the receiver.
Hth,
Mike
From: Amith Khandakar [mailto:[email protected]]
Sent: Friday, November 30, 2012 4:40 PM
To: Mike McLernon
Cc: [email protected]
Subject: RE: Simulink and USRP2
Dear Mr. Mike
Do you have any example for Real Time Image streaming using USRP ( 2 of them ).
I am working on a model , but can you help me with any built Simulink model
which transmits and on the other hand I can receive the image and reconstruct
it.
Sorry for the little information , but you can refer the attachment for more
information:
1. First run the m-file
2. Then run the Simulink model to use the data created from the m file
and then regenerate it ( image streaming )
I have plans of introducing a AWGN channel once I can properly reconstruct the
image on the other side and then finally involve the USRP.
I hope I could make you understand what I am trying to do .
THANK YOU SO MUCH for taking the time and helping me out with this. WILL REALLY
APPRECIATE IF YOU CAN HELP ME.
God Bless.
Regards
Amith
From: Mike McLernon [mailto:[email protected]]
Sent: Wednesday, November 28, 2012 4:50 PM
To: Amith Khandakar
Cc: [email protected]
Subject: RE: Simulink and USRP2
Hi Amith,
You can post to the list, and you?ll get a response.
Best,
Mike
From: USRP-users [mailto:[email protected]] On Behalf Of Amith
Khandakar
Sent: Wednesday, November 28, 2012 12:32 AM
To: [email protected]
Subject: [USRP-users] Simulink and USRP2
Hello everyone
Can anyone help me with an Implementation I am trying to do with Simulink and
USRP 2.
Please reply me back if you have some experience , so that I can share the
problem I am facing now .
Regards
________________________________
??????: ?? ???? ????? ??? ?????? ??????? ??????? ?? ???????? ????? ??????
??????? ????????? ??????? ?????? ?? ??????? ?????????? ???????????.
Our Vision: Qatar University shall be a model national university in the
region, recognized for high quality education and research, and for being a
leader of economic and social development.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20121210/aba2fba4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 1571 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20121210/aba2fba4/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.png
Type: image/png
Size: 444 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20121210/aba2fba4/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image006.png
Type: image/png
Size: 452 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20121210/aba2fba4/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 476 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20121210/aba2fba4/attachment-0001.sig>
------------------------------
Message: 6
Date: Mon, 10 Dec 2012 09:35:56 -0500
From: Joseph Payton <[email protected]>
To: [email protected]
Subject: [USRP-users] Multiple Channels, Different Rates to one
stream?
Message-ID:
<CAJmawsb2zTZdQvDTZqdf7=rm2fsvxvduztk3qj_qbeuo190...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Although I have looked through some archives of this mailing list and have
found several helpful answers, there is one that I have been unable to find
definitively. I apologize in advance if this question has been asked before:
I have read that it is possible to receive 2 IQ channels within the same
stream, but I was wondering if this is possible when using 2 different rx
rates. For example, if I want to get 25 MHz centered at one frequency and
6.25 in another. If so, I was wondering how difference between the rates
are handled. for example would I get [channel 1 I Q I Q I Q I Q] [Channel 2
I Q]...?
Would I be better off processing each channel as a separate stream?
In case there are any caveats for specific hardware, I am using a pair of
N200s, both on separate GB ethernet, (one is 192.168.10.2 one is
192.168.20.2) to handle this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20121210/b61db6d5/attachment-0001.html>
------------------------------
Message: 7
Date: Mon, 10 Dec 2012 09:16:02 -0600
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Multiple Channels, Different Rates to one
stream?
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 12/10/2012 08:35 AM, Joseph Payton wrote:
> Although I have looked through some archives of this mailing list and have
> found several helpful answers, there is one that I have been unable to find
> definitively. I apologize in advance if this question has been asked before:
>
> I have read that it is possible to receive 2 IQ channels within the same
> stream, but I was wondering if this is possible when using 2 different rx
> rates. For example, if I want to get 25 MHz centered at one frequency and
> 6.25 in another. If so, I was wondering how difference between the rates
> are handled. for example would I get [channel 1 I Q I Q I Q I Q] [Channel 2
> I Q]...?
>
> Would I be better off processing each channel as a separate stream?
>
It would have to be a separate streamer. One per channel.
-josh
> In case there are any caveats for specific hardware, I am using a pair of
> N200s, both on separate GB ethernet, (one is 192.168.10.2 one is
> 192.168.20.2) to handle this.
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 8
Date: Mon, 10 Dec 2012 09:28:38 -0600
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] set_time_next_pps and get_time_last_pps
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 12/10/2012 03:14 AM, raboteauo wrote:
> Le 10/12/2012 09:13, Josh Blum a ?crit :
>>
>> On 12/09/2012 02:53 AM, raboteauo wrote:
>>> Hi,
>>>
>>> Two questions about setting time is the usrp2 :
>>>
>>> first question: I set the time using set_time_next_pps and then
>>> (after a second) test this time using get_time_last_pps. I call
>>> the set_time_next_pps with a time_spec_t(xxx, 0.0). It should
>>> tell that at the next pps edge, the time is xxx.0. But when I
>>> test the time using get_time_last_pps it returns a time_spec_t
>>> object with interger part yyy and seconds part 0.99999486000. It
>>> is about 5 ms from 0. I thought it should be 0. Is it normal ?
>>>
>> Perhaps the time latched into the registers for time @ last pps was
>> the "old" registers. Typically, the call is used to determine when
>> the PPS edge had occurred.
>>
>> Perhaps if you call get_time_last_pps a second later, it will be
>> as expected.
> The re was a mistake in my last analysis : the clock was not
> configured as "external" at the time where set_time_next_pps was
> done. here is the result with the correct config.
>
> I make a call to get_time_last_pps each second after
> set_time_next_pps and I have always the same result :
>
> set time source : external set clock source : external set time next
> pps : 1345982 , 0.000000000000000 set time next PPS ok.
>
> (python) time= 1355129438.99 get time last PPS(C): 1345982 ,
> 0.999999980000000 (python) time= 1355129441.0 get time last PPS(C):
> 1345984 , 0.999999980000000 (python) time= 1355129443.02 get time
> last PPS(C): 1345986 , 0.999999980000000 (python) time= 1355129445.05
> get time last PPS(C): 1345988 , 0.999999980000000 (python) time=
> 1355129447.07 get time last PPS(C): 1345990 , 0.999999980000000
> (python) time= 1355129449.09 get time last PPS(C): 1345992 ,
> 0.999999980000000 (python) time= 1355129451.1 get time last PPS(C):
> 1345994 , 0.999999980000000 (python) time= 1355129453.12 get time
> last PPS(C): 1345996 , 0.999999980000000 (python) time= 1355129455.14
> get time last PPS(C): 1345998 , 0.999999980000000 (python) time=
> 1355129457.15 get time last PPS(C): 1346000 , 0.999999980000000
> (python) time= 1355129459.17 get time last PPS(C): 1346002 ,
> 0.999999980000000 (python) time= 1355129461.19 get time last PPS(C):
> 1346004 , 0.999999980000000 (python) time= 1355129463.2 get time last
> PPS(C): 1346006 , 0.999999980000000 (python) time= 1355129465.21 get
> time last PPS(C): 1346008 , 0.999999980000000
>
> So the is 20 ns from zero, but never 0...
Thats probably correct, its an oddity of floating point. Its technically
the same number/same clock cycle.
>>> second problem: I use a second usrp which is configured to "mimo"
>>> for both clock and time. If I don't call set_time_next_pps on
>>> this device, the get_time_now is not consistent with the first
>>> usrp. Even if I call set_time_next_pps, the get_time_last_pps
>>> always returns 0 0.0.
>>>
>> The device set to "mimo" time source will automatically sync the
>> time. I dont think you can call set_time_next_pps get_time_last_pps
>> when there is no PPS.
> I thought that it should work like this but if I don't call the
> set_time_next_pps on the slave device, the streamer metadata
> timestamp is not the same than the master device (the integer part of
> the time_spec_t on the slave is near 0 when it starts).
>
Can you try the rx_multi_samples example with --sync=mimo
--args="addr0=x.x.x.x,addr1=y.y.y.y"
-josh
>>
>> -josh
>>
>>> If semobody can help me... Thanks.
>>>
>>> Olivier
>>>
>>>
>>>
>>>
>>> _______________________________________________ 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
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 28, Issue 9
*****************************************
