Re: [Discuss-gnuradio] USRP tuning
Sounds like you are on the right track. I'll add those details tomorrow. Thanks, Justin Brian Padalino wrote: On 9/7/07, Justin Shaw <[EMAIL PROTECTED]> wrote: I think I have a misunderstanding regarding tuning the USRP. I have connected the TX-A directly to RX-A. I am plotting the FFT of both the transmitted and received signal. I have tuned RX to 0 Hertz so I expect the positive frequencies to look the same up to noise affects. I am assuming this means you used a cable to connect two different cards together? If these have any transmitting power to them, there should be some attenuators in line to make sure you don't blow anything up. This is just an FYI. What I get instead is mostly noise, with occasional blips at an offset frequency. I.E. 5 KHz input gives me occasional energy at about 3 KHz. But most often I don't see any signal at all. I have posted the GRC graph and FFT plots at http://wyoinnovation.blogspot.com/. So I've been looking at your GRC graph and I have some fundamental USRP questions as well as some questions with regards to your setup. First, your signal source has a frequency of 0 and an amplitude of 16, so you just want to transmit carrier? I am not sure if there is a constant block but using that to make a DC offset can accomplish the same thing. Second, your sampling rate appears to be 50ksps and your USRP interpolation rate is 200. This gives a final sampling rate of 10Msps. Does the USRP final sampling rate have to be 64Msps, or can the USRP drive the DAC at 10Msps? Next, your USRP source has a decimation rate of 1. I don't think this is a legal decimation rate. You should probably decimate your signal down a bit. A decimation rate of 128 would give a sampling rate of 500ksps for a signal sampled at much less than that which is really just a DC offset. Lastly, there seem to be some sliders in the GRC window which are controlling the aforementioned values. In those screen shots, I see a tuning frequency of 0 and a signal frequency of 5kHz. I am probably just getting confused. On the other hand, getting answers about the interpolation and decimation rates of the USRP would be good. Sorry if I haven't been much help. Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] QT Oscilloscope
Your intuition is correct. The Basic TX and RX boards allow this -- they don't do any RF front-end processing. The Basic boards let you make the USRP into a poor man's oscope, with very limited voltage ranges on the input. -Ian On 9/7/07, Rohit Garg <[EMAIL PROTECTED]> wrote: > Hi, > > I am curious about what you have created. I imagine that you are > grabbing the signals with the ADC of the usrp when used as an > oscilloscope. If that is correct then it must be possible to use it as > a signal generator as well if you plucked the output off the DAC. > > More generally, has the usrp been designed to allow easy decoupling of > the RF frontend and to use it as a pure signal analyzer/generator? > > On 9/7/07, Ian Larsen <[EMAIL PROTECTED]> wrote: > > All, > > > > As part of some thesis research, I've made a stand-alone > > oscilloscope/spectrum analyzer that also shows AM and FM demodulated > > signals, using the gnuradio C++ libraries. It uses QT, and the output > > looks very pretty, being anti-aliased and such. You can also grab > > screenshots from it by pressing a button. The sourceforge page is > > here: > > > > http://sourceforge.net/projects/usrposcope/ > > > > and you can get the source via subversion. Since (as far as I know) > > the C++ libraries don't support multiple daughterboards yet, this will > > only work with the BasicRX. > > > > It has fairly limited capability, but is a good intro for those who'd > > like to use the C++ libraries and/or would like to expand the > > functionality. > > > > -Ian Larsen > > > > -- > > My PGP Public Key: > > http://www.scrapshark.com/pubkey.txt > > > > > > ___ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org > > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > > -- > Rohit Garg > -- My PGP Public Key: http://www.scrapshark.com/pubkey.txt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP tuning
On 9/7/07, Justin Shaw <[EMAIL PROTECTED]> wrote: > I think I have a misunderstanding regarding tuning the USRP. > > I have connected the TX-A directly to RX-A. I am plotting the FFT of > both the transmitted and received signal. I have tuned RX to 0 Hertz > so I expect the positive frequencies to look the same up to noise > affects. I am assuming this means you used a cable to connect two different cards together? If these have any transmitting power to them, there should be some attenuators in line to make sure you don't blow anything up. This is just an FYI. > What I get instead is mostly noise, with occasional blips at an offset > frequency. I.E. 5 KHz input gives me occasional energy at about 3 > KHz. But most often I don't see any signal at all. > > I have posted the GRC graph and FFT plots at > http://wyoinnovation.blogspot.com/. So I've been looking at your GRC graph and I have some fundamental USRP questions as well as some questions with regards to your setup. First, your signal source has a frequency of 0 and an amplitude of 16, so you just want to transmit carrier? I am not sure if there is a constant block but using that to make a DC offset can accomplish the same thing. Second, your sampling rate appears to be 50ksps and your USRP interpolation rate is 200. This gives a final sampling rate of 10Msps. Does the USRP final sampling rate have to be 64Msps, or can the USRP drive the DAC at 10Msps? Next, your USRP source has a decimation rate of 1. I don't think this is a legal decimation rate. You should probably decimate your signal down a bit. A decimation rate of 128 would give a sampling rate of 500ksps for a signal sampled at much less than that which is really just a DC offset. Lastly, there seem to be some sliders in the GRC window which are controlling the aforementioned values. In those screen shots, I see a tuning frequency of 0 and a signal frequency of 5kHz. I am probably just getting confused. On the other hand, getting answers about the interpolation and decimation rates of the USRP would be good. Sorry if I haven't been much help. Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP tuning
I think I have a misunderstanding regarding tuning the USRP. I have connected the TX-A directly to RX-A. I am plotting the FFT of both the transmitted and received signal. I have tuned RX to 0 Hertz so I expect the positive frequencies to look the same up to noise affects. What I get instead is mostly noise, with occasional blips at an offset frequency. I.E. 5 KHz input gives me occasional energy at about 3 KHz. But most often I don't see any signal at all. I have posted the GRC graph and FFT plots at http://wyoinnovation.blogspot.com/. Thanks in advance for any help you can offer. Justin Shaw ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] 8 MHz Tx Bandwidth... What am I still missing?
Hi, what I've done so far is: --buy a new hardisk (a 7200 rpm sata), used only for the data to be transmitted,, and XFS formatted ---check my PC's USB bus via gnuradio benchmark_usb.py, which says everything is ok up to 32MB/s (output follows) ---use short int interleaved I/Q instead of gr_complex but still a 342958080 bytes long file, meant to last 10.717 seconds if played back at 32 MB/s (8 complex Msps) lasts 13+ seconds while, instead it should be: 342958080 / 32e6 = 10.717 seconds samples are damn slow to come out..this is quite frustrating as my application needs a true 8 MHz bandwidth... scaling down to 4 MHz is instead fine.. as I really get the right 342958080 / 16e6 = 21.435 seconds what else should I check/modify? any hint? the file meant to last 10.717 secs if played back with usrp_interp = 16 is at http://wwvince.interfree.it/of.dump please, if anybody manages to send it out in not more than 11 seconds, le me know.. it would be really good news... thanks vincenzo BENCHMARK_USB OUTPUT: [EMAIL PROTECTED] gr-mystuff]# ./monitor.sh Testing 2MB/sec... usb_throughput = 2M ntotal= 100 nright= 986311 runlength = 947654 delta = 52346 OK Testing 4MB/sec... usb_throughput = 4M ntotal= 200 nright= 1997961 runlength = 1997961 delta = 2039 OK Testing 8MB/sec... usb_throughput = 8M ntotal= 400 nright= 3997979 runlength = 3997979 delta = 2021 OK Testing 16MB/sec... usb_throughput = 16M ntotal= 800 nright= 7997477 runlength = 7997477 delta = 2523 OK Testing 32MB/sec... usb_throughput = 32M ntotal= 1600 nright= 15995879 runlength = 15991525 delta = 8475 OK Max USB/USRP throughput = 32MB/sec -- Vincenzo Pellegrini ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP and SDR
> All i need is to demonstrate a standard digital communication link > in software defined radio using USRP board. > Help Um, okay. Then do it. Check out the example programs [0]. Do what they do, but the way you want to do it. If you don't understand what they are doing (RF-wise), you might check out a digital communications or DSP book [1]. If you have a specific question or problem, then maybe the list can help. Until then, no, we won't do your homework for you ;). [0] http://gnuradio.org/trac/browser/gnuradio/trunk/gnuradio-examples [1] http://gnuradio.org/trac/wiki/SuggestedReading Good luck, -- Caleb Phillips ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Basic Bandwidth math
Hello all, I found that the 7 samples per symbol cap was from a pick_bitrate example code I was using. No matter what I changed the interpolation to, it used 7 samples per symbol. I added support for higher samples per symbol in that file, and seem to be good to go now. Other than some random spikes spurious showing up in my FFT that seem to be appearing when I use a lower interpolation number. Jeff On 9/7/07, Jeffrey Karrels <[EMAIL PROTECTED]> wrote: > Thanks Eric. So my math was right. Yesterday I seemed to be having > issues because I was running out of memory. I since have upgraded > boxes. Now I think I am down to 1 issue and I believe it is a basic > RF one that everyone is going to jump over me for! > > Let me give a picture tutorial of my problem. > > 1) If I transmit a modulated signal with two additional signals mixed > with -400kHz and 400kHz, I get what I expected. (see image 400.png) > > 2) If I transmit a modulated signal with two additional signal mixed > with -400kHz and 800kHz, I get the +800kHz showing up with some > additional power down at -1200kHz. (see image 800) > > 3) If I transmit... mixed with -400kHz and 1200kHz, I get something at > + and - 1000kHz. > (see image 1200) > > 4) If I transmit... mixed with -400kHz and 1600kHz, I get the same as > #3. (see image 1600). > > I was messing with samples per symbol, but it will not go any higher > than 7 without an error. > > Anyone have any suggestions on where to start looking or things to > try? Filters? > > Thanks all for your help! > Jeff > > > On 9/6/07, Eric Blossom <[EMAIL PROTECTED]> wrote: > > On Thu, Sep 06, 2007 at 11:56:30AM -0400, Jeffrey Karrels wrote: > > > Ok. I am having a world of problems today, the main one being > > > determining if it is my issues causing the headache or the headache > > > causing the issues. ;) > > > > > > I have a basic bandwidth limit that I am hitting and for some reason I > > > cannot do basic math today. > > > > > > I am trying to see how many carriers I can transmit on. I am mixing a > > > single gmsk modulated source with LOs in software and seeing how many > > > times I can do that. A single channel is 250kHz wide and the channels > > > are 400kHz apart center to center. In other words my LOs are 400e3, > > > 800e3, ... > > > > > > How many carriers would you expect that I could transmit on? > > > > > > > > > Thanks > > > Jeff > > > P.S. Sorry in advance, I am nuts today. > > > > In theory, 20. In reality probably about 16, unless you run out of > > CPU first. > > > > You can get 8Mz of IF bandwidth across the USB. > > This is 8MS/s * 2 * 2 = 32MB/s (16-bit I & Q). > > > > 8e6/4e5 = 20 "bins" (ignoring roll off) > > > > Allow for roll off because of CIC interpolator in FPGA. Say that 80% > > is usable (depends on your app, whether you preemph signal etc). > > > > 20 * .8 = 16 bins. > > > > There's a fence post problem here ;) > > > > So, 1 carrier needs 250kHz > > > > 3 carriers needs 2 * 400 + 2 * 125 > > > > 5 carriers needs 4 * 400 + 2 * 125 > > > > N carriers needs (N-1) * 400 + 250 (for odd N) > > > > 15 -> 5.85MHz > > 17 -> 6.65MHz > > 19 -> 7.45MHz > > > > Put the middle carrier at 0 Hz, > > then arrange the others symmetrically about it. > > > > Eric > > > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 8MHz Tx Bandwidth.. Nightmare and Fear
Hi vincenzo, No need to be confused , lets put it together again: 1) The USB benchmark software can be found in the gnuradio/gnuradio-examples/python/usrp/benchmark_usb.py 2) What do you mean by another disk? are both gnuradrio installation work from the same operating system ? or each drive has its own OS? 3) What is you OS? 4) What is the reading of [hdparm -t /mnt/sda ] on both drives? 5) Describe you setup please and what do you want to do. Fortunately, for one day or less, I have function generator and spectrum analyzer in my home with the USRP system and I can run a copy of your experiments at my home to see the result on my system. Firas Vincenzo Pellegrini <[EMAIL PROTECTED]> wrote: I'm recording and replaying interleaved shorts @ 8Msps.. how is the benchmarking software called? I also have noticed a diffference between my main, old gnuradio installation and a fresh one just done from trunk on another disk... the fisrt is all right with transmissions up to 4 MHz the second stops at 2MHz, (using the same scripts of mine on both installations): when, on the fresh installation, I ask for 4MHz I can hear only noise being sent out (I think this is a different problem than the slow flow).. I'm a bit confused... thanks vincenzo 2007/9/7, Firas abbas <[EMAIL PROTECTED]>: Hi Vincenzo, Are you recording the 8Msps complex or short ?. In recording, I always prefer the interleaved complex short, because the real coming samples from the USRP across the USB is 16 bit short. The conversion to float (32 bit) complex is being done by software in the PC and thus adds no new information and does not enhance the data. It only complicate file storage process. If converting to short does not solve your problem, try to record and play smaller bandwidth like 6.4MHz (decimation 10) or less. Also test your PC USB 2 speed by using the benchmark software found the gnuradio truck. Best Regards, Firas Vincenzo Pellegrini < [EMAIL PROTECTED]> wrote: hi Firas, thanks for help! i'm doing pretty much everything you suggested, and in fact, really!!, I do think that my HD is doing a very good work. nevertheless I keep having the same problem, this is what I also posted to the list: I finally have a 7200rpm disk that does keep up very well with 32MBps and, I guess, even much more.. is then this assumption correct? 8Msps with gr_complex data type ==> 8e6*8bytes per sample = 64 MB/s 8Msps with interleaved shorts ==> 8e6*2bytes per int * 2channels = 32 MB/s I'm sure now that my drive can keep up with recording and replaying the 32 MB/s and I guess that even 64 with my new, xfs formatted clean disk is fine my problem is that in both cases ( both using complex and interleaved shorts) If I work with a 4 MHz bandwidth everything looks allright. I can record and replay a 4 MHz fm band and perfectly listen to the station at the center of it when sending it back to the receiver but when I try to go 8 MHz I can hear a noisy, extremely weak replica of my signal, which is SLOW... like an old cassette player with flat batteries and this is consistent with the fact that a file meant to last 10.717 secs @ 32MB/s, when played with usrp_interp= 16 (8MHz Bandwidth) lasts MORE than 13 secs, while if played with usrp_interp=32 (4MHz), it lasts exactly the double of the correct value ie: 10.717*2=21.434 has this ever happened to anybody.. am I making huge mistakes that I havent discovered yet? thanks vincenzo On Wed, 2007-09-05 at 13:15 -0700, Firas abbas wrote: > Hi Vincenzo, > > Sorry for this delay, but I didn't saw your email in the mailing list > which I usually check. To solve your problem do : > > 1) Buy SATA II harddisk drive > 2) Put Linux in ext3 partition > 3) Create a small Ext2 partition for your recordings (about > 4Gbyte) > 4) Whenever you want to record or replay data use this ext2 partition > 5) When you want to record a new file, move the old file from the Ext2 > partition to another partition Ext3. Always keep in mind that the ext2 > partition should be totally empty before any new recording. Also don't > forget to empty the Trash after each file deletion from the Ext2 > partition. > > I hope I made it clear. For more information send me an email. > > Best regards, > > Firas > > > Vincenzo Pellegrini wrote: > On Mon, 2007-09-03 at 20:04 -0700, Eng. Firas wrote: > > Hi Vincenzo, > > > > > > 1) What is your recording system (PC specifications)?. > > 2) How fast your hard drive can read/write data? because > working with 8MHz > > means that your hard drive must be able to sustain writing > 32MByte/sec? > > 3) Do you use ext2 or ext3 ? Ext2 is very efficient in > writing. > > 4) Are you recording complex or interleaved Short 8 MHz > samples? > > > > Firas > > first of all thanks for listening Firas,
Re: [Discuss-gnuradio] sound card rate
Eric Blossom wrote: > Whoever wrote this piece of code failed to provide the > standard -O command line option to specify the audio output > device. If it were provided, then -O plughw:0,0 would most likely > fix your problem. Um, that would be me. I'll add this when I complete ticket:183. -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 8MHz Tx Bandwidth.. Nightmare and Fear
I'm recording and replaying interleaved shorts @ 8Msps.. how is the benchmarking software called? I also have noticed a diffference between my main, old gnuradio installation and a fresh one just done from trunk on another disk... the fisrt is all right with transmissions up to 4 MHz the second stops at 2MHz, (using the same scripts of mine on both installations): when, on the fresh installation, I ask for 4MHz I can hear only noise being sent out (I think this is a different problem than the slow flow).. I'm a bit confused... thanks vincenzo 2007/9/7, Firas abbas <[EMAIL PROTECTED]>: > > Hi Vincenzo, > > Are you recording the 8Msps complex or short ?. In recording, I always > prefer the interleaved complex short, because the real coming samples from > the USRP across the USB is 16 bit short. The conversion to float (32 bit) > complex is being done by software in the PC and thus adds no new information > and does not enhance the data. It only complicate file storage process. If > converting to short does not solve your problem, try to record and play > smaller bandwidth like 6.4MHz (decimation 10) or less. Also test your > PC USB 2 speed by using the benchmark software found the gnuradio truck. > > Best Regards, > > Firas > > *Vincenzo Pellegrini <[EMAIL PROTECTED]>* wrote: > > hi Firas, thanks for help! > > i'm doing pretty much everything you suggested, and in fact, really!!, I > do think that my HD is doing a very good work. > > nevertheless I keep having the same problem, > this is what I also posted to the list: > > > > > > > > > > I finally have a 7200rpm disk that does keep up very well with 32MBps > and, I guess, even much more.. > > is then this assumption correct? > > 8Msps with gr_complex data type ==> 8e6*8bytes per sample = 64 MB/s > > 8Msps with interleaved shorts ==> 8e6*2bytes per int * 2channels = 32 > MB/s > > I'm sure now that my drive can keep up with recording and replaying the > 32 MB/s > and I guess that even 64 with my new, xfs formatted clean disk is fine > > my problem is that in both cases ( both using complex and interleaved > shorts) > > If I work with a 4 MHz bandwidth everything looks allright. > I can record and replay a 4 MHz fm band and perfectly listen to the > station at the center of it when sending it back to the receiver > > but > > when I try to go 8 MHz I can hear a noisy, extremely weak replica of my > signal, which is SLOW... like an old cassette player with flat batteries > > and this is consistent with the fact that a file meant to last 10.717 > secs @ 32MB/s, when played with usrp_interp= 16 (8MHz Bandwidth) > lasts MORE than 13 secs, while if played with usrp_interp=32 (4MHz), > it lasts exactly the double of the correct value ie: 10.717*2=21.434 > > has this ever happened to anybody.. am I making huge mistakes that I > havent discovered yet? > > thanks > > vincenzo > > > On Wed, 2007-09-05 at 13:15 -0700, Firas abbas wrote: > > Hi Vincenzo, > > > > Sorry for this delay, but I didn't saw your email in the mailing list > > which I usually check. To solve your problem do : > > > > 1) Buy SATA II harddisk drive > > 2) Put Linux in ext3 partition > > 3) Create a small Ext2 partition for your recordings (about > > 4Gbyte) > > 4) Whenever you want to record or replay data use this ext2 partition > > 5) When you want to record a new file, move the old file from the Ext2 > > partition to another partition Ext3. Always keep in mind that the ext2 > > partition should be totally empty before any new recording. Also don't > > forget to empty the Trash after each file deletion from the Ext2 > > partition. > > > > I hope I made it clear. For more information send me an email. > > > > Best regards, > > > > Firas > > > > > > Vincenzo Pellegrini wrote: > > On Mon, 2007-09-03 at 20:04 -0700, Eng. Firas wrote: > > > Hi Vincenzo, > > > > > > > > > 1) What is your recording system (PC specifications)?. > > > 2) How fast your hard drive can read/write data? because > > working with 8MHz > > > means that your hard drive must be able to sustain writing > > 32MByte/sec? > > > 3) Do you use ext2 or ext3 ? Ext2 is very efficient in > > writing. > > > 4) Are you recording complex or interleaved Short 8 MHz > > samples? > > > > > > Firas > > > > first of all thanks for listening Firas, > > I'm using a sempron 3000+, 512MiB of Ram, and the HD is a IDE > > with ext3, > > and yes, 32MB/s is at is nominal limit... I'm using complex > > samples.. > > > > to bypass the "slow hd problem" before buying a new one, I was > > just > > storing a very few secs of my sample stream to the ram before > > sending it > > out.. > > > > in the next stage of my work I will need an hd which is very > > fast in > > reading a 32MB/s complex sample stream... what would you > > suggest for the > > kind of HD and for the filesystem? > > > > > > > > > Vincenzo Pellegrini wrote: > > > > > > > > Matt, > > > > > > > > > > > > Tonight > > > > I have been recording slices of commercial FM spectrum, > > all centered
