Re: [Discuss-gnuradio] NOAA Decoder work in progress
Hi Alexandru, I uploaded a test HRPT file to http://www.poes-weather.com/~patrik/1.7GHz/noaa18.dat 10 MB and a LRIT http://www.poes-weather.com/~patrik/1.7GHz/IMG_DK01IR1_199812240330_010.lrit 4.6 MB Select in the open dialog Files of type: GOES LRIT/HRIT (*) to display the full-disk image. Johnathan got loads of sample HRPT files Thanks, Patrik - Original Message - From: "Alexandru Csete" To: "Patrik Tast" Cc: ; "Jerry" Sent: Wednesday, February 10, 2010 21:51 Subject: Re: [Discuss-gnuradio] NOAA Decoder work in progress Very nice work, Patrik. I tried to build it on Linux and it was very easy via qtcreator. I'm very excited about all this new HRPT stuff in GNU Radio. Looking forward to try it as soon as I can get my hands on a suitable antenna and down converter. Alex On 10 February 2010 15:46, Patrik Tast wrote: FYI, There is also a cross-platform POES/GOES LRIT/HRIT spacecraft decoder work-in-progress Screen shot http://www.poes-weather.com/~patrik/1.7GHz/POES-USRP-Decoder.jpg At the moment it does the following: - render NOAA POES HRPT imagery - render decompressed GOES LRIT/HRIT full disk imagery - realtime satelellite tracking and prediction - LPT rotor control support - antenna AZ/EL HID device sensor support I have not yet bothered to make a HOWTO web-page but soon when it gets warmer up here North It is built using Qt Creator If you are interested, checkout the latest revision from and do a build svn checkout http://noaaport.poes-weather.com:8081/subversion/hrpt-decoder/branches/1.0.0.2/ View the work in progress at http://noaaport.poes-weather.com:8081/viewvc/branches/1.0.0.2/?root=hrpt-decoder Warning, it is a VERY work in progress SW, Patrik ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: Re: Re: [Discuss-gnuradio] RSSI Measurement--
On Thu, Feb 11, 2010 at 12:56 AM, wrote: > Hi, > In a lab scenario , RSSI may not be much affected by multipath signals. > and to the other question u asked, > I only want to plot BER against some received signal. It can be either RSSI > or SNR or anything. But I need some reference. If u have any idea please > share You could go off injected power level with fixed gain and attenuation. Or, if you didn't know injected power, you could go off inserted attenuation. Or, if you didn't have a nice variable attenuator, you could calculate EVM: http://en.wikipedia.org/wiki/Error_vector_magnitude Or, if you want to start being absurd since you said "anything", you can plot against time. Or, you can plot against the number of people in the room. Or, you can plot against how hungry you are. Just some ideas if you didn't want to figure out how to do RSSI yourself. I hope you find them helpful, and good luck! Brian PS - I hope by "In a lab scenario" you mean wired with low loss cables, or in a nice anechoic chamber. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MacPorts and GNU Radio 32-bit
hanks for all the feedback thus far! Can those of you on this thread return back to me the following (as executed in a terminal, individually): gcc -v machine uname -a Once I figure out the logic (and, via the below discussion, I think I know what to do but I just want more info to confirm my beliefs), I can insert a warning or something into the portfile for wxgui so that this issue doesn't happen. - MLD I think this is an OSX 10.6 32/64 bit issue, which I've worked around in GNU Radio already -- and as folks are finding, this error occurs in a background requirement (wxPython). IIRC: * If you boot into 10.5 (which is mixed 32/64-bit, no matter the CPU), you get 32-bit compiling by default with the option of 64-bit via the '-arch x86_64' flag to the compiler. This behavior made sense because the kernel itself wasn't truly 64-bit. * If you boot into 10.6 via the 32-bit kernel, then you get 32-bit compiling by default even if your CPU supports 64-bit compiling (just like 10.5, btw). * If you boot into 10.6 via the 64-bit kernel (assuming your CPU supports it; not all do that can execute 10.6), then you get 64-bit compiling by default. * A simple way to check to see which bit-size compiling is currently supported is to get "sizeof (void*)" and see if it is 4 or 8 (32 or 64 bit, respectively). Note that performing the test in this manner means one cannot make a "universal" executable via combining "-arch i386" and "-arch x86_64" ... you have to choose one way or the other. I've already implemented that change into the GNU Radio portfiles: when doing a universal install each file is compiled twice then the results merged together. * wxPython (2.8.9.10 -- the latest stable release) will currently compile only as 32-bit; the error folks are getting occurs when trying to compile wxPython as 64-bit. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question about ./benchmrk_rx
Tom Rondeau wrote: > > 2010/2/10 Li Mei-Wen : >> >> Hi: >> >> Why the benchmark_rx.py always can not receive the last one packet? >> Have any way to solve it? >> >> >> Best Regards. >> >> Mei-Wen Li (Emily) >> National Cheng-Kung University Dept. of >> Computer Science and Information Engineering >> emily7...@hotmail.com > > I thought we had solved that a while ago. I'll look into it again. > > Tom > > perviously it was the USB buffer problem right? =( Adib -- View this message in context: http://old.nabble.com/Question-about-.-benchmrk_rx-tp27542057p27545735.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] question about gr_ofdm_sampler.cc
Hi Tom, >I'm not sure what you mean by "modified." They have been adjusted by >the sync block to fit in the middle of the FFT bins and the CP has >been removed. Other than that, it's just the data stream. Here "modified", I mean the data which enter into the FFT process are different from the data if directly collected from usrp_rx_cfile.py. The value of the remaining data (after sync and CP removed) have been changed? If that's true, How can I match the original data ( same data obtained from usrp_rx_cfile.py but without CP and unsync'd data) to the FFT bins? Thank you, Bin On Thu, Feb 11, 2010 at 12:16 AM, Tom Rondeau wrote: > On Wed, Feb 10, 2010 at 8:46 PM, bin zan wrote: > > > > > > On Wed, Feb 10, 2010 at 10:18 PM, bin zan wrote: > >> > >> Hi Tom, > >> Thanks a lot for all your information. > >> Can I say that the predefined preambles are used both for symbol sync > and > >> then later correlation, and the CP is only used for symbol sync? > >> One preamble is inserted at transmitter every full packet? > >> > >> Thanks, > >> Bin > >> > >> On Wed, Feb 10, 2010 at 5:45 PM, Tom Rondeau > >> wrote: > >>> > >>> On Wed, Feb 10, 2010 at 11:40 AM, bin zan > wrote: > >>> > Hi Tom, > >>> > Can you help me answer the following questions? > >>> > 1. Does that mean, the data has not be divided into sync'd > >>> > segments until ofdm_sampler.cc? > >>> > >>> I'm not sure what "that" is you are talking about (please reply inline > >>> and don't top post when responding), but I think I get what you are > >>> asking. Yes, the sampler separates the stream into vectors that are > >>> fft_length in size. > >>> > >>> > 2. Why d_timeout_max=1000? Pre-defined preambles only > appear > >>> > every 1000 FFT length of data? > >>> > >>> 1000 was just an arbitrary number. We wanted to make sure that it > >>> would stop sampling after a while if no new packets are seen. It just > >>> has to be long enough to make sure the timeout/reset doesn't happen > >>> during the reception of one full packet. > >>> > >>> > >>> > 3. Only data after state_frame will go through FFT process, > >>> > others > >>> > will be dropped (including CP)? > >>> > >>> Yes, the sampler removes the CP. It's purpose is served so it is no > >>> longer necessary. > >>> > >>> > >>> > 4. According to your powerpoint OFDM implementation in GNU > >>> > radio, > >>> > FFT happens before preamble correlation, which file actually do the > >>> > preamble > >>> > correlation? > >>> > >>> This correlation is done in the ofdm_frame_acq (part of > >>> ofdm_receiver). We use the preamble in the frequency domain to figure > >>> out the subcarrier offset (how many bins away from DC the signal is) > >>> and then create the equalizer from it. The output of this block is > >>> just the occupied tones post equalizer. > >>> > >>> Tom > >>> > >>> > >>> > >>> > >>> > On Wed, Feb 10, 2010 at 12:36 PM, Tom Rondeau < > trondeau1...@gmail.com> > >>> > wrote: > >>> >> > >>> >> On Wed, Feb 10, 2010 at 8:10 AM, bin zan > wrote: > >>> >> > Hi, > >>> >> > I just wonder why in gr_ofdm_sampler.cc, the consume_each > for > >>> >> > STATE_NO_SIG and STATE_PREAMBLE are different. > >>> >> > consume_each(index - d_fft_length + 1); > >>> >> > consume_each(index-d_fft_length); > >>> >> > > >>> >> > Both suppose to leave one fft length, right? > >>> >> > Can any one explain it? > >>> >> > > >>> >> > Thanks, > >>> >> > Bi > >>> >> > >>> >> It's just like the comments say, in STATE_NO_SIG, we consume 1 less > >>> >> because we need to leave behind a full fft_length of items to test > for > >>> >> the preamble. When we have the preamble in STATE_PREAMBLE, we > consume > >>> >> everything including that one so that the next input block is the > >>> >> start of the packets. > >>> >> > >>> >> FYI: Matt and I are working on the OFDM stuff this week. We're > seeing > >>> >> some issues that we need to work out, so things we thought were > right > >>> >> could be wrong and will hopefully be fixed. > >>> >> > >>> >> Tom > >> > > > > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MacPorts and GNU Radio 32-bit
Michael Dickens wrote: Thanks for all the feedback thus far! Can those of you on this thread return back to me the following (as executed in a terminal, individually): gcc -v machine uname -a % gcc -v Using built-in specs. Target: i686-apple-darwin10 Configured with: /var/tmp/gcc/gcc-5646.1~2/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 Thread model: posix gcc version 4.2.1 (Apple Inc. build 5646) (dot 1) % machine i486 % uname -a Darwin eds-mac.local 10.2.0 Darwin Kernel Version 10.2.0: Tue Nov 3 10:37:10 PST 2009; root:xnu-1486.2.11~1/RELEASE_I386 i386 @(^.^)@ Ed ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] question about gr_ofdm_sampler.cc
On Thu, Feb 11, 2010 at 6:52 AM, bin zan wrote: > Hi Tom, >>I'm not sure what you mean by "modified." They have been adjusted by >>the sync block to fit in the middle of the FFT bins and the CP has >>been removed. Other than that, it's just the data stream. > Here "modified", I mean the data which enter into the FFT process are > different from the data if directly collected from usrp_rx_cfile.py. The > value of the remaining data (after sync and CP removed) have been changed? > If that's true, How can I match the original data ( same data obtained from > usrp_rx_cfile.py but without CP and unsync'd data) to the FFT bins? > > Thank you, > Bin Well then, yes, it is modified. The ofdm_sync blocks adjusts the frequency to make sure the subcarriers are in the center of the frequency bins for the FFT. If you don't do this, you introduce major ISI into the received symbol. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] question about gr_ofdm_sampler.cc
Hi Tom, > Well then, yes, it is modified. Since the data are changed, can I say if measure the SNR from the data after FFT, then they are inaccurate and bias? Thanks, Bin On Thu, Feb 11, 2010 at 2:04 PM, Tom Rondeau wrote: > On Thu, Feb 11, 2010 at 6:52 AM, bin zan wrote: > > Hi Tom, > >>I'm not sure what you mean by "modified." They have been adjusted by > >>the sync block to fit in the middle of the FFT bins and the CP has > >>been removed. Other than that, it's just the data stream. > > Here "modified", I mean the data which enter into the FFT process are > > different from the data if directly collected from usrp_rx_cfile.py. The > > value of the remaining data (after sync and CP removed) have been > changed? > > If that's true, How can I match the original data ( same data obtained > from > > usrp_rx_cfile.py but without CP and unsync'd data) to the FFT bins? > > > > Thank you, > > Bin > > Well then, yes, it is modified. The ofdm_sync blocks adjusts the > frequency to make sure the subcarriers are in the center of the > frequency bins for the FFT. If you don't do this, you introduce major > ISI into the received symbol. > > Tom > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MacPorts and GNU Radio 32-bit
Marcel, Ed, and Kunal - Thanks for the data points -- it looks like all 3 of your computers booted from the 64-bit kernel; please correct me if I'm wrong. --- Anyone else on the GR list have a Mac running OSX 10.5 or 10.6 who would care to participate in getting some more data points? I'm in particular looking for 32-bit 10.6, but the more data points the better to show that the ports actually work as hoped. (1) Use MacPorts to try to install GNU Radio (if already installed): sudo port selfupdate sudo port install gnuradio or, if you know you're running on 10.6 as 64-bit (see the NOTE below), do: sudo port selfupdate sudo port install gnuradio-audio-osx (2) return to me whether (1) worked, and also the results of executing the following in a terminal: gcc -v machine uname -a NOTE: If you're running 10.6 with the 64-bit kernel, then you'll have errors installing wxPython since it is not 64-bit compatible yet. There is no way around this issue at this time; these data points are to help provide me info so that I can get the portfiles to work no matter which OSX version or kernel you're compiling for. Thanks again! - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Firmware / FPGA bitstream for USRP2 Rev 4
Hi, I get a new Rev4 USRP2 two weeks ago, and have not yet been able to connect to it. I tried both the binary and the source code on different machines running different versions of Ubuntu (9.4, 9.10). I simply get "No USRP2 found." when I call find_usrps. I have reached a point that I am almost certain there is something wrong on the USRP2 side. The LEDs look fine though (6 of them flash at startup, 2 remain on). As a last resort, I tried to reprogram (a new) SD card. I followed the instructions on USRP2FAQ and copied txrx.bin and u2_rev3.bin on the new SD card. This time, even the LEDs don't light up, and of course I still cannot connect to the USRP2. How do I know which version of firmware and FPGA bitstream I should use? Is there a u2_rev4.bin available (since my USRP2 is revision 4)? Any hints on what I might be doing wrong? Thanks, Omid ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Firmware / FPGA bitstream for USRP2 Rev 4
On 02/11/2010 05:47 PM, Omid F wrote: Hi, I get a new Rev4 USRP2 two weeks ago, and have not yet been able to connect to it. I tried both the binary and the source code on different machines running different versions of Ubuntu (9.4, 9.10). I simply get "No USRP2 found." when I call find_usrps. Is there only one line of output that says No USRP2 found, or are there other lines of output? Are you using a release of GNU Radio or a build from git? I have reached a point that I am almost certain there is something wrong on the USRP2 side. The LEDs look fine though (6 of them flash at startup, 2 remain on). It is extremely unlikely that there is nothing wrong with your USRP2, as they are all 100% tested before shipping. There are many other variables. Is the USRP2 connected directly to the ethernet card? Are you certain it is a gigabit ethernet card? Can you send the output of dmesg after connecting the USRP2? Do you have a TTL serial adapter? As a last resort, I tried to reprogram (a new) SD card. I followed the instructions on USRP2FAQ and copied txrx.bin and u2_rev3.bin on the new SD card. This time, even the LEDs don't light up, and of course I still cannot connect to the USRP2. Then you did not copy the files correctly. You'll need to follow the instructions again, as those instructions work. If the LEDs don't light up, then the files are not on there and nothing will work. How do I know which version of firmware and FPGA bitstream I should use? Is there a u2_rev4.bin available (since my USRP2 is revision 4)? Any hints on what I might be doing wrong? No, rev3 and rev4 use the same .bin files. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Firmware / FPGA bitstream for USRP2 Rev 4
On 02/11/2010 06:50 PM, Matt Ettus wrote: On 02/11/2010 05:47 PM, Omid F wrote: I have reached a point that I am almost certain there is something wrong on the USRP2 side. The LEDs look fine though (6 of them flash at startup, 2 remain on). It is extremely unlikely that there is nothing wrong with your USRP2, as they are all 100% tested before shipping. Correction -- I meant to say "It is extremely unlikely that there is anything wrong with your USRP2." Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OFDM receiver on USRP2
On 02/11/2010 04:45 PM, Srinivas wrote: Hi All, I have 2 pairs of USRP2s with GNURadio-3.2 installed on their hosts. On one pair I am able to successfully run OFDM (benchmark_ofdm_tx & rx) with almost 95+% packet success rate. However on the other pair I am not receiving even 1 packet! I am using the same host machines and scripts. I also tried swapping the daughtercards (XCVR2450) and the firmwares with the working pair, but the problem remains. Does any one have a clue of where the problem might be ? PS: The received signal spectrum (usrp2_fft.py) on one of the non-working USRP2s is attached herewith. Besides this I plotted the spectrum of the received data from usrp2_rx_cfile.py at the receiver using MATLAB. The spectrum is of the same shape and strength as usrp2_fft.py displays. Srinivas, It looks like you are using a very narrow signal. The frequency offset of the USRP2s giving you trouble may be enough that you are outside of the search range of the OFDM receiver (which is a percentage of the bandwidth of the signal). You could try any or all of the following: - increasing the data rate by a factor of 2 or 4 - modifying the OFDM code to widen the search range - locking the usrps to a common reference - measure the frequency offset of the transmitter, and run the receiver with the actual frequency. For example, if the receiver sees the signal 30 kHz high using usrp2_fft.py, call the ofdm receiver with -f 2.450030G on the command line Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] installing new modules
Hi,
I am trying to install new modules into my gnu radio tree. I have MAC
OSX 10.5.5 but on a G4 PPC. Following instructions online that use
MacPorts, I have been able to successfully run built-in scripts and
verify that all required components of GNU radio are working. However,
when compiling and running the example gr-how-to I ran into some
interesting problems. First, looking at the output of the make install
I see that the module gets installed in the /opt/local/Library/
Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/
gnuradio directory. When I try to run the simple qa_howto.py script
it fails saying that module howto is no found. Looking at
bash-3.2$ echo $PYTHONPATH
/opt/local/lib/python2.6/site-packages:/usr/local/lib/python2.6/site-
packages
I can solve the problem by moving the installed components under the /
Frameworks/Python.framework/ tree to /usr/local/lib/python2.6/site-
packages/, but that is a hacked up method that whenever I write my
code or change it, I have to worry about copying before I am sure that
the new module is what is going to be used.
So I edited, what I think is the appropriate portion of my ./bashrc
file as follows
export PYTHON_VERSION=`python -V 2>&1 | sed -e 's...@\.@ @2' | awk
'{ print $2 }'`
export PYTHON_ROOT=`which python | sed -e 's@/bin/python@@g'`
export PYTHONPATH=${PYTHON_ROOT}/lib/python${PYTHON_VERSION}/site-
packages
if [ ${PYTHON_ROOT} != "/usr/include" ]; then
export PYTHONPATH=${PYTHONPATH}:/usr/local/lib/python$
{PYTHON_VERSION}/site-packages
fi
export PYTHONPATH=${PYTHONPATH}:/opt/local/Library/Frameworks/
Python.framework/Versions/2.6/lib/python2.6/site-packages <--- added
by me.
However, even this doesnt help if I do a new make install (and now the
$PYTHONPATH includes the directory with the installed files).
So I searched on the gnu radio mailing list, and it appears it has
something to do with multiple versions of python installed. I know
that I had previous installed python and so when I do a which python
bash-3.2$ which python
/opt/local/bin/python
and my $PATH variable is not pointing to where the Macport has
installed python2.6.
echo $PATH
/opt/local/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/
bin
What do I have to change (in the configure files or at a larger scale
on my system) to make sure my make install puts the new module in the
same place the GNU radio is looking at?
Thank you.
regards,
Affan
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] How is interp & decimation in grc taking zero.
Hi, Am using grc, to create a signal source connected to USRP2 sink, and from another USRP2 as source and to a scope sink. While setting the parameters, i could even set to interp on USRP2 sink and decimation on USRP2 source to zero. to see the samples or signal source correctly recieving. But when i try using tx_samples.cc and rx_streaming_samples.cc, it is not allowing to set to zero (only allowed to 4 to 512). Now my question is the usrp2 is calling the same low level C++ code and Why is it so. best regards, srinivas. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
