Re: [Discuss-gnuradio] Reading I Q from a binary file
I have updated from CVS and re-recorded a new file using complex types and the gain set to 20. LabView is able to read in any type, so I have defined it to read single precision floats (assuming the first 32 bits are I and the second 32 bits are Q). I have also read straight into a complex type and obtain the same results. I now have I and Q values as I should. The values are in the range of 10^-41. Has anyone looked at the sampled values from the USRP before?? I am using the basic daughter board with no front end. I want to check that these values are reasonable. D Shens tutorial mentions the PGA amplifies the signal to a dynamic range of +-1??? I want to make sure the values are ok before moving on the next stage. Regards Paul From: Eric Blossom [EMAIL PROTECTED] To: paul munro [EMAIL PROTECTED] CC: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Reading I Q from a binary file Date: Sun, 25 Jun 2006 19:47:06 -0700 On Sun, Jun 25, 2006 at 10:49:03PM +, paul munro wrote: Hi. I have sampled a FM signal and saved it to a file using 'usrp_rx_cfile.py'. I have checked the file by demodulating it using 'wfm_rcv_file.py' and everything works fine. I am now trying to read the file using LabView. The tutorial by Dawei Shen says the data is 16 bit signed integers in I followed by Q format. What I read in LabView is: each I sample is zero, and Q values range from 0 to +-32000 (see figure). The output of usrp_rx_cfile depends on the command line options you use. It saves files either with 16-bit I Q, or 32-bit float I Q (complexfloat). By default it writes complexfloat. Are these values reasonable?? Should the inphase sample be zero?? I doesn't seem right to me... Is it definitely I followed by Q, am I a word out?? I have tried with a few different files, but I get the same results. No, this doesn't sound reasonable. It's highly unlikely that every other sample is zero. If you are expecting 16-bit I Q, try using usrp_rx_cfile with the -s command line option. FYI, most of the examples understand --help. E.g., [EMAIL PROTECTED] usrp]$ ./usrp_rx_cfile.py --help audio: using audio_alsa usage: usrp_rx_cfile.py: [options] output_filename options: -h, --helpshow this help message and exit -R RX_SUBDEV_SPEC, --rx-subdev-spec=RX_SUBDEV_SPEC select USRP Rx side A or B (default=A) -d DECIM, --decim=DECIM set fgpa decimation rate to DECIM [default=16] -f FREQ, --freq=FREQ set frequency to FREQ -g GAIN, --gain=GAIN set gain in dB (default is midpoint) -8, --width-8 Enable 8-bit samples across USB --no-hb don't use halfband filter in usrp -s, --output-shorts output interleaved shorts in stead of complex floats -N NSAMPLES, --nsamples=NSAMPLES number of samples to collect [default=+inf] Eric _ Need more speed? Get Xtra Broadband @ http://jetstream.xtra.co.nz/chm/0,,202853-1000,00.html ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Reading I Q from a binary file
On Wed, Jun 28, 2006 at 06:00:13AM +, paul munro wrote:
I have updated from CVS and re-recorded a new file using complex types and
the gain set to 20.
OK.
LabView is able to read in any type, so I have defined it to read single
precision floats (assuming the first 32 bits are I and the second 32 bits
are Q). I have also read straight into a complex type and obtain the
same results.
OK.
I now have I and Q values as I should. The values are in the range of
10^-41. Has anyone looked at the sampled values from the USRP before??
Yes ;)
Why don't you start with something like
gnuradio-examples/python/usrp/usrp_oscope.py which will show you what
*we* think the values are. [Sorry, no experience with LABVIEW.]
./usrp_oscope.py -g 20
Or if you've got octave or matlab installed, set the path for that
tool to include gnuradio-core/src/utils (take a look in that
directory). For octave edit ~/.octaverc and put this line in it:
LOADPATH=:~/gr-build/gnuradio-core/src/utils;
Then try:
$ octave
octave:1 d = read_complex_binary('name_of_file.dat', 1e6);
octave:2 plot(real(d(1:1000)))
octave:3 plot(imag(d(1:1000)))
I am using the basic daughter board with no front end. I want to check that
these values are reasonable.
If you've got a signal generator, try connecting a 10 MHz signal with
a peak to peak amplitude of about 0.5V to the RX-A or RX-B inputs on
the Basic Rx daughterboard.
Then try one or both of these:
./usrp_fft.py -f 10M -g 20
./usrp_oscope.py -f 10M -g 20
D Shens tutorial mentions the PGA amplifies
the signal to a dynamic range of +-1???
I want to make sure the values are ok before moving on the next stage.
The values that you'll see from usrp.souce_c(...) are in (-1.0, +1.0).
The smallest value you'll see is about +/- 3e-5 (== 1.0/32768).
If you're seeing 1e-41 I think you've still got a problem with
LABVIEW's handling of binary input values.
The -g option sets the gain of the PGA. On the Basic Rx
daughterboard, the gain ranges from 0dB to 20dB by 0.1 dB steps.
Eric
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Which LinuxOS to use?--1.Unbuntu, Fedora, Mandrake, FreeBSD
On Monday 26 June 2006 18:22, Robert McGwier wrote: I installed Ubunto 5.X and GnuRadio just made and ran after I used apt (synaptic) to download any package GnuRadio could not find. With Ubunto Yes; on Fedora Core 5 I just used 'yum install' in an identical fashion as you would use 'apt-get install' to grab the dependencies, with the singular exception of SDCC, which I built from a source RPM and then installed with 'rpm -i'. At some point I'm going to put together GNUradio RPMs for FC5; I however track CVS/SVN and that makes it difficult. I've not built a tarball release in a very long time. Virtually all the modern distributions can do these sorts of automatic dependency resolution these days; it often falls to what packages you need and whether there is a package repository containing the mix of packages you need. PHP5, for instance, is in Fedora Core 5 already, and I didn't need to do any aclocal.m4 modifications to build GNUradio. My comment about bandwidth (I have a 1.5Mbit DSL at home) is in keeping up with package updates; no one but SuSE deals with this as yet, and I'm not sure if SuSE still does package deltas or not. The FC5 updates run several hundred megabytes per month; sometimes per week. Not sure about Ubuntu; I have a copy of Dapper, but have not had time to install it (I'm quite happy with CentOS 4 on the servers and FC5 on the linux desktops here; using a local repository rsynced to the master repos helps on the bandwidth side). The CentOS updates comprise far less volume on the machines that don't use the kde-redhat repository; those that do use kde-redhat can get a hundred MB or so per month since that repository includes later OpenOffice.org packages, as well as core kde libs and such. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] usrp_tv_rcv issues !!
I read the thread below and I have the same problems.http://lists.gnu.org/archive/html/discuss-gnuradio/2006-05/msg00026.html Here in Brazil these are the frequencies for valid analog TV channels (VHF / PAL-M): Mhz 54 - 60 Channel 2 66 - 70 Channel 4 82 - 88 Channel 6 186 - 182 Channel 9 210 - 216 Channel 13 I've tried many different things (specially decimation and gain) but I still can't get any image. The FM receiver example worked fine.Can anybody help me??Thanks a lot,-- Augusto Pedroza PS: I Congratulate those involved in this initiative. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Creating a CW receiver for 20m ham band
Good day.Does anyone have GNU Radio code I can inspect to learn how to decode and render to audio CW transmissions in, say, the US amateur bands?Thank you.-- Mark ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Export Controls
So, I was reading over a superficial summary of U.S. export controls today, and discovered that radio receivers capable of more than 1000 channels (what the heck is a channel?) and able to switch channels in under 1ms are export-controlled technology. It seems to me that a USRP with a Gnu Radio filterbank in the back-end is such a receiver, and is thus subject to U.S. export control. Anyone with a better view of this able to comment? -- Marcus LeechMail: Dept 1A12, M/S: 04352P16 Security Standards AdvisorPhone: (ESN) 393-9145 +1 613 763 9145 Strategic Standards Nortel Networks [EMAIL PROTECTED] ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Export Controls
Marcus Leech schrieb: So, I was reading over a superficial summary of U.S. export controls today, and discovered that radio receivers capable of more than 1000 channels (what the heck is a channel?) and able to switch channels in under 1ms are export-controlled technology. It seems to me that a USRP with a Gnu Radio filterbank in the back-end is such a receiver, and is thus subject to U.S. export control. Anyone with a better view of this able to comment? I only have my cynical view of the US government, and similar regulations that made 'encryption' an armament... on the other hand as an arms, every 'murkin citizen has the right to bear arms... and hence, by declaring encryption an armament, every 'murkin has a right to encryption... where's the NRA when ya need 'em... By similar reasoning then, every 'murkin has a right to a myriadchannel radio receiver... As for needeing a filter bank... with DSP there is no need for a 'filter bank'... at least as a physical element... And of course it is with good reason we, us 'murkins, get all of our manufactured products from China, since we then don't have to worry about US export regulations at all. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: [Commit-gnuradio] gnuradio-core/src/lib/general gr_correlate_acce...
[Moved to list, following my own recommendation ;)]
Regarding: searching for normal and conjugated match in
gr_correlate_access_code.
On Wed, Jun 28, 2006 at 05:03:09PM -0400, Tom Rondeau wrote:
This is OK, but there's a much simpler, and faster way to handle the
problem.
There's no need to check for the conjugate directly, or to run
multiple shift registerrs. Just look at the hamming distance. E.g.,
a perfect match of the conjugate will have the maximum hamming
distance, whereas a perfect match of the normal access will be 0.
But if we have a threshold value for the conjugate, (max-threshold) would
trigger on a number of wrong solutions, wouldn't it? We would pass anything
up that has between 52 and 64 bit errors in the access code.
If you're doing simultaneous detection of the normal conjugate by any
method, you've got the same problem. Note that this is a good reason
*not* to enable both normal and conjugate when using DPSK.
Say the access code was 10 long, and the threshold was 2.
When detecting both, the map goes like this:
hamming dist result
-
0 Normal match (perfect)
1 normal match (one off)
2 normal match (two off)
3 --
4 --
5 --
6 --
7 --
8 conj match (two off)
9 conj match (one off)
10 conj match (perfect)
Eric
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] RE: [Commit-gnuradio] gnuradio-core/src/lib/general gr_correlate_acce...
[Moving to list, per Eric's request] Right, so we are talking about implementing 8PSK and pi/4 DQPSK, the later being more important as it shows up in implementation often. My concern with both, though, is the phase and frequency synchronization. I'm sure someone out there has some experience with this. To summarize, we have a second order Costas loop for BPSK and a fourth order Costas loop for QPSK. What is normally used for synchronization with these modulations? For pi/4 DQPSK, I was thinking we could use the current fourth order loop, in which we can set the desired rotation. Each symbol received would cause the rotation variable to flip 45 degrees. a) does this work, and b) is there a better way to do this? Tom -Original Message- From: Johnathan Corgan [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 28, 2006 3:21 PM To: Tom Rondeau Cc: Eric Blossom Subject: Re: [Commit-gnuradio] gnuradio-core/src/lib/general gr_correlate_acce... Tom Rondeau wrote: My next target modulation is QPSK, OQPSK, and pi/4 DQPSK. If you give me information on some implementation details for 8PSK, I'll work those in, too. pi/4 DQPSK *is* 8PSK, but with a restriction. 1 8 2 73 6 4 5 The only allowed transitions are from an even constellation point to an odd one, or vice versa. For example, from point 1 it goes to 2,4,6,8 based on the two bits being encoded. There is only ever a phase change of pi/4 or 3*pi/4 (hence the name). This prevents the RF envelope from dropping to zero (as would be the case of a transition from say, 1 to 5, or from 7 to 3). You're right, the carrier/phase tracking is the hard part. Since it's differential you can let the lock be on any of the eight orientations; the symbol is encoded in how much phase change there is from one successive symbol to another. (Eric, I didn't copy you on my first email to Tom, asking about pi/4 QPSK. And this isn't copied to the list as I don't know how much you guys are sharing at this point.) -Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] NetBSD USB progress
There is a long outstanding bug in benchmark_usb that has it be unreliable. It's been a long time since I looked at it. The problem could be in the lfsr synchronization. Yeah, I saw the comment in the file. What I find interesting about it is that it's only failing for the slowest transfer rate, and the others are fine. So they are getting past that same point in the sequence with no trouble, and they're also not all failing ~60k samples before the end... It's probably indeed not very critical to figure it out, but it does strike me as odd that it's unreliable in this particular way. Joanne ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP from SVN - no ./bootstrap and ./configure
As per the USRP svn repository instructions I run the following command: svn co http://usrp.svnrepository.com/svn/usrp/trunk usrp Upon completion, the INSTALL file talks about ./configure. Some other how-to sites also talk about ./bootstrap. I cant find configure or bootstrap in the above svn repository. Where are they? Do I really need bootstrap? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP from SVN - no ./bootstrap and ./configure
Get bootstrap from http://opensdr.cvs.sourceforge.net/opensdr/usrp/ (old repository) ./bootstrap will rebuild configure. IMHO bootstrap should be on svn too. As per the USRP svn repository instructions I run the following command: svn co http://usrp.svnrepository.com/svn/usrp/trunk usrp Upon completion, the INSTALL file talks about ./configure. Some other how-to sites also talk about ./bootstrap. I cant find configure or bootstrap in the above svn repository. Where are they? Do I really need bootstrap? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- View this message in context: http://www.nabble.com/USRP-from-SVN---no-.-bootstrap-and-.-configure-tf1864620.html#a5095476 Sent from the GnuRadio forum at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
