Re: [Discuss-gnuradio] XCVR in the 2.2Ghz range
On Sun, 2008-11-16 at 20:42 -0500, Marcus D. Leech wrote: > How easily can the RFX1800 or RFX2400 be modified to operate around > 2.2Ghz? This is for a potential S-band satellite > project operating near that frequency. This is straightforward; I did an S-band satellite groundstation transceiver this way earlier this year. It's a matter of replacing the ADF4360 with a different rev. of the same chip that operates a lower frequency, and removing the 2.4G ISM filter. -Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] XCVR in the 2.2Ghz range
On Sun, Nov 16, 2008 at 8:42 PM, Marcus D. Leech <[EMAIL PROTECTED]> wrote: > How easily can the RFX1800 or RFX2400 be modified to operate around > 2.2Ghz? This is for a potential S-band satellite > project operating near that frequency. It looks like it uses an ADF4360 as the RX synthesizer. The RFX2400 looks like it has a lower bound at 2400MHz. Others in the family could probably be used: http://www.analog.com/en/rfif-components/pll-synthesizersvcos/adf4360-0/products/product.html Though it's all just handwaving as I haven't done a complete analysis, but it seems like changing that part and some of the db software would do the trick. Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] XCVR in the 2.2Ghz range
How easily can the RFX1800 or RFX2400 be modified to operate around 2.2Ghz? This is for a potential S-band satellite project operating near that frequency. -- Marcus Leech Principal Investigator, Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] BPSK modulatio
hey, I am triying to implement a BPSK link between two USRPs. I had a look to the bench mark code and I tried to implement such a modulator and demodulator except removing differential blocks in both RX and TX. the tx and rx chains are as below : TX :message_from_string->bytes2chunks->symbol_mapper->chunks2symbols->rrc_filter->amlifier->USRP RX : USRP->pre_scaler->AGC->rrc_filter->rec_clock_recovery->Channel_estimator&equaliser->slicer->symbol_mapper->unpack->access_code_correlator->framer_sink I have written a signal processing block which estimates the channel(by correlating the received signal points by access code and estimating based on access code). my problem is I can not receive properly, so, I don't have data in sink_file. first I thought it can be due to SPB, so, I modified the RX above into a two parallel receivers which get the input signal from the same USRP, I mean, I removed the SPB that I had written and 1-in the first chain I multiplied output of USRP_source by ( 1 ) 2- in the second chain I multiplied output of USRP_source by ( -1 ) and the rest of receivers for both paths are the same as mentioned above(again, I have removed SPBs in both receiving paths) I was thinking no matter what is the channel effect(BPSK modulation works based on sign of real part of signal) one of the chains will detect the data but still nothing in the output. now i am really confused what can be the problem of the communication chain I am trying to implement. any hint is appreciated, Mehdi -- View this message in context: http://www.nabble.com/BPSK-modulatio-tp20531949p20531949.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] GnuRadio and CUDA
On Fri, 2008-11-14 at 16:42 -0800, Bob Keyes wrote: > I've just been given a Nvidia Quadro 5600 and I am thinking of using it for > DSP. Has anyone experimented with USRP & gnuradio & cuda? > I have been working on this for quite some time now. I did a glsl implementation a few years back but it didn't perform that well and had some severe limitations. So I started over this year and have reimplemented major part of GnuRadio using CUDA. It is a one to one implementation. (every gr_something block is replaced with a cuda_something block) My work-in-progress code is at: http://gnuradio.org/trac/browser/gnuradio/branches/developers/nldudok1/gpgpu-wip Make sure you read http://gnuradio.org/trac/browser/gnuradio/branches/developers/nldudok1/gpgpu-wip/README.cuda Caleb Phillips made a wiki about my code, you can find it at: http://www.smallwhitecube.com/php/dokuwiki/doku.php?id=howto:gnuradio-with-cuda The majority of the gnuradio-core code is a unmodified gnuradio checkout of a few moths back. There are some important changes in gnuradio_core/src/lib/runtime to support CUDA device memory as an emulated circular buffer. I also implemented a gr.check_compare block which expects two input streams and checks if they are outputting the same data. I use this to check if my cuda blocks do exactly the same as the gr blocks. All the rest of the CUDA code is in gr_cuda. gr_cuda has to be configured and build seperately. gr_cuda is where the cuda reimplementations of some gnuradio blocks are. Then there are also a few new blocks cuda_to_host and host_to_cuda which copy memory from and to the GPU device memory. All python scripts to test and use the code are in /testbed. The code in testbed is changing on a day-by-day basis. There are several issues to be well aware of when doing SDR on a GPU. -overhead -call overhead -copying data from and to the GPU You need to do a lot of work on the GPU in one call to have any benefit. -circular buffers -GPU memory cant't be mmapped into a circular buffer -solution 1: use copying to emulate a circular buffer -solution 2: keep track of all the processing and make your own intelligent scheduler which does not need a circular buffer. -threads: with CUDA you can't access GPU device memory from different host-threads. So make sure you create use and destroy all device memory from the same thread. (The standard GnuRadio scheduler does not do it like this) -debugging: Debugging is hard and works quite different from normal debugging. -parallel: The GPU is good in doing calculations in parallel which are not dependant on each other. For this reason a FIR will perform well, while an IIR will perform bad. An IIR can only use one processing block of the GPU, in stead of 128. It can still be benificial to do the IIR on the GPU when all your other blocks are running on the GPU because you don't have to copy all samples to the CPU, do the IIR on the CPU and copy everything back to the GPU. All that said. I do have a complete WFM receiver which is running completely on the GPU. (using FIR and/or FFT filters, quadrature_demod, fm-deemph) The FFT filters use the cuda provided FFT. It shouldn't be too hard to use the FFT for other things (just look at the code of gr_cuda/src/lib/cuda_fft_*) At the moment the complete wfm receiver is not running faster then on the CPU with my 9600GT card, mainly because of the call overhead. (too little work items done per call) And the extra copying done to emulate circular buffers. I can increase the amount of work done per call by using output_multiple. But with the current scheduling code the flow-graph can hang. This needs work. So the performance will change in the future. First I want to make sure everything is working as expected. If I benchmark a single block with a big output_multiple then I do see performance increases. Greetings, Martin > > ___ > 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: [Discuss-gnuradio] GPU progress?
On Sat, 2008-11-15 at 10:30 -0500, Marcus D. Leech wrote: > What is the current status of GPU support in Gnu Radio? In particular, > a GPUed FFT implementation would be peachy keen. > I have been working on this for quite some time now. I did a glsl implementation a few years back but it didn't perform that well and had some severe limitations. So I started over this year and have reimplemented major part of GnuRadio using CUDA. It is a one to one implementation. (every gr_something block is replaced with a cuda_something block) My work-in-progress code is at: http://gnuradio.org/trac/browser/gnuradio/branches/developers/nldudok1/gpgpu-wip Make sure you read http://gnuradio.org/trac/browser/gnuradio/branches/developers/nldudok1/gpgpu-wip/README.cuda Caleb Phillips made a wiki about my code, you can find it at: http://www.smallwhitecube.com/php/dokuwiki/doku.php?id=howto:gnuradio-with-cuda The majority of the gnuradio-core code is a unmodified gnuradio checkout of a few moths back. There are some important changes in gnuradio_core/src/lib/runtime to support CUDA device memory as an emulated circular buffer. I also implemented a gr.check_compare block which expects two input streams and checks if they are outputting the same data. I use this to check if my cuda blocks do exactly the same as the gr blocks. All the rest of the CUDA code is in gr_cuda. gr_cuda has to be configured and build seperately. gr_cuda is where the cuda reimplementations of some gnuradio blocks are. Then there are also a few new blocks cuda_to_host and host_to_cuda which copy memory from and to the GPU device memory. All python scripts to test and use the code are in /testbed. The code in testbed is changing on a day-by-day basis. There are several issues to be well aware of when doing SDR on a GPU. -overhead -call overhead -copying data from and to the GPU You need to do a lot of work on the GPU in one call to have any benefit. -circular buffers -GPU memory cant't be mmapped into a circular buffer -solution 1: use copying to emulate a circular buffer -solution 2: keep track of all the processing and make your own intelligent scheduler which does not need a circular buffer. -threads: with CUDA you can't access GPU device memory from different host-threads. So make sure you create use and destroy all device memory from the same thread. (The standard GnuRadio scheduler does not do it like this) -debugging: Debugging is hard and works quite different from normal debugging. -parallel: The GPU is good in doing calculations in parallel which are not dependant on each other. For this reason a FIR will perform well, while an IIR will perform bad. An IIR can only use one processing block of the GPU, in stead of 128. It can still be benificial to do the IIR on the GPU when all your other blocks are running on the GPU because you don't have to copy all samples to the CPU, do the IIR on the CPU and copy everything back to the GPU. All that said. I do have a complete WFM receiver which is running completely on the GPU. (using FIR and/or FFT filters, quadrature_demod, fm-deemph) The FFT filters use the cuda provided FFT. It shouldn't be too hard to use the FFT for other things (just look at the code of gr_cuda/src/lib/cuda_fft_*) At the moment the complete wfm receiver is not running faster then on the CPU with my 9600GT card, mainly because of the call overhead. (too little work items done per call) And the extra copying done to emulate circular buffers. I can increase the amount of work done per call by using output_multiple. But with the current scheduling code the flow-graph can hang. This needs work. So the performance will change in the future. First I want to make sure everything is working as expected. If I benchmark a single block with a big output_multiple then I do see performance increases. Greetings, Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GMSK demodulation
i used both gr.quadrature_demod_cf, and gnuradio.blksimpl.gmsk_demod and both demodulation the signal with a lot of noises is there any way to solve the problem and get clean bits? -- Posted via http://www.ruby-forum.com/. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
