Re: [Discuss-gnuradio] Simultaneously send data and store it in file with high sample rate
> Hi, > How to simultaneously transmit data to usrp and also store it in a file.? > I > ran two separate flow graphs.But i want to have a sample rate of 25Mhz.Is > it possible to do it. > > I want the same thing in receiver side also(simultaneously detect the > packet and store the data) > > I am using USRPN210 and Ubuntu 12.04 > > Thanks. Hi, you can connect a block's output to as many inputs as you want. So take tha last block in your chain that generates your signal and connect it both to a uhd sink (which will make the USRP transmitt the signal) and a file sink (which will write the same samples to a file). Same goes for the receiver side. If you use GRC just add another connection from a block's out port to another ones in port and the output will be send to both blocks. Yours Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] build-gnuradio on Scientific Linux 6.3
> Possibly Ubuntu sets up /usr/local to be regular-user > writeable, but that would be a horrible security flaw. At least for my Ubuntu 12.04 /usr/local is owned by root:root with 0755 permissions and everything else would have given me nightmares ;) Maybe you started the script with sudo, instead of letting the script itself call sudo, then you would have had the necessary permissions. Yours Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP Transmit
I am transmitting and receiving using the USRP and both Leds A and C on. How to check that i am correctly Transmitting and Receiving. and how to see the Transmitted and received Signal? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] uhd_fft and benchmark_tx
when i run uhd_fft it runs ok but parallel i cannot run benchmark so i must close the uhd_fft to run the benchmark_tx as message appears that RuntimeError: LookupError: KeyError: No devices found for -> Empty Device Address although while searching i find video running both togothers. so how can i do this to see transmitted signal at certain frequency from the benchmark transmitted ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] uhd_fft and benchmark_tx
> when i run uhd_fft it runs ok but parallel i cannot run benchmark > so i must close the uhd_fft to run the benchmark_tx > > as message appears that RuntimeError: LookupError: KeyError: No devices > found for -> > Empty Device Address > although while searching i find video running both togothers. so how can i > do this to see transmitted signal at certain frequency from the benchmark > transmitted Hi, a USRP device can only be accessed by one process at a time. So when you run uhd_fft this process occupies your USRP. When starting benchmark_tx the UHD lib looks for other available USRPs and trhows LookupError because it can not find any unused USRP device (I assume you only have one USRP device connected?) unless you stop uhd_fft before (in which case your USRP is available again) Yours Martin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr_fir_fff: using 3DNow! core dump
On Wed, Mar 20, 2013 at 10:10 PM, Sid Boyce wrote: > On 20/03/13 23:50, Tom Rondeau wrote: >> >> On Wed, Mar 20, 2013 at 10:58 AM, Sid Boyce >> wrote: >>> >>> On 20/03/13 13:08, Tom Rondeau wrote: On Tue, Mar 19, 2013 at 9:20 PM, Sid Boyce wrote: > > I have a program that uses gnuradio to work with a HiQSDR. > > The first time I fired up qsdr it worked. > Closing it down and re-opening later I got the error. A reboot of the > system > didn't solve it. > > $ qsdr > starting server > Using Volk machine: sse4_a_64 gr_fir_fff: using 3DNow! > > terminate called after throwing an instance of 'std::runtime_error' > what(): unpaired unlock() call > Aborted (core dumped) > 73 ... Sid. Sid, What version of GNU Radio are you using for this? You should try to pull in the filter from the filter module instead of from gr: from gnuradio import filter fir = filter.fir_filter_ccf(decim, taps) Also, what is your processor? Tom >>> This is the output from the openSUSE boxes and the CPU flags which don't >>> include sse4_a. >>> Later I'll try rebuilding gnuradio with "-msse3" to see if that helps. >>> # qsdr >>> starting server >>> gri_fftw: can't import wisdom from /root/.gr_fftw_wisdom >>> Using Volk machine: avx_64_mmx_orc >> >> gr_fir_fff: using SSE >>> >>> connection from "127.0.0.1" >>> TCP: conneced >> >> gr_fir_ccc: using SSE >> gr_fir_ccf: using SSE >> gr_fir_fcc: gr_fir_fcc: using SSE >>> >>> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge >>> mca >>> cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt >>> pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid >>> aperfmperf pni pclmulqdq monitor ssse3 cx16 sse4_1 sse4_2 popcnt aes >>> xsave >>> avx lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse >>> 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 nodeid_msr topoext >>> perfctr_core perfctr_nb arat cpb hw_pstate npt lbrv svm_lock nrip_save >>> tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold >>> >>> 73 ... Sid. >>> >>> -- >>> Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot >>> Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support >>> Senior Staff Specialist, Cricket Coach >>> Microsoft Windows Free Zone - Linux used for all Computing Tasks >> >> Sid, >> >> Have you tried using the filters out of the filter module, yet? Those >> filters use VOLK for SIMD instead of the hand-crafted stuff that in >> the gr filters. That might help. Besides which, we're removing those >> filters, so moving to the new filter module will keep you more >> compatible as we go forward. >> >> Tom >> > Thanks Tom, > The qsdr design is not mine. > I'll pass this info on to the author. > > 73 ... Sid. Can't you change the code in qsdr yourself? If it's based on GNU Radio, you should have the source code and making this change is pretty trivial (the interface to the filter functions is the same; you just get them from a different module). Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP Transmit
On Thu, Mar 21, 2013 at 4:55 AM, Mohammed Ramadan wrote: > I am transmitting and receiving using the USRP and both Leds A and C on. > How to check that i am correctly Transmitting and Receiving. and how to see > the Transmitted and received Signal? > Do you have another device that can be used to receive or transmit? That's really the only way to know for sure what your signal looks like. Another USRP perhaps? Or you could look into getting one of the RTL-SDR devices for cheap. Or my personal favorite cheap signal detector/debugger: http://ossmann.blogspot.com/2010/03/16-pocket-spectrum-analyzer.html Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Overflow error even at lower sampling rates
On Thu, Mar 21, 2013 at 2:06 AM, john jade wrote: > Hi Marcus, > I am not getting overflow,when i use uhd_fft. Can you please tell me what > might be the problem. > > Thanks. All uhd_fft does is connect a USRP source to an FFT sink. Problems arise when you add more blocks to your application that take more processing time. The more CPU intensive the task, the harder it is to keep up with the flow of data. Tom > On Wed, Mar 20, 2013 at 1:10 PM, Marcus D. Leech wrote: >>> >>> Hi, >>> >>> I am getting overflow error ,even at low sampling rates.I am using USRP >>> N210 device.If the sampling rate is less than 5MHz then there is no error.I >>> know that USRP N210 can support at Max 25MHz.Can you please tell me what >>> might be the problem? >>> >>> I just connected UHD source block to FFT sink in my example. >>> >>> My system specifications. >>> >>> OS :Ubuntu 12.10 >>> processor :Intel Core i5-3570 CPU @ 3.40GHz × 4 >>> RAM 4GB >>> >>> I am using 1Gbit Ethernet card. >>> >>> >>> Thanks >> >> Overruns are caused by your computer not being able to "keep up" in real >> time with the dataflow from the USRP. >> >> What happens if you use "uhd_fft" at the sames rates you're getting >> overflow with in your simple flow-graph? >> >> >> >> >> -- >> Marcus Leech >> Principal Investigator >> Shirleys Bay Radio Astronomy Consortium >> http://www.sbrac.org >> >> >> >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP Transmit
My wife will demand a divorce when I start carrying such a pink "Hello Kitty" device with me :) Is there a more serious looking version available? Ralph. http://ossmann.blogspot.com/2010/03/16-pocket-spectrum-analyzer.html Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] TIMEOUT from "digital_ofdm_sampler.cc"
On Wed, Mar 20, 2013 at 3:06 PM, Sahoo, Anirudha wrote: > Hi, > >I am trying to implement an algorithm over the ofdm implementation > (modifying > > benchmark_xx.py) so that the txmitter and rcvr can communicate changing > > the subcarriers dynamically. > >The scheme is roughly as follows: > > (1) Inially the txmitter and the rcvr listen on a well-known set of > subcarriers. > > (2)then the txmitter sends a carrier map (set of subcarriers) > > over which the subsequent transmissions will happen. > > (3)the rcvr acks that it has received the new carrier map (and tunes to > those subcarriers for reception) > > (4)On receiving ACK, the txmitter also sets its carrier map to new > carrier map. > > (5)Now both the ends are synced to this new carrier map > > (6)some data packets are sent over this new carrier map > > (7)then the txmitter decides to change the carrier map and goes to step > (2). > > > > Here is the problem that I encounter: > > The rcvr gets few packets (usually first two times the carrier map reset > works and the rcvr > >is able to get the packets). > > > > But then the txmitter sends the new carrier map. The rcvr receives it, > sends an ACK, sets its > >carrier map appropriately. The txmitter receives the ACK, sets its > carrier map and then starts > > sending data packets. > > But now the rcvr does not get any packets (even though it is tuned to > the same subcarriers as > >the txmitter is transmitting on). > > Then I see the message “TIMEOUT” on the rcvr (coming from general_work() > of “digital_ofdm_sampler.cc”). That timeout indicates that a while ago, it saw the preamble symbol. But then it failed to find any following symbols and so times out so it will start looking for a new preamble, which it never finds. My guess is that the timeout is from the last preamble symbol before the carrier mapping is changed. I honestly can't quite recall how we did it, but it's possible that the carrier map affects all symbols in the OFDM chain, including the preamble. But the preamble is structured in a very specific way to be received and set the phase and timing at the receiver. If you mess with the carrier map too much, you could distort or destroy the necessary properties of the preamble. There are logging capabilities in the OFDM receiver, and one of them should be the detection line of the preamble. You can plot this to see when you stop detecting preambles. Wow, thinking through this right now makes it so much more apparent how much better we can do with all of our new tools and tricks in GNU Radio! We have a new OFDM transmitter based on this, but I can't wait until we can get into place a new receiver. Specifically, we want to use stream tags for the control over things like preamble detection, and we could use the metadata files to log the stages for debugging. The metadata files would allow us to know exactly when things happened and all of the tags associated with that event. Unfortunately, right now, you're just going to have to look at those log file of samples and try to reconstruct what's happening yourself. > I have even put some delays between resetting carrier map and sending > data (so that the receiver is > > ready with the new carrier map), but that did not help. > > > > Any idea why the receiver stops getting packets after few times the > carrier map is changed? > > > >I am running gnuradio version 3.6.2 on USRP N210. The txmitter and the > rcvr are connected over > > a channel emulator (using RF cable), which emulates a perfect lossless > channel. > > > > thanks and regards My final suggestion to get you going is to maybe send over the same carrier map every time. We start with a mapping that just drops the two middle carriers (for DC offset protection). Just use that as your carrier map every time and make sure that everything still works ok. If that works, great. If it still fails then you know what I said above about the preamble isn't the problem. > > --Anirudh Sahoo > > Advanced Network Technology Div. > > National Institute of Standards and Technology (NIST) > > 100 Bureau Drive, > > Gaithersburg, MD - 20878 > > Room – B230, bldg.- 222 > > Phone- 301-975-4439 Hope this helps, Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP Transmit
How about this: http://hackaday.com/2010/02/12/spectrum-analyzer-wedged-into-a-cellphone/ :) My wife would get a serious case of the giggles if I used a pink spectrum analyzer. MB On Thu, Mar 21, 2013 at 02:23:43PM +0100, Ralph A. Schmid, dk5ras wrote: > My wife will demand a divorce when I start carrying such a pink “Hello Kitty” > device with me :) Is there a more serious looking version available? > > Ralph. -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgpPKTRHHN4kB.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Trouble using file source
Hello everyone, I am using GRC to receive digital signals. I am getting perfect audio and perfect scopes. I hooked up a file sink directly to the receiving device (RTL2832). On replaying the capture, the gui greys-out. The gui never greys-out when receiving live. I have the throttle after the file source as was shown in tutorials. Is it possible that the capture is being done incorrectly? Or is the problem with the replay? What am I doing wrong? Thanks, Matt - ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP Transmit
Much nicer :) My Swiss army knife in RF is a RTL2832/E4000 stick, the Hama nano DVB-T-Receiver. http://dk5ras.dyndns.org/tmp/nano.jpg - unplugged after taking a look at a LTE channel with it. It is SMALL, it is (unlike the other cheap sticks) almost perfectly shielded, when you unplug the MCX connector, then there is NOTHING left but internal spurious peaks... I like it that much that I even ordered a spare one, in case I fry again a RTL4000 tuner chip for unknown reason or simply lose the tiny little thing. Can't repeat it often enough, hdsdr, sdr#, RTL2832, USRP1, gnuradio - this opens a whole new world for RF enthusiasts. We live in an exciting decade! Ralph. > How about this: > > http://hackaday.com/2010/02/12/spectrum-analyzer-wedged-into-a- > cellphone/ > > :) > > My wife would get a serious case of the giggles if I used a pink spectrum > analyzer. > > MB > > > On Thu, Mar 21, 2013 at 02:23:43PM +0100, Ralph A. Schmid, dk5ras wrote: > > My wife will demand a divorce when I start carrying such a pink “Hello > > Kitty” > > device with me :) Is there a more serious looking version available? > > > > Ralph. > > > -- > Karlsruhe Institute of Technology (KIT) > Communications Engineering Lab (CEL) > > Dipl.-Ing. Martin Braun > Research Associate > > Kaiserstraße 12 > Building 05.01 > 76131 Karlsruhe > > Phone: +49 721 608-43790 > Fax: +49 721 608-46071 > www.cel.kit.edu > > KIT -- University of the State of Baden-Württemberg and National Laboratory > of the Helmholtz Association ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Trouble using file source
On Thu, Mar 21, 2013 at 9:36 AM, wrote: > Hello everyone, > I am using GRC to receive digital signals. I am getting perfect audio and > perfect scopes. I hooked up a file sink directly to the receiving device > (RTL2832). On replaying the capture, the gui greys-out. The gui never > greys-out when receiving live. I have the throttle after the file source as > was shown in tutorials. > Is it possible that the capture is being done incorrectly? Or is the problem > with the replay? What am I doing wrong? > Thanks, > Matt What's the sample rate of the throttle block? Are you setting it to replay the file when it finishes and how many samples are in the file? Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Wireless @ VT conference, GnuRadio Hackfest, and Vacancy Announcements
Hello friends. One of the centers I belong to at Virginia Tech is Wireless@VT. We run a conference every summer and we are holding it again this summer. http://www.wireless.vt.edu/symposium/2013/ And I know several of you are attending and we are looking forward to hosting you. At one time, before I came to Virginia Tech, I was a regular contributor to GnuRadio but tapered off to zero around 2010. You know how Poltergeists are, WEEE ARE BACKK. We will be hosting GnuRadio Hackfest immediately after the Wireless Symposium and please expect an announcement from GnuRadio folks about that soon. SPAM FOLLOWS: Finally, let me announce that my Center is doing a lot of GnuRadio development both blocks and applications. We are in a serious hiring phase for members of technical staff, program managers, etc. Please visit this web site to see these announcements: http://www.hume.ictas.vt.edu/vacancies Bob -- Bob McGwier Owner and Technical Director, Allied Communication, LLC Senior Member IEEE Facebook: N4HYBob ARS: N4HY Faculty Advisor Virginia Tech Amateur Radio Assn. (K4KDJ) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Dev Call March 21
Just a quick reminder, the dev call will start in less than 1 hour. Everyone is welcome; you can also just idle in #gnuradio and follow the discussion there. Cheers, MB On Wed, Mar 20, 2013 at 07:41:05AM +0100, Martin Braun (CEL) wrote: > Hi everyone, > > small update: because of time zones (aaah!), the call times are wrong > (daylight saving etc.). The call will be at 1700 UTC (18:00 CET). > > The US times are correct! 10 AM Pacific, 1 PM Eastern. > > MB > > On Mon, Mar 18, 2013 at 03:11:17PM +0100, Martin Braun (CEL) wrote: > > Hi everyone, > > > > this Thursday, we'll be having our monthly dev call. > > Unlike last time, the agenda is currently quite compact: > > http://gnuradio.org/redmine/projects/gnuradio/wiki/Call20130321 > > > > The call is at 1800 UTC (10 AM Pacific, 1 PM Eastern, 19:00 CET) as usual. > > Check out this page on how to join: > > http://gnuradio.org/redmine/projects/gnuradio/wiki/DevelopersCalls > > > > This is the last time to discuss ideas for GSoC! > > -- > Karlsruhe Institute of Technology (KIT) > Communications Engineering Lab (CEL) > > Dipl.-Ing. Martin Braun > Research Associate > > Kaiserstraße 12 > Building 05.01 > 76131 Karlsruhe > > Phone: +49 721 608-43790 > Fax: +49 721 608-46071 > www.cel.kit.edu > > KIT -- University of the State of Baden-Württemberg and > National Laboratory of the Helmholtz Association > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgphgM_FKjQat.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gr_fir_fff: using 3DNow! core dump
On 21/03/13 13:14, Tom Rondeau wrote: On Wed, Mar 20, 2013 at 10:10 PM, Sid Boyce wrote: On 20/03/13 23:50, Tom Rondeau wrote: On Wed, Mar 20, 2013 at 10:58 AM, Sid Boyce wrote: On 20/03/13 13:08, Tom Rondeau wrote: On Tue, Mar 19, 2013 at 9:20 PM, Sid Boyce wrote: I have a program that uses gnuradio to work with a HiQSDR. The first time I fired up qsdr it worked. Closing it down and re-opening later I got the error. A reboot of the system didn't solve it. $ qsdr starting server Using Volk machine: sse4_a_64 gr_fir_fff: using 3DNow! terminate called after throwing an instance of 'std::runtime_error' what(): unpaired unlock() call Aborted (core dumped) 73 ... Sid. Sid, What version of GNU Radio are you using for this? You should try to pull in the filter from the filter module instead of from gr: from gnuradio import filter fir = filter.fir_filter_ccf(decim, taps) Also, what is your processor? Tom This is the output from the openSUSE boxes and the CPU flags which don't include sse4_a. Later I'll try rebuilding gnuradio with "-msse3" to see if that helps. # qsdr starting server gri_fftw: can't import wisdom from /root/.gr_fftw_wisdom Using Volk machine: avx_64_mmx_orc gr_fir_fff: using SSE connection from "127.0.0.1" TCP: conneced gr_fir_ccc: using SSE gr_fir_ccf: using SSE gr_fir_fcc: gr_fir_fcc: using SSE flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf pni pclmulqdq monitor ssse3 cx16 sse4_1 sse4_2 popcnt aes xsave avx lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 nodeid_msr topoext perfctr_core perfctr_nb arat cpb hw_pstate npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold 73 ... Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Senior Staff Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks Sid, Have you tried using the filters out of the filter module, yet? Those filters use VOLK for SIMD instead of the hand-crafted stuff that in the gr filters. That might help. Besides which, we're removing those filters, so moving to the new filter module will keep you more compatible as we go forward. Tom Thanks Tom, The qsdr design is not mine. I'll pass this info on to the author. 73 ... Sid. Can't you change the code in qsdr yourself? If it's based on GNU Radio, you should have the source code and making this change is pretty trivial (the interface to the filter functions is the same; you just get them from a different module). Tom OK Tom, I'll have a check. 73 ... Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Senior Staff Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Dev Call March 21
> It's #gnuradio on freenode. I think freenode has a web client. OK, great, I am in - using miranda, I hate webclients :) > MB Ralph. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Fading channel in GNURadio
I'm trying to make a block for fading channel model using hierarchical block. class channel(gr.hier_block2): def __init__(self): gr.hier_block2.__init__(self, "channel", gr.io_signature(1, 1, gr.sizeof_float), gr.io_signature(1, 1, gr.sizeof_gr_complex)) self.taps = generate_taps() self.filt = filter.fir_filter_ccc(1, self.taps) self.connect(self, self.filt, self) def generate_taps(): n_taps = random.randint(1, 10) r_taps = random.rand(n_taps) i_taps = random.rand(n_taps) return r_taps + 1j*i_taps I want the block to be able to update the channel filter taps in run time. Can I do that? Can I define a function in the class so that the filter taps are updated for every 5 seconds? Thank you. -- Manu T S ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] [BULK] Fading channel in GNURadio
On 03/21/2013 03:45 PM, Manu T S wrote: I'm trying to make a block for fading channel model using hierarchical block. class channel(gr.hier_block2): def __init__(self): gr.hier_block2.__init__(self, "channel", gr.io_signature(1, 1, gr.sizeof_float), gr.io_signature(1, 1, gr.sizeof_gr_complex)) self.taps = generate_taps() self.filt = filter.fir_filter_ccc(1, self.taps) self.connect(self, self.filt, self) def generate_taps(): n_taps = random.randint(1, 10) r_taps = random.rand(n_taps) i_taps = random.rand(n_taps) return r_taps + 1j*i_taps I want the block to be able to update the channel filter taps in run time. Can I do that? Can I define a function in the class so that the filter taps are updated for every 5 seconds? The set_taps function gives you access to this from the top_block level. In that case, your main thread would be updating the block's taps using a while loop with sleep(5). You could also make a block class that inherits from fir_filter_ccc or channel_model and change the taps within the work function every N seconds: every time (ninput_items / samp_rate) % N == 0. I hope that's enough info to point you in the right direction. Thank you. -- Manu T S ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- *Sean M. Nowlan* Research Engineer I ICL/CNSD Georgia Tech Research Institute 250 14th St NW, Suite 470 Atlanta, GA 30318 404.407.7952 sean.now...@gtri.gatech.edu ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] problem with benchmark_tx.py with "--discontinuous"
Hi, When I run benchmark_tx.py with "-discontinuous" flag ON, I notice the following problem: When the transmitter goes to sleep (for 1 sec), the receiver TIMEOUT (which is fine). But then when the txmitter wakes up and sends the next 5 packets, the receiver consistently does not receive the first packet (of this set of 5 packets). Occasionally, I see the rcvr does not get the first two packets. So, I think there is some problem when packets are sent after a period of "lull" which leads to very first packet (after a TIMEOUT) being lost. Can anyone think of what could be wrong with the ofdm implementation which may lead to this problem? I am running gnuradio 3.6.2 on USRP N210. thanks and regards --Anirudh Sahoo Advanced Network Technology Div. National Institute of Standards and Technology (NIST) 100 Bureau Drive, Gaithersburg, MD - 20878 Room - B230, bldg.- 222 Phone- 301-975-4439 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] build-gnuradio on Scientific Linux 6.3
On Thu, Mar 21, 2013 at 4:29 AM, Martin Luelf wrote: > > Possibly Ubuntu sets up /usr/local to be regular-user > > writeable, but that would be a horrible security flaw. > > At least for my Ubuntu 12.04 /usr/local is owned by root:root with 0755 > permissions and everything else would have given me nightmares ;) > > Maybe you started the script with sudo, instead of letting the script > itself call sudo, then you would have had the necessary permissions. > > Yours > Martin > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > I need to recheck the whole Ubuntu thing as soon as I get back to my lab. For my SL problem, I think it installed albeit without gnuradio companion working. I try to run "gnuradio-companion" in terminal and I get this following error: Cannot import gnuradio. Is the python path environment variable set correctly? All OS: PYTHONPATH Is the library path environment variable set correctly? Linux: LD_LIBRARY_PATH Windows: PATH MacOSX: DYLD_LIBRARY_PATH I tried setting the paths in my .bashrc here: # .bashrc # Source global definitions if [ -f /etc/bashrc ]; then . /etc/bashrc fi # User specific aliases and functions # library path for gnuradio export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib64 # python path for gnuradio export PYTHONPATH=$PYTHONPATH:/usr/local/lib64/python2.6/site-packages Oddly enough at the end of the build script I did not get the usual set pythonpath message (around line 1219 in the buildscript). I am going to test out the UHD driver tonight with an actual USRP. Jon ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Send custom data
Maybe I should cast arbitrary object to binary data followed by simple_framer block and bits_to_symbols block.Is it correct? 2013/3/20 1:47, Josh Blum wrote: Isnt all data, custom data? So the streamer interface is still just samples, as is the gr-uhd sink's input port. If you want to send arbitrary information, you still need to packet-ize and modulate the information. Maybe you will find this project relevant: https://github.com/jmalsbury/pre-cog/wiki -josh On 03/19/2013 03:35 AM, Gong Zhang wrote: Hi, I wanna send custom data such as the device number or device status with USRP.Does it mean I should go deeply into something like tx_stream->send()?Is there any similar example? Thanks in advance. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Wireshark Help
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello everyone, Does anyone know to sniff packets coming out of gnuradio? I am spinning my wheels trying to figure this out on my own. Is there some sort of sink that goes to an ip address or a USB port that will show up in wiresharks interface? Thanks, Matt D - -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJRS9oxAAoJEIC13XTKWhPPmuoH/27MbYkUsz67z5d4/XXr3Oxm eG6ZtiX2Mvacx2ZC2CteAs/1Pd0dvXPcoIZzFhj37/jR/8jnhR4gyR3CR7cfa34y 3g1PmmoYIu0vv8h4SBEPQr+eM2obeTKwsu12rjHyBYJkCsJ4ZU+0izKNVVMI09v7 L+/afPXPoJJ/ALEaMy6v0NE+1aENTEbOuvPiON1cal7K7Pc0RYrTFw+FqKtVkmoY 21Y1IT5TqBRIzi7yfTdbVwYXZfwsAxPTskYnpTyo5jtrfAUd93CU5kvYPhwj5VxT 2tXg8Bj5kg76JsZYZ9hlN3PLeMDeRwwf6ocuKJ+oumC64Ex8jCibEuqk0MJbEbM= =CtYL -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] PSK modulation (along with packed vs unpacked bytes)
Twoish questions:
I've done a lot of code reading the last 2 weeks and worked on a custom PSK
modulator (basically hierarchical 2/4psk). I've tested it at baseband on
everything seems good, so I'm hoping now to use something like
benchmark{rx,tx} to test it ota.
I've built a couple of sample flowgraphs. The first one is a BPSK loopback:
> from gnuradio import gr, digital
>
> src_data = (range(0,256))
>
> # blocks
> src = gr.vector_source_b( src_data )
> mod = digital.bpsk.bpsk_mod()
> demod = digital.bpsk.bpsk_demod()
> repacker = gr.unpacked_to_packed_bb(1, gr.GR_MSB_FIRST)
> dst = gr.vector_sink_b()
>
> # flow graph
> tb = gr.top_block()
> tb.connect(src, mod, demod, repacker, dst)
> tb.run()
> print dst.data()
>
It's output is *almost* correct:
> (0, 0, 0, 0, 0, 0, 0, 20, 18, 128, 0, 129, 1, 130, 2, 131, 3, 132, 4, 133,
> 5, 134, 6, 135, 7, 136, 8, 137, 9, 138, 10, 139, 11, 140, 12, 141, 13, 142,
> 14, 143, 15, 144, 16, 145, 17, 146, 18, 147, 19, 148, 20, 149, 21, 150, 22,
> 151, 23, 152, 24, 153, 25, 154, 26, 155, 27, 156, 28, 157, 29, 158, 30,
> 159, 31, 160, 32, 161, 33, 162, 34, 163, 35, 164, 36, 165, 37, 166, 38,
> 167, 39, 168, 40, 169, 41, 170, 42, 171, 43, 172, 44, 173, 45, 174, 46,
> 175, 47, 176, 48, 177, 49, 178, 50, 179, 51, 180, 52, 181, 53, 182, 54,
> 183, 55, 184, 56, 185, 57, 186, 58, 187, 59, 188, 60, 189, 61, 190, 62,
> 191, 63, 192, 64, 193, 65, 194, 66, 195, 67, 196, 68, 197, 69, 198, 70,
> 199, 71, 200, 72, 201, 73, 202, 74, 203, 75, 204, 76, 205, 77, 206, 78,
> 207, 79, 208, 80, 209, 81, 210, 82, 211, 83, 212, 84, 213, 85, 214, 86,
> 215, 87, 216, 88, 217, 89, 218, 90, 219, 91, 220, 92, 221, 93, 222, 94,
> 223, 95, 224, 96, 225, 97, 226, 98, 227, 99, 228, 100, 229, 101, 230, 102,
> 231, 103, 232, 104, 233, 105, 234, 106, 235, 107, 236, 108, 237, 109, 238,
> 110, 239, 111, 240, 112, 241, 113, 242, 114, 243, 115, 244, 116, 245, 117,
> 246, 118, 247, 119, 248, 120, 249, 121, 250, 122, 251)
The first few bytes are 0's, which as I understand has to do with the RRC
filters, frequency correction, and possibly agc filter. Then it starts at
128, 0 and increments by 1. I think I would expect it it to go from 0..255
but it looks like something else that's also incrementing by 1 is
interleaved in there. Looking at the output before the repacker confirms
that each byte appears repeated twice, but the first instance has the MSB
set to 1.
Doing a similar loopback in GRC with PSK Mod/Demod results in what I would
expect (non-repeated bytes with MSB not set to 1). Would this be the proper
way of using these blocks?
A related question, where is the packing being done in the benchmark_rx
path? The generic_demod does an unpack_k_bits, but doesn't appear to pack
them back up. In the benchmark_rx callback it looks like the packet is
already full of packed bytes, but I haven't seen the unpacked_to_packed in
pkt.py.
Thanks for any help,
-Nathan
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Wireshark Help
Are you talking about sniffing USRP data? Gnuradio doesn't have "packets" -- it only knows about raw samples. If you're using a USRP, UHD will packetize those samples on their way to/from the hardware; we use the VITA 49/VRT protocol for this. You can use the VRT dissector found here: https://github.com/bistromath/vrt-dissector ...to view those packets, although there's not a lot of information there aside from the samples themselves. Alexander Chemeris and Ivan Kluchnikov put together a dissector for the control protocol N-series USRPs use, which can be found here: https://github.com/chemeris/uhd_dissector Hope this helps, --n On 03/21/2013 09:12 PM, Matt D wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello everyone, Does anyone know to sniff packets coming out of gnuradio? I am spinning my wheels trying to figure this out on my own. Is there some sort of sink that goes to an ip address or a USB port that will show up in wiresharks interface? Thanks, Matt D - -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJRS9oxAAoJEIC13XTKWhPPmuoH/27MbYkUsz67z5d4/XXr3Oxm eG6ZtiX2Mvacx2ZC2CteAs/1Pd0dvXPcoIZzFhj37/jR/8jnhR4gyR3CR7cfa34y 3g1PmmoYIu0vv8h4SBEPQr+eM2obeTKwsu12rjHyBYJkCsJ4ZU+0izKNVVMI09v7 L+/afPXPoJJ/ALEaMy6v0NE+1aENTEbOuvPiON1cal7K7Pc0RYrTFw+FqKtVkmoY 21Y1IT5TqBRIzi7yfTdbVwYXZfwsAxPTskYnpTyo5jtrfAUd93CU5kvYPhwj5VxT 2tXg8Bj5kg76JsZYZ9hlN3PLeMDeRwwf6ocuKJ+oumC64Ex8jCibEuqk0MJbEbM= =CtYL -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Gr channel_model Problems
Hi guys, I am trying to use gnuradio channel_model to do some simulation right now, and I found something is not consistent in the implementation of the channel_model C++ code. Here is my confusion: In gnuradio-core/src/lib/hier/gr_channel_model.cc : line 57 d_timing_offset = gr_make_fractional_interpolator_cc(0.0, epsilon); defines the timing offset filter as a fractional interpolator. In ./gnuradio-core/src/lib/filter/gr_fractional_interpolator_cc.cc or its implementation, we can see that the constructor's first argument is `phase_shift' and the second arg is 'interp_ration'. From my point of view, `interp_ration' defines the number of input to output ratio, so if it is less than 1.0, this filter gives more output items than what it is input; And the `phase_shift' defines the relative phase of the interpolated sample. However, timing offset should be a metric of phase shift based on symbol timing T instead of `interpolation ratio'. In our software implementation, M=Ts/T >=2, which means the interpolator can only model timing offset at most 1/M, even so, line 57 of gr_channel_model.cc should be d_timing_offset = gr_make_fractional_interpolator_cc(epsilon, 1.0); And many other files using this channel model would then not need to define its timing offset (like example_timing.py, qa_constellation_receiver.py etc.) to be 1.0 to make things correct. I wonder if everyone agrees with this, or I am wrong about this? Thanks. Regards Wang Ning ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
