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 Tx Issues with Spurious Samples Being Tx'ed (Isaac Gerg)
2. Re: UHD Tx Issues with Spurious Samples Being Tx'ed (Josh Blum)
3. Re: win64 uhd showing wrong architecture (Stefano Speretta)
4. 4*4 MIMO receiver (Farrukh Aziz)
5. Re: 4*4 MIMO receiver (John Malsbury)
6. USRP N200 for standalone operation... (salman dinani)
7. Re: USRP N200 for standalone operation... (John Malsbury)
8. Re: USRP N200 for standalone operation... (salman dinani)
9. Re: USRP N200 for standalone operation... (Stan Gamla)
10. Re: USRP N200 for standalone operation... (Josh Blum)
11. Re: USRP N200 for standalone operation... (Josh Blum)
12. USRP behaviour with late packets in synchronised transmission
(Matthias Br?ndli)
13. Re: USRP behaviour with late packets in synchronised
transmission (Josh Blum)
14. Re: USRP behaviour with late packets in synchronised
transmission (Matthias Br?ndli)
15. uhd_fft.py mirrored spectrum (Sanat Gulvadi)
16. Re: UHD Tx Issues with Spurious Samples Being Tx'ed (Isaac Gerg)
17. Re: uhd_fft.py mirrored spectrum (Haris Kremo)
----------------------------------------------------------------------
Message: 1
Date: Thu, 3 May 2012 15:12:00 -0400
From: Isaac Gerg <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] UHD Tx Issues with Spurious Samples Being
Tx'ed
Message-ID:
<CADnN3yWMC2WUQ=lxos6s7gex2uykseo0frkxpocb_duhfus...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hi Josh,
After more analysis with the scope today I noticed that the waveforms
of my bursts seemed to get queued up and when I send say burst 5, I
see burst 3 go out.
Also, what file has the implementation of the tx_streamer->send()
function? With this interface, it looks like the parameter to capture
SEND_MODE_FULL_BUFF went away.
Have you had any time to check things out on your end?
Isaac
On Wed, May 2, 2012 at 2:39 PM, Isaac Gerg <[email protected]> wrote:
> Josh,
>
> Hooked up the USRP1 to an o-scope. ?I see that sometimes, my 250 sample
> burst goes through just fine. ?Other times, its jumbled in a way that looks
> like the bursts are?concatenated. ?Sometimes I see the decaying?exponential.
> ?It looks similar to this (ignore the units, just the shape
> matches):?http://www.innovatia.com/Design_Center/DC_images/image761.gif
>
> Thanks!
> Isaac
>
>
> On Wed, May 2, 2012 at 2:03 PM, Josh Blum <[email protected]> wrote:
>>
>>
>>
>> On 05/02/2012 10:37 AM, Isaac Gerg wrote:
>> > Hi Josh,
>> >
>> > I am not using the timed interface. ?I would just like to send a burst
>> > of
>> > samples.
>> >
>> > The functionality is possible with a USRP1. ?I was doing it last year
>> > with
>> > a USRP1 before the old UHD interfaces went away. ?If you recall, I had
>> > this
>> > same problem and you found a bug in the driver code where a flush was
>> > not
>> > being done correctly. ?You patched it and then my application worked
>> > fine.
>> > ?Since moving to the new UHD interface, I am getting the same behavior I
>> > had last year before your patch.
>> >
>>
>> Alright, flashbacks confirmed. The flushing code looks to be in there
>> and in-tact. Have to give it a closer look. -josh
>>
>> > Thanks,
>> > Isaac
>> >
>> > On Wed, May 2, 2012 at 1:33 PM, Josh Blum <[email protected]> wrote:
>> >
>> >>
>> >>
>> >> On 05/02/2012 05:30 AM, Isaac Gerg wrote:
>> >>> Hi Nick,
>> >>>
>> >>> I am using the LF RX/TX boards on a USRP1 with the UHD interface. ?I
>> >>> am
>> >>
>> >> So USRP1 doesnt really support the timed samples or bursty samples
>> >> interface. Its really only on or off. There is some attempt to emulate
>> >> the timed behaviour. But its just not exact.
>> >>
>> >>
>> >>
>> >> http://files.ettus.com/uhd_docs/manual/html/usrp1.html#missing-and-emulated-features
>> >>
>> >> I think that explains your observations. You cant really use USRP1 in
>> >> this way.
>> >>
>> >> -Josh
>> >>
>> >> _______________________________________________
>> >> USRP-users mailing list
>> >> [email protected]
>> >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> >>
>> >
>
>
------------------------------
Message: 2
Date: Thu, 03 May 2012 14:01:40 -0700
From: Josh Blum <[email protected]>
To: Isaac Gerg <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] UHD Tx Issues with Spurious Samples Being
Tx'ed
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 05/03/2012 12:12 PM, Isaac Gerg wrote:
> Hi Josh,
>
> After more analysis with the scope today I noticed that the waveforms
> of my bursts seemed to get queued up and when I send say burst 5, I
> see burst 3 go out.
>
> Also, what file has the implementation of the tx_streamer->send()
Its all in usrp1/io_impl.cpp
You should see that tx_stream_on_off is called with enable false when an
end of burst is set, and that flush_send_buff is called.
> function? With this interface, it looks like the parameter to capture
> SEND_MODE_FULL_BUFF went away.
>
There wasnt really a distinction. If you just wanted to send 1 packet,
then you just set the length to be 1 packet and no more. So its always
full buffer basically.
> Have you had any time to check things out on your end?
>
I verified that the flush is being called when EOB is set. I havent had
time to look any closer.
Hope that helps,
-Josh
------------------------------
Message: 3
Date: Thu, 03 May 2012 23:07:30 +0200
From: Stefano Speretta <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] win64 uhd showing wrong architecture
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Interesting... I had a look at boost source code to see how that macro
was defined and here is what I learned:
http://www.boost.org/doc/libs/1_49_0/boost/config/select_platform_config.hpp
http://www.boost.org/doc/libs/1_49_0/boost/config/platform/win32.hpp
Actually there is no check anywhere for 32/64 bit CPU. The platform is
only stating the OS
(also for the linux platform, there is no difference for 32/64 bit) so
win32 is not really correct...
anyway...
Stefano
Il 02/05/2012 18:36, Josh Blum ha scritto:
>
> On 05/02/2012 01:49 AM, Stefano Speretta wrote:
>> Hello,
>>
>> I tried today the UHD version 3.4.1 (x64) and on my machine works fine
>> (amd64), but when the library is loaded
>> this string is printed:
>>
>> Win32; Microsoft Visual C++ version 10.0; Boost_104700;
>> UHD_003.004.001-0-release
>>
>> while the architecture should have been Win64.
>> I checked and the same library does not run under a 32-bit machine.
>>
> You are looking at the result of BOOST_PLATFORM macro. I think that
> boost considers this a win32 platform regardless of compiler width.
>
> I have noticed this with some of cmake's defines as well. I think its
> just a proper nomenclature thing for windows x86* and friends.
>
> -Josh
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
--
Stefano Speretta
ISIS - Innovative Solutions In Space BV
Molengraaffsingel 12-14
2629 JD Delft
The Netherlands
Phone: +31(0)15 256 9018
Fax: +31(0)15 257 3969
E-mail: [email protected]
Web: www.isispace.nl
------------------------------
Message: 4
Date: Thu, 3 May 2012 21:51:29 -0700 (PDT)
From: Farrukh Aziz <[email protected]>
To: USRP user forum <[email protected]>
Subject: [USRP-users] 4*4 MIMO receiver
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
John,
I am using "0:RX1 0:RX2" in my SubDev Spec, and it is working well. I am also
able to do 4 simultaneous complex receptions using the setup I mentioned in my
previous post.
thanks
Farrukh Aziz Bhatti
PhD Candidate
Department of Electrical & Computer Engineering
University of Auckland+64 21 02973964
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120503/bbdc55f6/attachment-0001.html>
------------------------------
Message: 5
Date: Thu, 03 May 2012 21:55:32 -0700
From: John Malsbury <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] 4*4 MIMO receiver
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Farrukh,
I am happy you've gotten this configuration to work. Keep the community
posted on your progress and research.
Good luck.
-John
On 05/03/2012 09:51 PM, Farrukh Aziz wrote:
> John,
>
> I am using "0:RX1 0:RX2" in my SubDev Spec, and it is working well. I
> am also able to do 4 simultaneous complex receptions using the setup I
> mentioned in my previous post.
>
> thanks
>
> *Farrukh Aziz Bhatti*
> PhD Candidate
> Department of Electrical & Computer Engineering
> University of Auckland
>
> +64 21 02973964
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120503/c6f169af/attachment-0001.html>
------------------------------
Message: 6
Date: Fri, 4 May 2012 11:17:06 +0500
From: salman dinani <[email protected]>
To: usrp-users <[email protected]>
Subject: [USRP-users] USRP N200 for standalone operation...
Message-ID:
<CADT0h5YKzTmu9pfHkn6Maj0BhH5k6aaxOoU_b_=54aijtzc...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi all,
I am using USRP N200 for receiving signals of different modulation etc with
MATLAB R2011b.. i want to know can USRP N200 be used as a standalone
receiver or Transceiver? If yes than how??
Regards
Salman Dinani
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120504/6dc94cc1/attachment-0001.html>
------------------------------
Message: 7
Date: Thu, 03 May 2012 23:23:25 -0700
From: John Malsbury <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP N200 for standalone operation...
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Salman,
The N200/210 is not traditionally used in a standalone fashion.
However, I suppose that its possible to incorporate various processing
functions in the FPGA so that it could hypothetically operate in a
standalone fashion - _this would be a significant undertaking_.
Have you considered our USRP E100/E110 as a standalone platform? See
this link:
https://www.ettus.com/product/category/USRP_Embedded_Series
Let us know your thoughts.
-John
On 5/3/2012 11:17 PM, salman dinani wrote:
> Hi all,
>
> I am using USRP N200 for receiving signals of different modulation etc
> with MATLAB R2011b.. i want to know can USRP N200 be used as a
> standalone receiver or Transceiver? If yes than how??
>
> Regards
>
> Salman Dinani
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120503/92ae0987/attachment-0001.html>
------------------------------
Message: 8
Date: Fri, 4 May 2012 12:00:46 +0500
From: salman dinani <[email protected]>
To: John Malsbury <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] USRP N200 for standalone operation...
Message-ID:
<cadt0h5b29gbm67l3fbilaogsx+9egpom6xnb65thdka2v_g...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi John
Thanks for that..actually I am not that strong in verliog programming etc
so indeed it would be a challenge for me. out of curosity I wana ask that
how do u program USRP E100 for standalone operations? via verilog coding
and all that stuff or is there any other platform?? I am very comfortable
with MATLAB and Simulink is there any way of using them?
Regards
Salman Dinani
On Fri, May 4, 2012 at 11:23 AM, John Malsbury <[email protected]>wrote:
> Salman,
>
> The N200/210 is not traditionally used in a standalone fashion. However,
> I suppose that its possible to incorporate various processing functions in
> the FPGA so that it could hypothetically operate in a standalone fashion -
> *this would be a significant undertaking*.
>
> Have you considered our USRP E100/E110 as a standalone platform? See this
> link:
>
> https://www.ettus.com/product/category/USRP_Embedded_Series
>
> Let us know your thoughts.
>
> -John
>
>
>
>
> On 5/3/2012 11:17 PM, salman dinani wrote:
>
> Hi all,
>
> I am using USRP N200 for receiving signals of different modulation etc
> with MATLAB R2011b.. i want to know can USRP N200 be used as a standalone
> receiver or Transceiver? If yes than how??
>
> Regards
>
> Salman Dinani
>
>
> _______________________________________________
> USRP-users mailing
> [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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120504/143d8dce/attachment-0001.html>
------------------------------
Message: 9
Date: Fri, 4 May 2012 09:50:19 +0200
From: Stan Gamla <[email protected]>
To: "'salman dinani'" <[email protected]>, "'John Malsbury'"
<[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] USRP N200 for standalone operation...
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi Salman,
Please refer to an earlier thread from March 2012:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2012-March/0039
30.html>
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2012-March/00393
0.html
It sounds as if we are attempting to do something that could be quite
similar. My application is to use an N210 and a suitable radio board as what
could be called a channel sounder--a transmitter and receiver combination
that is used to determine the propagation characteristics of the radio
channel. One way of constructing a channel sounder is to transmit a signal
whose properties are specifically designed in order that an analysis of the
signal received "at the other end" will lead to a description of the
propagation channel. In practice, the transmitted signal could comprise a
repetitive sequence of data such as a pseudo-random bit sequence (PRBS) with
well-defined autocorrelation. Now as this sequence is being transmitted
continuously, the receiver need only supply a few cycles of the received
PRBS for analysis.
In effect, what I hope to have described above, is a requirement for what
you have called "standalone operation". If one had access to RF laboratory
equipment, then a vector signal generator and analyzer would be used as the
transmitter (VSG) and receiver (VSA) respectively. However, as I do not have
such instrumentation at my disposal, I am hoping on being able to use the
Ettus hardware instead.
@Ettus, the vision and expectation that I have of the N210 hardware is that
its basic RF configuration (including carrier frequency (for both Tx and
Rx), output power, input gain, etc.) can be programmed using commands that
are sent using calls to the UHD driver via Ethernet. Similarly, a transmit
file (or pattern, or vector) can also be downloaded and a command can be
sent to control transmission--on or off. Likewise, a command to transfer the
contents of capture buffers of the receiver to the host PC should also be
possible. Please comment.
To try and summarize, I do not wish to use the Ettus hardware to construct a
communications system which would require the host PC to perform the
processing of the baseband data more or less continuously. Instead, I want
to use the Ettus hardware as an alternative to very expensive VSG and a VSA
laboratory instrumentation in such a way that the host PC sends programming
commands to the N210 in order to configure it for transmission and
reception. The host PC will generate the Tx waveforms and will analyze the
Rx signals on what could be called an ad hoc basis.
Is it possible to use the Ettus hardware--without developing new Verilog
code--for the application I have described?
Thanks in advance to all,
Stan
_____
From: [email protected]
[mailto:[email protected]] On Behalf Of salman dinani
Sent: 04 May 2012 09:01
To: John Malsbury
Cc: [email protected]
Subject: Re: [USRP-users] USRP N200 for standalone operation...
Hi John
Thanks for that..actually I am not that strong in verliog programming etc so
indeed it would be a challenge for me. out of curosity I wana ask that how
do u program USRP E100 for standalone operations? via verilog coding and all
that stuff or is there any other platform?? I am very comfortable with
MATLAB and Simulink is there any way of using them?
Regards
Salman Dinani
On Fri, May 4, 2012 at 11:23 AM, John Malsbury <[email protected]>
wrote:
Salman,
The N200/210 is not traditionally used in a standalone fashion. However, I
suppose that its possible to incorporate various processing functions in the
FPGA so that it could hypothetically operate in a standalone fashion - this
would be a significant undertaking.
Have you considered our USRP E100/E110 as a standalone platform? See this
link:
https://www.ettus.com/product/category/USRP_Embedded_Series
Let us know your thoughts.
-John
On 5/3/2012 11:17 PM, salman dinani wrote:
Hi all,
I am using USRP N200 for receiving signals of different modulation etc with
MATLAB R2011b.. i want to know can USRP N200 be used as a standalone
receiver or Transceiver? If yes than how??
Regards
Salman Dinani
_______________________________________________
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120504/66542aa0/attachment-0001.html>
------------------------------
Message: 10
Date: Fri, 04 May 2012 01:19:28 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP N200 for standalone operation...
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
> @Ettus, the vision and expectation that I have of the N210 hardware is that
> its basic RF configuration (including carrier frequency (for both Tx and
> Rx), output power, input gain, etc.) can be programmed using commands that
> are sent using calls to the UHD driver via Ethernet. Similarly, a transmit
> file (or pattern, or vector) can also be downloaded and a command can be
> sent to control transmission--on or off. Likewise, a command to transfer the
> contents of capture buffers of the receiver to the host PC should also be
> possible. Please comment.
>
Thats the basic idea. We have a c++ driver that makes it easy to tune
the frontends and set various parameters, and send/recv samples.
You can code to this driver directly or use various environments on top
of it like simulink, labview, gnuradio...
Also see code examples:
http://code.ettus.com/redmine/ettus/projects/uhd/wiki#Code-Examples
> To try and summarize, I do not wish to use the Ettus hardware to construct a
> communications system which would require the host PC to perform the
> processing of the baseband data more or less continuously. Instead, I want
> to use the Ettus hardware as an alternative to very expensive VSG and a VSA
> laboratory instrumentation in such a way that the host PC sends programming
> commands to the N210 in order to configure it for transmission and
> reception. The host PC will generate the Tx waveforms and will analyze the
> Rx signals on what could be called an ad hoc basis.
>
> Is it possible to use the Ettus hardware--without developing new Verilog
> code--for the application I have described?
>
What are your specific requirements? The stock FPGA image has DDC and
DUC chains and ways to handled timed transmission and reception of samples.
You only really need to modify the verilog/FPGA to add functionality
thats not possible to perform in the host because of bandwidth
limitations, turn-around time, etc...
-josh
------------------------------
Message: 11
Date: Fri, 04 May 2012 01:32:13 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP N200 for standalone operation...
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 05/04/2012 12:00 AM, salman dinani wrote:
> Hi John
>
> Thanks for that..actually I am not that strong in verliog programming etc
> so indeed it would be a challenge for me. out of curosity I wana ask that
> how do u program USRP E100 for standalone operations? via verilog coding
> and all that stuff or is there any other platform?? I am very comfortable
> with MATLAB and Simulink is there any way of using them?
>
Salman,
What do you mean by stand-alone? I consider E100 to be stand-alone
because you do not need an external PC to use it. Thats because it has
an embedded ARM processor to interface with the FPGA. Whereas, N200, the
primary use case is with a desktop/laptop PC.
So, you dont need to know verilog to use a USRP (unless you want to
modify the stock FPGA images for some reason). Here are coding examples
for a few USRP development environments:
http://code.ettus.com/redmine/ettus/projects/uhd/wiki#Code-Examples
If you find that you need to implement something in the FPGA for
performance reasons; is it possible to design the processing chain in
MATLAB, and then tie the design into the E100 verilog? I am not very
familiar with MATLAB FPGA design, but this would be very neat to say the
least.
-josh
------------------------------
Message: 12
Date: Fri, 4 May 2012 11:15:55 +0200
From: Matthias Br?ndli <[email protected]>
To: [email protected]
Subject: [USRP-users] USRP behaviour with late packets in synchronised
transmission
Message-ID:
<CABtm9hMxiZVxqFKNnumj6q2gz=n7q9aoa7dlburjxu+067y...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Dear usrp-users,
There is an issue I cannot explain in my present setup. I have two
USRPs (one B100 and one USRP2), and would like to transmit the same
samples synchronously. I'm using two function generators to create the
10MHz REFCLK and the 1PPS signal (the 1PPS generator being
synchronised to the 10MHz too). The transmitted signal is made of 24ms
frames that have a null symbol that is easily observable on an
oscilloscope, so I immediately see if transmission is aligned or not.
I generate the samples to be transmitted twice (either on the same
computer, or on two different computers. They are identical both in
data and timestamps.) using a custom C++ program. Those generated
samples have a timestamp, which is given to uhd::tx_streamer::send()
through the metadata.
When I start the program, it uses set_time_unknown_pps to set USRP
time (the computer itself is synchronised using NTP). Let's assume
that this works[1], and that both USRPs have the same time. They also
have the same 10MHz REFCLK, and so they both stay in time forever.
Since both USRPs receive the same sample stream, they transmit in
sync, and I can observe that on the scope too.
Once in a few minutes, the USRP2 gives me an underrun (prints U on
screen), followed by a bunch of late packets (prints L a hundred times
on screen). Sometimes, I then observe a relative delay between the two
USRPs on the scope. The only way this can happen in my understanding
is that the internal usrp clocks have become desynchronised.
I check for the REFCLK lock sensor every frame (= every 24ms), and it
doesn't complain (unless I unplug the REFCLK). Is it possible that the
lock is lost between my checks, and that I don't know about that ? Is
there a way to tell the USRP to inform me when there is a lock loss,
instead of polling the sensor ?
Or is there another reason why the internal clock might jump ?
best regards,
mpb
--------
Some more details:
- The B100 never generates underruns.
- REFCLK: sine, 10MHz, 1.5Vpp, 0V DC offset
- 1PPS: square, 0V to 4V
[1]:
One issue could be that the rising edge from the 1PPS generator is not
aligned to computer second change, but that's another question.
------------------------------
Message: 13
Date: Fri, 04 May 2012 02:35:34 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP behaviour with late packets in
synchronised transmission
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
> Once in a few minutes, the USRP2 gives me an underrun (prints U on
> screen), followed by a bunch of late packets (prints L a hundred times
> on screen). Sometimes, I then observe a relative delay between the two
> USRPs on the scope. The only way this can happen in my understanding
> is that the internal usrp clocks have become desynchronised.
>
Given the number of L's it sounds like you are putting timestamps on
every packet. Is it possible that the timestamps are incorrectly
interpolated for the given sample rate? I think that could explain the
late part, dropping a bunch of packets, and then catching back up.
The actual samples rates B100 and USRP2 can do may not overlap (depends
how you set B100 master clock rate). Does usrp->get_tx_sample_rate()
match the desired set value?
Another thought, make sure you have the right level for the ref:
http://files.ettus.com/uhd_docs/manual/html/usrp2.html#ref-clock-10mhz
You might want to poll usrp->get_time_now() over time and see if things
are drifting apart, more delta between the devices. That would be a sign
of not locking as well.
-Josh
------------------------------
Message: 14
Date: Fri, 4 May 2012 12:15:07 +0200
From: Matthias Br?ndli <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP behaviour with late packets in
synchronised transmission
Message-ID:
<CABtm9hMNnW0xkgyJ5Nh0AOSSLk-d=q6wvn2X+=prph3nkey...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On 4 May 2012 11:35, Josh Blum <[email protected]> wrote:
>> Once in a few minutes, the USRP2 gives me an underrun (prints U on
>> screen), followed by a bunch of late packets (prints L a hundred times
>> on screen). Sometimes, I then observe a relative delay between the two
>> USRPs on the scope. The only way this can happen in my understanding
>> is that the internal usrp clocks have become desynchronised.
>
> Given the number of L's it sounds like you are putting timestamps on
> every packet.
Yes, that's true.
> Is it possible that the timestamps are incorrectly
> interpolated for the given sample rate? I think that could explain the
> late part, dropping a bunch of packets, and then catching back up.
I do a md.time_spec = timespec_of_first_packet +
uhd::time_spec_t(0, num_acc_samps/sampleRate)
where num_acc_samps is the number of samples of my frame already sent.
I believe that if that would be off, then most if not all
transmissions would fail, and give late packets.
> The actual samples rates B100 and USRP2 can do may not overlap (depends
> how you set B100 master clock rate). Does usrp->get_tx_sample_rate()
> match the desired set value?
Check.
I'm using the same sample rate on both, and get_tx_sample_rate
corresponds to the desired one.
> Another thought, make sure you have the right level for the ref:
> http://files.ettus.com/uhd_docs/manual/html/usrp2.html#ref-clock-10mhz
Yes, and lowering the level gives me a refclk lock loss. So I set a
level a bit higher, where I don't see any loss. I also used the dBm
table at http://ifmaxp1.ifm.uni-hamburg.de/DBM.shtml as reference.
> You might want to poll usrp->get_time_now() over time and see if things
> are drifting apart, more delta between the devices. That would be a sign
> of not locking as well.
Okay.
Do I understand it correctly that there is no way to receive a
notification when the lock is lost, and that polling is the only way
of measuring this ? Is it probable that the refclk lock can be lost
for a very short time (let's say some 10s of microseconds) ? If it is
probable, then it is likely that we aren't able to notice it when
sampling the sensor every 24ms.
Or is there a sensor "refclk_locked_for_a_long_duration" ?
Thank you for your answers,
mpb
------------------------------
Message: 15
Date: Fri, 4 May 2012 12:33:12 +0200
From: Sanat Gulvadi <[email protected]>
To: [email protected]
Subject: [USRP-users] uhd_fft.py mirrored spectrum
Message-ID:
<CAH12yLvoM4==Y=2_F6P_uOoBFxphQi5Da1D=usrs2+e2-g2...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Good Afternoon,
I am using 2 USRP2-REV4 devices each connected with an RFX2400
daughterboard and connected to 2 different host computers to simulate an
OFDM transmission. I generated the OFDM symbol on MATLAB and am
transmitting it by passing it to a command line application I wrote using
UHD_003.004.001-111-g869e5ff1. I used the uhd_fft.py on the other machine
to observe the spectrum.
I suspect that the spectrum being shown is somehow mirrored. To test if
this is indeed the case, I set some subcarriers in adjacent bands to zero
on either halves of the spectrum such that these 'zero bands' are closer to
the middle of the spectrum. As I suspected, at the receiver, the spectrum
indeed appears to be mirrored, since the 'zero bands' are towards the edges
rather than the middle. I also tried this with just making them zero on one
half of the spectrum to observe the received spectrum. I also tried this
with just transmitting distinct subcarriers. The following pictures should
illustrate what I mean :
http://imgur.com/a/N7nT5
also seen when I transmit some distinct subcarriers only and suppress the
rest :
http://imgur.com/a/ZGziW
Is there some reason that's causing the spectrum to get mirrored? Should
this question have been directed to the discuss-gnuradio list instead ?
Thanks and Best Regards,
Sanat
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120504/6738d8ab/attachment-0001.html>
------------------------------
Message: 16
Date: Fri, 4 May 2012 09:27:03 -0400
From: Isaac Gerg <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] UHD Tx Issues with Spurious Samples Being
Tx'ed
Message-ID:
<CADnN3yUc2VT=nPkgOe=ktqmq+5ovsn1e61fwbl4bg3v+7s8...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Josh,
The send call from tx_streamer doesnt match the interface in io_impl.
This has 4 arguments,
http://files.ettus.com/uhd_docs/doxygen/html/stream_8hpp_source.html
This has 6,
http://ettus-apps.sourcerepo.com/redmine/ettus/projects/uhd/repository/revisions/6c13ef7855dcfe9c825e819f69f219851387da25/entry/host/lib/usrp/usrp1/io_impl.cpp
I am looking for the implementation of send() call with 4 arguments.
Isaac
On Thu, May 3, 2012 at 5:01 PM, Josh Blum <[email protected]> wrote:
>
>
> On 05/03/2012 12:12 PM, Isaac Gerg wrote:
>> Hi Josh,
>>
>> After more analysis with the scope today I noticed that the waveforms
>> of my bursts seemed to get queued up and when I send say burst 5, I
>> see burst 3 go out.
>>
>> Also, what file has the implementation of the tx_streamer->send()
>
>
> Its all in usrp1/io_impl.cpp
>
> You should see that tx_stream_on_off is called with enable false when an
> end of burst is set, and that flush_send_buff is called.
>
>> function? ?With this interface, it looks like the parameter to capture
>> SEND_MODE_FULL_BUFF went away.
>>
>
> There wasnt really a distinction. If you just wanted to send 1 packet,
> then you just set the length to be 1 packet and no more. So its always
> full buffer basically.
>
>> Have you had any time to check things out on your end?
>>
>
> I verified that the flush is being called when EOB is set. I havent had
> time to look any closer.
>
> Hope that helps,
> -Josh
------------------------------
Message: 17
Date: Fri, 04 May 2012 23:25:22 +0900
From: Haris Kremo <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] uhd_fft.py mirrored spectrum
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Sanat,
Here is a hint that might be useful: Try fftshift function in Matlab.
Most likely Matlab puts zero frequency at the left end of the band, and
UHD puts it in the middle.
Regards,
H.
On 5/4/2012 7:33 PM, Sanat Gulvadi wrote:
> Good Afternoon,
>
> I am using 2 USRP2-REV4 devices each connected with an RFX2400
> daughterboard and connected to 2 different host computers to simulate
> an OFDM transmission. I generated the OFDM symbol on MATLAB and am
> transmitting it by passing it to a command line application I wrote
> using UHD_003.004.001-111-g869e5ff1. I used the uhd_fft.py on the
> other machine to observe the spectrum.
> I suspect that the spectrum being shown is somehow mirrored. To test
> if this is indeed the case, I set some subcarriers in adjacent bands
> to zero on either halves of the spectrum such that these 'zero bands'
> are closer to the middle of the spectrum. As I suspected, at the
> receiver, the spectrum indeed appears to be mirrored, since the 'zero
> bands' are towards the edges rather than the middle. I also tried this
> with just making them zero on one half of the spectrum to observe the
> received spectrum. I also tried this with just transmitting distinct
> subcarriers. The following pictures should illustrate what I mean :
>
> http://imgur.com/a/N7nT5
>
> also seen when I transmit some distinct subcarriers only and suppress
> the rest :
>
> http://imgur.com/a/ZGziW
>
> Is there some reason that's causing the spectrum to get mirrored?
> Should this question have been directed to the discuss-gnuradio list
> instead ?
>
> Thanks and Best Regards,
> Sanat
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120504/a9d5791c/attachment-0001.html>
------------------------------
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
End of USRP-users Digest, Vol 21, Issue 4
*****************************************
