Udp source - endianness anomaly?

Hi All,

I was wondering if anyone has had any issues with the interpretation of
shorts by the GNU Radio udp source function, when the shorts are
transmitted from a big endian based platform? In my situation I am
transmitting UDP packets comprised of 16 bit samples from an AVR32 (big
endian) which utilises the LWIP open source TCP/IP stack. On my GNU
Radio
destination PC (Intel Pentium D CPU, little endian) I construct a simple
flowgraph (using GRC/GNU Radio v3.2.1) with a UDP source set to
interpret
incoming data as shorts, into the short to float block and then straight
into the GUI scope. I’m receiving the UDP packets OK which I assume
means
that all the protocol header info is being interpreted with the correct
endianness, but the waveform displayed in the scope is corrupt, until
that
is, I manually re-order the LSB and MSB of the transmitted samples at
the
AVR32 end. Normally the lower level network code would take care of byte
reordering as required to match network byte order to the relevant host
byte
order, however this doesn’t appear to be happening correctly on the GNU
Radio side. I must be missing something simple here, can anyone shed
some
light?

Thanks

Regards
Richard

On Mon, Oct 12, 2009 at 11:16:11AM +1300, Richard C. wrote:

into the GUI scope. I’m receiving the UDP packets OK which I assume means
that all the protocol header info is being interpreted with the correct
endianness, but the waveform displayed in the scope is corrupt, until that
is, I manually re-order the LSB and MSB of the transmitted samples at the
AVR32 end. Normally the lower level network code would take care of byte
reordering as required to match network byte order to the relevant host byte
order, however this doesn’t appear to be happening correctly on the GNU
Radio side. I must be missing something simple here, can anyone shed some
light?

Is there a good reason to have packets in something other than
network byte order (to match the IP headers) ?


Dave Emery N1PRE/AE, [email protected] DIE Consulting, Weston,
Mass 02493
"An empty zombie mind with a forlorn barely readable weatherbeaten
‘For Rent’ sign still vainly flapping outside on the weed encrusted pole

  • in
    celebration of what could have been, but wasn’t and is not to be now
    either."

No indeed, that’s what I’m saying. The AVR32 platform is sending out
everything in network byte order but the GNU Radio udp source doesn’t
appear
to be interpreting it from network byte order (big endian) into the host
byte order (little endian) correctly. My current work around to this is
to
artificially over ride the byte ordering of the transmitted payload data
at
the transmitting AVR32 end, to compensate for the apparent problem at
the
GNU Radio host end. I’m sure if there was really a problem with the code
at
the GNU Radio end it would have been picked up long ago, so my
assumption is
that I’ve missed something obvious, or I need to look more suspiciously
at
the LWIP code (v1.3.0). However, any ideas are welcomed.

Richard

2009/10/12 David I. Emery [email protected]

http://gnuradio.org/cgit/gnuradio.git/tree/gnuradio-core/src/lib/io/gr_udp_source.cc

The udp source is just memcopying bytes from the udp socket to a output
vector, it has no concept of what the data is and therefore cant be
byteswapping it.

This may facilitate the need for a htonx block and a ntohx block for our
gr short and int types, but the udp blocks are simple as can be; that
being a good thing.

-Josh

Aha, guess I should have paid closer attention to the GNU Radio source.
That
explains things then. Guess I’ll implement a custom byte swapping block,
as
I’d rather the PC do it than the AVR32. Thanks Josh.

Cheers
Richard

2009/10/12 Josh B. [email protected]

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs