UHD's recv_frame_size for E100

GNU Radio
1

Unlike USRP1 over USB, it seems specifying the recv_frame_size on “args”
doesn’t have any effect on E100. I see get_max_recv_samps_per_packet()
always returning 506 and I see fragmented segements from recv() calls.
Is it
unadjustable for E100 or am I doing something wrong here?

Thanks,

Michael

2

On 04/25/2011 08:28 PM, Michael Dev wrote:

Unlike USRP1 over USB, it seems specifying the recv_frame_size on “args”
doesn’t have any effect on E100. I see get_max_recv_samps_per_packet()
always returning 506 and I see fragmented segements from recv() calls. Is it
unadjustable for E100 or am I doing something wrong here?

Due to the design of the fpga interface, the largest transfer between
the fpga and gpp is 2048 bytes. Beyond this, Josh will need to comment
:slight_smile:

Philip

3

On 04/25/2011 06:01 PM, Philip B. wrote:

On 04/25/2011 08:28 PM, Michael Dev wrote:

Unlike USRP1 over USB, it seems specifying the recv_frame_size on “args”
doesn’t have any effect on E100. I see get_max_recv_samps_per_packet()
always returning 506 and I see fragmented segements from recv() calls.
Is it
unadjustable for E100 or am I doing something wrong here?

Due to the design of the fpga interface, the largest transfer between
the fpga and gpp is 2048 bytes. Beyond this, Josh will need to comment :slight_smile:

I didnt put in the hooks to change the frame size. It should be possible
without too much fuss. Right now, the frame size defaults to the maximum
size of the kernel ring buffer frames, or optimized for bandwidth. This
hook would allow you to make the frames smaller (optimized for latency).
Is that what you are looking for?

-Josh

4

On 04/25/2011 06:34 PM, Michael Dev wrote:

Yes, improved latency with smaller frame size is what I’m looking for. 506
samples of buffering is pretty big for me. Also, being able to adjust the
frame size to a nice size for my app would mean I don’t have to have some
additional buffering code (and the code to ‘manufacture’ rx timestamps for
fragments that don’t come with timestamps) between the recv() call and
feeding the result to my app.

Can you try this branch:
http://code.ettus.com/redmine/ettus/projects/uhd/repository/show?rev=usrp_e100_frame_sizes

-Josh

5

It seg faults on me.
Opening USRP-E on /dev/usrp_e0
USRP-E100 clock control: 6
r_counter: 1
a_counter: 0
b_counter: 12
prescaler: 8
vco_divider: 2
chan_divider: 15
vco_rate: 1920.000000MHz
chan_rate: 960.000000MHz
out_rate: 64.000000MHz
[New LWP 847]
Program received signal SIGSEGV, Segmentation fault.
[Switching to LWP 847]
0x401ff524 in usrp_e100_impl::io_impl::recv_pirate_loop (this=0x92e20,
spawn_barrier=, clock_ctrl=…)
at /home/root/uhd-new/uhd/host/lib/usrp/usrp_e100/io_impl.cpp:116
116 managed_recv_buffer::sptr buff = this->data_xport->get_recv_buff();

6

Program received signal SIGSEGV, Segmentation fault.
[Switching to LWP 847]
0x401ff524 in usrp_e100_impl::io_impl::recv_pirate_loop (this=0x92e20,
spawn_barrier=, clock_ctrl=…)
at /home/root/uhd-new/uhd/host/lib/usrp/usrp_e100/io_impl.cpp:116
116 managed_recv_buffer::sptr buff = this->data_xport->get_recv_buff();

Whoops, missed a & and stored the wrong reference to the shared pointer.
Can you try this branch w/ fix (I ran it myself this time):
http://code.ettus.com/redmine/ettus/projects/uhd/repository/show?rev=usrp_e100_frame_sizes2

7

Yes, improved latency with smaller frame size is what I’m looking for.
506
samples of buffering is pretty big for me. Also, being able to adjust
the
frame size to a nice size for my app would mean I don’t have to have
some
additional buffering code (and the code to ‘manufacture’ rx timestamps
for
fragments that don’t come with timestamps) between the recv() call and
feeding the result to my app.

Michael

8

I was able to control the frame size with this build. That’s a good
start.
But my app is not able to demodulate the received signal like it used
to. It
works fine if I switch back to the regular libuhd. I double checked
everything and I don’t think it’s due to my code.
Another thing is that application of the “recv_frame_size” value is a
bit
off compared to the USB version. For example, with USB, when I specify
1536,
each packet will get me 1536/4 = 384 samples. For usrp-e with this
build, I
have to specify a number somewhat higher than 1536 to fit 384 samples.
It
may be due to the header size consideration? It would be good to have a
more
consistent application of this parameter if possible. Definitely not a
biggie though. :slight_smile:
Michael