Re: [Discuss-gnuradio] gnuradio applications on UHD
On Sun, May 22, 2011 at 4:24 AM, open bts wrote: > Has anyone ported the example applications such as > hf_radio to the UHD interface? It looks like the hf_radio > code already has the USRP-specific code isolated out so > that it shouldn't be too difficult (although I'm still new enough > to be intimidated by it :). > It has not been done (publicly at least), but it should be fairly straight-forward. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Store data with usrp_spectrum_sense.py
On Sat, May 21, 2011 at 7:04 PM, Miguel Angel Sanz Rodriguez < mikys...@hotmail.com> wrote: > Hi everyone, > I am new in GNUradio and I want to sense the spectrum of Wifi from 2.4G to > 2.5 G with a USRP. > I have been reading through a lot of discussions in the forum but I have > not been able to store any data using usrp_spectrum_sense.py. I want to > analyze this data with matlab, but I dont get any suitable file after > running spectrum sense. I know that I have to modify the script, but I dont > know how. I am quite bad at programming, so I would appreciate so much a way > to find the solution(it must be very easy, but I am usless in programming) > Thanks in advance for your help > Have a look at usrp_rx_cfile.py. This saves the data from the USRP directly to a file. You can then mix this and the usrp_spectrum_sense.py to probably get what you want. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Synchronize host and USRP N210
Hi Everyone Here are several questions related to USRP N210 1. Considering USRP N210 with GPSDO. Is it possible to use the "PPS in" of the USRP as PPS out ? Can I just put in contact all 3 pins with the jumper j510 ? Will the PPS still be good enough once split ? I'm interested in this to keep the host PC in sync, linking PPS to RS232 PC port, and monitoring rising edge. 2. About size_t uhd::device::send(...) It says "This is a blocking call and will not return until the number of samples returned have been read out of each buffer" Does this mean that function call returns when all data to be transmitted has been copied to USRP memory ? What is the size of USRP N210 memory for sending data with daughter board WBX-FE-Simple ? Considering the timeout, if a timed data to transmit is bigger than internal USRP memory, and tx_timestamp occurs after timeout, then the data will never be sent ? Or never sent entirely ? Is this the case mentioned in doc as "Under a timeout condition, the number of samples returned may be less than the number of samples specified." 3. When using time_spec_t uhd::usrp::multi_usrp::get_time_now(...) what is the typical delay to expect before the function returns ? (still with USRP N210) Can I rely on this call to get precision around 10 - 20 msec ? Bastien ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UCLA Zigbee PHY examples updated for UHD
Thanks for the reply Josh.
However, I'm confused by all the frequency setting/tuning functions at our
disposition. In my example,
1)I am setting cordic-freq (set by parser) while calling the main program, e.g.
-c 245000 -that's the frequency I want to set my USRP to.
2)output of
self.u.set_center_freq(options.cordic_freq, 0)
print "Center frequency: %d" %(self.u.get_center_freq())
is:
Center frequency: 245000
3)output of
uhd.tune_request(options.cordic_freq, 0)
print "Center frequency: %d " %(self.u.get_center_freq())
print ("%s") %(uhd.tune_result())
is:
Center frequency: 26
Tune Result:
Target RF Freq: 0.00 (MHz)
Actual RF Freq: 0.00 (MHz)
Target DSP Freq: 0.00 (MHz)
Actual DSP Freq: 0.00 (MHz)
Why is uhd.tune_request setting the center frequency to 2.6 instead of 2.45 GHz?
Also, am I calling the uhd.tune_result function wrong - why are all the values
0?
Furthermore, what is the difference between
self.u.set_center_freq(options.cordic_freq,0).actual_rf_freq and
self.u.set_center_freq(options.cordic_freq,0) functions?
Regards,
Kresimir
-Original Message-
From: discuss-gnuradio-bounces+kresimir.dabcevic=fer...@gnu.org on behalf of
Josh Blum
Sent: Mon 5/23/2011 12:54 AM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] UCLA Zigbee PHY examples updated for UHD
>> Blocked waiting for GDB attach (pid = 5466)
>> Press Enter to continue:
>> cordic_freq = 2.45G
> Not sure whats wrong, but, cordic_freq should be the error in tuning the
> RF center freq, so only a few kHz really. That may be a good place to
> start looking.
>
> -josh
___
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] QAM demod Error in GRC
Dear Marcus and Bob, I did understand that the block was hollow, but this thread is kindda old, so I thought that in the mean time maybe someone implemented the code and functionality you are referring to. I'm using GRC, but I don't have time to start learning python with the sole purpose of being able to write the QAM block. It would probably be easier to use Simulink, which I'd rather not do. Vlad. Marcus D. Leech wrote: > > On 19/05/2011 1:21 PM, Robert McGwier wrote: >> Vlad >> >> It is apparent to me that you did not understand Josh's explanation. >> Possibly he was not forceful enough. ;-). >> >> This is not an error. It is the mathematical consequence of doing QAM >> with rotational symmetries. YOU MUST provide your OWN synchronization >> to remove the phase ambiguity. It is not a bug or an error. It is a >> feature. It is the mathematical nature of the beast. >> >> Bob >> > Perhaps I have only part of the conversation here, but it sounds like > the main complaint is that there are internal errors inside the >QAMx, x=8,16,64,256 demod blocks--they're implemented as hierarchical > blocks in Python. > > Looking into it, it seems like there still aren't any implementations of > QAMx demodulators--what is there is basically a hollow shell that >does nothing useful. > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- View this message in context: http://old.nabble.com/QAM-demod-Error-in-GRC-tp23722153p31679995.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] A few words on development
On Fri, May 20, 2011 at 12:32 PM, Michael Dickens wrote: > On May 17, 2011, at 5:39 PM, Tom Rondeau wrote: > > What I'm now seeing, and this where the recent UHD apps comes in, is that > there we really have a lack of developers. > > > What it seems to come down to is a lack of initiative. We are all willing > to wait until someone else does something for us, and then report on the > problems. But it's hard to start something and push it out there. > > > Hi Tom - Related to this thread, this blog post about Qt's developer > hierarchy might be interesting. GNU Radio isn't nearly as huge as Qt, but > maybe it could benefit from a similar hierarchy -- which is already in place > to some degree, but maybe having such a post or wiki page would help > solidify it. - MLD > > < > http://labs.qt.nokia.com/2011/05/20/open-governance-roles-and-responsibilities/> > > Last week, in my blog on the Maturity Level List and in the previous week’s > Maturity Levels, I left some indications of what would be expected of a > maintainer of a portion of the Qt codebase. In this blog I’d like to explain > a bit more what’s expected of people working via the Qt Open Governance, > what roles will exist and what responsibilities will each have. > > In short, there will be three levels only: > >• Contributor >• Approver >• Maintainer > > The presence of a “Chief Maintainer” is not exactly a fourth level. More on > that below. Thanks, Michael, that's really useful; it'll definitely give me something to think over, but initially, I like the idea of different people having approval say over some component (like Josh and anything GRC or Achilleas and gr-trellis [if he'd want to]), which would ease the burden on me to make sure everything is good. BTW: I just updated my master branch on my github account. I'll try to remember to keep it up. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] HINT: You can also track the movement of an volcanic ash cloud using USRP
An GR application note, This aint ment to be a commercial advertise, just FYI what you also can do with a USRPx We're tracking the volcanic ash cloud movement from Island, Grimsvotn using USRP + TVRX, 137 MHz and 1.7 GHz (downconverter), 4km and 1km pixel resolution. Air traffic from Scandinavia to US is rerouted. Sample (downsampled 1km image) from Sunday, 22 May @ 0635Z http://www.poes-weather.com/downloads/Iceland-Ash-Cloud/Sun-22-May-2011/ash-cloud-22-05-2011.jpg https://github.com/poes-weather Have fun, Patrik___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UCLA Zigbee PHY examples updated for UHD
update: turns out the problem was power squelch block - connecting self.u
directly to self.packet_receiver did the trick...
-Original Message-
From: Kresimir Dabcevic
Sent: Mon 5/23/2011 12:03 PM
To: j...@joshknows.com; discuss-gnuradio@gnu.org
Subject: RE: [Discuss-gnuradio] UCLA Zigbee PHY examples updated for UHD
>
>Thanks for the reply Josh.
>
>However, I'm confused by all the frequency setting/tuning functions at our
>disposition. In my example,
>1)I am setting cordic-freq (set by parser) while calling the main program,
>e.g. -c 245000 -that's the frequency I want to set my USRP to.
>
>2)output of
>self.u.set_center_freq(options.cordic_freq, 0)
>print "Center frequency: %d" %(self.u.get_center_freq())
>is:
>Center frequency: 245000
>
>3)output of
>uhd.tune_request(options.cordic_freq, 0)
>print "Center frequency: %d " %(self.u.get_center_freq())
>print ("%s") %(uhd.tune_result())
>is:
>Center frequency: 26
>Tune Result:
>Target RF Freq: 0.00 (MHz)
>Actual RF Freq: 0.00 (MHz)
>Target DSP Freq: 0.00 (MHz)
>Actual DSP Freq: 0.00 (MHz)
>
>Why is uhd.tune_request setting the center frequency to 2.6 instead of 2.45
>GHz?
>Also, am I calling the uhd.tune_result function wrong - why are all the values
>0?
>Furthermore, what is the difference between
>self.u.set_center_freq(options.cordic_freq,0).actual_rf_freq and
>self.u.set_center_freq(options.cordic_freq,0) >functions?
>
>Regards,
>Kresimir
-Original Message-
From: discuss-gnuradio-bounces+kresimir.dabcevic=fer...@gnu.org on behalf of
Josh Blum
Sent: Mon 5/23/2011 12:54 AM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] UCLA Zigbee PHY examples updated for UHD
>>>
>>>
>>> Blocked waiting for GDB attach (pid = 5466)
>>> Press Enter to continue:
>>> cordic_freq = 2.45G
>>>
>> Not sure whats wrong, but, cordic_freq should be the error in tuning the
>> RF center freq, so only a few kHz really. That may be a good place to
>> start looking.
>>
>> -josh
___
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] QAM demod Error in GRC
On 05/23/2011 03:29 AM, Vlad Stoianovici wrote: > > Dear Marcus and Bob, > I did understand that the block was hollow, but this thread is kindda old, > so I thought that in the mean time maybe someone implemented the code and > functionality you are referring to. > I'm using GRC, but I don't have time to start learning python with the sole > purpose of being able to write the QAM block. > It would probably be easier to use Simulink, which I'd rather not do. > This is a motivating example for a new gr-digital component that can make use of tags: the QAM deframer block. :-) -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UCLA Zigbee PHY examples updated for UHD
> However, I'm confused by all the frequency setting/tuning functions at our > disposition. In my example, > 1)I am setting cordic-freq (set by parser) while calling the main program, > e.g. -c 245000 -that's the frequency I want to set my USRP to. > OK, I guess everything is fine. As a matter of terminology, calling it center freq might make more sense. The cordic frequency is the DSP frequency. > Why is uhd.tune_request setting the center frequency to 2.6 instead of 2.45 > GHz? > Also, am I calling the uhd.tune_result function wrong - why are all the > values 0? You are making a new (empty tune result object). Not the one returned by the set center frequency. > Furthermore, what is the difference between > self.u.set_center_freq(options.cordic_freq,0).actual_rf_freq and > self.u.set_center_freq(options.cordic_freq,0) functions? > Accessing a parameter vs not accessing a parameter? -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Non SDHC Card Availability for USRP2s
I discovered today that almost no big retailer (newegg, bestbuy, etc) except amazon appears to sell 1 GB SD cards any more and 2GB cards are probably going to be headed that way sooner or later. 2GB cards, while also overkill on the USRPs, are riskier to buy since some may be SDHC. What's the long term plan for making sure we have cards we can stick in these things? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Non SDHC Card Availability for USRP2s
On 05/23/2011 10:54 AM, Brett L. Trotter wrote: > I discovered today that almost no big retailer (newegg, bestbuy, etc) > except amazon appears to sell 1 GB SD cards any more and 2GB cards are > probably going to be headed that way sooner or later. 2GB cards, while > also overkill on the USRPs, are riskier to buy since some may be SDHC. > > What's the long term plan for making sure we have cards we can stick in > these things? > We have a big supply of them, and you can get them from us. Matt Ettus ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How exactly dose rx_callback work in benchmark script?
You need to follow the code into the other modules that are imported by benchmark_rx.py. The rx_callback function is passed as an argument to the constructor of my_top_block, which in turn passes it to the constructor of usrp_receive_path (in usrp_receive_path.py). In usrp_receive_path, the function is then passed to the constructor of the class receive_path (in receive_path.py), which then passes it to the constructor of class demod_pkts in the blks2 namespace. Now here it may get a little confusing, because (1) there is no blks2.py file if you want to look up the code for demod_pkts, and (2) the relevant code is in a different part of the gnuradio source tree. The code for class demod_pkts is actually in /gnuradio-core/src/python/gnuradio/blks2impl/pkt.py. In pkt.py, you'll see that demod_pkts spawns a thread that listens for messages dispatched over a queue, and invokes the rx_callback function passed to it each time it receives a message. The queue is asynchronously fed by a flow-graph (including filter, demodulator, correlator etc.) in the demod_pkts class that receives samples from a source and converts to packets. The code for making and un-making packets is in /gnuradio-core/src/python/gnuradio/packet_utils.py. Disclaimer: I'm on an outdated version of the source tree, so things may not be exactly as I described them. Hope this helps. Kunal On Sat, May 21, 2011 at 3:20 AM, yulong yang wrote: > Hi all, > > I have been reading the benchmark_rx.py codes.I want to add the channel > sensing and selecting in callback function. > > I understand rx_callback in benchmark_rx is a function that make the block > wait for packet generating from the data that received from the receive_path > while running. But how dose it work exactly? Is the tb.wait() waiting for > this callback? Why I cannot find anywhere that have called this function in > the script, dose it run automatically? > > Thank you in advance. > > > > > ___ > 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] To implement WiMAX with GnuRadio or not?
Hi community, Our WiMAX Scanner project (http://code.google.com/p/wimax-scanner/) approaches the moment when we should start writing C/C++ code - our Matlab model decodes broadcast messages from all recordings we have on hands. At this point we have to make a choice - rely on GnuRadio or create our own framework. Until recently I was sure would create our own framework, but recent discussions on this list made me think GnuRadio may be an option. So, I'm looking for the community help with the the following questions: 1) How well is GnuRadio suited for packet data processing? WiMAX is essentially a packet-oriented system. 2) We don't want to use Python. Is there anything we can't do without it? And where can we find examples of C++-only flowgraphs? 3) Right now all our code is open-source, but we must leave an option for proprietary plugins. How can we make this possible? 4) Related to (3) - how can we make sure our protocol stack can be embedded into a closed-source application/system? PS I have heavy travel schedule these days and a lot of other duties, so please excuse me is I respond slow. -- Regards, Alexander Chemeris. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] QAM demod Error in GRC
On Mon, May 23, 2011 at 12:09 PM, Josh Blum wrote: > > > On 05/23/2011 03:29 AM, Vlad Stoianovici wrote: >> >> Dear Marcus and Bob, >> I did understand that the block was hollow, but this thread is kindda old, >> so I thought that in the mean time maybe someone implemented the code and >> functionality you are referring to. >> I'm using GRC, but I don't have time to start learning python with the sole >> purpose of being able to write the QAM block. >> It would probably be easier to use Simulink, which I'd rather not do. >> > > This is a motivating example for a new gr-digital component that can > make use of tags: the QAM deframer block. :-) > > -josh > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > In the psk8 branch of my github repo (www.github.com/benreynwar/gnuradio/) there is QAM modulation and demodulation within the "digital" category of GRC. I haven't tested it recently though. Let me know if you try it and it doesn't work. Cheers, Ben ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] About gr_buffer_add_reader
Hi list, I have a USRP N210, running on Ubuntu-10.04, when I try to use the Gnuradio-Companion to make a fm_receiver, I success generate the python code, but when i try to run it, it shows --- terminate called after throwing an instance of 'std::invalid_argument' what(): gr_buffer_add_reader: nzero_preload must be >= 0 --- what is that mean? I know that I might have some problem in the flow graph or parameter because I use the old version example(USRP1) which I search on the internet as the reference, can any one help me? PS I would like to ask an additional question: If I only have DBSRX RFX1200 RFX1800 these three daughterboards, is that means I can't receive the 100MHz FM Radio Signal by my fm_receiver through the USRP N210 (bandwidth not right)? or there is some other ways ? thanks, Eddie ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] To implement WiMAX with GnuRadio or not?
On Mon, May 23, 2011 at 11:50:52PM +0400, Alexander Chemeris wrote: > Hi community, Hi Alex, > Our WiMAX Scanner project (http://code.google.com/p/wimax-scanner/) > approaches the moment when we should start writing C/C++ code - our > Matlab model decodes broadcast messages from all recordings we have on > hands. That's great. I think GNU Radio would benefit from having big, cool projects. Here's my thoughts and experiences: > At this point we have to make a choice - rely on GnuRadio or create > our own framework. Until recently I was sure would create our own > framework, but recent discussions on this list made me think GnuRadio > may be an option. So, I'm looking for the community help with the the > following questions: > > 1) How well is GnuRadio suited for packet data processing? WiMAX is > essentially a packet-oriented system. What you're writing is receiver-only, right? In that case, GNU Radio will be able to handle all your data just fine. It gets tricky when you have a transceiver with timing-sensitive operations, but it seems your project would work well. GNU Radio is pretty agnostic of the data moved between blocks. > 2) We don't want to use Python. Is there anything we can't do without > it? And where can we find examples of C++-only flowgraphs? There are some examples in gnuradio-examples/c++. It's really not that hard, and I've done some C++-only projects with great success. However, let me ask why you don't want to use Python. Is it because you want a final product that works without Python, or do you have a real 'allergy'? Because I recommend that *even* for a C++-only project, you still use Python for unit tests. Also, this gives you the opportunity to quickly click together tests using GRC. This will make development a *lot* easier. Side note: Porting from Matlab to Python is much simpler than going from Matlab to C++ (for porting your unit tests). > 3) Right now all our code is open-source, but we must leave an option > for proprietary plugins. How can we make this possible? > > 4) Related to (3) - how can we make sure our protocol stack can be > embedded into a closed-source application/system? IANAL, TINLA. I'm guessing your best bet would be to separate the actual DSP code from the GNU Radio bindings and have very lean GNU Radio blocks (being GPL) which only call your module. Still, I don't know how or if you may link code across licenses. You will have to get legal help here, I would not rely on anything said on this list. Good luck with your project! MB -- 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 pgpGqd3gIeZ4h.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
