[Top][All Lists]
[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: |
Dan Halperin |
Subject: |
Re: [Discuss-gnuradio] Output of usrp_rx_cfile and Input of ATSC demodulator |
Date: |
Thu, 29 Nov 2007 14:13:01 -0800 |
User-agent: |
Thunderbird 2.0.0.6 (X11/20071022) |
-----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-----