Forum: GNU Radio USRP2 modulated signal tx error

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
4960c18fe86cafa1f819b4db3e2d758a?d=identicon&s=25 Ronaldo Nunez (Guest)
on 2009-03-24 20:04
(Received via mailing list)
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
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2009-03-25 19:31
(Received via mailing list)
On Tue, Mar 24, 2009 at 04:03:36PM -0300, Ronaldo Nunez 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
D0072e69d706bb3ca211d33a1b536e2c?d=identicon&s=25 Johnathan Corgan (Guest)
on 2009-03-25 20:10
(Received via mailing list)
On Wed, Mar 25, 2009 at 11:30 AM, Eric Blossom <eb@comsec.com> 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
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2009-03-25 20:13
(Received via mailing list)
On Wed, Mar 25, 2009 at 12:09:36PM -0700, Johnathan Corgan 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
4960c18fe86cafa1f819b4db3e2d758a?d=identicon&s=25 Ronaldo Nunez (Guest)
on 2009-03-25 20:17
(Received via mailing list)
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 Blossom <eb@comsec.com>:
>>
>
> 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
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2009-03-25 20:46
(Received via mailing list)
On Wed, Mar 25, 2009 at 12:12:27PM -0700, Eric Blossom 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
4960c18fe86cafa1f819b4db3e2d758a?d=identicon&s=25 Ronaldo Nunez (Guest)
on 2009-03-27 12:43
(Received via mailing list)
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
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2009-03-31 08:22
(Received via mailing list)
On Fri, Mar 27, 2009 at 08:42:43AM -0300, Ronaldo Nunez 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
This topic is locked and can not be replied to.