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
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.
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. 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):
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?
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.
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.
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!