I think we are moving in the right direction, I will try if I have some time
tomorrow, but most of my radios are in a space that is not easy to get to…
Last question is related to timespec, 0.1 seconds is not a large time, do you
reset the time on the usrp clock to zero anywehere?
That ti
I don't think the problem is in the metadata, unless I'm really doing it wrong.
I've tried the suggestion you put out earlier, modeling my code after the
example txrx_loopback_to_file. The first packet has a startofburst = true and
subsequent packets have the start_of_burst value and the has_tim
Ehh, I dont think that's an accurate description of what's going on...
Take a look at the 32-bit floating point definition:
https://en.wikipedia.org/wiki/Single-precision_floating-point_format The
wikipedia definition seems to be essentially what's going on here, with the
added twist that the out
I think some of the issue here as well is the tx_metadata.
For continuous streaming, the first packet ONLY should have startofburst = true…
Further packets after the first one should have startofburst = false, cuz they
really are not start of burst, they are continuations of the initial bu
Hi Jason,
I have the same under-run problem with my project. I use x310 as well. I
don't have a solution. I'll appreciate it if anyone can figure out what is
causing this.
Regards,
Edwin
Jason W Zheng via USRP-users 于2017年8月14日周一
下午2:42写道：
> Hi Robin, Marcus
>
>
> It makes no sense to me, th
Hi Robin, Marcus
It makes no sense to me, then why changing transmit to be on its own channel
(daughtercard) would cause the program to work.
// set up TX streams and threads
std::thread tx_threads[NUM_CHANNELS];
uhd::tx_streamer::sptr tx_streams[NUM_CHANNELS];
uhd::tx_metadata
Hi EJ,
Thanks for the pointers. Ok, I think I see now that float_to_iq module is
fixed point. Am I interpreting these lines of code correctly that put an
8-bit bound on the mantissa with a 2's complement sign bit, leaving the
remaining 8-bits for radix:
assign shift_val = (in[30:23] > 127)? (in[
Willing to bet significant money your tx thread is being put on the physical
processor that does not have your NIC card attached to it...
Then, all data must go over QPI between processors.
NUMA is not good for this.
You can experiment with affinity to make sure things are all on the same
p
On 08/14/2017 02:48 PM, Jason W Zheng wrote:
Hi Marcus, Robin,
I've set the tx_metadata, yet the issue still occurs. There are
constant streams of underruns when receiving and transmitting on the
same channel.
I've attached the code
One thing I notice, and forgive me if I'm just missing
Thanks for the advice, Michael!
I'll do some profiling for sure. It's been a while, but my first diagnoses
(which was very useful) was to use the gr performance monitoring tool to
visually see the buffer fullness for each block in the fg. In a naive
implementation, where I added "fill frames" earl
Hi Marcus, Robin,
I've set the tx_metadata, yet the issue still occurs. There are constant
streams of underruns when receiving and transmitting on the same channel.
I've attached the code
From: USRP-users on behalf of Marcus D.
Leech via USRP-users
Sent: Mo
Hi Frank,
The naming is a little inconsistent and needs cleaning up. The equalizer is
called "eq" and the demapper is called "ofdm_constellation_demapper". Note
that the rfnoc-ofdm branch is in an experimental state right as we are
actively trying to merge it into rfnoc-devel.
Jonathon
On Sun, A
I'm running on a server with 2 Intel Xeon E5-2650 v4, CPU is listed here:
https://ark.intel.com/products/91767/Intel-Xeon-Processor-E5-2650-v4-30M-Cache-2_20-GHz
The network card I'm using is the recommended Intel X520-DA2
I also have over 500 gigs of ram, so that is not an issue
I don't think m
On 08/14/2017 02:27 PM, Jason W Zheng via USRP-users wrote:
How should I set the tx metadata? My application will essentially
stream continuously.
Thanks,
Jason
From the tx_samples_from_file example code (which you should probably
study)
uhd::tx_metadata_t md;
md.start_of_burst
Ron is correct about the defaults.
USB 3.0 has a MTU of 1024 B on the bus and USB 2.0 has a MTU of 512 B, so
you might get something by reducing the send_frame_size to those values. I
recommend also increasing the num_send_frames to something like 256 if you
do. One thing to keep in mind is that
How should I set the tx metadata? My application will essentially stream
continuously.
Thanks,
Jason
From: ROBIN TORTORA
Sent: Monday, August 14, 2017 11:17:07 AM
To: Jason W Zheng via USRP-users; Jason W Zheng
Subject: Re: [USRP-users] Buffer underrun issue w
I dont see you setting the tx metadata object members to any values, so you are
essentially going to tx with default metadata IF there is a constructor that
initializes all the members to a consistent value...
> On August 14, 2017 at 1:56 PM Jason W Zheng via USRP-users
> wrote:
>
>
>
What are the specs on your computer? What type of 10GiG interface card
are you using?
On 2017-08-14 13:56, Jason W Zheng via USRP-users wrote:
> Since I haven't gotten a response in a week, I thought some source code might
> help. I've removed any buffer dependencies leaving just the receive
Since I haven't gotten a response in a week, I thought some source code might
help. I've removed any buffer dependencies leaving just the receive thread and
transmit thread. The receive thread is constant receiving to a buffer, while
the transmit thread is constantly transmitting 0s from another
Hi,
I'm interested in constructing a beamforming system using X310s, and try to
utilize the FPGA resources within the X310 USRP device.
After some searching and reading of the introduction materials on RFNoC, I am
still wondering whether is it possible for the RFNoC framework to scale to
sever
Hello.How to interrupt the transmission of a signal on a button and how to
generate a constant and not a specified amount of time ??
Tell me how the get_rx_stream function works and what arguments are passed
to it. I do not want to open the session every time.
I use Python API
_
Hello, I'm trying to run an RFNoC 802.11 receiver similar to the one
demonstrated at GRCon 2015 but I'm having a problem.
I'm having trouble running the RFNoC OFDM receiver in
gr-etts/examples/rfnoc/rfnoc_ofdm.grc
The problem occurs when I use the uhd_image_builder_gui.py to build an
image for th
Hi Andrew,
As far as I can tell, that particular verilog block implements a 32-bit
floating point to 16-bit fixed point conversion. The name may be a misnomer
because it does not actually break the input into I/Q channels.
For floating to fixed conversion in software, I usually refer to this
wiki
23 matches
Mail list logo
