[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Discuss-gnuradio] Output of usrp_rx_cfile and Input of ATSC demodulator
From: |
Wuest Brandon-WTVR47 |
Subject: |
[Discuss-gnuradio] Output of usrp_rx_cfile and Input of ATSC demodulator |
Date: |
Thu, 29 Nov 2007 14:08:26 -0500 |
All,
In the hopes of
trying to understand the various aspects of GNU Radio and the USRP
hardware, I am trying to use the ATSC demodulator included with GNU Radio to
create an MPEG transport stream from the output of usrp_rx_cfile.py.
Something I know has been discussed many times on this
forum.
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>.
So far this method
has not yielded a single HDTV frame and I assume this to be a problem with
converting 8-bit samples to a complex<float>. I know I have a good
signal because I can clearly see the 6 MHz channel with strong pilot
centered about my frequency using the fft utility, so here are my questions (the
answer to some of these may not really be necessary to get this to work, but I
ask them anyway so I am clear on what is going on):
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?
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.
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.
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.
Any incite in to
these questions would be most appreciated!
Thanks,
Brandon
- [Discuss-gnuradio] Output of usrp_rx_cfile and Input of ATSC demodulator,
Wuest Brandon-WTVR47 <=