Do you know if the USRP is in fact little endian? I wrote a little C program to test the endian-ness of my machine (which I am sure everyone did in CS 101) and its big endian.
Endian-ness is based purely off the processor and not the OS right? Sorry for the somewhat non-related SDR question, I generally work with Java, so I sometimes forget about those silly low level details :). -----Original Message----- From: Dan Halperin [mailto:[EMAIL PROTECTED] Sent: Thursday, November 29, 2007 4:13 PM To: Wuest Brandon-WTVR47 Cc: Discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Output of usrp_rx_cfile and Input of ATSC demodulator -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Wuest Brandon-WTVR47 wrote: > I am having a problems with disk writing not being able to keep up > with the high data rate, so I am trying to do a little manipulation of > the IQ data to get around this. What I am trying to do it get 8-bit > samples from the usrp (which my disk can keep up with) and then before > I feed that in to interp.py, I convert every pair of bytes to a complex<float>. A logical approach if your disk can't handle 32MBps linear write. I'll answer question #0 first: For converting pairs of bytes to complex, this might seem a bit (really, a lot) silly, but a simple way to do it in GNU Radio would be gr.file_source(gr.sizeof_char,"file") -> gr.char_to_float() -> gr.float_to_short() -> gr.interleaved_short_to_complex() You could also write a gr.interleaved_char_to_complex() block (which appears to not exist in gnuradio-core/src/lib/general) which would be a MUCH better solution but would require effort :-D. > 1. What is going on with byte order? From looking at the output of > usrp_rx_cfile.py, it looks like everything is little endian, but if > this is the case, I do not see where the ATSC demodulator converts > little endian to big endian to ensure for cross platform compatibility > (the GNU Radio website does indicate that this is possible to run on > windows and I have not found any information regarding byte order > concerns). I am running Ubuntu on an x86 processor which is big > endian and it sounds like most users machines are big endian, so is > there some conversion going on or am I just reading the output of > usrp_rx_cfile.py incorrectly (when set to stream complex floats)? Or > is it that the USRP does send down floats in little endian and the > ATSC demodulator expects that the input is of the same byte order of the machine it was compiled? Source files are assumed to be in local-Endian, and sink files are created local-Endian. Cross-platform is in the eye of the user :-D. Also, I challenge your assertion that Ubuntu on an x86 processor is big Endian. Endian-ness is a function of the architecture (except some crazy and/or cool chips that have an Endian-switch like I think some older Macs). > 2. What are the float values expected by the ATSC demodulator? In > other words, what is the expected range of each float? Should they > all be in the range (-1,1) or (0,1) or (min float value, max float > value) or something else? It looks like the floats are all bounded to > 2 bytes and the higher two bytes are just not used. No idea > 3. When converting an 8-bit sample to a float, do I need to scale it > or just cast it to a float? So if I have a byte with the value of > 100, could I just something like "scale = 100/255; i = FLOAT_MAX * scale?" > Looking at some of the conversion methods included, it seems that a > char gets simply casted to a float, but I believe this would have a > negative effect since it causes all the amplitudes to appear weak. Usually you'd just cast to a float. The demodulator should presumably handle low-amplitude signals. But see my answer to (2). > 4. When I specify 8-bit samples from usrp_rx_cfile.py, are these bytes > signed or unsigned? I find this important because if I want to scale > each byte to a float, instead of just casting, I would possibly need > to do some bit masking to account for this. Signed. Good luck! Dan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHTzlty9GYuuMoUJ4RAvDdAJ0ez/tzvBN4WYBM54dqsus2jSbo3gCgm3pv ot0SaQ5gcSorrETliLcaulI= =t79U -----END PGP SIGNATURE----- _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio