Hi folks,
I tried to TX a FM modulated signal using USRP2 BasicTX.
The signal was a 440 Hz sinusoid, and the carrier 1 MHz.
I used the signal generator and fm modulator blocks provided by
GNURadio.
When I tx it the follow message appeared on the screen:
USRP2::Tx_RAW: FIXME: short packet: 1 item (32 bytes)
Sometimes the item number changes to 4 or 8…
What that mean?
I took a look at the usrp2_impl.cc (last revision) and i couldn’t
identify any problem…
Any suggestion is welcome.
Regards,
Ronaldo
On Tue, Mar 24, 2009 at 04:03:36PM -0300, Ronaldo N. wrote:
Sometimes the item number changes to 4 or 8…
What that mean?
I took a look at the usrp2_impl.cc (last revision) and i couldn’t
identify any problem…
Any suggestion is welcome.
Regards,
Ronaldo
Hi Ronaldo,
There’s a bug in the on-the-wire format for the USRP2 where we’re not
currently transmitting the valid length of the packet. With ethernet,
the minimum packet size is 64-bytes, and there are some times where
the host code is naively fragmenting the received samples in a way
that produces a packet that is too short for ethernet.
I’ve opened ticket:378 on this. It will be properly fixed when we
rework the on-the-wire format as part of the VRT work, but I think
there’s an intermediate step that can avoid most cases of the problem
happening. I’m not sure that I can find time to fix this in time for
3.2.0, but if you’d like to take a look at it, we’d love a patch for
it. What needs to happen is that the loop in usrp2_impl.cc(tx_raw)
that fragments the nitems items needs to be a little smarter about
breaking the items into ethernet frames. Each piece needs to be
between 9 and U2_MAX_SAMPLES samples long. (9 works out to the
smallest number of samples that plus the headers ends up being >= 64
bytes).
Eric
On Wed, Mar 25, 2009 at 11:30 AM, Eric B. [email protected] wrote:
There’s a bug in the on-the-wire format for the USRP2 where we’re not
currently transmitting the valid length of the packet. With ethernet,
the minimum packet size is 64-bytes, and there are some times where
the host code is naively fragmenting the received samples in a way
that produces a packet that is too short for ethernet.
I’ve opened ticket:378 on this. It will be properly fixed when we
rework the on-the-wire format as part of the VRT work, but I think
there’s an intermediate step that can avoid most cases of the problem
happening.
I had planned to at least temporarily work around this for gr-usrp by
avoiding passing flowgraph data to libusrp2 that would result in these
short fragments. This wouldn’t fix things for low-level libusrp2
users, but it’s a small change that would get us by until the real fix
with the new VRT transport work. Let me know if this is an issue.
Johnathan
On Wed, Mar 25, 2009 at 12:09:36PM -0700, Johnathan C. wrote:
there’s an intermediate step that can avoid most cases of the problem
happening.
I had planned to at least temporarily work around this for gr-usrp by
avoiding passing flowgraph data to libusrp2 that would result in these
short fragments. This wouldn’t fix things for low-level libusrp2
users, but it’s a small change that would get us by until the real fix
with the new VRT transport work. Let me know if this is an issue.
Johnathan,
After a bit of lunch, I think I can fix this in libusrp2 in a few
minutes.
I’ll set up a developer branch in a bit and you all know when it’s
ready to test.
Eric
On Wed, Mar 25, 2009 at 12:12:27PM -0700, Eric B. wrote:
rework the on-the-wire format as part of the VRT work, but I think
After a bit of lunch, I think I can fix this in libusrp2 in a few minutes.
I’ll set up a developer branch in a bit and you all know when it’s
ready to test.
Eric
Ronaldo,
Can you please check out, build and install this developer branch and
let me know if your problem goes away?
$ svn co http://gnuradio.org/svn/gnuradio/branches/developers/eb/t378
Thanks,
Eric
Hi Eric,
Sorry for not reply earlier. I’ve tried your solution but the error
persists.
I will work on the code this morning. If I get positive results I’ll
send you.
Thanks for all help.
Ronaldo
Ronaldo,
Can you please check out, build and install this developer branch and
let me know if your problem goes away?
$ svn co http://gnuradio.org/svn/gnuradio/branches/developers/eb/t378
Thanks,
Eric
–
Ronaldo A. Viera Nunez
Acadêmico/Engenharia Elétrica
Universidade Federal de Santa Maria
Santa Maria - RS - Brasil
Hi Eric,
Thanks for your answer.
I will take a look at that. I’ll work hard to patch it. I promise, I
need the USRP2 working fine as soon as possible.
When I finish I’ll send it gnuradio the patch.
Thanks for all help.
Regards,
Ronaldo
2009/3/25 Eric B. [email protected]:
there’s an intermediate step that can avoid most cases of the problem
–
Ronaldo A. Viera Nunez
Acadêmico/Engenharia Elétrica
Universidade Federal de Santa Maria
Santa Maria - RS - Brasil
On Fri, Mar 27, 2009 at 08:42:43AM -0300, Ronaldo N. wrote:
Hi Eric,
Sorry for not reply earlier. I’ve tried your solution but the error persists.
I will work on the code this morning. If I get positive results I’ll send you.
Thanks for all help.
Ronaldo
Can you post a link to the code you are running so that I can attempt
to reproduce the error you’re seeing?
Eric