discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Output of usrp_rx_cfile and Input of ATSC demodul


From: George Nychis
Subject: Re: [Discuss-gnuradio] Output of usrp_rx_cfile and Input of ATSC demodulator
Date: Thu, 29 Nov 2007 17:56:02 -0500
User-agent: Thunderbird 2.0.0.6 (X11/20071022)

The USRP transfers data in little endian order.

It is based off the processor architecture.

- George


Wuest Brandon-WTVR47 wrote:
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-----


_______________________________________________
Discuss-gnuradio mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio





reply via email to

[Prev in Thread] Current Thread [Next in Thread]