discuss-gnuradio
[Top][All Lists]
Advanced

[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

reply via email to

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