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 Blum <[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 > > 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 <[email protected]> >> >> 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, 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." >>> >>> >>> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> [email protected] >> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >
_______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
