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.
Ronaldo N. (Guest)
on 2009-03-24 21: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
Eric B. (Guest)
on 2009-03-25 20:31
(Received via mailing list)
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
Johnathan C. (Guest)
on 2009-03-25 21:10
(Received via mailing list)
On Wed, Mar 25, 2009 at 11:30 AM, Eric B. <removed_email_address@domain.invalid> 
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
Eric B. (Guest)
on 2009-03-25 21:13
(Received via mailing list)
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
Ronaldo N. (Guest)
on 2009-03-25 21: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 B. <removed_email_address@domain.invalid>:
>>
>
> 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
Eric B. (Guest)
on 2009-03-25 21:46
(Received via mailing list)
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
Ronaldo N. (Guest)
on 2009-03-27 13: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
Eric B. (Guest)
on 2009-03-31 10:22
(Received via mailing list)
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
This topic is locked and can not be replied to.