|
From: | Josh Blum |
Subject: | Re: [Discuss-gnuradio] udp source - endianness anomaly? |
Date: | Sun, 11 Oct 2009 16:41:23 -0700 |
User-agent: | Thunderbird 2.0.0.23 (X11/20090817) |
http://gnuradio.org/cgit/gnuradio.git/tree/gnuradio-core/src/lib/io/gr_udp_source.ccThe 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 Richard Clarke wrote:
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 <address@hidden>On Mon, Oct 12, 2009 at 11:16:11AM +1300, Richard Clarke wrote: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, untilthatis, 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 hostbyteorder, 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, address@hidden 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."------------------------------------------------------------------------ _______________________________________________ Discuss-gnuradio mailing list address@hidden http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Prev in Thread] | Current Thread | [Next in Thread] |