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. [N210] AD9510 Configuration Issues (Galler Florian)
2. NEWSDR -- This Thursday/Friday at Tufts University (Neel Pandeya)
3. Typecasting CPU timestamp as uhd timestamp (Sumit Kumar)
4. Re: Typecasting CPU timestamp as uhd timestamp (Marcus M?ller)
5. [E310] - Destroy rx_streamer (Bobby Zovsky)
6. Re: Shifting frequencies (Rob Kossler)
7. Re: Shifting frequencies (Derek Kozel)
8. Re: GRC + RFNoC + Radio Loopback (Christophe ALEXANDRE)
9. Re: Shifting frequencies (Rob Kossler)
10. Re: Shifting frequencies ([email protected])
11. Gnuradio wideband processing speed (?????? ????)
12. Re: Gnuradio wideband processing speed (?????? ????)
----------------------------------------------------------------------
Message: 1
Date: Mon, 29 May 2017 13:13:56 +0000
From: Galler Florian <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] [N210] AD9510 Configuration Issues
Message-ID:
<ec5cecfcc50d094aa99030a3304ed49d71dc3...@ex2010dag1.emce.tuwien.ac.at>
Content-Type: text/plain; charset="us-ascii"
Hello all,
I am running the N210 with a custom developed Fpga image, because I needed the
full sampling rate of the ADC and DAC. However, I have problems with the
configuration of the AD9510. With my settings, it seems that the PLL of the
AD9510 needs 500ms to lock to the 10 MHz internal reference (5MHz PDF and 3mA
CP current as stated in the N2XX schematics). Sometime it takes even longer.
Could you please provide the register setting used with the UHD driver or other
working register settings?
I want to connect two USRPs with a MIMO cable and synchronize the sampling
clocks. Could you please give me tips how to configure the AD9510s.
I now have configured the master to provide a 100 MHz ref signal over the MIMO
cable. The clock switch (U18) of the slave is configured to the Mimo cable
input (clk_exp_in). The PLL's phase detector runs at 5 MHz and all other
settings like in the single unit case.
To check the synchronization I have connected a scope to the testclk output of
master and slave. I triggered on the clock of the master and activated
persistence. At first, it seems that the two clocks are synchronized (see
picture 1). However, after some time the phase lock is lost for short periods
of time, which can be seen in the persistent trace (see picture 2).
I also have tried to simulate/calculate the loop filter by ADIsim CLK but I
didn't managed to simulate the values of the schematic by entering the design
parameters (3kHz BW, 45 deg Phase margin with 5 MHz compare freq and 3mA CP
current).
Looking forward to your reply
Florian
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170529/8a7b93a9/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scope_2.png
Type: image/png
Size: 42024 bytes
Desc: scope_2.png
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170529/8a7b93a9/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scope_1.png
Type: image/png
Size: 42645 bytes
Desc: scope_1.png
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170529/8a7b93a9/attachment-0003.png>
------------------------------
Message: 2
Date: Mon, 29 May 2017 14:13:16 -0700
From: Neel Pandeya <[email protected]>
To: usrp-users <[email protected]>
Subject: [USRP-users] NEWSDR -- This Thursday/Friday at Tufts
University
Message-ID:
<cacaxmv9iao9xa-1mkuclxg-3zhnnxa84thetyrox8ksohzo...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
*********************************************************************
CALL-FOR-PARTICIPATION
*********************************************************************
NEWSDR 2017
New England Workshop on Software Defined Radio
Seventh-Annual
Evening Workshops
Thursday June 1
17:30 to 21:00
Day-Long Symposium
Friday June 2
08:00 to 16:00
Tufts University
Medford, MA, USA
http://www.sdr-boston.org/
Free Pre-Registration
*********************************************************************
INVITATION TO PARTICIPATE
You are cordially invited to the 2017 New England Workshop on
Software Defined Radio (NEWSDR 2017), which is the seventh installment
of an annual series of symposium and workshop events organized by
the Boston SDR User Group (SDR-Boston).
This year, NEWSDR will be held at Tufts University, and consists of
a day-long symposium on Friday, as well as several hands-on technical
workshops the evening before on Thursday. You are welcome to attend
either or both events, which are entirely free when pre-registering.
Attendance is typically about 100 people, and attendees are evenly
split between academia and industry.
*********************************************************************
EVENING WORKSHOPS
THURSDAY JUNE 1
17:00 to 21:00
Tufts University
Medford, Massachusetts
AGENDA
16:00 ? 17:30 Setup session for the Workshop Events (optional)
17:30 ? 21:00 Workshop Events
Two hands-on technical workshops are being offered in parallel:
* "SDR Using USRP E310 and Simulink"
by MathWorks
* "FPGA Programming on the USRP with the RFNoC Framework"
by Ettus Research
MathWorks and Ettus Research will each run a workshop on the evening
before the main event. Workshops are technical, practical, hands-on
activities in a group setting. Specific topics and further details
about the workshops is listed below. Attendance is free, but
pre-registration is required. Free pizza and soda will be provided.
*********************************************************************
DAY-LONG SYMPOSIUM
FRIDAY JUNE 2
08:00 to 16:00
Breed Memorial Hall
Tufts University
51 Winthrop Street
Medford, Massachusetts
AGENDA
07:30 to 08:00 Coffee and Light Refreshments
08:00 to 08:15 Welcome and Introduction
08:15 to 09:40 Sponsor Overview Presentations (20 minutes each)
09:40 to 10:15 Elevator-Pitch Oral Presentations
of Poster Presenters (2 minutes each)
10:15 to 10:45 Coffee, Attendee Networking, Poster Sessions,
Sponsor Exhibits, and Demos
10:45 to 11:45 Industry Tutorial Presentation by MediaTek USA:
"Prototyping Next Generation Wireless Devices"
11:45 to 13:00 Lunch and Attendee Networking
13:00 to 14:00 Keynote Presentation by Professor Dennis Roberson
14:00 to 14:30 Coffee, Attendee Networking, Poster Sessions,
Sponsor Exhibits, and Demos
14:30 to 15:30 Industry Tutorial Presentation by Analog Devices:
"ADALM-PLUTO SDR Prototyping with Matlab"
15:30 to 16:00 Closing Remarks, Best Poster Award, Announcements
Keynote Speaker:
* Professor Dennis Roberson, Illinois Institute of Technology
Technical Poster Presentations:
* Covering the recent work in SDR and cognitive radio technology
* Poster presentations are now being solicited
* See link at the bottom of this email to submit your abstract
Corporate Sponsors:
* Analog Devices
* Ettus Research
* MathWorks
* MediaTek USA
The symposium features plenary speakers, technical poster
presentation sessions, hardware and software demonstrations from the
event sponsors, and workshops from the event sponsors, all focusing
on recent work in SDR and cognitive radio technology. Free breakfast,
lunch, and coffee will be provided. Attendance is free, but advance
registration is required.
The symposium provides an excellent networking opportunity and a
terrific venue to exchange thoughts and ideas with other people
working in the SDR space.
*********************************************************************
WORKSHOP DESCRIPTION
SDR with E310 using Simulink
MathWorks
This tutorial focuses on demonstrating modeling SDR-based designs in
MATLAB and Simulink, and configuring and deploying on the USRP E310.
Topics presented will include modeling communication systems using
Simulink, implementing radio I/O with E310 and Simulink, and
prototyping deployment with real-time data via HW/SW co-design.
Prior knowledge of programming Xilinx Zynq SoCs with MATLAB and
Simulink, and knowledge of communications systems and hardware design
are prerequisites.
Outline:
Model Communication system using Simulink:
* Model and simulate RF signal chain and communication algorithms.
* Overview of Software Defined Radio concepts and workflows.
* Simulate a communication system that includes a transmitter,
AD9361 transceiver, channel, and receiver (RF test environment).
Implement Radio I/O with E310 SDR and Simulink:
* Verify the operation of baseband transceiver algorithm using real
data streamed from the AD9361 into MATLAB and Simulink.
* Overview of System objects and hardware platforms.
* Perform baseband processing in MATLAB and Simulink on received
signal.
* Verify algorithm performance for real data versus simulated data.
Hardware-Software Co-Design for Software:
* Split and deploy Tx/Rx algorithms to PL and PS.
* Overview of Zynq HW/SW co-design workflow.
* Implement transmitter and receiver on PL/PS using HW/SW co-design
workflow.
* Download generated code to the ARM & FPGA, and tune system
parameters in real-time operation via Simulink.
*********************************************************************
WORKSHOP DESCRIPTION
FPGA Programming on the USRP with the RFNoC Framework
Ettus Research
Ettus Research's RFNoC (RF Network-on-Chip) software is meant
to decrease the development time for experienced FPGA engineers
seeking to integrate IP into the USRP signal processing chain.
RFNoC is the architecture for USRP devices that use Xilinx 7-series
FPGAs (E310, E312, X300, X310). RFNoC is built around a packetized
network infrastructure in the FPGA that handles the transport of
control and sample data between the host CPU and the radio. Users
target their custom algorithms to the FPGA in the form of
Computation Engines (CE), which are processing blocks that attach to
this network. CEs act as independent nodes on the network that can
receive and transmit data to any other node (e.g., another CE, the
radio block, or the host CPU). Users can create modular,
FPGA-accelerated SDR applications by chaining CEs into a flow graph.
RFNoC is supported in UHD and GNU Radio. In this workshop, we will
present an interactive hands-on tutorial on RFNoC, including a
discussion on its design and capabilities, demonstrations of several
existing examples, and a walk-through on implementing a user-defined
CE and integrating the CE into GNU Radio.
Prerequisites:
* Attendees are expected to bring their own laptops to the workshop.
The laptop should have a minimum of 4 GB memory, 60 GB of free disk
space, one Ethernet port available, and one USB 3.0 port available.
* Attendees are expected to install VirtualBox 5.1.22 or newer.
All necessary USRP hardware will be provided in the workshop.
Attendees do not need to bring any USRP hardware.
*********************************************************************
REGISTRATION
* Pre-register for the Symposium, or for the Workshop, or both
* Pre-registration is required, but is completely free
* Pre-registration takes less than 5 minutes
* Pre-registration includes free meals at the event
* Parking available
* You must pre-register online
* Attendance, meals, parking are all limited, so please
pre-register online as soon as possible to secure your spot
* See link at the bottom of this announcement to pre-register online
*********************************************************************
LINKS
Attendee Pre-registration:
https://goo.gl/Oy99HU
Poster Abstract Submission:
https://goo.gl/pJohKn
*********************************************************************
ADDITIONAL INFORMATION
More information, and the event schedule,
for this event can be found at our website:
http://www.sdr-boston.org/
*********************************************************************
EOF
*********************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170529/e557feac/attachment-0001.html>
------------------------------
Message: 3
Date: Tue, 30 May 2017 06:17:32 +0200
From: Sumit Kumar <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Typecasting CPU timestamp as uhd timestamp
Message-ID:
<CAOExtcT4npEazJJkOX+ZS_=xtp7hp7t20nwxj9un9xo-h0j...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
I am putting this question based on my understanding (please correct if
wrong)
"uhd gives timestamp of the received samples. These timestamps are tagged
to the received samples in the FPGA itself and have nothing to do with CPU
time. "
If this is correct, then my main question is :
How to typecast/use the CPU timestamps as uhd timestamps.
For example, I want my wifi transceiver to send ACK , "X" time after the
initial sync has been achieved. I know the CPU timestamp when initial sync
is achieved(say "Y"). Now how shall I tell the transmitter to schedule
transmission at Y + X
Regards
--
--
Sumit kumar
Doctoral Student, UPMC
Eurecom, BIOT
France
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170530/98e6ba5b/attachment-0001.html>
------------------------------
Message: 4
Date: Tue, 30 May 2017 10:32:01 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Typecasting CPU timestamp as uhd timestamp
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Hi Sumit!
On 30.05.2017 06:17, Sumit Kumar via USRP-users wrote:
> Hi,
>
> I am putting this question based on my understanding (please correct
> if wrong)
>
> "uhd gives timestamp of the received samples. These timestamps are
> tagged to the received samples in the FPGA itself and have nothing to
> do with CPU time. "
>
Correct!
> If this is correct, then my main question is :
>
> How to typecast/use the CPU timestamps as uhd timestamps.
In the spirit of keeping these two independent clocks mentally separated:
Not at all.
So, technically, the answer is: The USRPs internally have a /tick
counter/, which increases once every master clock rate cycle. To the
software user, however, UHD uses uhd::time_spec_t, which allows you to
define time in full seconds (integer) + fractional seconds (float),
which gets converted to a tick number in UHD.
>
> For example, I want my wifi transceiver to send ACK , "X" time after
> the initial sync has been achieved. I know the CPU timestamp when
> initial sync is achieved(say "Y"). Now how shall I tell the
> transmitter to schedule transmission at Y + X
Don't do that, it won't work; mixing CPU and device clock is *pretty
much always* a bad idea. Always refer everything to the device time! If
you know which sample corresponds to the initial sync, then you know the
USRP time of the initial sync. You then just add X to that USRP time,
and use it as the transmit time.
Best regards,
Marcus
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170530/f0e8de8a/attachment-0001.html>
------------------------------
Message: 5
Date: Tue, 30 May 2017 12:00:48 +0000 (UTC)
From: Bobby Zovsky <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] [E310] - Destroy rx_streamer
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hello,
I am currently testing the USRP E312 to use it as a receiver.I want to be able
to trigger some RX process according specified tuning given as parameters.
My problem is that I am able to get a rx_streamer only once in my program.
You will find below an example on how I am using the UHD streamer and the error
returned by the program.
int main(void){??? device_addrs_t dev_addrs = device::find(device_addr_t());
??? usrp::mulit_usrp::sptr ettus_e312 = usrp::multi_usrp::make(dev_addrs[0]);
????uhd::stream_args_t stream_args(std::string("sc16"), std::string("sc16"));
??? std::cout << "getting rx streamer once... ";
??? rx_streamer::sptr rx_stream = ettus_e312->get_rx_stream(stream_args);???
std::cout << " OK" << std::endl;
??? usleep(1000000);
??? std::cout << "Reset" << std::endl;
??? rx_stream.reset();
??? usleep(1000000);
??? std::cout << "getting rx streamer twice... ";??? rx_stream =
ettus_e312->get_rx_stream(stream_args);??? std::cout << " OK" << std::endl;
??? return EXIT_SUCCESS;
}
This program compile properly, but during the second call to get_rx_stream()
the following assertion error is thrown:
terminate called after throwing an instance of 'uhd::assertion_error'???
what(): AssertionError: _send_entries_in_use.at(which_stream? <=
H2S_NUM_CMDS??? in uhd::transport::zero_copy_if::sptr
e300_fifo_interface_impl::_make_xport(size_t, const
uhd::transport::zero_copy_xport_params&, bool)??? at
/home/balister/release-4/build/tmp-glibc/work/armv7ahf-vfp-neon-oe-linux-arm-gnueabi/uhd/3.9.2-r0/uhd-3.9.2/lib/usrp/e300/e300_fifo_config.cpp:395Aborted
What am I doing wrong ? And how can I use rx_streamer multiple times ?
Thanks in advance.
Benjamin
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170530/a68b17c3/attachment-0001.html>
------------------------------
Message: 6
Date: Tue, 30 May 2017 08:51:41 -0400
From: Rob Kossler <[email protected]>
To: [email protected]
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Shifting frequencies
Message-ID:
<CAB__hTSWF9Bx5BtHRkWn7ZOy=F=cree+1wlztxst480wgsm...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Regarding #1, I have not personally implemented the digital tuning I
mentioned, but I think that you just need to set the value of lo_offset
such that lo_offset=desired_rf-desired_lo. Thus, if you want your LO at
99MHz and your RF signal at 100MHz, initialize tune_req(100e6,1e6). Then,
if you want to change your RF while leaving your LO the same, use
tune_req(105e6,6e6). You can use command timing if you want precise
control of the timing of this frequency change.
Regarding #2, the file format can be anything you want, really. Just
needs to match what the "playing application" wants. In the case of the
tx_samples_from_file example program, this application wants interleaved
I/Q samples (samp #1 real, samp #1 imag, samp #2 real, samp #2 imag, ...,
samp #N real, samp #N imag). The binary format of each element can be
either 2's complement integers (16 bit) or floating point values (4 byte or
8 byte). You just choose the appropriate file format option when you
execute tx_samples_from_file. In order to use this method, you need to be
comfortable generating baseband I/Q data files (using an
application/environment of your choice such as Matlab, Octave, python, C++,
etc) such that you know how to generate a tone and then create frequency
hops. If you are not confident in generating these baseband data files,
perhaps approach #1 would be easier.
Rob
On Mon, May 29, 2017 at 8:57 AM, <[email protected]> wrote:
> Hi!
>
> Thanks for you help! This sounds like something I need! I am still new to
> UHD and don't know how a lot of these things work.
>
> to 1) Do you mean changing the center frequency by something like this:
>
> uhd::tune_request_t tune_req(100e6, lo_offset);
> usrp->set_tx_freq(tune_req);
> send...
> uhd::tune_request_t tune_req(105e6, lo_offset);
> usrp->set_tx_freq(tune_req);
> send...
>
> I don't really know what the "lo_offset" is supposed to do. In the end,
> the first frequency is set as center frequency, isn't it?
>
> to 2) this sounds really useful. How do I generate this file? I tried to
> write the samples into a dat-file the same way as I write them into the
> buffer but this does not work. How does it have to look like?
>
> Thanks for you help!
>
> Mareike
>
>
>
> Zitat von Rob Kossler <[email protected]>:
>
>
> Hi Mareike,
>> I didn't look closely to know why your approach is not working. However,
>> perhaps there are two other approaches you might consider.
>> 1) perhaps you could use the FPGA to digitally change your frequency
>> (using
>> LO Offset)
>> 2) perhaps you could generate your entire desired waveform (including all
>> frequency changes) in a static baseband IQ waveform file. If this is
>> possible for your application, then perhaps you could just use
>> tx_samples_from_file without modification to send your waveform.
>>
>> Rob
>>
>>
>> On Wed, May 24, 2017 at 5:18 AM, hetzel--- via USRP-users <
>> [email protected]> wrote:
>>
>> Hi!
>>>
>>> I want to shift my output frequency. For example I set my center
>>> frequency
>>> at 100MHz and I want to send a varying frequency between 100 and 105
>>> MHz. I
>>> changed the tx_waveforms C++ code where I changed the frequency inside
>>> the
>>> while-loop:
>>>
>>> int i = 0;
>>> while (true) {
>>> i++;
>>> double count = static_cast<double>(i);
>>>
>>> if (stop_signal_called) break;
>>> if (total_num_samps > 0 and num_acc_samps >= total_num_samps)
>>> break;
>>>
>>> for (size_t n = 0; n < buff.size(); n++) {
>>> double convertn = static_cast<double>(n);
>>> shift[n] = (1.0 / buff.size() * convertn);
>>> buff[n] = 0.15 * exp(2.0 *im* M_PI* shift[n] * count);
>>> }
>>>
>>> num_acc_samps += tx_stream->send(
>>> buffs, buff.size(), md
>>> );
>>> }
>>>
>>> This was working fine and I could define the frequency range by adjusting
>>> the counter. But with higher sample rates or generating more frequencies
>>> I
>>> got a lot of underflows which I could solve for static frequencies by
>>> pre-calculating the buffer (outside the while-loop).
>>> Now I want to pre-calculate the varying frequencies. I tried to write
>>> them
>>> into an array like this:
>>>
>>> std::complex<float> buffer[spb][columns];
>>> ...
>>> for (size_t k = 0; k < columns; k++) {
>>> double convertn = static_cast<double>(k);
>>> shift[k] = (1.0 / columns* convertn);
>>>
>>> for (size_t n = 0; n < spb; n++) {
>>> double count = static_cast<double>(n);
>>> buffer[n][k] = 0.15 * exp(2.0 *im* M_PI* shift[k] *
>>> count);
>>> }
>>> }
>>> int m=0;
>>> while(true) {
>>> m++;
>>> std::vector<std::complex<float> *> buffers(channel_nums.size(),
>>> &buffer[0][m]);
>>> ...
>>> send(...);
>>> ...
>>> }
>>>
>>> But this is generating very strange output. Instead of sweeping the
>>> frequency it generates a lot of frequencies at the same time. I tried to
>>> find out what is happening and started with only one column which worked.
>>> But already with two columns there appeared additional peaks at +/- 10
>>> MHz
>>> with a sampling rate of 20MHz although I calculated and send only one
>>> column. I did this for a couple of numbers and it generated frequencies
>>> at
>>> +/-sample_rate/columns and multiples of that.
>>> Do you have any solution or idea how to pre-calculate the buffers? Is it
>>> possible to send parts of an array?
>>> Or is there a completely different way to sweep the frequencies?
>>>
>>> Best regards,
>>> Mareike
>>>
>>>
>>> _______________________________________________
>>> 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/20170530/e51158ce/attachment-0001.html>
------------------------------
Message: 7
Date: Tue, 30 May 2017 14:26:51 +0100
From: Derek Kozel <[email protected]>
To: Rob Kossler <[email protected]>
Cc: [email protected], "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] Shifting frequencies
Message-ID:
<CAA+K=tua4kdxrm4dx_rmdgwkdfnbgjv2ts9j7wa2mqxt1+o...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Hetzel and Rob,
The lo_offset should be the distance in hertz that you wish to move the RF
local oscillators from your target_frequency. UHD will automatically
calculate a DSP shift which is applied in the DDC. This shift will also
account for any error in the actual LO frequencies the synthesizers are
able to achieve. The true values can be read from the return value.
http://files.ettus.com/manual/page_general.html#general_tuning_process
Regards,
Derek
On Tue, May 30, 2017 at 1:51 PM, Rob Kossler via USRP-users <
[email protected]> wrote:
> Regarding #1, I have not personally implemented the digital tuning I
> mentioned, but I think that you just need to set the value of lo_offset
> such that lo_offset=desired_rf-desired_lo. Thus, if you want your LO at
> 99MHz and your RF signal at 100MHz, initialize tune_req(100e6,1e6). Then,
> if you want to change your RF while leaving your LO the same, use
> tune_req(105e6,6e6). You can use command timing if you want precise
> control of the timing of this frequency change.
>
> Regarding #2, the file format can be anything you want, really. Just
> needs to match what the "playing application" wants. In the case of the
> tx_samples_from_file example program, this application wants interleaved
> I/Q samples (samp #1 real, samp #1 imag, samp #2 real, samp #2 imag, ...,
> samp #N real, samp #N imag). The binary format of each element can be
> either 2's complement integers (16 bit) or floating point values (4 byte or
> 8 byte). You just choose the appropriate file format option when you
> execute tx_samples_from_file. In order to use this method, you need to be
> comfortable generating baseband I/Q data files (using an
> application/environment of your choice such as Matlab, Octave, python, C++,
> etc) such that you know how to generate a tone and then create frequency
> hops. If you are not confident in generating these baseband data files,
> perhaps approach #1 would be easier.
>
> Rob
>
> On Mon, May 29, 2017 at 8:57 AM, <[email protected]> wrote:
>
>> Hi!
>>
>> Thanks for you help! This sounds like something I need! I am still new to
>> UHD and don't know how a lot of these things work.
>>
>> to 1) Do you mean changing the center frequency by something like this:
>>
>> uhd::tune_request_t tune_req(100e6, lo_offset);
>> usrp->set_tx_freq(tune_req);
>> send...
>> uhd::tune_request_t tune_req(105e6, lo_offset);
>> usrp->set_tx_freq(tune_req);
>> send...
>>
>> I don't really know what the "lo_offset" is supposed to do. In the end,
>> the first frequency is set as center frequency, isn't it?
>>
>> to 2) this sounds really useful. How do I generate this file? I tried to
>> write the samples into a dat-file the same way as I write them into the
>> buffer but this does not work. How does it have to look like?
>>
>> Thanks for you help!
>>
>> Mareike
>>
>>
>>
>> Zitat von Rob Kossler <[email protected]>:
>>
>>
>> Hi Mareike,
>>> I didn't look closely to know why your approach is not working. However,
>>> perhaps there are two other approaches you might consider.
>>> 1) perhaps you could use the FPGA to digitally change your frequency
>>> (using
>>> LO Offset)
>>> 2) perhaps you could generate your entire desired waveform (including all
>>> frequency changes) in a static baseband IQ waveform file. If this is
>>> possible for your application, then perhaps you could just use
>>> tx_samples_from_file without modification to send your waveform.
>>>
>>> Rob
>>>
>>>
>>> On Wed, May 24, 2017 at 5:18 AM, hetzel--- via USRP-users <
>>> [email protected]> wrote:
>>>
>>> Hi!
>>>>
>>>> I want to shift my output frequency. For example I set my center
>>>> frequency
>>>> at 100MHz and I want to send a varying frequency between 100 and 105
>>>> MHz. I
>>>> changed the tx_waveforms C++ code where I changed the frequency inside
>>>> the
>>>> while-loop:
>>>>
>>>> int i = 0;
>>>> while (true) {
>>>> i++;
>>>> double count = static_cast<double>(i);
>>>>
>>>> if (stop_signal_called) break;
>>>> if (total_num_samps > 0 and num_acc_samps >= total_num_samps)
>>>> break;
>>>>
>>>> for (size_t n = 0; n < buff.size(); n++) {
>>>> double convertn = static_cast<double>(n);
>>>> shift[n] = (1.0 / buff.size() * convertn);
>>>> buff[n] = 0.15 * exp(2.0 *im* M_PI* shift[n] * count);
>>>> }
>>>>
>>>> num_acc_samps += tx_stream->send(
>>>> buffs, buff.size(), md
>>>> );
>>>> }
>>>>
>>>> This was working fine and I could define the frequency range by
>>>> adjusting
>>>> the counter. But with higher sample rates or generating more
>>>> frequencies I
>>>> got a lot of underflows which I could solve for static frequencies by
>>>> pre-calculating the buffer (outside the while-loop).
>>>> Now I want to pre-calculate the varying frequencies. I tried to write
>>>> them
>>>> into an array like this:
>>>>
>>>> std::complex<float> buffer[spb][columns];
>>>> ...
>>>> for (size_t k = 0; k < columns; k++) {
>>>> double convertn = static_cast<double>(k);
>>>> shift[k] = (1.0 / columns* convertn);
>>>>
>>>> for (size_t n = 0; n < spb; n++) {
>>>> double count = static_cast<double>(n);
>>>> buffer[n][k] = 0.15 * exp(2.0 *im* M_PI* shift[k] *
>>>> count);
>>>> }
>>>> }
>>>> int m=0;
>>>> while(true) {
>>>> m++;
>>>> std::vector<std::complex<float> *> buffers(channel_nums.size(),
>>>> &buffer[0][m]);
>>>> ...
>>>> send(...);
>>>> ...
>>>> }
>>>>
>>>> But this is generating very strange output. Instead of sweeping the
>>>> frequency it generates a lot of frequencies at the same time. I tried to
>>>> find out what is happening and started with only one column which
>>>> worked.
>>>> But already with two columns there appeared additional peaks at +/- 10
>>>> MHz
>>>> with a sampling rate of 20MHz although I calculated and send only one
>>>> column. I did this for a couple of numbers and it generated frequencies
>>>> at
>>>> +/-sample_rate/columns and multiples of that.
>>>> Do you have any solution or idea how to pre-calculate the buffers? Is it
>>>> possible to send parts of an array?
>>>> Or is there a completely different way to sweep the frequencies?
>>>>
>>>> Best regards,
>>>> Mareike
>>>>
>>>>
>>>> _______________________________________________
>>>> 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/20170530/d80138c6/attachment-0001.html>
------------------------------
Message: 8
Date: Tue, 30 May 2017 15:42:33 +0200
From: Christophe ALEXANDRE <[email protected]>
To: Nick Foster <[email protected]>, Jonathon Pendlum
<[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] GRC + RFNoC + Radio Loopback
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Hi Nick,
i have spent more time on your guide at :
https://corvid.io/2017/04/22/stupid-rfnoc-tricks-loopback/
i have tried :
step 1, approach 1, uhd solution
step 2, with GnuRadio
step 3, GRC + manual change in the flowgraph
After all the modifications, i have run pybombs to recompile
uhd and gr-ettus with the following command :
pybombs -p rfnoc rebuild uhd gr-ettus
i have made 2 tests (you will find attached 2 flowgraphs) :
A) Radio Rx -> Radio Tx loopback
B) Radio Rx -> DDC -> DUC -> Radio Tx loopback
The A test runs, but with a strange behavior.
1) i power on the x310
2) i run loopback_radio_radio.py
it starts with no errors, but doesn't work
when i stop the flowgraph, an error messages occurs :
fpga@elec58:~/Documents$ ./loopback_radio_radio.py
[INFO] [UHD] linux; GNU C++ version 4.8.4; Boost_105400;
UHD_4.0.0.rfnoc-devel-316-g24b98579
[INFO] [X300] X300 initialization sequence...
[INFO] [X300] Determining maximum frame size...
[INFO] [X300] Maximum frame size: 1472 bytes.
[INFO] [X300] Setup basic communication...
[INFO] [X300] Loading values from EEPROM...
[INFO] [X300] Setup RF frontend clocking...
[INFO] [X300] Radio 1x clock:200
[INFO] [X300] Detecting internal GPSDO....
[INFO] [GPS] No GPSDO found
[INFO] [RFNOC] [DMA FIFO] Running BIST for FIFO 0...
[INFO] [RFNOC] pass (Throughput: 1304.9MB/s)
[INFO] [RFNOC] [DMA FIFO] Running BIST for FIFO 1...
[INFO] [RFNOC] pass (Throughput: 1304.5MB/s)
[INFO] [RFNOC RADIO] Register loopback test passed
[INFO] [RFNOC RADIO] Register loopback test passed
[INFO] [RFNOC RADIO] Register loopback test passed
[INFO] [RFNOC RADIO] Register loopback test passed
[WARNING] [RFNOC] [0/SplitStream_0] defines 2 input buffer sizes, but 1
input ports
[INFO] [CORES] Performing timer loopback test...
[INFO] [CORES] Timer loopback test passed
[INFO] [CORES] Performing timer loopback test...
[INFO] [CORES] Timer loopback test passed
[WARNING] [X300 RADIO] set_tx_gain: could not apply gain for this
daughterboard.
[WARNING] [X300 RADIO] set_rx_gain: could not apply gain for this
daughterboard.
[INFO] [RFNOC] Assuming max packet size for 0/Radio_1
Press Enter to quit:
[ERROR] [UHD] Exception caught in safe-call.
in virtual ctrl_iface_impl::~ctrl_iface_impl()
at /home/fpga/rfnoc/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:76
this->peek32(0); -> EnvironmentError: IOError: Block ctrl
(CE_00_Port_30) packet parse error - EnvironmentError: IOError: Expected
SID: 02:30>00:00 Received SID: 02:50>00:00
3) i run loopback_radio_radio.py again
it start with no errors, and it works. Rx signal is copied on Tx
output, both leds are on
when i stop the flowgraph, the same error messages occurs.
Each time i want to run the flowgraph, i need to follow these steps.
the B test doesn't work. When i run the flowgraph
loopback_radio_ddc_duc_radio.py,
it starts with no errors, but doesn't work. When i stop it, i get the
same error than with the A test.
Do you have any idea ?
regards.
Christophe ALEXANDRE
Conservatoire National des Arts et M?tiers (CNAM)
Laboratoire CEDRIC-LAETITIA
EPN3 EEAM EASY
Acc?s 11B niveau -1
292 rue Saint Martin
75141 PARIS CEDEX 03
FRANCE
email : [email protected]
tel. 0140272699
mob. 0651087311
fax. 0140272994
Le 23/05/2017 ? 21:08, Nick Foster a ?crit :
> Christophe,
>
> This might be a dumb question, but If you followed Step 2 in the guide
> I wrote, did you also follow steps 1 & 3?
>
> --n
>
> On Tue, May 23, 2017 at 7:43 AM Jonathon Pendlum via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> Hi Christophe,
>
> Out of the box, all RFNoC flowgraphs require at least one
> connection back to the host. This is a limitation of UHD that we
> plan on fixing. That is also why your second flowgraph worked. We
> are having some discussions on making a block to allow loopback,
> but I can't give you any dates when that will be done. If you want
> to give it a try yourself, one possibility would be to make a
> custom rfnoc block with 2 inputs / 1 output. One of the inputs
> would be from the rx radio, the other a "dummy" connection from
> the host. The output would connect to the tx radio. The block
> would also need to adjust vita time or just strip it off the header.
>
>
>
> Jonathon
>
> On Tue, May 23, 2017 at 5:40 AM, Christophe ALEXANDRE via
> USRP-users <[email protected]
> <mailto:[email protected]>> wrote:
>
> Hi,
>
> i'm using an X310 with 2 BasicRx and 2 BasicTx and a fresh
> install of RFNoC.
>
> i'm trying to understand how i can use RFNoC with gnuradio
> companion
> and how i can mix gnuradio software blocks and RFNoC blocks.
>
> With the help of Ettus documentations, i think i understand
> the idea
> except in one case, when i try to use both Rx and Tx radio
> blocks (and i can't
> see any examples in ~rfnoc/src/gr-ettus/examples/rfnoc).
>
> My first test is a simple loopback :
>
>
>
>
> when i run this flowgraph, there is no errors, but nothing happens
> and the rf0 and rf1 leds are off. There is no signal copy
> from rf1:Rx2 to rf0:Tx.
>
> if i understand clearly the problem explained here :
>
> https://corvid.io/2017/04/22/stupid-rfnoc-tricks-loopback/
>
> this is a timestamp problem on the Tx side. I've tried to
> follow the proposed solution
> (Step 2: Enable Streamer), but without success.
>
> But if the flowgraph go back to the host doing nothing (add a
> 0 constant), it works
> (i suppose that gnuradio creates the necessary timestamps for
> the Tx side) :
>
>
>
>
> Leds are on and the input signal is going from rf1:Rx2 to rf0:Tx.
>
>
> Is there any better way to solve this problem ?
>
>
> regards.
>
>
> Christophe ALEXANDRE
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170530/696e8029/attachment-0001.html>
-------------- next part --------------
#!/usr/bin/env python2
# -*- coding: utf-8 -*-
##################################################
# GNU Radio Python Flow Graph
# Title: Loopback
# Generated: Tue May 30 14:29:20 2017
##################################################
from gnuradio import eng_notation
from gnuradio import gr
from gnuradio import uhd
from gnuradio.eng_option import eng_option
from gnuradio.filter import firdes
from optparse import OptionParser
import ettus
class loopback(gr.top_block):
def __init__(self):
gr.top_block.__init__(self, "Loopback")
##################################################
# Variables
##################################################
self.device3 = variable_uhd_device3_0 =
ettus.device3(uhd.device_addr_t( ",".join(('type=x300', "addr=192.168.10.2")) ))
self.samp_rate = samp_rate = 25e6
##################################################
# Blocks
##################################################
self.uhd_rfnoc_streamer_radio_1 = ettus.rfnoc_radio(
self.device3,
uhd.stream_args( # Tx Stream Args
cpu_format="fc32",
otw_format="sc16",
args='',
),
uhd.stream_args( # Rx Stream Args
cpu_format="fc32",
otw_format="sc16",
args="", # empty
),
0, 0
)
self.uhd_rfnoc_streamer_radio_1.set_rate(2e8)
for i in xrange(1):
self.uhd_rfnoc_streamer_radio_1.set_tx_freq(0, i)
self.uhd_rfnoc_streamer_radio_1.set_tx_gain(0, i)
self.uhd_rfnoc_streamer_radio_1.set_tx_dc_offset(True, i)
self.uhd_rfnoc_streamer_radio_1.set_tx_antenna("TX/RX", 0)
self.uhd_rfnoc_streamer_radio_0 = ettus.rfnoc_radio(
self.device3,
uhd.stream_args( # Tx Stream Args
cpu_format="fc32",
otw_format="sc16",
args="", # empty
),
uhd.stream_args( # Rx Stream Args
cpu_format="fc32",
otw_format="sc16",
args='',
),
1, -1
)
self.uhd_rfnoc_streamer_radio_0.set_rate(2e8)
for i in xrange(1):
self.uhd_rfnoc_streamer_radio_0.set_rx_freq(0, i)
self.uhd_rfnoc_streamer_radio_0.set_rx_gain(0, i)
self.uhd_rfnoc_streamer_radio_0.set_rx_dc_offset(True, i)
self.uhd_rfnoc_streamer_radio_0.set_rx_bandwidth(56e6, 0)
self.uhd_rfnoc_streamer_radio_0.set_rx_antenna("RX2", 0)
self.uhd_rfnoc_streamer_radio_0.set_rx_streamer(True, 0)
stream_cmd =
uhd.stream_cmd_t(uhd.stream_cmd_t.STREAM_MODE_START_CONTINUOUS)
self.uhd_rfnoc_streamer_radio_0.issue_stream_cmd(stream_cmd)
self.uhd_rfnoc_streamer_duc_0 = ettus.rfnoc_generic(
self.device3,
uhd.stream_args( # TX Stream Args
cpu_format="fc32", # TODO: This must be made an option
otw_format="sc16",
args="input_rate={},output_rate={},fullscale={},freq={}".format(samp_rate, 2e8,
1.0, 0.0),
),
uhd.stream_args( # RX Stream Args
cpu_format="fc32", # TODO: This must be made an option
otw_format="sc16",
args="",
),
"DUC", -1, -1,
)
self.uhd_rfnoc_streamer_ddc_0 = ettus.rfnoc_generic(
self.device3,
uhd.stream_args( # TX Stream Args
cpu_format="fc32", # TODO: This must be made an option
otw_format="sc16",
channels=range(1),
args="input_rate={},output_rate={},fullscale={},freq={}".format(2e8, samp_rate,
1.0, 0.0),
),
uhd.stream_args( # RX Stream Args
cpu_format="fc32", # TODO: This must be made an option
otw_format="sc16",
channels=range(1),
args="",
),
"DDC", 0, -1,
)
for chan in xrange(1):
self.uhd_rfnoc_streamer_ddc_0.set_arg("input_rate", float(2e8),
chan)
self.uhd_rfnoc_streamer_ddc_0.set_arg("output_rate",
float(samp_rate), chan)
self.uhd_rfnoc_streamer_ddc_0.set_arg("fullscale", 1.0, chan)
self.uhd_rfnoc_streamer_ddc_0.set_arg("freq", 0.0, chan)
##################################################
# Connections
##################################################
self.device3.connect(self.uhd_rfnoc_streamer_ddc_0.get_block_id(), 0,
self.uhd_rfnoc_streamer_duc_0.get_block_id(), 0)
self.device3.connect(self.uhd_rfnoc_streamer_duc_0.get_block_id(), 0,
self.uhd_rfnoc_streamer_radio_1.get_block_id(), 0)
self.device3.connect(self.uhd_rfnoc_streamer_radio_0.get_block_id(), 0,
self.uhd_rfnoc_streamer_ddc_0.get_block_id(), 0)
def get_variable_uhd_device3_0(self):
return self.variable_uhd_device3_0
def set_variable_uhd_device3_0(self, variable_uhd_device3_0):
self.variable_uhd_device3_0 = variable_uhd_device3_0
def get_samp_rate(self):
return self.samp_rate
def set_samp_rate(self, samp_rate):
self.samp_rate = samp_rate
self.uhd_rfnoc_streamer_duc_0.set_arg("input_rate",
float(self.samp_rate))
for i in xrange(1):
self.uhd_rfnoc_streamer_ddc_0.set_arg("output_rate",
float(self.samp_rate), i)
def main(top_block_cls=loopback, options=None):
tb = top_block_cls()
tb.start()
try:
raw_input('Press Enter to quit: ')
except EOFError:
pass
tb.stop()
tb.wait()
if __name__ == '__main__':
main()
-------------- next part --------------
#!/usr/bin/env python2
# -*- coding: utf-8 -*-
##################################################
# GNU Radio Python Flow Graph
# Title: Loopback
# Generated: Tue May 30 11:48:26 2017
##################################################
from gnuradio import eng_notation
from gnuradio import gr
from gnuradio import uhd
from gnuradio.eng_option import eng_option
from gnuradio.filter import firdes
from optparse import OptionParser
import ettus
class loopback(gr.top_block):
def __init__(self):
gr.top_block.__init__(self, "Loopback")
##################################################
# Variables
##################################################
self.device3 = variable_uhd_device3_0 =
ettus.device3(uhd.device_addr_t( ",".join(('type=x300', "addr=192.168.10.2")) ))
self.samp_rate = samp_rate = 25e6
##################################################
# Blocks
##################################################
self.uhd_rfnoc_streamer_radio_1 = ettus.rfnoc_radio(
self.device3,
uhd.stream_args( # Tx Stream Args
cpu_format="fc32",
otw_format="sc16",
args='',
),
uhd.stream_args( # Rx Stream Args
cpu_format="fc32",
otw_format="sc16",
args="", # empty
),
0, 0
)
self.uhd_rfnoc_streamer_radio_1.set_rate(2e8)
for i in xrange(1):
self.uhd_rfnoc_streamer_radio_1.set_tx_freq(0, i)
self.uhd_rfnoc_streamer_radio_1.set_tx_gain(0, i)
self.uhd_rfnoc_streamer_radio_1.set_tx_dc_offset(True, i)
self.uhd_rfnoc_streamer_radio_1.set_tx_antenna("TX/RX", 0)
self.uhd_rfnoc_streamer_radio_0 = ettus.rfnoc_radio(
self.device3,
uhd.stream_args( # Tx Stream Args
cpu_format="fc32",
otw_format="sc16",
args="", # empty
),
uhd.stream_args( # Rx Stream Args
cpu_format="fc32",
otw_format="sc16",
args='',
),
1, -1
)
self.uhd_rfnoc_streamer_radio_0.set_rate(2e8)
for i in xrange(1):
self.uhd_rfnoc_streamer_radio_0.set_rx_freq(0, i)
self.uhd_rfnoc_streamer_radio_0.set_rx_gain(0, i)
self.uhd_rfnoc_streamer_radio_0.set_rx_dc_offset(True, i)
self.uhd_rfnoc_streamer_radio_0.set_rx_bandwidth(56e6, 0)
self.uhd_rfnoc_streamer_radio_0.set_rx_antenna("RX2", 0)
self.uhd_rfnoc_streamer_radio_0.set_rx_streamer(True, 0)
stream_cmd =
uhd.stream_cmd_t(uhd.stream_cmd_t.STREAM_MODE_START_CONTINUOUS)
self.uhd_rfnoc_streamer_radio_0.issue_stream_cmd(stream_cmd)
##################################################
# Connections
##################################################
self.device3.connect(self.uhd_rfnoc_streamer_radio_0.get_block_id(), 0,
self.uhd_rfnoc_streamer_radio_1.get_block_id(), 0)
def get_variable_uhd_device3_0(self):
return self.variable_uhd_device3_0
def set_variable_uhd_device3_0(self, variable_uhd_device3_0):
self.variable_uhd_device3_0 = variable_uhd_device3_0
def get_samp_rate(self):
return self.samp_rate
def set_samp_rate(self, samp_rate):
self.samp_rate = samp_rate
def main(top_block_cls=loopback, options=None):
tb = top_block_cls()
tb.start()
try:
raw_input('Press Enter to quit: ')
except EOFError:
pass
tb.stop()
tb.wait()
if __name__ == '__main__':
main()
------------------------------
Message: 9
Date: Tue, 30 May 2017 09:58:57 -0400
From: Rob Kossler <[email protected]>
To: Derek Kozel <[email protected]>
Cc: [email protected], "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] Shifting frequencies
Message-ID:
<cab__htrpk-e4rvzqgbtzkpcwb2kx+yh3xn5enj13ndv3jer...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks Derek,
So, it seems like I had the wrong sign for the LO in my last email such
that if you want your LO at 99MHz and your RF signal at 100MHz, you should
initialize tune_req(100e6,-1e6).
I looked at the link you sent, but there is not much information to help
someone who wants to implement digital tuning (keeping LO at fixed freq).
Are there any examples or other documentation describing the way to do this?
Rob
On Tue, May 30, 2017 at 9:26 AM, Derek Kozel <[email protected]> wrote:
> Hello Hetzel and Rob,
>
> The lo_offset should be the distance in hertz that you wish to move the RF
> local oscillators from your target_frequency. UHD will automatically
> calculate a DSP shift which is applied in the DDC. This shift will also
> account for any error in the actual LO frequencies the synthesizers are
> able to achieve. The true values can be read from the return value.
> http://files.ettus.com/manual/page_general.html#general_tuning_process
>
> Regards,
> Derek
>
> On Tue, May 30, 2017 at 1:51 PM, Rob Kossler via USRP-users <
> [email protected]> wrote:
>
>> Regarding #1, I have not personally implemented the digital tuning I
>> mentioned, but I think that you just need to set the value of lo_offset
>> such that lo_offset=desired_rf-desired_lo. Thus, if you want your LO at
>> 99MHz and your RF signal at 100MHz, initialize tune_req(100e6,1e6). Then,
>> if you want to change your RF while leaving your LO the same, use
>> tune_req(105e6,6e6). You can use command timing if you want precise
>> control of the timing of this frequency change.
>>
>> Regarding #2, the file format can be anything you want, really. Just
>> needs to match what the "playing application" wants. In the case of the
>> tx_samples_from_file example program, this application wants interleaved
>> I/Q samples (samp #1 real, samp #1 imag, samp #2 real, samp #2 imag, ...,
>> samp #N real, samp #N imag). The binary format of each element can be
>> either 2's complement integers (16 bit) or floating point values (4 byte or
>> 8 byte). You just choose the appropriate file format option when you
>> execute tx_samples_from_file. In order to use this method, you need to be
>> comfortable generating baseband I/Q data files (using an
>> application/environment of your choice such as Matlab, Octave, python, C++,
>> etc) such that you know how to generate a tone and then create frequency
>> hops. If you are not confident in generating these baseband data files,
>> perhaps approach #1 would be easier.
>>
>> Rob
>>
>> On Mon, May 29, 2017 at 8:57 AM, <[email protected]> wrote:
>>
>>> Hi!
>>>
>>> Thanks for you help! This sounds like something I need! I am still new
>>> to UHD and don't know how a lot of these things work.
>>>
>>> to 1) Do you mean changing the center frequency by something like this:
>>>
>>> uhd::tune_request_t tune_req(100e6, lo_offset);
>>> usrp->set_tx_freq(tune_req);
>>> send...
>>> uhd::tune_request_t tune_req(105e6, lo_offset);
>>> usrp->set_tx_freq(tune_req);
>>> send...
>>>
>>> I don't really know what the "lo_offset" is supposed to do. In the end,
>>> the first frequency is set as center frequency, isn't it?
>>>
>>> to 2) this sounds really useful. How do I generate this file? I tried to
>>> write the samples into a dat-file the same way as I write them into the
>>> buffer but this does not work. How does it have to look like?
>>>
>>> Thanks for you help!
>>>
>>> Mareike
>>>
>>>
>>>
>>> Zitat von Rob Kossler <[email protected]>:
>>>
>>>
>>> Hi Mareike,
>>>> I didn't look closely to know why your approach is not working.
>>>> However,
>>>> perhaps there are two other approaches you might consider.
>>>> 1) perhaps you could use the FPGA to digitally change your frequency
>>>> (using
>>>> LO Offset)
>>>> 2) perhaps you could generate your entire desired waveform (including
>>>> all
>>>> frequency changes) in a static baseband IQ waveform file. If this is
>>>> possible for your application, then perhaps you could just use
>>>> tx_samples_from_file without modification to send your waveform.
>>>>
>>>> Rob
>>>>
>>>>
>>>> On Wed, May 24, 2017 at 5:18 AM, hetzel--- via USRP-users <
>>>> [email protected]> wrote:
>>>>
>>>> Hi!
>>>>>
>>>>> I want to shift my output frequency. For example I set my center
>>>>> frequency
>>>>> at 100MHz and I want to send a varying frequency between 100 and 105
>>>>> MHz. I
>>>>> changed the tx_waveforms C++ code where I changed the frequency inside
>>>>> the
>>>>> while-loop:
>>>>>
>>>>> int i = 0;
>>>>> while (true) {
>>>>> i++;
>>>>> double count = static_cast<double>(i);
>>>>>
>>>>> if (stop_signal_called) break;
>>>>> if (total_num_samps > 0 and num_acc_samps >= total_num_samps)
>>>>> break;
>>>>>
>>>>> for (size_t n = 0; n < buff.size(); n++) {
>>>>> double convertn = static_cast<double>(n);
>>>>> shift[n] = (1.0 / buff.size() * convertn);
>>>>> buff[n] = 0.15 * exp(2.0 *im* M_PI* shift[n] * count);
>>>>> }
>>>>>
>>>>> num_acc_samps += tx_stream->send(
>>>>> buffs, buff.size(), md
>>>>> );
>>>>> }
>>>>>
>>>>> This was working fine and I could define the frequency range by
>>>>> adjusting
>>>>> the counter. But with higher sample rates or generating more
>>>>> frequencies I
>>>>> got a lot of underflows which I could solve for static frequencies by
>>>>> pre-calculating the buffer (outside the while-loop).
>>>>> Now I want to pre-calculate the varying frequencies. I tried to write
>>>>> them
>>>>> into an array like this:
>>>>>
>>>>> std::complex<float> buffer[spb][columns];
>>>>> ...
>>>>> for (size_t k = 0; k < columns; k++) {
>>>>> double convertn = static_cast<double>(k);
>>>>> shift[k] = (1.0 / columns* convertn);
>>>>>
>>>>> for (size_t n = 0; n < spb; n++) {
>>>>> double count = static_cast<double>(n);
>>>>> buffer[n][k] = 0.15 * exp(2.0 *im* M_PI* shift[k] *
>>>>> count);
>>>>> }
>>>>> }
>>>>> int m=0;
>>>>> while(true) {
>>>>> m++;
>>>>> std::vector<std::complex<float> *>
>>>>> buffers(channel_nums.size(),
>>>>> &buffer[0][m]);
>>>>> ...
>>>>> send(...);
>>>>> ...
>>>>> }
>>>>>
>>>>> But this is generating very strange output. Instead of sweeping the
>>>>> frequency it generates a lot of frequencies at the same time. I tried
>>>>> to
>>>>> find out what is happening and started with only one column which
>>>>> worked.
>>>>> But already with two columns there appeared additional peaks at +/- 10
>>>>> MHz
>>>>> with a sampling rate of 20MHz although I calculated and send only one
>>>>> column. I did this for a couple of numbers and it generated
>>>>> frequencies at
>>>>> +/-sample_rate/columns and multiples of that.
>>>>> Do you have any solution or idea how to pre-calculate the buffers? Is
>>>>> it
>>>>> possible to send parts of an array?
>>>>> Or is there a completely different way to sweep the frequencies?
>>>>>
>>>>> Best regards,
>>>>> Mareike
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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/20170530/fc5c94b0/attachment-0001.html>
------------------------------
Message: 10
Date: Tue, 30 May 2017 10:19:29 -0400
From: [email protected]
To: Rob Kossler <[email protected]>
Cc: Derek Kozel <[email protected]>, [email protected]
Subject: Re: [USRP-users] Shifting frequencies
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
There's also:
http://files.ettus.com/manual/structuhd_1_1tune__request__t.html
On 2017-05-30 09:58, Rob Kossler via USRP-users wrote:
> Thanks Derek,
> So, it seems like I had the wrong sign for the LO in my last email such that
> if you want your LO at 99MHz and your RF signal at 100MHz, you should
> initialize tune_req(100e6,-1e6).
>
> I looked at the link you sent, but there is not much information to help
> someone who wants to implement digital tuning (keeping LO at fixed freq).
> Are there any examples or other documentation describing the way to do this?
>
> Rob
>
> On Tue, May 30, 2017 at 9:26 AM, Derek Kozel <[email protected]> wrote:
>
> Hello Hetzel and Rob,
>
> The lo_offset should be the distance in hertz that you wish to move the RF
> local oscillators from your target_frequency. UHD will automatically
> calculate a DSP shift which is applied in the DDC. This shift will also
> account for any error in the actual LO frequencies the synthesizers are able
> to achieve. The true values can be read from the return value.
> http://files.ettus.com/manual/page_general.html#general_tuning_process [1]
>
> Regards, Derek
>
> On Tue, May 30, 2017 at 1:51 PM, Rob Kossler via USRP-users
> <[email protected]> wrote:
>
> Regarding #1, I have not personally implemented the digital tuning I
> mentioned, but I think that you just need to set the value of lo_offset such
> that lo_offset=desired_rf-desired_lo. Thus, if you want your LO at 99MHz and
> your RF signal at 100MHz, initialize tune_req(100e6,1e6). Then, if you want
> to change your RF while leaving your LO the same, use tune_req(105e6,6e6).
> You can use command timing if you want precise control of the timing of this
> frequency change.
>
> Regarding #2, the file format can be anything you want, really. Just needs
> to match what the "playing application" wants. In the case of the
> tx_samples_from_file example program, this application wants interleaved I/Q
> samples (samp #1 real, samp #1 imag, samp #2 real, samp #2 imag, ..., samp #N
> real, samp #N imag). The binary format of each element can be either 2's
> complement integers (16 bit) or floating point values (4 byte or 8 byte).
> You just choose the appropriate file format option when you execute
> tx_samples_from_file. In order to use this method, you need to be
> comfortable generating baseband I/Q data files (using an
> application/environment of your choice such as Matlab, Octave, python, C++,
> etc) such that you know how to generate a tone and then create frequency
> hops. If you are not confident in generating these baseband data files,
> perhaps approach #1 would be easier.
>
> Rob
>
> On Mon, May 29, 2017 at 8:57 AM, <[email protected]> wrote:
> Hi!
>
> Thanks for you help! This sounds like something I need! I am still new to UHD
> and don't know how a lot of these things work.
>
> to 1) Do you mean changing the center frequency by something like this:
>
> uhd::tune_request_t tune_req(100e6, lo_offset);
> usrp->set_tx_freq(tune_req);
> send...
> uhd::tune_request_t tune_req(105e6, lo_offset);
> usrp->set_tx_freq(tune_req);
> send...
>
> I don't really know what the "lo_offset" is supposed to do. In the end, the
> first frequency is set as center frequency, isn't it?
>
> to 2) this sounds really useful. How do I generate this file? I tried to
> write the samples into a dat-file the same way as I write them into the
> buffer but this does not work. How does it have to look like?
>
> Thanks for you help!
>
> Mareike
>
> Zitat von Rob Kossler <[email protected]>:
>
> Hi Mareike,
> I didn't look closely to know why your approach is not working. However,
> perhaps there are two other approaches you might consider.
> 1) perhaps you could use the FPGA to digitally change your frequency (using
> LO Offset)
> 2) perhaps you could generate your entire desired waveform (including all
> frequency changes) in a static baseband IQ waveform file. If this is
> possible for your application, then perhaps you could just use
> tx_samples_from_file without modification to send your waveform.
>
> Rob
>
> On Wed, May 24, 2017 at 5:18 AM, hetzel--- via USRP-users <
> [email protected]> wrote:
>
> Hi!
>
> I want to shift my output frequency. For example I set my center frequency
> at 100MHz and I want to send a varying frequency between 100 and 105 MHz. I
> changed the tx_waveforms C++ code where I changed the frequency inside the
> while-loop:
>
> int i = 0;
> while (true) {
> i++;
> double count = static_cast<double>(i);
>
> if (stop_signal_called) break;
> if (total_num_samps > 0 and num_acc_samps >= total_num_samps)
> break;
>
> for (size_t n = 0; n < buff.size(); n++) {
> double convertn = static_cast<double>(n);
> shift[n] = (1.0 / buff.size() * convertn);
> buff[n] = 0.15 * exp(2.0 *im* M_PI* shift[n] * count);
> }
>
> num_acc_samps += tx_stream->send(
> buffs, buff.size(), md
> );
> }
>
> This was working fine and I could define the frequency range by adjusting
> the counter. But with higher sample rates or generating more frequencies I
> got a lot of underflows which I could solve for static frequencies by
> pre-calculating the buffer (outside the while-loop).
> Now I want to pre-calculate the varying frequencies. I tried to write them
> into an array like this:
>
> std::complex<float> buffer[spb][columns];
> ...
> for (size_t k = 0; k < columns; k++) {
> double convertn = static_cast<double>(k);
> shift[k] = (1.0 / columns* convertn);
>
> for (size_t n = 0; n < spb; n++) {
> double count = static_cast<double>(n);
> buffer[n][k] = 0.15 * exp(2.0 *im* M_PI* shift[k] * count);
> }
> }
> int m=0;
> while(true) {
> m++;
> std::vector<std::complex<float> *> buffers(channel_nums.size(),
> &buffer[0][m]);
> ...
> send(...);
> ...
> }
>
> But this is generating very strange output. Instead of sweeping the
> frequency it generates a lot of frequencies at the same time. I tried to
> find out what is happening and started with only one column which worked.
> But already with two columns there appeared additional peaks at +/- 10 MHz
> with a sampling rate of 20MHz although I calculated and send only one
> column. I did this for a couple of numbers and it generated frequencies at
> +/-sample_rate/columns and multiples of that.
> Do you have any solution or idea how to pre-calculate the buffers? Is it
> possible to send parts of an array?
> Or is there a completely different way to sweep the frequencies?
>
> Best regards,
> Mareike
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [2]
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [2]
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Links:
------
[1]
http://files.ettus.com/manual/page_general.html#general_tuning_process
[2] 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/20170530/83dee1c6/attachment-0001.html>
------------------------------
Message: 11
Date: Tue, 30 May 2017 17:54:48 +0300
From: ?????? ???? <[email protected]>
To: [email protected]
Subject: [USRP-users] Gnuradio wideband processing speed
Message-ID:
<CABh6qSTEswj6msYRkZ-k2Tra1bnti60QO3kPuOks_mKQuGY7=w...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
My goal is to cut out several channels (10-30, 100e3 each) from a wide band
with a width of 40e6 and write them into files at real-time / or pass they
immediately into another flowgraph.
The gnuradio's USRPSurce already at a sample in ~10e6 gave out buffer
overflow ("OOOOO..."), therefore its use has been immediately rejected. Next,
I wrote the code that interacts directly with uhd and writes the results
directly into the RAM (tmpfs) - I got rid of the overflow, but now faced
the task of how to transfer data to gnuradio for further processing. Now
I'm using FIFO and, on the side of the gnuradio i have an ordinary "file
source" for reading from fifo. As a result, I again get overflows - gnuradio
simply can not cope with the processing of so much data. Some cores are
completely overloaded, realtime scheduling in flowgraph is turned ON.
I get overflow even on this scheme:
file_source->controlled_rotator->polyphase_arbitrary_resampler->fosphor_sink
The only one flow-graph in which I managed to avoid overflows:
file_source->null_sink =)
Probably the main issue is my sincere surprise that the 40-th core
processor can not cope with such a task.
1 Is there a way to "optimize" the gnuradio?)
2 Or does it make sense to write my own "implementation" of the all
functionality I need from the gnuradio for optimization purposes?
3 Is it rare to work with 40e6 or more?
Thank you in advance,
Anik
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170530/8adf8ecd/attachment-0001.html>
------------------------------
Message: 12
Date: Tue, 30 May 2017 18:15:54 +0300
From: ?????? ???? <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Gnuradio wideband processing speed
Message-ID:
<cabh6qsrpng5xxuare-w520kgzhdan3g2vd6uwkkfvvcuhyu...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Ahh, sorry, forgot about throttle block. It reduces the number of
overflows, but does not get rid of them.
As additional info:
i used samples_per_buffer = 10000,
wire_format = sc12,
in /etc/security/limits.conf i added this line: @usrp - rtprio 99
2017-05-30 17:54 GMT+03:00 ?????? ???? <[email protected]>:
> Hi,
>
> My goal is to cut out several channels (10-30, 100e3 each) from a wide
> band with a width of 40e6 and write them into files at real-time / or
> pass they immediately into another flowgraph.
> The gnuradio's USRPSurce already at a sample in ~10e6 gave out buffer
> overflow ("OOOOO..."), therefore its use has been immediately rejected. Next,
> I wrote the code that interacts directly with uhd and writes the results
> directly into the RAM (tmpfs) - I got rid of the overflow, but now faced
> the task of how to transfer data to gnuradio for further processing. Now
> I'm using FIFO and, on the side of the gnuradio i have an ordinary "file
> source" for reading from fifo. As a result, I again get overflows - gnuradio
> simply can not cope with the processing of so much data. Some cores are
> completely overloaded, realtime scheduling in flowgraph is turned ON.
> I get overflow even on this scheme: file_source->controlled_
> rotator->polyphase_arbitrary_resampler->fosphor_sink
> The only one flow-graph in which I managed to avoid overflows:
> file_source->null_sink =)
>
> Probably the main issue is my sincere surprise that the 40-th core
> processor can not cope with such a task.
>
> 1 Is there a way to "optimize" the gnuradio?)
> 2 Or does it make sense to write my own "implementation" of the all
> functionality I need from the gnuradio for optimization purposes?
> 3 Is it rare to work with 40e6 or more?
>
> Thank you in advance,
>
> Anik
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170530/aeb39c71/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 81, Issue 30
******************************************
