Re: [Discuss-gnuradio] usrp2 reference clock
Jin Zhang wrote: 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! The reference clock input is 10 MHz. The master clock for the system is 100 MHz. Which is it that you want to change? Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Error whle performing make check for gnuradio-3.2
Hi all, I am facing th following error while performing make check for gnu radio 3.2: make[4]: Leaving directory `/home/somya/gnuradio-3.2rc1/gnuradio-core/src/tests' make[3]: Leaving directory `/home/somya/gnuradio-3.2rc1/gnuradio-core/src/tests' Making check in python make[3]: Entering directory `/home/somya/gnuradio-3.2rc1/gnuradio-core/src/python' Making check in gnuradio make[4]: Entering directory `/home/somya/gnuradio-3.2rc1/gnuradio-core/src/python/gnuradio' Making check in gr make[5]: Entering directory `/home/somya/gnuradio-3.2rc1/gnuradio-core/src/python/gnuradio/gr' make check-TESTS make[6]: Entering directory `/home/somya/gnuradio-3.2rc1/gnuradio-core/src/python/gnuradio/gr' ...F. == FAIL: test_sub_ii_1 (__main__.test_head) -- Traceback (most recent call last): File "./qa_add_and_friends.py", line 102, in test_sub_ii_1 expected_result, op) File "./qa_add_and_friends.py", line 41, in help_ii self.assertEqual (exp_data, result_data) AssertionError: (-1, -2, -3, -4, -5) != (0, 0, 0, 0, 0) -- Ran 9 tests in 0.015s FAILED (failures=1) -- Ran 32 tests in 0.092s OK .. -- Ran 6 tests in 0.012s OK . -- Ran 1 test in 0.004s OK -- Ran 0 tests in 0.000s OK -- Ran 4 tests in 0.047s OK . -- Ran 1 test in 0.016s OK ... -- Ran 7 tests in 0.013s OK . -- Ran 1 test in 0.002s OK .. -- Ran 2 tests in 0.003s OK .. -- Ran 2 tests in 0.004s OK ... -- Ran 3 tests in 0.218s OK . -- Ran 1 test in 0.002s OK -- Ran 0 tests in 0.000s OK -- Ran 8 tests in 0.001s OK ..>>> gr_fir_ccc: using SSE -- Ran 6 tests in 2.496s OK .. -- Ran 2 tests in 0.010s OK >>> gr_fir_fff: using SSE ... -- Ran 3 tests in 0.008s OK >>> gr_fir_fff: using SSE >>> gr_fir_ccf: using SSE . -- Ran 1 test in 0.001s OK . -- Ran 1 test in 0.002s OK .. -- Ran 2 tests in 0.004s OK .. -- Ran 6 tests in 2.248s OK .. -- Ran 2 tests in 0.030s OK . -- Ran 1 test in 0.002s OK .. -- Ran 26 tests in 0.008s OK >>> gr_fir_fff: using SSE . -- Ran 1 test in 0.003s OK -- Ran 8 tests in 0.016s OK .. -- Ran 2 tests in 0.006s OK >>> gr_fir_fff: using SSE . -- Ran 1 test in 0.002s OK .. -- Ran 2 tests in 0.336s OK .. -- Ran 2 tests in 0.501s OK .. -- Ran 2 tests in 0.004s OK ... -- Ran 7 tests in 0.004s OK ... -- Ran 3 tests in 0.006s OK . -- Ran 1 test in 0.002s OK . -- Ran 1 test
[Discuss-gnuradio] GNU Radio and Channel Estimation
Hi All, I had started my Master's Project in which i need to work towards Channel Estimation using GNU radio as Platform. Can any one please guide me and let me know about any work been done in this field on GNU radio. Any help is really appreciated. Thanks & Regards, Somya Ajmera New Email names for you! Get the Email name you've always wanted on the new @ymail and @rocketmail. Hurry before someone else does! http://mail.promotions.yahoo.com/newdomains/aa/___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: Re[Discuss-gnuradio] ceiving packets using 2 daughterboads in 2 framer sink didn't work correctly.
Thands for answering my question http://www.nabble.com/Receiving-packets-using-2-daughterboads-in-2-framer-sink-didn%27t-work-correctly.-tp22658504p22672600.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] Brief question involving optfir.low_pass()
optfir.low_pass() returns the coefficients for the desired filter, use the python len() method to get the number of taps. Kieran On Tue, Mar 24, 2009 at 11:08 AM, Francesco B. wrote: > > Is there any way to determine the order of the filter that > optfir.low_pass() > is generating in any given case? It works properly, but knowing the order > would be beneficial to my group's documentation. > -- > View this message in context: > http://www.nabble.com/Brief-question-involving-optfir.low_pass%28%29-tp22670322p22670322.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 mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] (no subject)
hi everybody.. i want to do a project on GNU RADIO based RFID reader . i need information about any advancement has been done in this field and what are the paths alongwith advancement is required. Regards, Harshal Jadhav ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Brief question involving optfir.low_pass()
Is there any way to determine the order of the filter that optfir.low_pass() is generating in any given case? It works properly, but knowing the order would be beneficial to my group's documentation. -- View this message in context: http://www.nabble.com/Brief-question-involving-optfir.low_pass%28%29-tp22670322p22670322.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] howto make
Doing this presents another problem. When I run "make" I get an error that indicates that "PYTHON" is undefined in my Makefile.am (line 56). This is because the aclocal.m4 file generated by just running ./configure after removing the old aclocal.m4 file does not contain this the AM_PATH_PYTHON(...) anymore. Thoughts? On Sun, Mar 22, 2009 at 6:56 PM, William Harding wrote: > Thank you Eric, but doing this present another problem. When I run "make" > I get an error that indicates that "PYTHON" is undefined in my Makefile.am > (line 56). > > This is because the aclocal.m4 file generated by just running ./configure > after removing the old aclocal.m4 file does not contain this the > AM_PATH_PYTHON(...) anymore. > > Thoughts? > > > > > On Sun, Mar 22, 2009 at 2:51 PM, Eric Blossom wrote: > >> On Sun, Mar 22, 2009 at 01:51:55PM -0500, William Harding wrote: >> > When I try to make the howto package (from the "How to write a signal >> > processing block" tutorial), I get and error which says: >> > >> > Version mismatch error. This is libtool 2.2.6, but the definition of >> this >> > LT_INIT comes from libtool 2.2.4. >> > >> > Then it indicates that I need to recreate aclocal.m4. I have removed >> > aclocal.m4 and then run ./bootstrap and ./configure again as someone >> > suggested doing in a previous post, but when I try to make I get the >> same >> > error. >> >> $ rm aclocal.m4 >> $ ./configure >> >> Don't bootstrap again or the problem will recur. >> >> Eric >> > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP Input Calibration / CIC Filter Response
On Mon, Mar 23, 2009 at 10:44:21AM -0700, Eric Blossom wrote: > On Mon, Mar 23, 2009 at 12:58:17PM -0400, Erich Stuntebeck wrote: > > The daughterboard gain was set to the mid-point. > > > > I don't have the range of the time domain samples as I did the FFT > > processing in real-time and discarded the raw data. The data was > > collected using a script I wrote to link the USRP block with a custom > > processing block that I wrote. This custom block take the FFT of the > > incoming data and outputs the amplitude of the appropriate bin. It > > determines the appropriate bin based on a given frequency as an input, > > and searches a few neighboring bins in case of clock errors to select > > the bin nearby with the maximum amplitude. > > > > I'm using the firmware without the half-band filter. > > > > The signal generator is an Agilent 33220A. I don't have a spectrum > > analyzer, but I do have two of the 33220A's and they both perform the > > same way so I'm guessing its not a calibration issue with the signal > > generator. > A person who desires to remain anonymous passes on this comment: eric, i saw your response on the mailing list (below). i think the problem has nothing to do with gain. in my opinion the mistake is that erich is using FFT without applying a window-function first. in other words, he's using a 'rectangle' window. a rectangle window is a bad choice for amplitude flatness measurements, because the amplitude response depends on whether the signal is at bin center, or between 2 bins (the worst case). there is a difference of ~3.7dB between these two scenarios. if he wants to measure flatness, he should use a window function which is designed to give the same amplitude response for any frequency, be it bin-centered of not. a 'flattop' window (google for it) is recommended in that case - it has 0.02dB flatness. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] SDR Summer Internship
Hello all, We are looking for a student or recent graduate who is familiar with GNU Radio and the USRP for a summer internship at the Naval Research Laboratory in Washington DC. We will be prototyping a unique multi-user communication system. If anyone is interested, shoot me an email with your resume and we can discuss it further. Applicants must be US Citizens. Thanks, Kevin Rudd, PhD Naval Research Laboratory kevin.r...@nrl.navy.mil 202-404-3687 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Command Line Arguments for usrp transmission and reception
Hi, I posted my question a couple of days ago but could not get any response, probably because it was an over-datailed mail. Here, I am just posting a part of it, Is there any problem if I do call benchmark_rx.py and benchmark_tx.py with following command line arguments? $ python ./benchmark_rx.py -f 10M -R A --rx-gain=70 -v -r 500K $ python ./benchmark_tx.py -TA -f 10M -r 500k -v --tx-amplitude=2 While doing so, I am getting following outputs: I called benchmark_rx on my usrp and left it running, $ python ./benchmark_rx.py -f 10M -R A --rx-gain=70 -v -r 500K bits per symbol = 1 M&M clock recovery omega = 2.00 M&M clock recovery gain mu = 0.175000 M&M clock recovery mu = 0.50 M&M 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 called 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? -Ahmed___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: help on xlating frequency
Paul Mathews schrieb: See 'usrp_am_mw_rcv.py' for an example. Look for the code relating to these lines in particular: if self.use_IF: # Turn If to baseband and filter. self.chan_filt = gr.freq_xlating_fir_filter_ccf (chanfilt_decim, chan_filt_coeffs, self.IF_freq, usrp_rate) hI pAUL, i used this example as possible as i can, but this frequency translating filter has one important difference to my application, the FFT-Plot-sink which is connected to this xlating filter is staticly. I have a slider to change my baseband to the wished spectrum, so my xlating filter it is dynamically. I still doesn't know whether to use a low_pass is usefull or a band_pass. The low_pass doesn't delete the middle signal in the FFT-Plot in my tryings. Further on i doesn't know which conditions have to be made to let my application work fluidly ? Which decimation ? Which rate is useful ? Should it use the same rate, than the element before ? Which is the centerpoint from which the low_pass_cutoff and the high_pass_cutoff frequency will be counted ? I tried it out, but still doesn't know how it works. Regards Markus ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: help on xlating frequency
Paul Mathews schrieb: See 'usrp_am_mw_rcv.py' for an example. Look for the code relating to these lines in particular: if self.use_IF: # Turn If to baseband and filter. self.chan_filt = gr.freq_xlating_fir_filter_ccf (chanfilt_decim, chan_filt_coeffs, self.IF_freq, usrp_rate) hI pAUL, i used this example as possible as i can, but this frequency translating filter has one important difference to my application, the FFT-Plot-sink which is connected to this xlating filter is staticly. I have a slider to change my baseband to the wished spectrum, so my xlating filter it is dynamically. I still doesn't know whether to use a low_pass is usefull or a band_pass. The low_pass doesn't delete the middle signal in the FFT-Plot in my tryings. Further on i doesn't know which conditions have to be made to let my application work fluidly ? Which decimation ? Which rate is useful ? Should it use the same rate, than the element before ? Which is the centerpoint from which the low_pass_cutoff and the high_pass_cutoff frequency will be counted ? I tried it out, but still doesn't know how it works. Regards Markus ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP Input Calibration / CIC Filter Response
On Mon, Mar 23, 2009 at 12:58:17PM -0400, Erich Stuntebeck wrote: > The daughterboard gain was set to the mid-point. > > I don't have the range of the time domain samples as I did the FFT > processing in real-time and discarded the raw data. The data was > collected using a script I wrote to link the USRP block with a custom > processing block that I wrote. This custom block take the FFT of the > incoming data and outputs the amplitude of the appropriate bin. It > determines the appropriate bin based on a given frequency as an input, > and searches a few neighboring bins in case of clock errors to select > the bin nearby with the maximum amplitude. > > I'm using the firmware without the half-band filter. > > The signal generator is an Agilent 33220A. I don't have a spectrum > analyzer, but I do have two of the 33220A's and they both perform the > same way so I'm guessing its not a calibration issue with the signal > generator. Thanks, Erich. Without seeing the time domain samples, I'm guessing that the gain is too low and/or the input is too low, and that what you're seeing is the result of only a few of the least significant bits moving in received samples. That is, you're not using the full dynamic range of the signal processing pipeline. I suggest running it again with the Rx gain set to its maximum value. Let us know how it turns out. Eric ___ 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 Mon, Mar 23, 2009 at 08:00:52AM -0700, kaleem ahmad wrote: > > Hi, > > I have one more confusion about this sampling rate of USRP. > > At FPGA level it is 64MSps and when we decimate (D = 4...256), the sampling > rate is reduced to 64MSps/D. Now I am confused that if the actual sampling > rate of USRP is changed from 64MSps to the new decimated sampling rate or > the USRP is still sampling at 64MSps and only internal sampling rate (i.e > just for channel selection) is changed. The ADCs on the USRP always run at 64MS/s. The decimation occurs inside of the FPGA. This is explained in the USRP FAQ on the wiki. If this concept is still confusing, you might want to spend some time looking at a text book that talks about decimating filters and/or multirate signal processing. http://gnuradio.org/trac/wiki/SuggestedReading > Addition to this as maximum value of decimation rate is 256 so sampling rate > can be reduced to 250ks/s, if I want to set it to 3ksps then how it is > possible. You will need to do additional decimation on the host. You can do that after the usrp.source_c block with a gr.fir_filter_ccf. grep the examples for examples. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: Re[Discuss-gnuradio] ceiving packets using 2 daughterboads in 2 framer sink didn't work correctly.
On Mon, Mar 23, 2009 at 04:39:14AM -0700, Ling Huang wrote: > > Hi, I have posted my question a few days ago, but no one answer my question. > Maybe I didn't make my question clear. If there are any puzzle of my > statements, please let me know. > > Here is my staff, > I use rfx400 and rfx2400 multi daughterboads on one USRP to receive or > transmit at the same time.I modified the codes of gnuradio-examples/digital > to do the work. > The transmit part worked well. But the receive path didn't work correctly. > Only the framer_sink of rfx2400 side work. The other side of rfx400 can > receive the signal(I set --log-rx-power, and see the rfx400 did receive the > signal.) But the framer_sink of rfx400 didn't work. If I understand what you're trying to do (One USRP using both the rfx400 and rfx2400 at the same time, and both of them receiving and transmitting using Auto TR and temporally the two streams are independently of each other), I don't think you can make that work without a substantial overhaul of the host, FX2 and FPGA code. Why this is so, is that when using two channels, the two channels are interleaved 1:1 in both the Tx and Rx directions. There is in effect only a single Tx queue and a single Rx queue in the FPGA. When using Auto TR, that single Tx queue controls whether both daugherboards are in Tx or Rx mode. If I've misunderstood what you're trying to do, please ask again. If I did understand your situation, I suggest using two USRPs, one with the rfx400 and the other with the rfx2400. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] help on xlating frequency
See 'usrp_am_mw_rcv.py' for an example. Look for the code relating to these lines in particular: if self.use_IF: # Turn If to baseband and filter. self.chan_filt = gr.freq_xlating_fir_filter_ccf (chanfilt_decim, chan_filt_coeffs, self.IF_freq, usrp_rate) Paul Mathews -Original Message- From: feldmaus [mailto:feldmann_mar...@gmx.de] Sent: Monday, March 23, 2009 6:36 AM To: discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] help on xlating frequency Hi All, i tried out to delete some antialiasing and the middle signal of the FFT-Plot. Therefor i use this filter: ### VARIABLE ### #At adc_rate=64MS/s and decim=64 we get an usrp_rate of 1 MS/s self.decim=64 self.usrp_rate=1e6 ### FILTER ### self.firdes_filt_coeffs = gr.firdes.low_pass(1, self.usrp_rate, self.usrp_rate*0.5, self.usrp_rate*0.001, gr.firdes.WIN_RECTANGULAR) self.chan_filt = gr.freq_xlating_fir_filter_ccf (self.chanfilt_decim, self.firdes_filt_coeffs, self.usrp_freq, self.usrp_rate) ### SOURCE ### As source i use: self.usrp_source = usrp.source_c(which=0, decim_rate=self.decim) ### SINNK ### And as sink i use an FFT-sink-Plot: self.wxgui_fftsink2 = fftsink2.fft_sink_c( self.GetWin(), baseband_freq = self.usrp_freq, y_per_div = 10, y_divs = 8, ref_level = 0, sample_rate = self.usrp_rate, fft_size = 512*2, fft_rate = 30, ref_scale=11885000.0,# 11885000.0 oder 32768.0 ? average = True, avg_alpha = None, title = "FFT Plot", size=(1024, 600), peak_hold = False, ) ### CONNECT ### Then i connect this all together: self.connect((self.usrp_source, 0), (self.chan_filt, 0)) self.connect((self.chan_filt, 0), (self.wxgui_fftsink2, 0)) But the antialiasing still exist and the middle signal of the FFT-Plot too. There comes the next problem, that my spectrum in the FFT-Plot will be shifted. Can i use the usrp_rate in the source as well as for the xlating element ? Or do i have to use another decimation value ? Which rate must i use for the FFT-Plot ? Why is the low cut off frequency limited to usrp_rate/2 ? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: documentation of the gnuradio python modules
Martin Braun schrieb: On Mon, Mar 23, 2009 at 12:42:04PM +, feldmaus wrote: Hi All, i only want to say,it would be nice to have a clearer and more comprehensive gnuradio python modules documentation with examples. This would solve many basic problems ! Hi Markus, as explained in http://gnuradio.org/trac/wiki/Tutorials/WritePythonApplications, the Doxygen generated docs are also very useful for Python development, Ok for python development, but not for using python. since the functions which export the blocks to the Python domain are always mapped in the same way (e.g. gr_make_sig_source_f becomes gr.sig_source_f etc.). I always have a browser window open with my local copy of the Doxygen files when developing GR and I find it very easy to jump straight to the correct block documentation thanks to the categories of signal processing blocks. The only disadvantage I see is that default arguments don't show up in the doxy-docs - but as the source code is always linked into the documentation, this is very easy to find if necessary. I admit this might be a bit cumbersome for people who don't want to touch the C++ domain at all, but for someone who at least knows how to read the code it doesn't take much getting used to. As for examples, between the unit tests and the files in gnuradio-examples and gr-utils, there really is loads of stuff to choose from regarding examples. grep and find are your friends. I'm sorry that this answer doesn't exactly give you what you asked for - but even though I agree that documentation is not GNU Radio's strongest point, I must say the way the code is organised makes it extremely easy to find oneself's way around without too much of a hassle. Just give it a try, I doubt you'll find it that hard yourself. Cheers MB Hi Martin and thanks for your answer, I am an user not developer, so i am not reading C++ code to understand how this function works. C++ code is not equal documentation. And there is also a need for long discriptions. You are using the API like a reference book. A reference book is useful, but not for beginners. A beginner doesn't know which possibilities are there to solve a specific problem ! Where in the API is written which solutions exists to get an offset in the amplitude ? (for example) Ok a beginner could read the whole API first and than maybe he knows it. There is still a difference between "i know there is a function which could be useful" and the "knowledge to use this method correctly". The examples are very useful, but it should be more explained step by step. The API could be more useful, if all parameters are explained. The API doesn't give me any answer how to solve my problem, but give me infos about the paramter type i can load into some method and the return type. It is nice that there is a short explanation of some methods, but for difficult methods it should be more explained. 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 Mon, Mar 23, 2009 at 11:04 AM, kaleem ahmad wrote: > > Thanks Brian, > > By cycle time I mean that a transmitter (e.g. FSK, ZigBee or any other) is > transmitting something (I am not interested what is being transmitted) after > fixed time intervals let say 50ms. Now this transmitter will continue > transmitting data after every 50ms. This 50ms is the cycle time. Keep it in the time domain and just do RSSI estimation. Then count the number of samples between high power and no power input. This should work well for high SNR situations. If you need to work in lower SNR situations, you can perform some other operations on the signal to detect if there is something there that resembles a digital signal (an exercise left to the reader). You definitely don't need to move to the frequency domain and should probably be avoided. As for your ADC question, it's just doing filtering with decimation. The actual ADC sample rate stays the same, but your signal is digitally filtered and samples thrown away. The filtering avoids aliasing that occurs when you throw samples away. 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
Thanks Brian, By cycle time I mean that a transmitter (e.g. FSK, ZigBee or any other) is transmitting something (I am not interested what is being transmitted) after fixed time intervals let say 50ms. Now this transmitter will continue transmitting data after every 50ms. This 50ms is the cycle time. Best Regards Brian Padalino wrote: > > On Mon, Mar 23, 2009 at 10:20 AM, kaleem ahmad > wrote: >> >> Thanks for all these replies, >> >> The problem is my investigation about cycle time is not restricted to >> FSK, >> I just gave the example of FSK system. I would like to calculate the >> cycle >> time of any system (ZigBee, FSK, CSS etc) present in the area. My target >> is >> to sense as much systems as possible and then calculate the cycle time of >> that. > > I suppose I am missing the meaning of "cycle time". Do you mean > symbol rate? Or do you mean how often a TDMA system gets on the > channel? Both are significantly different metrics. > > It's best to describe what you want to try to accomplish as clearly as > possible. In some cases, it helps your understanding as well as > others. > > 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-tp22598748p22661956.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] Can threading disturb sensing continuety
Hi, I have one more confusion about this sampling rate of USRP. At FPGA level it is 64MSps and when we decimate (D = 4...256), the sampling rate is reduced to 64MSps/D. Now I am confused that if the actual sampling rate of USRP is changed from 64MSps to the new decimated sampling rate or the USRP is still sampling at 64MSps and only internal sampling rate (i.e just for channel selection) is changed. Addition to this as maximum value of decimation rate is 256 so sampling rate can be reduced to 250ks/s, if I want to set it to 3ksps then how it is possible. Best Regards Ed Criscuolo-2 wrote: > > > > kaleem ahmad 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? > > As Firas already noted, you should be using the decimated sample rate > NOT the ADC rate. > >> >> 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 ???) > > There's no need to go that big. The problem is that you are sampling > too high for the cycle time you're looking for. > > As an example, if the cycle time will be between 1 and 200 ms, this > corresponds to a frequency range of 1KHz to 5 Hz. So you only need a > minimum sample rate of 2 K-samples/sec. Let's use 3 so we have some > margin. Now, simply take your high-rate data stream, run it through > a 1.5 KHz low-pass filter (for anti-aliasing) and downsample the data > to a 3 Ksample/sec rate. A 512 bin FFT now has a resolution of around > 5 Hz per bin. > > @(^.^)@ 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-tp22598748p22661896.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] Can threading disturb sensing continuety
On Mon, Mar 23, 2009 at 10:20 AM, kaleem ahmad wrote: > > Thanks for all these replies, > > The problem is my investigation about cycle time is not restricted to FSK, > I just gave the example of FSK system. I would like to calculate the cycle > time of any system (ZigBee, FSK, CSS etc) present in the area. My target is > to sense as much systems as possible and then calculate the cycle time of > that. I suppose I am missing the meaning of "cycle time". Do you mean symbol rate? Or do you mean how often a TDMA system gets on the channel? Both are significantly different metrics. It's best to describe what you want to try to accomplish as clearly as possible. In some cases, it helps your understanding as well as others. Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] setup taps in grc
feldmaus wrote: Hi All, i played around with an frequency translating filter and noticed that there is no possibilty to create some taps with or in grc. Or am I wrong ? yes, read the wiki page. http://gnuradio.org/trac/wiki/GNURadioCompanion Regards Markus ___ 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] documentation of the gnuradio python modules
On Mon, Mar 23, 2009 at 12:42:04PM +, feldmaus wrote: > Hi All, > > i only want to say,it would be nice to have a clearer and > more comprehensive gnuradio python modules documentation with > examples. > > This would solve many basic problems ! > Hi Markus, as explained in http://gnuradio.org/trac/wiki/Tutorials/WritePythonApplications, the Doxygen generated docs are also very useful for Python development, since the functions which export the blocks to the Python domain are always mapped in the same way (e.g. gr_make_sig_source_f becomes gr.sig_source_f etc.). I always have a browser window open with my local copy of the Doxygen files when developing GR and I find it very easy to jump straight to the correct block documentation thanks to the categories of signal processing blocks. The only disadvantage I see is that default arguments don't show up in the doxy-docs - but as the source code is always linked into the documentation, this is very easy to find if necessary. I admit this might be a bit cumbersome for people who don't want to touch the C++ domain at all, but for someone who at least knows how to read the code it doesn't take much getting used to. As for examples, between the unit tests and the files in gnuradio-examples and gr-utils, there really is loads of stuff to choose from regarding examples. grep and find are your friends. I'm sorry that this answer doesn't exactly give you what you asked for - but even though I agree that documentation is not GNU Radio's strongest point, I must say the way the code is organised makes it extremely easy to find oneself's way around without too much of a hassle. Just give it a try, I doubt you'll find it that hard yourself. Cheers MB -- Dipl.-Ing. Martin Braun Phone: +49-(0)721-608 3790 Institut fuer Nachrichtentechnik Fax: +49-(0)721-608 6071 Universitaet Karlsruhe (TH) http://www.int.uni-karlsruhe.de/ pgpuFpNWRffI7.pgp Description: PGP signature ___ 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 for all these replies, The problem is my investigation about cycle time is not restricted to FSK, I just gave the example of FSK system. I would like to calculate the cycle time of any system (ZigBee, FSK, CSS etc) present in the area. My target is to sense as much systems as possible and then calculate the cycle time of that. Best Regards Brian Padalino wrote: > > On Fri, Mar 20, 2009 at 1:27 PM, Johnathan Corgan > 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 > > -- View this message in context: http://www.nabble.com/Can-threading-disturb-sensing-continuety-tp22598748p22661057.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] help on xlating frequency
Hi All, i tried out to delete some antialiasing and the middle signal of the FFT-Plot. Therefor i use this filter: ### VARIABLE ### #At adc_rate=64MS/s and decim=64 we get an usrp_rate of 1 MS/s self.decim=64 self.usrp_rate=1e6 ### FILTER ### self.firdes_filt_coeffs = gr.firdes.low_pass(1, self.usrp_rate, self.usrp_rate*0.5, self.usrp_rate*0.001, gr.firdes.WIN_RECTANGULAR) self.chan_filt = gr.freq_xlating_fir_filter_ccf (self.chanfilt_decim, self.firdes_filt_coeffs, self.usrp_freq, self.usrp_rate) ### SOURCE ### As source i use: self.usrp_source = usrp.source_c(which=0, decim_rate=self.decim) ### SINNK ### And as sink i use an FFT-sink-Plot: self.wxgui_fftsink2 = fftsink2.fft_sink_c( self.GetWin(), baseband_freq = self.usrp_freq, y_per_div = 10, y_divs = 8, ref_level = 0, sample_rate = self.usrp_rate, fft_size = 512*2, fft_rate = 30, ref_scale=11885000.0,# 11885000.0 oder 32768.0 ? average = True, avg_alpha = None, title = "FFT Plot", size=(1024, 600), peak_hold = False, ) ### CONNECT ### Then i connect this all together: self.connect((self.usrp_source, 0), (self.chan_filt, 0)) self.connect((self.chan_filt, 0), (self.wxgui_fftsink2, 0)) But the antialiasing still exist and the middle signal of the FFT-Plot too. There comes the next problem, that my spectrum in the FFT-Plot will be shifted. Can i use the usrp_rate in the source as well as for the xlating element ? Or do i have to use another decimation value ? Which rate must i use for the FFT-Plot ? Why is the low cut off frequency limited to usrp_rate/2 ? >From which point starts the low cut-off frequency and to which direction ? Why must i use the transition width>0 by the WIN_RECTANGULAR ? How can the shifting of the spectrum in my FFT-Plot corrected ? Any Hints ? Regards Markus ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] documentation of the gnuradio python modules
Hi All, i only want to say,it would be nice to have a clearer and more comprehensive gnuradio python modules documentation with examples. This would solve many basic problems ! The documentation at, https://radioware.nd.edu/documentation/a-dictionary-of-the-gnu-radio-blocks seems to b a good beginning. This is the only side where few gnuradio modules are documented ! I know there are examples, but they are sparse documented. Regards Markus ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re[Discuss-gnuradio] ceiving packets using 2 daughterboads in 2 framer sink didn't work correctly.
Hi, I have posted my question a few days ago, but no one answer my question. Maybe I didn't make my question clear. If there are any puzzle of my statements, please let me know. Here is my staff, I use rfx400 and rfx2400 multi daughterboads on one USRP to receive or transmit at the same time.I modified the codes of gnuradio-examples/digital to do the work. The transmit part worked well. But the receive path didn't work correctly. Only the framer_sink of rfx2400 side work. The other side of rfx400 can receive the signal(I set --log-rx-power, and see the rfx400 did receive the signal.) But the framer_sink of rfx400 didn't work. my connect flow graph is #for side a self.connect((di,0),self.chan_filt_a,self._demodulator_a,self.correlator_a, self.framer_sink_a) self._watcher_a = _queue_watcher_thread_a(self._rcvd_pktq_a, self._rx_callback_a) #for side b self.connect((di,1),self.chan_filt_b,self._demodulator_b,self.correlator_b, self.framer_sink_b) self._watcher_b= _queue_watcher_thread_bself._rcvd_pktq_b self._rx_callback_b) I switch the connect of deinterleave output to test each receive side flow graph such as self.connect((di,1),self.chan_filt_a,self._demodulator_a,self.correlator_a, self.framer_sink_a) self.connect((di,0),self.chan_filt_b,self._demodulator_b,self.correlator_b, self.framer_sink_b) The rfx400 side didn't work all the same, and the rfx2400 work fine just like before. Then I can say the two path of connection is both working well. And the rfx400 side is no wrong until connect to the self._demodulator_a. Have anyone ever do the same experiment of receiving packets using both daughterboard? Can anyone tell me what's the mistake I made? -- View this message in context: http://www.nabble.com/Receiving-packets-using-2-daughterboads-in-2-framer-sink-didn%27t-work-correctly.-tp22658504p22658504.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 use gr.message_sink and gr.message_source
Hi, I am new to gnuradio and trying to understand how gr.message_sink and gr.message_source work. I want to convert a byte stream (read from a file) into a message of 50 bytes and store it in a queue. Then i want to retrieve that message, convert it back to byte stream and write it to another file to make the copy of original file. Here is the code I have written for this but its not working. Perhaps I am misunderstanding how to convert a byte stream into a "message": #!/usr/bin/env python from gnuradio import gr from gnuradio import audio class main_fg(gr.top_block): def __init__(self): gr.top_block.__init__(self) self.packet_src= gr.message_source(50) self.file_msgq = gr.msg_queue() self.packet_sink = gr.message_sink(50, self.file_msgq, False) file_src=gr.file_source(1,'/home/sajjad/Desktop/work/source_data') file_dst=gr.file_sink(1,'/home/sajjad/Desktop/work/dstdata') v2s=gr.vector_to_stream(1,50) s2v=gr.stream_to_vector(1,50) self.connect(file_src, s2v, self.packet_sink) self.connect(self.packet_src, v2s, file_dst) fg=main_fg() fg.start() bytes=0; while True: data=fg.file_msgq.delete_head() fg.packet_src.msgq().insert_tail(data) bytes+=5 print bytes fg.stop() Please make me understand how these two blocks work cz i severely and urgently need them. Thanks a lot! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: [USRP2]Receiving a DC voltage
Johnathan Corgan wrote: > On Tue, Mar 17, 2009 at 5:26 AM, dbeken wrote: > >> last time I didn?t get a solution for my problem of interpolating and >> decimating using a sinusoidal signal. Now i went even easier. I connected a >> DC Power Supply (with 0.01A max limit) to my LFRX daughterboard. The USRP2 >> Source is only connected to a Scope Sink. But with 0.5 Voltage input, I only >> see very small variations about the 0 line. The current is 0.01 A. So, what >> can I do to see a signal? > > Make sure you don't have AC coupling turned on in your scope block. > > Johnathan where do you see if dc or ac coupling is on in the scope sink ? thanx -- 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] Re: [USRP2]Receiving a DC voltage
Karthik wrote: > On Tue, Mar 17, 2009 at 9:37 AM, Johnathan Corgan < > jcor...@corganenterprises.com> wrote: > >> what >> > can I do to see a signal? >> >> Make sure you don't have AC coupling turned on in your scope block. >> >> Johnathan >> > > For receiving DC signals, you need to disable the DC offset removal > which is > automatically performed in the USRP. I am not sure if this happens in > USRP2 > as well, most likely it does. This thread has the discussion and how it > was > solved. > http://lists.gnu.org/archive/html/discuss-gnuradio/2008-10/msg00465.html > > Karthik I looked at usrp2_base file but there is not a line similar to that in the usrp_base where you can change the offset so easily, I need another solution, but thanx for your help -- 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] setup taps in grc
Hi All, i played around with an frequency translating filter and noticed that there is no possibilty to create some taps with or in grc. Or am I wrong ? Regards Markus ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
