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. MIMO System Synchronization Problem for USRP N210 (fengguo tian)
2. Re: getting noise for FM receiver with usrp e110 ?
(Wafa Elhajhmida)
3. USRP1 frequency difference between TX+RX (William Grissom)
4. Re: USRP1 frequency difference between TX+RX (Marcus M?ller)
5. Re: USRP1 frequency difference between TX+RX (Marcus D. Leech)
6. USRP FPGA Loading Concern ([email protected])
7. Re: USRP FPGA Loading Concern (Marcus D. Leech)
8. Re: USRP FPGA Loading Concern (Marcus M?ller)
9. Re: USRP FPGA Loading Concern (Nowlan, Sean)
10. Re: USRP FPGA Loading Concern (Marcus M?ller)
11. Re: B210 channel assignment (Michael West)
12. Re: sample time alignment in GRC
(Lapointe, Benjamin - 1008 - MITLL)
13. Re: sample time alignment in GRC (Robert Kossler)
----------------------------------------------------------------------
Message: 1
Date: Sun, 15 Jun 2014 22:59:13 +0000
From: fengguo tian <[email protected]>
To: [email protected]
Subject: [USRP-users] MIMO System Synchronization Problem for USRP
N210
Message-ID:
<cagjw6c2q4jbyv0msiwo-e-rwvogxl5++5jq56nj+5dwuw28...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Dear all,
Can anyone help me? Our group bought 6 N210 USRPs from your company to
build a 3x3 MIMO system. I have searched lots of literature to help me
synchronize the USRPs and I also downloaded all the related pdf documents
from your website.
Environment Ubuntu 12.04, GNURadio 3.7.2 .
1. The thing is when I try to use the GRC block to synchronize the USRPs
to realize the 2X2 MIMO system, there is always an error saying "
RuntimeError: ValueError: Could not resolve device hint "addr=192.168.10.3"
to a single device."
?
I draw this flowgraph based on your Application Note called Synchronization
and MIMO Capability with USRP Devices. Now the receiver side work. It says
" All principles illustrated in this example are applicable to operations
in the transmit direction." But now it always has error and cannot work.
ping 192.168.10.2 is ok, while ping 192.168.10.2 is not reachable. I've
been stuck for 2 months. Can you help me solve the problem.
2. now I still need to synchronize the USRPs to build the 3x3 MIMO system.
would you mind give me some useful material or GRC flowgraph especially for
the transmitted side.
Best regards,
--
Fengguo Tian
[email protected]
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140615/4fb2babf/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 16 Jun 2014 11:18:49 +0200
From: Wafa Elhajhmida <[email protected]>
To: Mike Jameson <[email protected]>, discuss-gnuradio
<[email protected]>, [email protected]
Subject: Re: [USRP-users] getting noise for FM receiver with usrp e110
?
Message-ID:
<CADHj1Ttrsvjtz268M=oid4xyq+n7fe9yfqgsh7bgqpgb6sq...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks a lot for your reply.
In fact, in order to respect the band range frequency of the SBX
daughterboard Rev 5.1.
I sent an FM signal from a signal generator called *NI PXIe-5673* described
in this link:
http://sine.ni.com/nips/cds/view/p/lang/en/nid/205593. The signal that I
generated, it is a sinus and has *900* *MHz *frequency.
So that I created my proper FM station on 900 MHz to respect the band
range frequency allowed by SBX daughterboard Rev 5.1.
In order to receive the signal generated by usrp e110, I implemented an FM
receiver flow graph on usrp e110 which is attached below and I used an VERT900
Antenna, described in this link:
https://www.ettus.com/product/details/VERT900 .
But I still have noise generated by usrp e110.
Have you an idea if there is a non suitable parameter on the flow graph ?
Thanks in advance
Best regards,
Wafa HAJ HMIDA
2014-06-12 12:33 GMT+02:00 Mike Jameson <[email protected]>:
> The SBX has a frequency range of 400MHz to 4.4GHZ which is why you cannot
> tune to broadcast FM stations between 88-108MHz:
>
> https://www.ettus.com/product/details/SBX
>
> Mike
>
> --
> Mike Jameson M0MIK BSc MIET
> Email: [email protected]
> Web: http://scanoo.com
>
>
> On Thu, Jun 12, 2014 at 11:14 AM, Wafa Elhajhmida via USRP-users <
> [email protected]> wrote:
>
>> Hi everybody,
>>
>> I'm trying to implement FM receiver on usrp e110. The daugtherboard used
>> is SBX Board Rev 5.1.
>>
>> As a result, I got only noise, I wasn't able to hear the local station at
>> 103.5 Mhz.
>>
>> And I got this error:
>> *UHD Warning:*
>> * The hardware does not support the requested RX frequency:*
>> * Target frequency: 103.500000 MHz*
>> * Actual frequency: 423.500000 MHz*
>> *>>> gr_fir_ccf: using armv7_a*
>> *>>> gr_fir_fff: using armv7_a*
>>
>> *aUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUaUOaUaUaUOaUaUaUaUaUaUaUaUaUaUaUaUaUaU*
>>
>> I attached a screenshot of FM receiver 's GRC.
>>
>> Can you help me to detect if there are some parameters which are wrong ?
>>
>> Best regards,
>>
>> Wafa HAJ HMIDA
>>
>> _______________________________________________
>> 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/20140616/10cfe528/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fm receiver with NI PXIe-5673.jpg
Type: image/jpeg
Size: 1348499 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140616/10cfe528/attachment-0001.jpg>
------------------------------
Message: 3
Date: Mon, 16 Jun 2014 11:47:52 -0500
From: William Grissom <[email protected]>
To: [email protected]
Subject: [USRP-users] USRP1 frequency difference between TX+RX
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hi all,
I am using a USRP1 with BasicTX and BasicRX boards and GNU Radio for basic
pulse-and-acquire NMR experiments at 20 MHz. Overall everything works as
expected except that there is a small frequency offset between transmit and
receive, which I have measured to be on the order of a few Hz. It seems to
change each time I power on the radio. I have written code to estimate it and
post-process the data to remove it prior to averaging measurements, but I would
obviously prefer if it didn't exist in the first place. My flowgraph comprises
only a block pulse generator and USRP Sink for transmit, and a USRP Source and
scope for receive. I am using a 250 kHz sample rate, and the USRP blocks use
the same center frequency variable.
I am wondering if this is an issue that I can fix with a simple change in my
flowgraph settings, or is there something hardware-related to it?
Thanks very much for any help,
Best,
Will Grissom
------------------------------
Message: 4
Date: Mon, 16 Jun 2014 19:52:13 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP1 frequency difference between TX+RX
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
Hello Will,
the Basic daughterboards don't have any mixers, so the only oscillator
involved in BasicTX-RX transmission are these of the DAC/ADC. Assuming
these are on the same USRP1, there should not be any offset, since both
daughterboards are driven off the same LO.
If they are on two different USRP1, then it's physically impossible to
have both oscillators on exactly the same frequency, which would explain
some offset even with the rather high quality oscillators on USRPs.
Greetings,
Marcus
On 16.06.2014 18:47, William Grissom via USRP-users wrote:
> Hi all,
>
> I am using a USRP1 with BasicTX and BasicRX boards and GNU Radio for basic
> pulse-and-acquire NMR experiments at 20 MHz. Overall everything works as
> expected except that there is a small frequency offset between transmit and
> receive, which I have measured to be on the order of a few Hz. It seems to
> change each time I power on the radio. I have written code to estimate it and
> post-process the data to remove it prior to averaging measurements, but I
> would obviously prefer if it didn't exist in the first place. My flowgraph
> comprises only a block pulse generator and USRP Sink for transmit, and a USRP
> Source and scope for receive. I am using a 250 kHz sample rate, and the USRP
> blocks use the same center frequency variable.
>
> I am wondering if this is an issue that I can fix with a simple change in my
> flowgraph settings, or is there something hardware-related to it?
>
> Thanks very much for any help,
> Best,
> Will Grissom
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 5
Date: Mon, 16 Jun 2014 13:56:13 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP1 frequency difference between TX+RX
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 06/16/2014 12:47 PM, William Grissom via USRP-users wrote:
> Hi all,
>
> I am using a USRP1 with BasicTX and BasicRX boards and GNU Radio for basic
> pulse-and-acquire NMR experiments at 20 MHz. Overall everything works as
> expected except that there is a small frequency offset between transmit and
> receive, which I have measured to be on the order of a few Hz. It seems to
> change each time I power on the radio. I have written code to estimate it and
> post-process the data to remove it prior to averaging measurements, but I
> would obviously prefer if it didn't exist in the first place. My flowgraph
> comprises only a block pulse generator and USRP Sink for transmit, and a USRP
> Source and scope for receive. I am using a 250 kHz sample rate, and the USRP
> blocks use the same center frequency variable.
>
> I am wondering if this is an issue that I can fix with a simple change in my
> flowgraph settings, or is there something hardware-related to it?
>
> Thanks very much for any help,
> Best,
> Will Grissom
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
There should be *zero* frequency difference between RX and TX in this
case, since everything is driven off a common clock, and you have no
analog up/downconversion happening.
Simplify, for purposes of experiment. Issue a CW tone on the TX side,
and see what the RX sees.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
------------------------------
Message: 6
Date: Mon, 16 Jun 2014 11:42:47 -0700
From: <[email protected]>
To: [email protected]
Subject: [USRP-users] USRP FPGA Loading Concern
Message-ID:
<20140616114247.c6355082b0b40c5de13775a07caa2e05.7e768fbdb0....@email10.secureserver.net>
Content-Type: text/plain; charset="us-ascii"
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140616/7f36f1b9/attachment-0001.html>
------------------------------
Message: 7
Date: Mon, 16 Jun 2014 15:00:43 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP FPGA Loading Concern
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 06/16/2014 02:42 PM, mhorvat--- via USRP-users wrote:
> Hello Everyone,
>
> I am currently working with the USRP b210 hardware and would like to
> connect to it remotely using a Raspberry Pi and USB/IP. I have tried
> this method with a BladeRF device and it works just fine. I would now
> like to use the larger bandwidth provided by the USRP. The issue I am
> having with the USRP is that whenever I try to run my top_block.py
> <http://top_block.py>, the USRP must reload the FPGA for some reason.
> This usually takes about 2 minutes locally, but takes just about
> forever using USB/IP unfortunately... Is there anyway I can load the
> FPGA locally on the Raspberry Pi, and then bypass the automatic
> loading feature when executing the top_block?
>
> Thank you,
>
> Michael Horvat
>
>
The firmware should only load if the B2xx has been power-cycled or
otherwise reset since the last session with it.
Also, the rPI has very little "horsepower" so even if you're just using
it as a "data-pump", it'll run out of steam pretty quickly, just
ferrying samples
back and forth.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140616/586c55f8/attachment-0001.html>
------------------------------
Message: 8
Date: Mon, 16 Jun 2014 21:54:25 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP FPGA Loading Concern
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hello Michael,
I don't want to ruin your mood, but I'm afraid you will not get a better
bandwidth with a B200.
Note that a) the raspberry Pi doesn't have USB3, so that's limiting your
sampling rate and b) if I'm not mistaken, the rPi is using the LAN9512,
hanging on the only USB bus, to offer LAN. You'll not only have only
USB2.0, you'll effectively have a fast ethernet adapter (not gigabit)
competing for the USB bus that the B200 needs to use. Let's assume you
can actually shuffle 100Mb/s with zero overhead over the ethernet link,
nevertheless:
You'll get 100Mb/s / (2*16b/sample) = 3.125Msam/s maximum. If you reduce
to 8bit samples, you'll get but 6.25Msam/s max.
This is the same limit your BladeRF will run into, if the ARM is not the
limiting factor anyway. To be completely honest, the <50EUR rPi is just
not the proper platform for high-rate SDR devices in 0.5kEUR+ region.
Generally: I think the right thing to do is doing the hardware
interfacing on the Raspberry and just transfer the samples using
UDP/TCP, avoiding the overhead and roundtrip times that USB/IP
transports introduce.
Greetings,
Marcus
On 16.06.2014 20:42, mhorvat--- via USRP-users wrote:
> Hello Everyone,
>
> I am currently working with the USRP b210 hardware and would like to connect
> to
> it remotely using a Raspberry Pi and USB/IP. I have tried this method with a
> BladeRF device and it works just fine. I would now like to use the larger
> bandwidth provided by the USRP. The issue I am having with the USRP is that
> whenever I try to run my top_block.py <http://top_block.py>, the USRP must
> reload the FPGA for some reason. This usually takes about 2 minutes locally,
> but
> takes just about forever using USB/IP unfortunately... Is there anyway I can
> load the FPGA locally on the Raspberry Pi, and then bypass the automatic
> loading
> feature when executing the top_block?
>
> Thank you,
>
> Michael Horvat
>
>
>
>
> _______________________________________________
> 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/20140616/7009beae/attachment-0001.html>
------------------------------
Message: 9
Date: Mon, 16 Jun 2014 20:14:02 +0000
From: "Nowlan, Sean" <[email protected]>
To: Marcus M?ller <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP FPGA Loading Concern
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
If you?re looking for something with much more horsepower but still having a
small form factor, I recommend the Intel NUC:
http://www.amazon.com/Intel-D54250WYK1-i5-4250U-Processor-Power/dp/B00H3YT8CC/ref=sr_1_3?ie=UTF8&qid=1402949483&sr=8-3&keywords=intel+nuc
It has a Core i3 or i5 (depending which model you get), USB 3.0, and a Gigabit
Ethernet controller. Depending what size of memory and hard drive you get for
it, you?re looking at $400-600 (USD).
Sean
From: USRP-users [mailto:[email protected]] On Behalf Of
Marcus M?ller via USRP-users
Sent: Monday, June 16, 2014 3:54 PM
To: [email protected]
Subject: Re: [USRP-users] USRP FPGA Loading Concern
Hello Michael,
I don't want to ruin your mood, but I'm afraid you will not get a better
bandwidth with a B200.
Note that a) the raspberry Pi doesn't have USB3, so that's limiting your
sampling rate and b) if I'm not mistaken, the rPi is using the LAN9512, hanging
on the only USB bus, to offer LAN. You'll not only have only USB2.0, you'll
effectively have a fast ethernet adapter (not gigabit) competing for the USB
bus that the B200 needs to use. Let's assume you can actually shuffle 100Mb/s
with zero overhead over the ethernet link, nevertheless:
You'll get 100Mb/s / (2*16b/sample) = 3.125Msam/s maximum. If you reduce to
8bit samples, you'll get but 6.25Msam/s max.
This is the same limit your BladeRF will run into, if the ARM is not the
limiting factor anyway. To be completely honest, the <50? rPi is just not the
proper platform for high-rate SDR devices in 0.5k?+ region.
Generally: I think the right thing to do is doing the hardware interfacing on
the Raspberry and just transfer the samples using UDP/TCP, avoiding the
overhead and roundtrip times that USB/IP transports introduce.
Greetings,
Marcus
On 16.06.2014 20:42, mhorvat--- via USRP-users wrote:
Hello Everyone,
I am currently working with the USRP b210 hardware and would like to connect to
it remotely using a Raspberry Pi and USB/IP. I have tried this method with a
BladeRF device and it works just fine. I would now like to use the larger
bandwidth provided by the USRP. The issue I am having with the USRP is that
whenever I try to run my top_block.py
<http://top_block.py><http://top_block.py>, the USRP must
reload the FPGA for some reason. This usually takes about 2 minutes locally, but
takes just about forever using USB/IP unfortunately... Is there anyway I can
load the FPGA locally on the Raspberry Pi, and then bypass the automatic loading
feature when executing the top_block?
Thank you,
Michael Horvat
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[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/20140616/f5a29c57/attachment-0001.html>
------------------------------
Message: 10
Date: Mon, 16 Jun 2014 23:22:12 +0200
From: Marcus M?ller <[email protected]>
To: [email protected], usrp-users <[email protected]>
Subject: Re: [USRP-users] USRP FPGA Loading Concern
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
You could certainly just use UHD[1] on the rPi and use plain sockets to
transfer the samples you get from the USRP using UDP (and the other way
round). Actually, there's already an example for that:
rx_samples_to_udp.cpp [2]
Compiling UHD on the rPi sounds like... not so much fun. You might want
to set up some kind of cross-compilation system.
Anyway, you will not be able use your B210's bandwidth potential over
the fast ethernet link, even with the UHD-UDP setup.
Greetings,
Marcus
[1] UHD doxygen: http://files.ettus.com/uhd_docs/doxygen/html/annotated.html
[2]
https://github.com/EttusResearch/uhd/blob/master/host/examples/rx_samples_to_udp.cpp
On 16.06.2014 23:09, [email protected] wrote:
> Hello Marcus,
>
> You most certainly did not ruin my day! Our first instinct was to do it the
> way
> you suggested, but we found that our rPi wasn't able to install/compile
> Gnuradio. This is when we decided to use USB/IP so that our remote PC could
> handle our GRC flow graph seperately. Is there a way to transfer the samples
> over UDP/TCP without installing Gnuradio to the rPi?
>
> Thanks,
>
> Michael Horvat
>
> -------- Original Message --------
> Subject: Re: [USRP-users] USRP FPGA Loading Concern
> From: Marcus_M?ller via USRP-users <[email protected]
> <mailto:[email protected]>>
> Date: Mon, June 16, 2014 3:54 pm
> To: [email protected] <mailto:[email protected]>
>
> Hello Michael,
> I don't want to ruin your mood, but I'm afraid you will not get a better
> bandwidth with a B200.
>
> Note that a) the raspberry Pi doesn't have USB3, so that's limiting your
> sampling rate and b) if I'm not mistaken, the rPi is using the LAN9512,
> hanging on the only USB bus, to offer LAN. You'll not only have only
> USB2.0,
> you'll effectively have a fast ethernet adapter (not gigabit) competing
> for
> the USB bus that the B200 needs to use. Let's assume you can actually
> shuffle 100Mb/s with zero overhead over the ethernet link, nevertheless:
> You'll get 100Mb/s / (2*16b/sample) = 3.125Msam/s maximum. If you reduce
> to
> 8bit samples, you'll get but 6.25Msam/s max.
>
> This is the same limit your BladeRF will run into, if the ARM is not the
> limiting factor anyway. To be completely honest, the <50? rPi is just not
> the proper platform for high-rate SDR devices in 0.5k?+ region.
>
> Generally: I think the right thing to do is doing the hardware interfacing
> on the Raspberry and just transfer the samples using UDP/TCP, avoiding the
> overhead and roundtrip times that USB/IP transports introduce.
>
> Greetings,
> Marcus
>
> On 16.06.2014 20:42, mhorvat--- via USRP-users wrote:
> > Hello Everyone,
> >
> > I am currently working with the USRP b210 hardware and would like to
> > connect to
> > it remotely using a Raspberry Pi and USB/IP. I have tried this method
> > with a
> > BladeRF device and it works just fine. I would now like to use the
> > larger
> > bandwidth provided by the USRP. The issue I am having with the USRP is
> > that
> > whenever I try to run mytop_block.py <http://top_block.py>
> > <http://top_block.py>, the USRP must
> > reload the FPGA for some reason. This usually takes about 2 minutes
> > locally, but
> > takes just about forever using USB/IP unfortunately... Is there anyway
> > I can
> > load the FPGA locally on the Raspberry Pi, and then bypass the
> > automatic loading
> > feature when executing the top_block?
> >
> > Thank you,
> >
> > Michael Horvat
> >
> >
> >
> >
> > _______________________________________________
> > USRP-users mailing list
> > [email protected]
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
> --------------------------------------------------------------------------------
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 11
Date: Mon, 16 Jun 2014 16:45:40 -0700
From: Michael West <[email protected]>
To: Ben Hilburn <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] B210 channel assignment
Message-ID:
<CAM4xKrpNaJ-NE0wTidnu3p=5b3pmpsfxl4zd9e_mcpyusuk...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi all,
Good news! We have tracked down the B210 channel assignment issue and we
have a fix in review and testing now. The problem was an incorrect
algorithm in the firmware when reconfiguring the active chains. The fix
will be available in the next release.
For those that cannot wait for the next release, contact me directly and I
will be happy to provide an "unofficial" firmware image with the fix.
Regards,
Michael E. West
Senior Software Design Engineer
Ettus Research
www.ettus.com
On Thu, May 22, 2014 at 12:48 PM, Ben Hilburn via USRP-users <
[email protected]> wrote:
> Hi all -
>
> Thanks for the complete bug report, including steps to reproduce and
> flowgraphs! It's on our high-priority list. We'll get this fixed as soon as
> we can.
>
> Cheers,
> Ben
>
>
> On Wed, May 21, 2014 at 6:17 PM, Tom Tsou via USRP-users <
> [email protected]> wrote:
>
>> On Tue, May 13, 2014 at 5:03 AM, Stefan Ereth via USRP-users
>> <[email protected]> wrote:
>> > Hi all,
>> > I try to capture samples of both channels from a B210 and save them in
>> separate files. The Problem is that the channel assignment is different
>> after retuning.
>> > I connected a signal generator to channel 1 and let channel 2 open.
>> Normally the file "measure0" should always contain my signal and "measure1"
>> noise. But out of 20 times the signal is 17 times in "measure0" and 3 times
>> in "measure1".
>>
>> I've seen this behaviour as well, though not after retuning. Swap
>> seems to occur at startup. Out of 20 starts I'll see at least one A/B
>> channel reversal. I do retune the DDC frequently while running, and
>> that does not seem to be related.
>>
>> UHD_003.007.001-65-g79c9b12b
>> Rate: 15.36 MHz
>> Freq: 1 GHz
>>
>> -TT
>>
>> _______________________________________________
>> 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/20140616/0628a23d/attachment-0001.html>
------------------------------
Message: 12
Date: Tue, 17 Jun 2014 13:58:53 +0000
From: "Lapointe, Benjamin - 1008 - MITLL" <[email protected]>
To: "[email protected]" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] sample time alignment in GRC
Message-ID:
<ba0ac330d0347f4b8d5a1e064a965464023...@lle2k10-mbx02.mitll.ad.local>
Content-Type: text/plain; charset="utf-8"
Hi All,
I am still having trouble time aligning sample streams from two USRP X310
devices. In GRC I noticed a random time offset from run to run in the two data
streams using a WX GUI Scope Sink. Looking at recorded data in MATLAB I also
see a random time offset from run to run in the two data streams (8, 18, and 24
sample offset). I verified that the two data streams that I am inputting into
the X310 devices are time aligned using a physical scope.
My GRC setup:
USRP Source 1 (with internal GPSDO-MINI)
- Sync = unknown PPS
- Mb0: Clock Source = Default
- Mb0: Time Source = Default
USRP Source 2
- Sync = unknown PPS
- Mb0: Clock Source = External
- Mb0: Time Source = External
For looking at the data streams I have USRP Source -> Complex to Mag -> WX GUI
Scope Sink.
For recording the data streams I have USRP Source -> Head (5K) -> File Sink
(Unbuffered: OFF)
Ref Out SMA of USRP 1 is connected to Ref In SMA of USRP 2 with a 6? SMA cable.
PPS Trig Out SMA of USRP 1 is connected to PPS Trig In SMA of USRP 2 with a 6?
SMA cable.
RF input to USRP devices is a pulsed RF signal, to make it easier to look at
time offset.
GPS on USRP 1 is locked; however, I work with tall buildings completely
surrounding me and so I don?t know the strength of the GPS lock.
I have an OctoClock-G on order to distribute 10 MHz Ref and 1 PPS signals, but
until then..
Does anyone have any other ideas for getting time-aligned samples from run to
run in GRC, or what I am doing wrong? I would expect at most a minimal constant
time offset between data streams if the 10 MHz Ref and 1 PPS signals are
locked.
Thanks!
-ben
From: Marcus Leech [mailto:[email protected]]
Sent: Friday, June 13, 2014 2:04 PM
To: Lapointe, Benjamin - 1008 - MITLL
Cc: [email protected]
Subject: Re: [Discuss-gnuradio] sample time alignment in GRC
Make sure that you specify that the 2nd X310 uses external clock and 1PPS, and
all of them should use time synch of
"unknown PPS".
Also, there has been a bug in the scope sink (dunno if fixed) where samples are
*not* time-aligned in the scope sink. The except
is that a complex-pair will be time-aligned internally, but not necessarily
to other streams being displayed.
on Jun 13, 2014, Lapointe, Benjamin - 1008 - MITLL <[email protected]> wrote:
Hi,
I have two USRP X310 devices that I am trying to time align in GNU Radio
Companion. One X310 has a GPSDO that is sending 10 MHz reference and 1 PPS
signals to the other one. The GPS is locked. Ideally I would have matched
length cables for 10 MHz reference and 1 PPS, but I think my setup is close
enough. (Input signal from sig gen = pulsed 10.005 MHz, input is split with
matched length cables, USRP output sampling rate = 5M, USRP center frequency =
10M.)
I am using WX GUI Scope Sink to look at the magnitudes of each stream from the
USRP devices. I expect to see no/minimal delay between the two signal streams,
but I am seeing delays of 24, 13, 9, 0, 3, 6, 25, 24 samples from run to run
between the two signal streams. The period of the signal is 50 samples, so the
maximum delay difference is 25 samples. Am I missing something in my
configuration? Since I am using a 10 MHz reference and 1 PPS signals, I expect
time alignment between the two sample streams. Is there a GRC block for
forcing time alignment?
Thanks!
-Ben
_____
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140617/af2ea67c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6662 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20140617/af2ea67c/attachment-0001.p7s>
------------------------------
Message: 13
Date: Tue, 17 Jun 2014 10:28:26 -0400
From: Robert Kossler <[email protected]>
To: "Lapointe, Benjamin - 1008 - MITLL" <[email protected]>
Cc: "[email protected]" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] sample time alignment in GRC
Message-ID:
<cab__httpkrcqq9bb-err7ha9_oxpe4ns8f2-pjhn1tc3gbo...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Ben,
I am having a similar (but not identical issue). I have a single X310 for
which I am trying to make sure both channels are time aligned. I have
tried both the internal PPS signal and an external PPS signal. I noticed
channel-to-channel time delays of 1, 2, or 3 "clock" cycles (at clock rate,
not sample rate) which varied from run to run. My measurements were done
with a modified "rx_samples_to_file" program and Matlab processing. I have
not yet duplicated using GRC.
Rob
On Tue, Jun 17, 2014 at 9:58 AM, Lapointe, Benjamin - 1008 - MITLL via
USRP-users <[email protected]> wrote:
> Hi All,
>
>
>
> I am still having trouble time aligning sample streams from two USRP X310
> devices. In GRC I noticed a random time offset from run to run in the two
> data streams using a WX GUI Scope Sink. Looking at recorded data in MATLAB
> I also see a random time offset from run to run in the two data streams (8,
> 18, and 24 sample offset). I verified that the two data streams that I am
> inputting into the X310 devices are time aligned using a physical scope.
>
>
>
> My GRC setup:
>
>
>
> USRP Source 1 (with internal GPSDO-MINI)
>
> - Sync = unknown PPS
>
> - Mb0: Clock Source = Default
>
> - Mb0: Time Source = Default
>
> USRP Source 2
>
> - Sync = unknown PPS
>
> - Mb0: Clock Source = External
>
> - Mb0: Time Source = External
>
>
>
> For looking at the data streams I have USRP Source -> Complex to Mag -> WX
> GUI Scope Sink.
>
> For recording the data streams I have USRP Source -> Head (5K) -> File
> Sink (Unbuffered: OFF)
>
>
>
> Ref Out SMA of USRP 1 is connected to Ref In SMA of USRP 2 with a 6? SMA
> cable.
>
> PPS Trig Out SMA of USRP 1 is connected to PPS Trig In SMA of USRP 2 with
> a 6? SMA cable.
>
> RF input to USRP devices is a pulsed RF signal, to make it easier to look
> at time offset.
>
> GPS on USRP 1 is locked; however, I work with tall buildings completely
> surrounding me and so I don?t know the strength of the GPS lock.
>
> I have an OctoClock-G on order to distribute 10 MHz Ref and 1 PPS signals,
> but until then..
>
>
>
> Does anyone have any other ideas for getting time-aligned samples from run
> to run in GRC, or what I am doing wrong? I would expect at most a minimal
> constant time offset between data streams if the 10 MHz Ref and 1 PPS
> signals are locked.
>
>
>
> Thanks!
>
> -ben
>
>
>
> *From:* Marcus Leech [mailto:[email protected]]
> *Sent:* Friday, June 13, 2014 2:04 PM
> *To:* Lapointe, Benjamin - 1008 - MITLL
> *Cc:* [email protected]
> *Subject:* Re: [Discuss-gnuradio] sample time alignment in GRC
>
>
>
> Make sure that you specify that the 2nd X310 uses external clock and 1PPS,
> and all of them should use time synch of
>
> "unknown PPS".
>
>
>
> Also, there has been a bug in the scope sink (dunno if fixed) where
> samples are *not* time-aligned in the scope sink. The except
>
> is that a complex-pair will be time-aligned internally, but not
> necessarily to other streams being displayed.
>
>
>
>
>
>
>
> on Jun 13, 2014, *Lapointe, Benjamin - 1008 - MITLL* <[email protected]>
> wrote:
>
> Hi,
>
>
>
> I have two USRP X310 devices that I am trying to time align in GNU Radio
> Companion. One X310 has a GPSDO that is sending 10 MHz reference and 1 PPS
> signals to the other one. The GPS is locked. Ideally I would have matched
> length cables for 10 MHz reference and 1 PPS, but I think my setup is close
> enough. (Input signal from sig gen = pulsed 10.005 MHz, input is split with
> matched length cables, USRP output sampling rate = 5M, USRP center
> frequency = 10M.)
>
>
>
> I am using WX GUI Scope Sink to look at the magnitudes of each stream from
> the USRP devices. I expect to see no/minimal delay between the two signal
> streams, but I am seeing delays of 24, 13, 9, 0, 3, 6, 25, 24 samples from
> run to run between the two signal streams. The period of the signal is 50
> samples, so the maximum delay difference is 25 samples. Am I missing
> something in my configuration? Since I am using a 10 MHz reference and 1
> PPS signals, I expect time alignment between the two sample streams. Is
> there a GRC block for forcing time alignment?
>
>
>
> Thanks!
>
> -Ben
>
>
> ------------------------------
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> [email protected]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> _______________________________________________
> 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/20140617/5be8794c/attachment-0001.html>
------------------------------
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 46, Issue 17
******************************************
