[Discuss-gnuradio] Re: 'BoxSizer' object has no attribute 'AddStretchSpacer'
Hello Sir, Actually i was trying to install python-wxPython-2.8.9.1-1.el4.pp.src.rpm but somehow it could not be build.So i had to go with the wx-2.5.3-gtk2-ansi.Even i had tried with the wx-2.8.3-gtk2-ansi but python 2.4 (abi) is required.Can u just tell me what should i do??In which directory does the rpm python-wxPython-2.8.9.1-1.el4.pp.src.rpm gets installed.I m having problem with the usrp_fft.py program only. I am really very new to the Gnuradio installation.So kindly help me out. -- Posted via http://www.ruby-forum.com/. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] unknown peak in the FFT-Plot Sink
Hi All, in all the examples and in my own gnuradio Programm, there is an unknown Peak in the FFT-Plot sink. Here is the Screenshot: http://img257.imageshack.us/img257/8017/nochstrender.jpg How to avoid this ? Wherefrom does this come ? I attach my Program to this mail, but i think it is still ok. I need this to measure the power of the noise. Further on you see the noise has a wave form always in the middle of the FFT-Plot, still when i watch another spectrum. In the gnuraio example from Eric Blossom this doesn't appear, but this example only use a sin-signal-source not a usrp-source. How to avoid this ? I tried to change the decimation and the sample Rate, but doesn't solved this. Regards Markus #!/usr/bin/env python # encoding: utf8 Title:Mehrfrequentes Impulsmessverfahren mit FPGA- gestützten SDR-(Software definded radio)-Komponenten. Beschreibung: Mit Hilfe dieses Programmes soll ein mehrfrequentes Impulsmessverfahren entwickelt werden, womit Teilentladungen an Hochspannungsisolationen nachgewiesen werden können. __title__='Mehrfrequentes Impulsmessverfahren' __author__='Markus Feldmann' __version__='Diplom WS08/09 Ver.:2009-03-09-01' __license__='GPL' from gnuradio import gr from gnuradio import usrp from gnuradio.wxgui import fftsink2 from grc_gnuradio import usrp as grc_usrp from grc_gnuradio import wxgui as grc_wxgui from optparse import OptionParser from usrpm import usrp_dbid import sys import time import wx class uebertragungschar_LF_RX(grc_wxgui.top_block_gui): def __init__(self, options): grc_wxgui.top_block_gui.__init__(self, __title__+' - '+__author__+' - '+__version__) ## # DEBUG ## self.debug = options.debug if self.debug is True: print 'DEBUG: start debug modus.' ## # Parameters ## self.usrp_freq = options.usrp_freq self.usrp_freq_min = options.usrp_freq_min self.usrp_freq_max = options.usrp_freq_max self.decim = options.usrp_decim ## # Variables ## self.middle_freq_fft_plot = self.usrp_freq self.gain_usrp_source = 0 The Argument options.dev must be converted into the intern ID, so that we can select the device. The ID will be saved in this variable: self.selected_device = None ## # Blocks ## # self.gr_complex_to_real_0 = gr.complex_to_real(1) self.usrp_source = usrp.source_c(which=0, decim_rate=self.decim) ## # Further Variables ## Because we do not know where the LF_RX(for example) is placed, we have to search for it and select it. First we have to get the intern ID. For example we search after LF_RX and get an ID like (1, 0), this means the LF_RX is placed onto side B and there at RXB. (0, 0)--side A/RXA (0, 1)--side A/TXA (1, 0)--side B/RXB (1, 1)--side B/TXB After we found the device and got the intern ID, we select it. if options.device=='LFRX': self.device_found = usrp.pick_subdev(self.usrp_source, (usrp_dbid.LF_RX,)) if self.debug: print 'DEBUG: self.device_found is ',self.device_found self.selected_device = usrp.selected_subdev(self.usrp_source, self.device_found) if self.debug: print 'DEBUG: self.selected_device is ',self.selected_device elif options.device=='BasicRX': self.device_found = usrp.pick_subdev(self.usrp_source, (usrp_dbid.BASIC_RX,)) if self.debug: print 'DEBUG: self.device_found is ',self.device_found self.selected_device = usrp.selected_subdev(self.usrp_source, self.device_found) if self.debug: print 'DEBUG: self.selected_device is ',self.selected_device else: print 'ERROR: You selected an illegal device named: ',options.device parser.print_help() sys.exit(1) self.mux_value = usrp.determine_rx_mux_value(self.usrp_source,self.device_found) if self.debug: print 'DEBUG: self.mux_value',self.mux_value We have to calculate the fftp_rate which is equal to the usrp_rate. At adc_rate=64MS/s and decim=250 we get an usrp_rate of 256 kS/s self.usrp_rate = (self.usrp_source.adc_rate() / self.decim ) / 2 if self.debug: print 'DEBUG: self.decim is ',self.decim if self.debug: print 'DEBUG: self.usrp_source.adx_rate is ',self.usrp_source.adc_rate() if self.debug: print 'DEBUG: self.usrp_rate is ',self.usrp_rate ## # Futher Blocks ## # self.gr_throttle_0 = gr.throttle(gr.sizeof_float*1, self.usrp_rate) self.usrp_source.set_mux(self.mux_value) self.wxgui_fftsink2 = fftsink2.fft_sink_c( self.GetWin(),
Re: [Discuss-gnuradio] USRP2 - BasicTX first Nyquist zone frequencies
Hi Eric, I solved the problem using your suggestion. I changed the line 76 at u2_init.c: from: ad9777_write_reg(1, R1_INTERP_4X | R1_REAL_MIX); to: ad9777_write_reg(1, 0xB0 | R1_REAL_MIX); Then, I was able to tx frequencies higher than 50 MHz - [50,100] MHz. Thanks a lot! :D ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Can threading disturb sensing continuety
Thanks Ed, ADC sampling rate = 64MHz it gives resulution time = 1/64MHz = 156 ns if we choose N=512 for FFT then total observation time for one scan(one complete FFT) is = 156ns x 512 = 8 micro sec if the maximum possible (expected) cycle time is 200ms then: it needs 200ms/8microsec = 2500 continues FFT scans to cover the range of frequencies that correspond to 200ms cycle time. Is above calculation correct? The other possibility to increase the observation time is to increase the FFT size, but to cover entire 200ms would need 200ms/1/64MHz = 1280 = FFT size (Which is not possible! Is it ???) Now please comment if my above calculations are correct or not and secondaly if my calculations are correct then how can I process (using GNURadio) 2500 cosective FFT's (with surety that no FFT in between these 2500 FFT's is missing due to slow processing or thread switching) to find two peaks in a single array (availability of two peaks will give me the oppertunity to calculate the time distance between them). Thanks and Best Regards Ed Criscuolo-2 wrote: kaleem ahmad wrote: 3- Can you suggest some different way to solve this problem, The problem is simply to calculate the cycle time of some system which is already working in the environment Since your unknown FSK signal has a regular cycle time, it should be relatively easy to detect. For example, if your signal has a 1 ms cycle time, the low frequency spectrum should exhibit a large spike at 1 KHz. It seems that all you would need is an fft that covers the range of frequencies that correspond to your possible cycle times. @(^.^)@ Ed ___ 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/Can-threading-disturb-sensing-continuety-tp22598748p22620394.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
[Discuss-gnuradio] how to exactly determine the current value in the FFT-Plot sink
Hi All, i want to determine the value of the shown signal in my FFT-Plot sink as exactly as i can. The reading error is to big. If i could zoom into the FFT-Plot sink it would be better, but i don't know how to zoom in. It would be nicer to read the value of the middle of the FFT-Plot by any python function. Any Hints ? Regards Markus ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] running python tests
Dear all, I just installed gnuradio and a USRP. When running the python tests such as the one bellow I am getting the following error message that seems to do with some upgrade: test_dft_synth.py usrp_tv_rcv.py %: ~/gnuradio-3.1.3/gnuradio-examples/python/usrp$ ./test_dft_analysis.py Traceback (most recent call last): File ./test_dft_analysis.py, line 4, in module from gnuradio.wxgui import stdgui2, fftsink2, slider ImportError: cannot import name stdgui2 Could anyone help? Thanks, Djamel ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Can threading disturb sensing continuety
On Fri, Mar 20, 2009 at 9:34 AM, kaleem ahmad kaleem_...@yahoo.com wrote: Thanks Ed, ADC sampling rate = 64MHz it gives resulution time = 1/64MHz = 156 ns if we choose N=512 for FFT then total observation time for one scan(one complete FFT) is = 156ns x 512 = 8 micro sec if the maximum possible (expected) cycle time is 200ms then: it needs 200ms/8microsec = 2500 continues FFT scans to cover the range of frequencies that correspond to 200ms cycle time. Is above calculation correct? The other possibility to increase the observation time is to increase the FFT size, but to cover entire 200ms would need 200ms/1/64MHz = 1280 = FFT size (Which is not possible! Is it ???) Now please comment if my above calculations are correct or not and secondaly if my calculations are correct then how can I process (using GNURadio) 2500 cosective FFT's (with surety that no FFT in between these 2500 FFT's is missing due to slow processing or thread switching) to find two peaks in a single array (availability of two peaks will give me the oppertunity to calculate the time distance between them). It sounds like you're trying to do autobaud for an unknown FSK system - but using the frequency domain to do this instead of the time domain phases. I'd recommend thinking of an algorithm in the time domain that would suit your needs. Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DBPSK and Carrier Suppressed or Not?
As a follow upI did some popping and swapping and found that the RFX 900 board was bad. I put in a RFX 2400 card and the the very pronouced carrier I saw before dissappeared and the signal transmitted out of the RFX brd looked liked the signal coming out of the modulator. I was able send a text file over the RFX brd and rx it on the other side. I guess there is nothing that can be done to bring the other board back online...I didn't see any pots on it. Even though I was able to transmit a text file, parts of it was garbled on the other end.any suggestions for tighting things up to take out the garble? This test took place on one usrp with two RFX 2400 brds and using a cable to connect the transmit side of one card to the receive side of the other card. I will next try between two usrps via coax and then OTA. Also I had to take out the channel filter because the signal out of it would start up and then would die after about 10 to 20 seconds ( Channel filter = FFT filter - Decimanation=1, TAPS = lowpass(1,2,1, .5, WIN_HAMMING)) With the RFX 900 I was tranmitting at 800Mhz and with the RFX 2400 I'm tranmitting at 2.5 GHz...Mod - DBPSKAny thoughts or suggestions? Cheers, Jody On Wed, Mar 18, 2009 at 5:23 PM, Bill Stevenson bill.stevenso...@yahoo.comwrote: -- *From:* Eric Blossom e...@comsec.com *To:* w w biscuitk...@gmail.com *Cc:* discuss-gnuradio@gnu.org *Sent:* Wednesday, March 18, 2009 4:30:04 PM *Subject:* Re: [Discuss-gnuradio] DBPSK and Carrier Suppressed or Not? On Wed, Mar 18, 2009 at 02:55:41PM -0400, w w wrote: I'm putting together a DBPSK Tx and Rx and running into problems when the modulated signal hits the USRP. When I receive the signal on the USRP there's a very pronouced carrierI've confirmed with a spectrum analyser that the signal on the FFT is the one that I'm recieving. It seems to me that the sidebands should be close to the highest amplitute and the carrier should be suppressed.is this correct? Shouldn't the output of the DPSK modulator FFT plot look very similar to the FFT plot on the RX side of the usrp? I'm modeling the block connections after the benchmark samples in the digital example section. I put a channel filter inline with the usrp and the dpsk demod block just like the example.do I need to put more filtering in place to suppress the carrier? If so, do you have any examples? If I take the output of the modulator and go directly to the demod thru the channel filter, data flows just fine(bypassing the usrp). I'm only using one usrp and taking the output of the TX via coax and going into the RX side...that shouldn't make a difference should it? Any thoughts? Cheers, Jody Before writing your own, did you take a look at the implementation of dbpsk that's already in the tree? See the -m dbpsk option below $ ./benchmark_tx.py --help Usage: benchmark_tx.py [options] Options: -h, --helpshow this help message and exit -m MODULATION, --modulation=MODULATION Select modulation from: cpm, d8psk, qam8, dbpsk, dqpsk, gmsk [default=gmsk] -s SIZE, --size=SIZE set packet size [default=1500] -M MEGABYTES, --megabytes=MEGABYTES set megabytes to transmit [default=1.0] --discontinuous enable discontinous transmission (bursts of 5 packets) --from-file=FROM_FILE use file for packet contents -f FREQ, --freq=FREQ set Tx and/or Rx frequency to FREQ [default=none] -r BITRATE, --bitrate=BITRATE specify bitrate. samples-per-symbol and interp/decim will be derived. -w WHICH, --which=WHICH select USRP board [default=0] -T TX_SUBDEV_SPEC, --tx-subdev-spec=TX_SUBDEV_SPEC select USRP Tx side A or B --tx-amplitude=AMPL set transmitter digital amplitude: 0 = AMPL 32768 [default=12000] -v, --verbose Expert: -S SAMPLES_PER_SYMBOL, --samples-per-symbol=SAMPLES_PER_SYMBOL set samples/symbol [default=none] --tx-freq=FREQ set transmit frequency to FREQ [default=none] -i INTERP, --interp=INTERP set fpga interpolation rate to INTERP [default=none] --log Log all parts of flow graph to file (CAUTION: lots of data) --use-whitener-offset make sequential packets use different whitening --excess-bw=EXCESS_BW set RRC excess bandwith factor [default=0.35] (PSK) --no-gray-code disable gray coding on modulated bits (PSK) --bt=BTset bandwidth-time product [default=0.35] (GMSK) -B FUSB_BLOCK_SIZE, --fusb-block-size=FUSB_BLOCK_SIZE specify fast usb block size [default=0] -N FUSB_NBLOCKS, --fusb-nblocks=FUSB_NBLOCKS
Re: [Discuss-gnuradio] Can threading disturb sensing continuety
Thank Brian, Can you give some hint, what do mean ??? I mean a little idea what do you want to say? Best Regards Brian Padalino wrote: On Fri, Mar 20, 2009 at 9:34 AM, kaleem ahmad kaleem_...@yahoo.com wrote: Thanks Ed, ADC sampling rate = 64MHz it gives resulution time = 1/64MHz = 156 ns if we choose N=512 for FFT then total observation time for one scan(one complete FFT) is = 156ns x 512 = 8 micro sec if the maximum possible (expected) cycle time is 200ms then: it needs 200ms/8microsec = 2500 continues FFT scans to cover the range of frequencies that correspond to 200ms cycle time. Is above calculation correct? The other possibility to increase the observation time is to increase the FFT size, but to cover entire 200ms would need 200ms/1/64MHz = 1280 = FFT size (Which is not possible! Is it ???) Now please comment if my above calculations are correct or not and secondaly if my calculations are correct then how can I process (using GNURadio) 2500 cosective FFT's (with surety that no FFT in between these 2500 FFT's is missing due to slow processing or thread switching) to find two peaks in a single array (availability of two peaks will give me the oppertunity to calculate the time distance between them). It sounds like you're trying to do autobaud for an unknown FSK system - but using the frequency domain to do this instead of the time domain phases. I'd recommend thinking of an algorithm in the time domain that would suit your needs. Brian ___ 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/Can-threading-disturb-sensing-continuety-tp22598748p22621780.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
[Discuss-gnuradio] DQPSK Mod/Demod and Garbled Text
In GRC I'm setting up a flow graph to modulate and demodulate a text file (simulation and without the USRP). DBPSK and D8PSK runs just fine , however with DQPSK I get the text but it is garbled in places? Since it's the same flow graphs, with the only differnece being menu picks in the mod and demod blocks, could this be a bug? Also.I'm doing the same thing for BPSK and was wondering if I can use the Packet encoder and decoder with the MPSK reciever? If so, how do I do the type conversion from complex to byte? Cheers, Jody ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] unknown peak in the FFT-Plot Sink
Use an Intermediate Frequency (IF) and frequency translating filter. Paul Mathews -Original Message- From: Markus Feldmann [mailto:feldmann_mar...@gmx.de] Sent: Friday, March 20, 2009 5:06 AM To: gnu radio mailing list Subject: [Discuss-gnuradio] unknown peak in the FFT-Plot Sink Hi All, in all the examples and in my own gnuradio Programm, there is an unknown Peak in the FFT-Plot sink. Here is the Screenshot: http://img257.imageshack.us/img257/8017/nochstrender.jpg How to avoid this ? Wherefrom does this come ? I attach my Program to this mail, but i think it is still ok. I need this to measure the power of the noise. Further on you see the noise has a wave form always in the middle of the FFT-Plot, still when i watch another spectrum. In the gnuraio example from Eric Blossom this doesn't appear, but this example only use a sin-signal-source not a usrp-source. How to avoid this ? I tried to change the decimation and the sample Rate, but doesn't solved this. Regards Markus ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Can threading disturb sensing continuety
On Fri, Mar 20, 2009 at 11:30 AM, kaleem ahmad kaleem_...@yahoo.com wrote: Thank Brian, Can you give some hint, what do mean ??? I mean a little idea what do you want to say? FSK is all about delta phase shifts. If a mark is a + frequency, and a space is a - frequency (or vice versa, your choice), then I would think it would be easy to keep track of how large the deltas between phases were and when they happened. Since you're expecting random data, you should be able to average some information and - voila; autobaud. Right? What do you think? I don't want to detract you from your FFT algorithm if you feel that is better suited. I've never done autobaud before, so this was just a random thought. Good luck. Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Can threading disturb sensing continuety
On Fri, Mar 20, 2009 at 10:11 AM, Brian Padalino bpadal...@gmail.com wrote: FSK is all about delta phase shifts. If a mark is a + frequency, and a space is a - frequency (or vice versa, your choice), then I would think it would be easy to keep track of how large the deltas between phases were and when they happened. A common, non-coherent method for FSK demodulation and baud rate detection is to multiply each succeeding sample by the complex conjugate of the preceding sample, then take the phase of the product. This turns the sample series into baseband level shifts. If you are at zero IF, then the sample stream will be roughly symmetrical about zero (frequency offsets are turned into DC offsets, though). From here you can use zero crossings to estimate baud rate and integration between transitions to improve noise performance. The success of this technique relies on sufficient zero crossing density, and has a higher bit error rate than coherent detection and demodulation. GNU Radio has a block, gr.quadrature_demod_cf, that does the first portion of this, taking a complex baseband stream, doing the conjugate multiply and arctan, and outputting a float stream of demodulated samples. An example is in gr-pager, where the FLEX pager protocol's 4-level FSK is first processed by it. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Using one USRP
Hi Ali - Check out the following MS thesis, by a ex-colleague of mine here at ND: Practical Implementation of a Cognitive Radio System for Dynamic Spectrum Access http://etd.nd.edu/ETD-db/theses/available/etd-07252008-162749/ It sounds similar to what you're talking about, and certainly worth a look-through IMHO. - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Can threading disturb sensing continuety
On Fri, Mar 20, 2009 at 1:27 PM, Johnathan Corgan jcor...@corganenterprises.com wrote: A common, non-coherent method for FSK demodulation and baud rate detection is to multiply each succeeding sample by the complex conjugate of the preceding sample, then take the phase of the product. This turns the sample series into baseband level shifts. If you are at zero IF, then the sample stream will be roughly symmetrical about zero (frequency offsets are turned into DC offsets, though). From here you can use zero crossings to estimate baud rate and integration between transitions to improve noise performance. The success of this technique relies on sufficient zero crossing density, and has a higher bit error rate than coherent detection and demodulation. Assuming an FSK system with unknown frequency separation and baudrate, is the above algorithm robust enough to determine said parameters to then pass along to a coherent demodulator to achieve a better BER? I would assume yes - since you're just taking a quick guess/estimate and letting the coherent demodulator actually timetrack, figure out the bits, etc. Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] tunnel.py buffer crash
On Thu, Mar 19, 2009 at 09:12:00PM -0700, Eric Blossom wrote: On Thu, Mar 19, 2009 at 08:50:13PM -0700, yyzhuang wrote: I'm sorry. If we do ./tunnel and ping between two boxes over the air, both tx and rx breaks after a few ICMP packets exchange. They don't break at the same time though, but it does happen every time. If we do over channel emulator (by connecting the antenna of USRP to the emulator), we can ping the two machines much longer, but it still breaks. Sorry again, no offense. I didn't mean to be rude or something. No problem. I didn't take it that way. I'm busy with something else right now, but I think I can get you some instrumented code that will locate the offending block sometime tomorrow. It's great news that it fails regularly for you! Eric We fixed a bug yesterday in gr_clock_recovery_mm_ff.cc [10646], which is used by the GMSK demodulator, and which could be causing the problem you are seeing. Can you please checkout a copy of the trunk, build and install it and try to reproduce the problem you've been seeing? Thanks! Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] I/O lines standards
I'm just checking so's I don't destroy my USRP mboard. The I/O lines such as io_tx_13 etc. that are available on the flex 2400's seem to go straight to the Cyclone FPGA. If that's the case, are they set to LVCMOS or LVTTL? And, is the voltage used 3.3 V? I think I read the answer on the schematics, but I need to check! Thanks, All. -- Dr. Don Latham AJ7LL Six Mile Systems LLP 17850 Six Mile Road POB 134 Huson, MT, 59846 VOX 406-626-4304 www.lightningforensics.com www.sixmilesystems.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] I/O lines standards
Don Latham wrote: I'm just checking so's I don't destroy my USRP mboard. The I/O lines such as io_tx_13 etc. that are available on the flex 2400's seem to go straight to the Cyclone FPGA. If that's the case, are they set to LVCMOS or LVTTL? And, is the voltage used 3.3 V? I think I read the answer on the schematics, but I need to check! Thanks, All. They go straight to the FPGA. They are 3.3V CMOS. Don't pull more than about 5mA. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Can threading disturb sensing continuety
On Fri, Mar 20, 2009 at 10:33 AM, Brian Padalino bpadal...@gmail.com wrote: Assuming an FSK system with unknown frequency separation and baudrate, is the above algorithm robust enough to determine said parameters to then pass along to a coherent demodulator to achieve a better BER? Yes, though perhaps not in low SNR situations. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Status of GNURadio + GPU (specifically CUDA)
I noticed there was some work in this area being done by Martin Dudok van Heel in the developers branch of the repository. Can anyone comment on what has been done so far in this area and what kind of speeds they are getting now? Thanks in advance, Isaac -- View this message in context: http://www.nabble.com/Status-of-GNURadio-%2B-GPU-%28specifically-CUDA%29-tp22630060p22630060.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] Using one USRP
Michael Dickens wrote: Hi Ali - Check out the following MS thesis, by a ex-colleague of mine here at ND: Practical Implementation of a Cognitive Radio System for Dynamic Spectrum Access http://etd.nd.edu/ETD-db/theses/available/etd-07252008-162749/ It sounds similar to what you're talking about, and certainly worth a look-through IMHO. - MLD Sounds like an interesting paper but the website requires a Notre Dame password to download the file. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] No Packet Reception for benchmark_rx and No PINGing for tunnel.py
Hi, I completed the installations and checked tone generation and benchmark_tx/rx over a pair of usrp, along with usrp_wfm_rcv.py for or FM reception. These examles ran pretty fine. Then I tried tunnel.py with command line arguments as in README file: ./tunnel.py -f 423.0M --bitrate=500k The output was a series of 'B', stating no carrier sensing. I reduced the carrier freauency to 10 M and tried running it again. This time, there was no 'B' sequence and the output of first machine was: gr_fir_fff modulation: gmsk frequency: 10M bitrate: 500kb/sec sample/symbol: 2 Carrier Sense Threshold: 30dB Allocated Virtual Network Interface: gr0 Then, after ifconfig on another terminal window, first window showed: Tx: len(payload) = 90 Tx: len(payload) = 54 Rx: ok = false len(payload) = 90 Tx: len(payload) = 289 Tx: len(payload) = 193 Tx: len(payload) = 289 Tx: len(payload) = 78 Tx: len(payload) = 289 Tx: len(payload) = 265 Rx: ok = false len(payload) = 265 and so on.. The output of the second machine was identical, except there was NO Rx: ok = true/false len(payload) = xx in that. When I pinged one machine with other, the following error message appeared: PING 192.168.200.1 (192.168.200.1) 56(84) bytes of data From 192.168.200.2 icmp_seq=1 Destination Host Unreachable (Till icmp_seq=32, when I disconnected). After that, I am able to run usrp_wfm_rcv.py, but when I again ran benchmark_rx.py and benchmark_tx.py, following is the output with NO packet reception: (Please note, earlier I used same command line arguments and got some packets received) I call benchmark_rx on my usrp and leave it running, $ python ./benchmark_rx.py -f 10M -R A --rx-gain=70 -v -r 500K bits per symbol = 1 MM clock recovery omega = 2.00 MM clock recovery gain mu = 0.175000 MM clock recovery mu = 0.50 MM clock recovery omega rel. limit = 0.005000 frequency error = 0.00 Receive Path: Using RX d'board A: Basic Rx Rx gain: 70 modulation: gmsk_demod bitrate: 250kb/s samples/symbol: 2 decim: 128 Rx Frequency: 10M I then call benchmark_tx on my second usrp, $ python ./benchmark_tx.py -TA -f 10M -r 500k -v --tx-amplitude=2 gr_fir_fff: using SSE bits per symbol = 1 Gaussian filter bt = 0.35 Using TX d'board A: Basic Tx Tx amplitude 2.0 modulation: gmsk_mod bitrate: 500kb/s samples/symbol: 2 interp: 128 Tx Frequency: 10M This shows packets are apparently being transmitted. However when I checked the console of second machine for benchmark_rx, no packet notifications are being displayed. My Questions: 1- Is the USRP transmitting data? 2- Why is it not receiving this data if it is transmitting? 3- Do 'Carrier Sensing' has something to do with frequency, in tunnel.py? -Ahmed___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Fwd: Re: [Discuss-gnuradio] I/O lines standards]
Hello the list: I need to use the digital I/O from my 2400 daughterboard to drive a sequencer for a t/r system. I wanted to convert the USRP lines to 5 V safely. I tried 5 Fairchild type H11L1 optoisolators, current production, available from Digi-Key, in a test setup. Put a 1k ohm resistor in series with the input diode. All 5 drew less than 2 ma current at 3.3 volts, and switched state from low to high at .8 to .9 ma (about 2.7 volts). According to the spec less than 5 ma drain per line, these will be safe to use as output buffering and transition to 5v logic. Note that they will be high (5 v) with the inputs at either 3-state or low. To use 5v logic with the USRP lines as inputs, use the Fairchild driving a voltage divider to yield about 2.5 volts to the input pin. Note the Altera device is operating as LVCMOS so it will not draw enough current to unbalance the divider. The H11L1 is an open collector output, so a simple divider with 2 1k resistors or even larger should work fine. With the H11L1 connected to a 5v supply, no condition will exceed the 5 ma limit. Note that you can use the USRP lines directly with any of the PIC processors that run on 3.3 volts. I still suggest optoisolation just because there are two different power supplies involved... Naturally, I'm not assuming any responsibility if your USRP gets goofed :-) Don Original Message Subject: Re: [Discuss-gnuradio] I/O lines standards From:Matt Ettus m...@ettus.com Date:Fri, March 20, 2009 15:36 To: Don Latham d...@montana.com -- 5 each Don Latham wrote: Sorry, Matt, one more Q? 5 ma/line or 5 ma total? Thanks v much for your time! Don Matt Ettus Don Latham wrote: I'm just checking so's I don't destroy my USRP mboard. The I/O lines such as io_tx_13 etc. that are available on the flex 2400's seem to go straight to the Cyclone FPGA. If that's the case, are they set to LVCMOS or LVTTL? And, is the voltage used 3.3 V? I think I read the answer on the schematics, but I need to check! Thanks, All. They go straight to the FPGA. They are 3.3V CMOS. Don't pull more than about 5mA. Matt -- Dr. Don Latham AJ7LL Six Mile Systems LLP 17850 Six Mile Road POB 134 Huson, MT, 59846 VOX 406-626-4304 www.lightningforensics.com www.sixmilesystems.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Using one USRP
Sounds like an interesting paper but the website requires a Notre Dame password to download the file. I apologize; I didn't realize that website was password protected (it didn't ask me ;) Here's another: http://www.nd.edu/~jnl/pubs/crohas-ms-nd-2008.pdf ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Using one USRP
Hi Ali, I have done the similar as a part in my thesis as well. But I used two USRPs to serve as receiver and transmitter. When u try to listen on a daughter board using same USRP and transmit simultaneously ( which I tried ) you do not receive the transmitted signal. I did not dwell much on this because I had two USRPs to serve as two users. I know that both tramsitter and receiver programs can be run using two daughter boards. *But the receiver in this case seems to receive only signals send from other USRPs. But signals Transmitted from a diiferent antenna/daughter board on same USRP was not received*. I used this isolation for my benefit to run a scanner simultaneously to detect signal from while transmission is going on. I do not know if this isolation can be removed by changing some parameters. I do not have access to my boards now will try it next week and let you know.But I would recommend you to search the archive there are some related discussions. Thank you Swapna 2009/3/20 ali siddiqi chain...@gmail.com Hi I am trying to implement a cognitive radio system for dynamic spectrum access. I am trying to implement it in GNU radio. But the problem is that i have only one USRP at the moment with Basic RX and TX daughterboards. The setup consists of Station A transmitting to Station B. In order to be able to use the licensed spectrum, the transmitter must know which channels are free in the vicinity. Thus it has to do a parallel detection of spectrum as well---receiver mode. The Transmitter first senses the spectrum for some time say 10ms and then transmits on the free frequency for say 90 ms before sensing the spectrum again and so on. Thus the following questions arise: 1. Can the Station B be implemented on the same USRP when the Station A is only transmitting[not sensing(recieving)]? 2. What effects would this have on the Data Rates and any problem with the USB interface? Is there any built in example within gnuradio with which i can test the simultaneous transmission and reception from the BasicTX to the BasicRX respectively on the same usrp? Regards, Ali ___ 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
[Discuss-gnuradio] usrp2 reference clock
Hi, I'm a new comer to usrp2. If we want to use a reference 10MHz clock instead of 100MHz, is there any hardware modification needed? Now I only change the fpga_master_clock_freq in usrp2_impl.cc from *freq = 1L to *freq = 1000L. I tried to send digital signal in gnuradio-example/python/digital, but it doesn't work, the signal is still the same as before. Is there any suggestion? Thanks very much! Jin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
