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. B200xx agc performance (Knud Steven Knudsen)
2. Re: B200xx agc performance (Steven Knudsen)
3. Re: B210 and Simulink sample times (Marcus M?ller)
4. Re: B210 and Simulink sample times (Mike McLernon)
5. Re: usrp b210 problem (Mike McLernon)
6. Re: install gr-doa via pybombs - how? (Nicolas Cuervo)
7. Re: Transmit number to FPGA (Rohit Dilip)
8. Timeout on Chan 0 (Stephen Larew)
9. Re: Timeout on Chan 0 (Jonathon Pendlum)
10. Re: Timeout on Chan 0 (Stephen Larew)
11. Wide FFT Snapshots (Dave NotTelling)
12. Re: Wide FFT Snapshots (Derek Kozel)
13. B210 GPS L1 receviver in Simulink (Mihkel M)
14. Re: 10G BASE-T with x310 (Derek Kozel)
15. Re: Wide FFT Snapshots (Dave NotTelling)
16. x310 rfnoc fpga code (Lihua Ren)
17. Re: x310 rfnoc fpga code (Derek Kozel)
18. Re: Timeout on Chan 0 (Jonathon Pendlum)
----------------------------------------------------------------------
Message: 1
Date: Wed, 26 Apr 2017 10:50:57 -0600
From: Knud Steven Knudsen <[email protected]>
To: USRP-users <[email protected]>
Subject: [USRP-users] B200xx agc performance
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi,
I?ve done a bit of an online search and not turned up anything (but this could
be my lack of imagination at work) on AGC performance for a B200xx. I am
specifically interested in the B20xmini, but results from any USRP based on the
AD936x will suffice.
Can anyone point me in the right direction?
If not, then what is a good way to test AGC for a USRP? Use a second USRP to
transmit a modulated signal with large dynamic range?
Thanks for your help!
steven
Steven Knudsen, Ph.D., P.Eng.
www. techconficio.ca
www.linkedin.com/in/knudstevenknudsen
Der entscheidende Augenblick der menschlichen Entwicklung ist immerw?hrend.
Darum sind die revolution?ren geistigen Bewegungen, welche alles Fr?here f?r
nichtig erkl?ren, im Recht, denn es ist noch nichts geschehen. - Franz Kafka
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170426/493ed293/attachment-0001.html>
------------------------------
Message: 2
Date: Wed, 26 Apr 2017 11:51:42 -0600
From: Steven Knudsen <[email protected]>
To: USRP-users <[email protected]>
Subject: Re: [USRP-users] B200xx agc performance
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
I was a little impatient and should have thought to look at the AD9361 users
guide for more info. I?ve also dug through some list conversations and
confirmed that the property tree for the B200mini indicates support for setting
the AD9364 agc mode and parameters, though I am still figuring out how to use
that info.
Anyone have any wisdom to impart regarding agc with the AD936x? Specifically in
a bursty traffic situation (TDMA)?
thanks,
steven
Steven Knudsen, Ph.D., P.Eng.
www. techconficio.ca
www.linkedin.com/in/knudstevenknudsen
Du bist die Aufgabe. Kein Sch?ler weit und breit. - Franz Kafka
> On Apr 26, 2017, at 10:50, Knud Steven Knudsen via USRP-users
> <[email protected]> wrote:
>
> Hi,
>
> I?ve done a bit of an online search and not turned up anything (but this
> could be my lack of imagination at work) on AGC performance for a B200xx. I
> am specifically interested in the B20xmini, but results from any USRP based
> on the AD936x will suffice.
>
> Can anyone point me in the right direction?
>
> If not, then what is a good way to test AGC for a USRP? Use a second USRP to
> transmit a modulated signal with large dynamic range?
>
> Thanks for your help!
>
> steven
>
>
> Steven Knudsen, Ph.D., P.Eng.
> www. techconficio.ca <http://techconficio.ca/>
> www.linkedin.com/in/knudstevenknudsen
> <http://www.linkedin.com/in/knudstevenknudsen>
>
> Der entscheidende Augenblick der menschlichen Entwicklung ist immerw?hrend.
> Darum sind die revolution?ren geistigen Bewegungen, welche alles Fr?here f?r
> nichtig erkl?ren, im Recht, denn es ist noch nichts geschehen. - Franz Kafka
>
> _______________________________________________
> 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/20170426/65066346/attachment-0001.html>
------------------------------
Message: 3
Date: Wed, 26 Apr 2017 20:04:23 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] B210 and Simulink sample times
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Mihkel,
don't know Simulink overly well, but "ideal rectangular pulse filter"
sounds like a moving average ? and that would completely destroy your data.
So, I don't think this is going to work. Not sure you need an extra
"buffer" block.
Best regards,
Marcus
On 04/26/2017 12:25 PM, Mihkel M via USRP-users wrote:
>
> Hello!
>
>
> I am trying to generate GPS signals with USRP B210 SDR. I have made a
> source "from workspace" where are values ones and zeros. There are
> 30690000 values, with sample time 1/1023000, which is the GPS L1
> signal rate (1,023 MHz). Next block is "ideal rectangular pulse
> filter" with Pulse Length=4, which i have left in from examples i have
> found online( i'm not sure, if i really need this). Next block is BPSK
> modulator baseband with default settings. Next block is "Buffer" with
> size 1000 and final block is "SDRu Transmitter", with Fc-1575.42e6 Hz,
> LO offset-0 Hz, Gain-5 dB, Master Clock Rate- 20.95104e6 Hz,
> Interpolation- 512 and everything else is default.
>
>
> When i run the model, my GPS evaluation software (U-center) receives
> gibberish. Intermittent signal and pseudo satellites. Occasionally, it
> finds the satellite code, which i generate. (In the source block there
> is PRN #01 and NavData for 30 seconds)
>
>
> My question is, that why my simulation transmits such gibberish
> signal? As far as i have searched for this answer, the problem should
> be with mismatching sample rates? Anyone could explain me, how the DSP
> and SDR Tx sample times are related? How should i configure them? Also
> i have issues with running the simulation in real time, as i need to
> acquire the generated signal with u-center, where it should "see"
> legit GPS satellite information.
>
>
> Mihkel.
>
>
>
> _______________________________________________
> 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/20170426/1eb569ff/attachment-0001.html>
------------------------------
Message: 4
Date: Wed, 26 Apr 2017 18:23:28 +0000
From: Mike McLernon <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] B210 and Simulink sample times
Message-ID:
<bn1pr05mb437f516d9cbbaac247cf878e9...@bn1pr05mb437.namprd05.prod.outlook.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi Mihkel,
I can confirm Marcus' suspicions. The rectangular pulse filter will destroy
your data.
The BPSK modulator block needs binary (0/1) input.
Hth,
Mike
From: USRP-users [mailto:[email protected]] On Behalf Of
Marcus M?ller via USRP-users
Sent: Wednesday, April 26, 2017 2:04 PM
To: [email protected]
Subject: Re: [USRP-users] B210 and Simulink sample times
Hi Mihkel,
don't know Simulink overly well, but "ideal rectangular pulse filter" sounds
like a moving average - and that would completely destroy your data.
So, I don't think this is going to work. Not sure you need an extra "buffer"
block.
Best regards,
Marcus
On 04/26/2017 12:25 PM, Mihkel M via USRP-users wrote:
Hello!
I am trying to generate GPS signals with USRP B210 SDR. I have made a source
"from workspace" where are values ones and zeros. There are 30690000 values,
with sample time 1/1023000, which is the GPS L1 signal rate (1,023 MHz). Next
block is "ideal rectangular pulse filter" with Pulse Length=4, which i have
left in from examples i have found online( i'm not sure, if i really need
this). Next block is BPSK modulator baseband with default settings. Next block
is "Buffer" with size 1000 and final block is "SDRu Transmitter", with
Fc-1575.42e6 Hz, LO offset-0 Hz, Gain-5 dB, Master Clock Rate- 20.95104e6 Hz,
Interpolation- 512 and everything else is default.
When i run the model, my GPS evaluation software (U-center) receives gibberish.
Intermittent signal and pseudo satellites. Occasionally, it finds the satellite
code, which i generate. (In the source block there is PRN #01 and NavData for
30 seconds)
My question is, that why my simulation transmits such gibberish signal? As far
as i have searched for this answer, the problem should be with mismatching
sample rates? Anyone could explain me, how the DSP and SDR Tx sample times are
related? How should i configure them? Also i have issues with running the
simulation in real time, as i need to acquire the generated signal with
u-center, where it should "see" legit GPS satellite information.
Mihkel.
_______________________________________________
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/20170426/d0f35503/attachment-0001.html>
------------------------------
Message: 5
Date: Wed, 26 Apr 2017 18:44:31 +0000
From: Mike McLernon <[email protected]>
To: ??? <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] usrp b210 problem
Message-ID:
<bn1pr05mb437aa9576962ec29ff4e5f0e9...@bn1pr05mb437.namprd05.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
Hi Gyeong,
When you run the B210 receiver in burst mode with two channels, you will
encounter latencies that don?t exist when you receive with just one channel.
Do you need both channels?
Also, your code below indicates that you?re sampling at 30.72 MHz. Is that a
requirement?
Also, are you running your computer with your power management set to maximum
performance?
Best,
Mike
From: USRP-users [mailto:[email protected]] On Behalf Of ???
via USRP-users
Sent: Wednesday, April 26, 2017 2:10 AM
To: [email protected]
Subject: [USRP-users] usrp b210 problem
Dear Sir.
Hello.
When we connect to the B210 with matlab(USB 3.0) , the following errors often
happend
Could not execute UHD driver command in 'receiveData_c':
libmwusrp_uhd_capi:receiveData:ErrWrongRecvSize Did not receive expected number
of samples in
a burst reception.
This is likely due to overflow within the burst.
See possible solutions in section 'Unexpected number of samples in burst
reception' at
http://www.mathworks.com/help/supportpkg/usrpradio/ug/common-problems-and-fixes.html.
Expected: 307200
Found : 53469
matlab 2016b setting (LTE 20MHz bandwidth)
radio = comm.SDRuReceiver('Platform','B210', ...
'SerialNum', radiolist(i).SerialNum);
radio.MasterClockRate = 1.92e6*16; %1.92e6 * 4; % Need to exceed 5 MHz
minimum
radio.DecimationFactor = 1; % Sampling rate is 1.92e6
radioFound = true;
radio.ChannelMapping = [1 2]; % Receive signals from both channels
radio.CenterFrequency = 900e6;
radio.Gain = 30;
radio.SamplesPerFrame = 153600;%19200; % Sampling rate is 1.92 MHz. LTE frames
are 10 ms long
radio.OutputDataType = 'double';
radio.EnableBurstMode = true;
radio.NumFramesInBurst = 1;
radio.OverrunOutputPort = true;
How do I set the masterclockrate and decimation factor in burst mode(LTE
bandwidth 20MHz)?
Answers I'll wait.
thank you for your help in advance.
best regards
Gyeong mi Sun
[https://cgwebmail-001.cafe24.com/check_receive.php?idx=2698749]
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170426/8bc0f6ef/attachment-0001.html>
------------------------------
Message: 6
Date: Wed, 26 Apr 2017 22:34:05 +0200
From: Nicolas Cuervo <[email protected]>
To: Haile Berhe <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] install gr-doa via pybombs - how?
Message-ID:
<CAOuPCvjSyHw3Q=KxShEim0gsYCHq0WURsVf9=yxf=svbvey...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Haile,
you can find a first version of the PyBombs recipe for gr-doa available now
along with the recipes provided by Ettus Research. [1] You can add this
recipes by running:
$ pybombs recipes add ettus-pybombs git+
https://github.com/EttusResearch/ettus-pybombs.git
After that, you should be able to install gr-doa by running:
$ pybombs -p your_prefix install gr-doa
This will install the basic dependencies, but not the software required for
QA testing nor documentation (listed at [2]). Please feel free to give it a
try and provide feedback.
Cheers,
-N
[1] https://github.com/EttusResearch/ettus-pybombs
[2] https://github.com/EttusResearch/gr-doa
On Wed, Apr 26, 2017 at 1:17 PM, Nicolas Cuervo <[email protected]>
wrote:
> Hello Haile,
>
> it seems that there is no recipe (yet, I'm going to create one) for gr-doa
> in the PyBombs recipes. You can however install it by hand:
>
> For that, you need to install "Armadillo" in your system, as it is a basic
> dependency (the testing and documentation dependencies are recommended as
> well). Thereafter, you can follow the steps that are listed in the gr-doa
> wiki [1]
>
> For it to be installed into the PyBombs prefix of your choice, be sure to
> tell CMake about it. I.e. instead of running only
>
> $ cmake ..
>
> you should run
>
> $ cmake -DCMAKE_INSTALL_PREFIX=/path/to/your/prefix/ ..
>
> and the rest of the steps should be followed as usual (you should not need
> 'sudo' for installing into your own pybombs prefix).
>
> Regards,
> - Nicolas
>
>
> [1] https://github.com/EttusResearch/gr-doa
>
>
>
> On Wed, Apr 26, 2017 at 11:20 AM, Haile Berhe via USRP-users <
> [email protected]> wrote:
>
>> Dear all,
>> I have successfully installed gnuradio and many useful OOT modules using
>> pybombs thanks to [1]. However, I could not install gr-doa in the same
>> fashion I did to other OOT modules.
>> When I run 'pybombs install gr-doa', pybombs display the following error:
>> PyBOMBS.get_recipe - ERROR - Error fetching recipe `gr-doa':
>> Package gr-doa has no recipe file!
>> I don't want to risk my clean installation by trying to add recipe or
>> something like that as the error suggests.
>> Any suggestion please!
>> Thanks
>>
>> Haile
>>
>> [1] https://www.gnuradio.org/blog/pybombs-the-what-the-how-and-the-why/
>>
>> _______________________________________________
>> 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/20170426/c3c5e148/attachment-0001.html>
------------------------------
Message: 7
Date: Wed, 26 Apr 2017 17:33:33 -0400
From: Rohit Dilip <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Transmit number to FPGA
Message-ID:
<CALumccedWOwzyvxwrvD39Q=0KqazYVCFusar=uqp993dogd...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
I'm using a B200. I tried writing
reg [31:0] myreg;
wire [31:0] myreg_sr;
wire myreg_ch;
setting_reg #(.my_addr(0)) sr_0
(.clk(clk), .rst(reset), .strobe(set_stb), .addr(set_addr),
.in(set_data), .out(myreg_sr), .changed(myreg_ch));
always @(posedge clk)
if (myreg_ch)
myreg <= myreg_sr;
Then in the C++ file (tx_waveform.cpp
at
https://github.com/EttusResearch/uhd/blob/master/host/examples/tx_waveforms.cpp
<https://github.com/EttusResearch/uhd/blob/master/host/examples/tx_waveforms.cpp>)
I added
usrp -> set_user_register(0, myreg, 0);
but received an error "lookup error, path not found in tree,
mboards/0/user/regs." Is it possible to write to the register in this way
on the B200?
On Mon, Apr 24, 2017 at 5:18 PM, Jonathon Pendlum <
[email protected]> wrote:
> Hi,
>
> What device are you using? In the E3xx and X3xx series devices, you can
> use RFNoC.
>
> For other devices, you can use "set_user_register()". See this mailing
> list question: http://lists.ettus.com/pipermail/usrp-users_lists.
> ettus.com/2015-August/015333.html
>
> On Apr 22, 2017 5:23 PM, "Rohit Dilip via USRP-users" <
> [email protected]> wrote:
>
>> Hi,
>>
>> I modified an FPGA on a USRP device to generate and output a wave using a
>> lookup table. Is there a way to use gnuradio to input a number to the FPGA,
>> so I could generate that number of waves, summed together? I'd like to be
>> able to input several numbers -- say f1,f2,f3... -- to the FPGA, then
>> output sin(f1*t) + sin(f2*t) + ... If I have the ability to input a series
>> of numbers I can easily modify the verilog code. It seems that there should
>> be a way, since I can pass the master_clock_rate in the existing blocks,
>> but I haven't been able to find exactly where in the Ettus github
>> repository those parameters are.
>>
>> Best,
>> Rohit
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
--
-Rohit Dilip
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170426/feb0fcfe/attachment-0001.html>
------------------------------
Message: 8
Date: Wed, 26 Apr 2017 17:44:29 -0400
From: Stephen Larew <[email protected]>
To: USRP-users <[email protected]>
Subject: [USRP-users] Timeout on Chan 0
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi,
I am trying to implement a schmidl cox synchroniser on X310 using the given
RFNoC blocks. I have my grc flowgraph attached below, with the grc xml and uhd
xml files. There were some errors regarding "offset " not being found which I
had to change to the "delay" register. Everytime I run my top_block.py, I seem
to get a timeout on chan 0 error, which after reading some previous emails on
this list leads me to believe that some block is not producing data. Any
suggestions on why this would be happening would be great!
I am using the rfnoc-devel branch as I only have access to Vivado 2015.4.
Thanks,
-Stephen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: top_block_schmidl_cox.py
Type: text/x-python-script
Size: 9753 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170426/76d96518/attachment-0001.py>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: uhd_rfnoc_schmidlcox.xml
Type: application/xml
Size: 3270 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170426/76d96518/attachment-0002.xml>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: schmidlcox.xml
Type: application/xml
Size: 2285 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170426/76d96518/attachment-0003.xml>
------------------------------
Message: 9
Date: Wed, 26 Apr 2017 17:02:45 -0500
From: Jonathon Pendlum <[email protected]>
To: Stephen Larew <[email protected]>
Cc: USRP-users <[email protected]>
Subject: Re: [USRP-users] Timeout on Chan 0
Message-ID:
<cagdo0uscunxjbh884clmqtl3psup03d2le73eq_k7kxpzmg...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Stephen,
The Schmidl Cox block does not output any samples unless it detects a
preamble. While the timeouts sound bad, in this case it is perfectly
reasonable. Have you tried creating the preamble in GNU Radio and testing
against that? Also, when I last touched the Schmidl Cox block, performance
was somewhat sensitive to gain and I had planned on adding some additional
AGC to deal with it.
Jonathon
On Wed, Apr 26, 2017 at 4:44 PM, Stephen Larew via USRP-users <
[email protected]> wrote:
> Hi,
>
> I am trying to implement a schmidl cox synchroniser on X310 using the
> given RFNoC blocks. I have my grc flowgraph attached below, with the grc
> xml and uhd xml files. There were some errors regarding "offset " not being
> found which I had to change to the "delay" register. Everytime I run my
> top_block.py, I seem to get a timeout on chan 0 error, which after reading
> some previous emails on this list leads me to believe that some block is
> not producing data. Any suggestions on why this would be happening would be
> great!
>
> I am using the rfnoc-devel branch as I only have access to Vivado 2015.4.
>
> Thanks,
> -Stephen
>
> _______________________________________________
> 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/20170426/beba4b99/attachment-0001.html>
------------------------------
Message: 10
Date: Wed, 26 Apr 2017 20:32:31 -0400
From: Stephen Larew <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: USRP-users <[email protected]>
Subject: Re: [USRP-users] Timeout on Chan 0
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
I am using two X310s. One is transmitting using the stock GNU Radio OFDM TX,
which I understand includes the preamble for Schmidl & Cox synch. The other
which is using the RFNOC Schmidl Cox synchroniser. I will verify that the GNU
Radio ofdm_sync_sc_cfb block can sync correctly with over air and wire
transmissions and report back.
Doesn?t the SC timing metric, M(d) in the original paper, effectively do AGC
for us? The denominator of M(d) normalizes the metric based on receive power,
right?
> On Apr 26, 2017, at 18:02, Jonathon Pendlum <[email protected]>
> wrote:
>
> Hi Stephen,
>
> The Schmidl Cox block does not output any samples unless it detects a
> preamble. While the timeouts sound bad, in this case it is perfectly
> reasonable. Have you tried creating the preamble in GNU Radio and testing
> against that? Also, when I last touched the Schmidl Cox block, performance
> was somewhat sensitive to gain and I had planned on adding some additional
> AGC to deal with it.
>
>
>
> Jonathon
>
>> On Wed, Apr 26, 2017 at 4:44 PM, Stephen Larew via USRP-users
>> <[email protected]> wrote:
>> Hi,
>>
>> I am trying to implement a schmidl cox synchroniser on X310 using the given
>> RFNoC blocks. I have my grc flowgraph attached below, with the grc xml and
>> uhd xml files. There were some errors regarding "offset " not being found
>> which I had to change to the "delay" register. Everytime I run my
>> top_block.py, I seem to get a timeout on chan 0 error, which after reading
>> some previous emails on this list leads me to believe that some block is not
>> producing data. Any suggestions on why this would be happening would be
>> great!
>>
>> I am using the rfnoc-devel branch as I only have access to Vivado 2015.4.
>>
>> Thanks,
>> -Stephen
------------------------------
Message: 11
Date: Thu, 27 Apr 2017 07:53:36 -0400
From: Dave NotTelling <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Wide FFT Snapshots
Message-ID:
<CAK6GVuMd=4hG--yw4U4==y--kzzxrdkf3wnre_cutm-vtzv...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Is there a way to do a 1 GHz sweep with the X310, N210, or B200 in the same
way that you can with the HackRF? I need a way to characterize large
bandwidths and stitching together FFTs seems like the easiest way to
accomplish that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170427/5cdfe4aa/attachment-0001.html>
------------------------------
Message: 12
Date: Thu, 27 Apr 2017 13:05:15 +0100
From: Derek Kozel <[email protected]>
To: Dave NotTelling <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Wide FFT Snapshots
Message-ID:
<CAA+K=tt7otdxj9uaeoylocc2-2svo9pzj0r+4h2a5e7w+ow...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Dave,
It is certainly possible to do multiple acquisitions with different center
frequencies and stitch together the resulting FFTs to provide a broader
view. We have an example of doing this type of acquisition and FFT for the
TwinRX.
https://github.com/EttusResearch/uhd/blob/master/host/examples/twinrx_freq_hopping.cpp
It does not include a graphical frontend, but the GNU Radio vector sink
could be used with some code to aggregate multiple FFTs.
Regards,
Derek
On Thu, Apr 27, 2017 at 12:53 PM, Dave NotTelling via USRP-users <
[email protected]> wrote:
> Is there a way to do a 1 GHz sweep with the X310, N210, or B200 in the
> same way that you can with the HackRF? I need a way to characterize large
> bandwidths and stitching together FFTs seems like the easiest way to
> accomplish that.
>
> _______________________________________________
> 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/20170427/3cc69101/attachment-0001.html>
------------------------------
Message: 13
Date: Thu, 27 Apr 2017 08:54:47 +0000
From: Mihkel M <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] B210 GPS L1 receviver in Simulink
Message-ID:
<he1pr0402mb27156b31ebf54dc9134bf52dde...@he1pr0402mb2715.eurprd04.prod.outlook.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi.
My friend has project, where he has also couple of questions:
"I am trying to receive and play GPS L1 signal using Simulink and B210. For
observation I am using Ucenter 5.0. An active GPS antenna is used for
receiving. I am not sure what the receiver block parameters should be because
based on my calculations (decimation=master clock rate*sample time) I used
Fc=1.57542 Ghz, master clock rate 6.138Mhz, decimation is 6 and sample rate is
1/1023000. Should I use some additional blocks before saving the signal to
workspace and playing it back from workspace to the transmitter block? In
additon to that can someone please explain how IF is formulated using receiver
block parameters?"
Mihkel.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170427/6b5c24af/attachment-0001.html>
------------------------------
Message: 14
Date: Thu, 27 Apr 2017 14:21:30 +0100
From: Derek Kozel <[email protected]>
To: Juan Francisco <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] 10G BASE-T with x310
Message-ID:
<CAA+K=tvCvDqzAHUhZf4_fV1bso3eahzvqE-=xrmesz+uqms...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Juan,
Sorry for the long delay here. ProLabs 10G-SFPP-T-C.
On Thu, Mar 23, 2017 at 3:52 AM, Juan Francisco <[email protected]>
wrote:
> Derek,
>
> What adapter did you use to convert from SFP+ to 10GBaseT? I'm also
> interested in getting a configuration like this working.
>
> Thanks,
> Juan
>
> On Wed, Mar 22, 2017 at 1:47 PM, Derek Kozel via USRP-users <
> [email protected]> wrote:
>
>> Hello Jeff,
>>
>> I have such a system running on my desk. There are no changes required to
>> UHD or the FPGA images. I've done short term verification of 200 MS/s, but
>> not long term ones.
>>
>> Regards,
>> Derek
>>
>> On Wed, Mar 22, 2017 at 6:37 AM, Long, Jeffrey P. via USRP-users <
>> [email protected]> wrote:
>>
>>> Has anyone tried using 10G BASE-T with the x310 presumably using an SFP
>>> media adapter at the x310 side?
>>>
>>> Looking at building a system and there are some motherboard choices that
>>> have dual 10G BASE-T connections on them.
>>>
>>> I am trying to conserve PCI slots for other uses and would prefer to try
>>> to use this built in 10G capability if it works.
>>>
>>>
>>>
>>> Thanks
>>>
>>> Jeff
>>>
>>> _______________________________________________
>>> 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/20170427/97d2a794/attachment-0001.html>
------------------------------
Message: 15
Date: Thu, 27 Apr 2017 10:24:32 -0400
From: Dave NotTelling <[email protected]>
To: Derek Kozel <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Wide FFT Snapshots
Message-ID:
<CAK6GVuNgHaRtemipBDCTy6zUZ-hMQ_ydcO7U9cbvAdKhhx=-c...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Derek,
Thank you very much!
-Dave
On Thu, Apr 27, 2017 at 8:05 AM, Derek Kozel <[email protected]> wrote:
> Hello Dave,
>
> It is certainly possible to do multiple acquisitions with different center
> frequencies and stitch together the resulting FFTs to provide a broader
> view. We have an example of doing this type of acquisition and FFT for the
> TwinRX.
> https://github.com/EttusResearch/uhd/blob/master/
> host/examples/twinrx_freq_hopping.cpp
>
> It does not include a graphical frontend, but the GNU Radio vector sink
> could be used with some code to aggregate multiple FFTs.
>
> Regards,
> Derek
>
> On Thu, Apr 27, 2017 at 12:53 PM, Dave NotTelling via USRP-users <
> [email protected]> wrote:
>
>> Is there a way to do a 1 GHz sweep with the X310, N210, or B200 in the
>> same way that you can with the HackRF? I need a way to characterize large
>> bandwidths and stitching together FFTs seems like the easiest way to
>> accomplish that.
>>
>> _______________________________________________
>> 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/20170427/6490ecc8/attachment-0001.html>
------------------------------
Message: 16
Date: Thu, 27 Apr 2017 22:28:19 +0800 (CST)
From: "Lihua Ren" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] x310 rfnoc fpga code
Message-ID: <[email protected]>
Content-Type: text/plain; charset="gbk"
hi,
My design is as follows :in GNUradio, RFnoc: radio-->RFnoc: DDC ---> RFnoc:my
block,
in radio block, sampling rate :16.384MHz,
in DDC block ?input rate :16.384MHz,output rate :1.6384MHz,
I think the data rate in the FPGA code should be :1.6384MHz ?but the use of
ChipScope to see the data rate does not match.why?
,I would like to know the axis interface the i_valid cycle, and effective
time?
Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170427/a3281b2b/attachment-0001.html>
------------------------------
Message: 17
Date: Thu, 27 Apr 2017 15:38:16 +0100
From: Derek Kozel <[email protected]>
To: Lihua Ren <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] x310 rfnoc fpga code
Message-ID:
<CAA+K=ts=smc2lcyebp98cxdwwxwfa8tc0kgp5qzgggolkxa...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Lihua,
The X310 RFNoC Radio block will always have a sample rate of either 200
MS/s or 100 MS/s if using the TwinRX. If you look in the log messages you
will see a warning saying that the 16.384 MHz rate could not be set.
Regards,
Derek
On Thu, Apr 27, 2017 at 3:28 PM, Lihua Ren via USRP-users <
[email protected]> wrote:
> hi,
>
> My design is as follows :in GNUradio, RFnoc: radio-->RFnoc: DDC --->
> RFnoc:my block,
> in radio block, sampling rate :16.384MHz,
> in DDC block ?input rate :16.384MHz,output rate :1.6384MHz,
> I think the data rate in the FPGA code should be :1.6384MHz ?but the use
> of ChipScope to see the data rate does not match.why?
> ,I would like to know the axis interface the i_valid cycle,
> and effective time?
> Thanks.
>
>
>
>
> _______________________________________________
> 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/20170427/3f057a59/attachment-0001.html>
------------------------------
Message: 18
Date: Thu, 27 Apr 2017 10:19:13 -0500
From: Jonathon Pendlum <[email protected]>
To: Stephen Larew <[email protected]>
Cc: USRP-users <[email protected]>
Subject: Re: [USRP-users] Timeout on Chan 0
Message-ID:
<cagdo0us7z62sjvhtdntor6hw7dk_mpurtiy5dshoed7p594...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
You are correct on the normalization and I had that working very well in
simulation using floating point. However, after moving to the fixed point
implementation I noticed the sensitivity. If has been about two years since
I've looked at this, so bear with my fuzzy recollection, but I think the
issue was an intermediate value was getting saturated as the signal power
varied.
On Wed, Apr 26, 2017 at 7:32 PM, Stephen Larew <[email protected]> wrote:
> I am using two X310s. One is transmitting using the stock GNU Radio OFDM
> TX, which I understand includes the preamble for Schmidl & Cox synch. The
> other which is using the RFNOC Schmidl Cox synchroniser. I will verify
> that the GNU Radio ofdm_sync_sc_cfb block can sync correctly with over air
> and wire transmissions and report back.
>
> Doesn?t the SC timing metric, M(d) in the original paper, effectively do
> AGC for us? The denominator of M(d) normalizes the metric based on receive
> power, right?
>
> > On Apr 26, 2017, at 18:02, Jonathon Pendlum <[email protected]>
> wrote:
> >
> > Hi Stephen,
> >
> > The Schmidl Cox block does not output any samples unless it detects a
> preamble. While the timeouts sound bad, in this case it is perfectly
> reasonable. Have you tried creating the preamble in GNU Radio and testing
> against that? Also, when I last touched the Schmidl Cox block, performance
> was somewhat sensitive to gain and I had planned on adding some additional
> AGC to deal with it.
> >
> >
> >
> > Jonathon
> >
> >> On Wed, Apr 26, 2017 at 4:44 PM, Stephen Larew via USRP-users <
> [email protected]> wrote:
> >> Hi,
> >>
> >> I am trying to implement a schmidl cox synchroniser on X310 using the
> given RFNoC blocks. I have my grc flowgraph attached below, with the grc
> xml and uhd xml files. There were some errors regarding "offset " not being
> found which I had to change to the "delay" register. Everytime I run my
> top_block.py, I seem to get a timeout on chan 0 error, which after reading
> some previous emails on this list leads me to believe that some block is
> not producing data. Any suggestions on why this would be happening would be
> great!
> >>
> >> I am using the rfnoc-devel branch as I only have access to Vivado
> 2015.4.
> >>
> >> Thanks,
> >> -Stephen
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170427/bc9521c1/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 80, Issue 27
******************************************
