RE: [Discuss-gnuradio] Output of usrp_rx_cfile and Input of ATSC demodulator

[Wuest Brandon-WTVR47]

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:address@hidden 
Sent: Thursday, November 29, 2007 4:13 PM
To: Wuest Brandon-WTVR47
Cc: address@hidden
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-----