Re: [Discuss-gnuradio] Added functionality for pre and post samples to burst tagger
Hi, I have made some improvements to my code at GitHub: - Created GRC xml files for the modified burst tagger and the existing tagged file sink - Added a tagged message sink, which is based on the existing tagged file sink - Added Python QA code for the burst tagger and the tagged message sink Maybe this additions are useful for somebody on the list. It would be a pleasure for me :-). Best regards, Daniel > Hi, > > > I have made some modifications to the existing burst tagger in the GNU Radio > source code. > It is now able to specify an amount of pre and post samples, which are > additionally tagged before and after the tag signal. > > I have put my changes on my GitHub account, which is: > > https://bar...@github.com/bartel/gnuradio-bartel.git > > > Since this is my first work with Git and my first direct change to the GNU > Radio source code, I would be glad for any advise on improving my > code/changes. > > I have also tested my code locally, since I am not quite sure, how to add a > QA > code for a C++ block to GNU Radio. Should it be with cppunit or pyunit? > Thank's for helping. > > Best regards, > Daniel ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Question about grc parameter entry
Just curious: what is the meaning of the different colors of the parameter entry blocks in the various grc modules ?? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DC component
I have noticed that there are some fixed frequency spurious signals in my N210. These spurious signals are probably associated with the harmonics of the clock. If your DC component is at some nice even frequency like 2GHz, I would suspect a spurious signal to be the cause. Evan -Original Message- From: discuss-gnuradio-bounces+evan=syndetix@gnu.org [mailto:discuss-gnuradio-bounces+evan=syndetix@gnu.org] On Behalf Of Marcus D. Leech Sent: Thursday, December 22, 2011 11:42 AM To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] DC component > Hi all,I'm observing a DC component inside my spectrum as you can see > in the two pictures in attachment (differentfrequency ranges), this DC > is only shown when there is no active transmission (only noise). > Consider I'm already using the UHD's advanced tuning specifying the LO > at 3Mhz. I'm receiving a signal witha central frequency of 430MHz with > a bandwidth of around 5Mhz, the DC due the LO should be quite away. > Is this normal ? > > Regards > Gaetano > You can use the "calibration" utilities that come with a modern UHD (latest from GIT), assuming either a SBX or WBX board, which can reduce the magnitude of the "DC anomaly", by calibrating the phase and gain errors in the mixers at various frequencies, and compensating in the FPGA. http://files.ettus.com/uhd_docs/manual/html/calibration.html -- 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 - No virus found in this message. Checked by AVG - www.avg.com Version: 2012.0.1901 / Virus Database: 2109/4696 - Release Date: 12/22/11 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] PSD Display from USRP Data
Can i get the USRP code ? Rahman Doost wrote: > > Hello Guys, > > I am very new to GNU Radio. I am trying to develop a python program that > graphically displays data from USRP which sweeps a user-defined frequency > band from down-freq to up-freq. USRP is tuned to divide the input band to > 3 > MHz sub-bands and return the power spectral density. I am using > usrp.source_c to connect to the board. I have two threads, one running GUI > and shows the input of PSD; the second one stores the FFT components of > each > sub-band to a file. In the GUI, I use fftsink2.usrp_sink_c() to display > the > PSD for the currect scanning band. But what I can not display is the > current > sub-band whose FFT result are plotted by usrp_sink_c. That's because on > the > X-axis of the plot I have the center frequency 0 and freq ranging from > -1.5 > MHz to 1.5 MHz. What I need is either having the whole spectrum being > plotted with history, not just the current scanned sub-band, or > representing > the currect frequency sub-band which is being scanned. I was wondering If > someone can help me out on this. > > Regards, > Rahman Doost > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- View this message in context: http://old.nabble.com/PSD-Display-from-USRP-Data-tp19715258p33029436.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] DC component
Please do not get me wrong. I believe that the work from Ettus and the contributors to GNU-Radio are revolutionary! The equipment with the interface to GNU-Radio is not only priced at a level that is affordable to many amateurs and hobbyists, it opens up a brand new world for... (the list is too long to list here) In fact, I am so impressed that I desire to contribute to the community. First by contributing to these forums and second by eventually posting projects to CGRAN! My intent was to let Gaetano know of the potential for spurious signals so that he can properly select a center frequency that is free of these little nuisances. Again, I am impressed with the level of commitment and the work that the team puts into to improving an already great product. Evan Merewether -Original Message- From: discuss-gnuradio-bounces+evan=syndetix@gnu.org [mailto:discuss-gnuradio-bounces+evan=syndetix@gnu.org] On Behalf Of Marcus D. Leech Sent: Friday, December 23, 2011 7:54 AM To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] DC component > I have noticed that there are some fixed frequency spurious signals in my > N210. These spurious signals are probably associated with the harmonics of > the clock. If your DC component is at some nice even frequency like 2GHz, I > would suspect a spurious signal to be the cause. > > Evan > > Spurious signals are a virtually-inevitable aspect of modern receivers/transmitters. Many of us are used to radios that are "purpose built", and probably don't realize that most such radios have their own problems with spurious signals ("spurs"), but that they get "tweaked" in the design phase to move those (inevitable) "spurs" outside the operational envelope of the particular application at hand. Your radio have a CPU? Move the fundamental of its clock frequency so that the fundamental and harmonics fall outside of your band of interest. But in a radio whose "band of interest" lies anywhere from DC up to a few GHz, that's a very tall order. The good news is that most of the time, these "spurs" are quite weak, and are generally overwhelmed by any actual signal coming in from the antenna at the the same frequencies. For modern wideband modulation schemes, an in-band spur that's 30-40dB below your nominal incoming signal make essentially no difference to the receive SNR. For narrowband weak signals that are coming in just above the noise floor, it might be a different story. I've attached a plot of 50MHz of spectrum (thanks to the latest 50Msps/sc8 support in UHD) around 1.420GHz, with the receiver input terminated in a 50 Ohm lab-grade termination. You can clearly see spurious signals spaced every 5MHz, and a stronger one right at 1.40MHz. The 5MHz may be from the ethernet clock, not sure, but the stronger spur at 1.4GHz is very likely due to an even harmonic of the 100MHz master clock. Even though this "spur" at 1.4GHz is 40dB "out of the noise", in most applications the signals themselves will *dwarf* that spur. The other spurs, across 50MHz of bandwidth are no more than 20dB "out of the noise". They don't worry me that much, even for applications like radio astronomy, where the signals are really weak. Placing a low-noise gain chain ahead of the receiver, with enough gain to "swamp" the receiver spurs is all I need to make these go away. It's true that a $40K laboratory-calibrated receiver like an (Agilent, R&S, etc) spectrum analyser will likely have fewer "spurs". But if you open one of those up, you'll notice a lot of individually shielded sub-assemblies--that's not just for show. They'll also do tricks like spreading the clocks for the control/monitoring CPU, shifting clocks around, to make the "spurs" move away from the current band of interest. And for the most part, things like laboratory spectrum analysers are "deaf as a post"--they aren't designed, generally, to be "off-air" receivers, so they tend to be less sensitive to their own "spurs". -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org - No virus found in this message. Checked by AVG - www.avg.com Version: 2012.0.1901 / Virus Database: 2109/4697 - Release Date: 12/22/11 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Added functionality for pre and post samples to burst tagger
On Fri, Dec 23, 2011 at 4:35 AM, Daniel Bartel wrote: > Hi, > > I have made some improvements to my code at GitHub: > > - Created GRC xml files for the modified burst tagger and the existing > tagged file sink > - Added a tagged message sink, which is based on the existing tagged file > sink > - Added Python QA code for the burst tagger and the tagged message sink > > Maybe this additions are useful for somebody on the list. > It would be a pleasure for me :-). > > Best regards, > Daniel Hi Daniel, Sorry for not responding before; just lost track. I really wanted to thank you for putting this together and offering it to the community. That's really great! I plan on looking this over soon. Tom > > Hi, > > > > > > I have made some modifications to the existing burst tagger in the GNU > Radio > > source code. > > It is now able to specify an amount of pre and post samples, which are > > additionally tagged before and after the tag signal. > > > > I have put my changes on my GitHub account, which is: > > > > https://bar...@github.com/bartel/gnuradio-bartel.git > > > > > > Since this is my first work with Git and my first direct change to the > GNU > > Radio source code, I would be glad for any advise on improving my > code/changes. > > > > I have also tested my code locally, since I am not quite sure, how to > add a QA > > code for a C++ block to GNU Radio. Should it be with cppunit or pyunit? > > Thank's for helping. > > > > Best regards, > > Daniel > > > > ___ > 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] DC component
> > Please do not get me wrong. I believe that the work from Ettus and the > contributors to GNU-Radio are revolutionary! The equipment with the > interface to GNU-Radio is not only priced at a level that is affordable to > many amateurs and hobbyists, it opens up a brand new world for... (the list > is too long to list here) > > In fact, I am so impressed that I desire to contribute to the community. > First by contributing to these forums and second by eventually posting > projects to CGRAN! > > My intent was to let Gaetano know of the potential for spurious signals so > that he can properly select a center frequency that is free of these little > nuisances. > > Yup, understood. At lot of the folks on this list come at SDR from a background in software/digital, where the "vagaries" of the analog world are entirely foreign to them, and they may see the existence of such things as "spurs" as some kind of horrible defect, rather than an inevitable annoyance. So I felt an explanatory note was in order. Another subset on this forum come from a background where they're used to dealing with lab-calibrated instruments that their corporate lords and masters (or university administration) have spent significant money on, so their performance expectations (along certain vectors, anyway) will be driven by what they've seen their $40-$100K lab instruments do. The ham radio community is used to dealing with this. As radios became more and more broadly-tunable, it was no big surprise that "birdies" (a peculiar ham-radio term for "spurs") became more and more frequently observable, since it was no longer possible to "tune" the underlying "birdy-producing" mechanisms to produce those "birdies" outside the band of interest, since the "band of interest" became larger and larger. -- 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] GNURadio website
http://www.downforeveryoneorjustme.com/gnuradio.org Philip ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question about grc parameter entry
On 12/23/2011 04:44 AM, John L DuBois wrote: > Just curious: what is the meaning of the different colors of the > parameter entry blocks in the various grc modules ?? > Each color is a data type. You can mouse over a particular parameter box. A tool top window pops up to describe the parameter and data type. -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] UHD default subdevice.
Hello all, Some programs don't let you specify a subdevice, they let UHD decide, in my case it picks wrong. Is there a uhd config file to chose the default subdevice if one is not specified ( I also wouldn't have to type "--spec "A:0" so much ). Thank you! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNURadio website
Back up. Tom On Dec 23, 2011, at 1:23 PM, Philip Balister wrote: > http://www.downforeveryoneorjustme.com/gnuradio.org > > Philip > > ___ > 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] UHD default subdevice.
Could you give me a hint? How do you interface with UHD before a C++/python program requests the device? On Fri, Dec 23, 2011 at 3:21 PM, Marcus D. Leech wrote: > > Hello all, > > > > Some programs don't let you specify a subdevice, they let UHD decide, > > in my case it picks wrong. Is there a uhd config file to chose the > > default subdevice if one is not specified ( I also wouldn't have to > > type "--spec "A:0" so much ). > > > > Thank you! > You could always write a little startup script that provides all the > defaults you want. > > > > -- > 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] Regarding internship and PhD opportunities
Hello Everyone!! I am an International Student enrolled in Masters of Science in Embedded Systems at ECE Paris. I am pursuing a 2 years MS course in Paris with prestigious Ile de France Fellowship by French Government. Before that I have completed my Bachelor of Technology from BKBIET Pilani in July 2011. Currently I am also involved in a research project on Software Defined Radio at my university in Paris, which involves work on Universal Software Radio Peripheral Device (USRP) and GnuRadio. I am also highly skilled in microcntrollers and their assembly programming. Also I am good at algorithm development for different problems. I am highly motivated to pursue my career in Research and PhD. As my masters requires me to do two internships during my studies, one in first year for 4 months (May 2012 to September 2012) and second in second year for 6 months (Feb 2013 to Jul 2013), I am interested in pursuing these internships in same research field so that I can excel in that which will also help me in pursuing PhD further. I would be glad to know if there is any institute or organization looking for candidates like me ready to devote 10 months of internship as well as pursue PhD in same field. Thank you very much Best Regards Shashank Gaur ECE Paris ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD default subdevice.
Could you give me a hint? How do you interface with UHD before a C++/python program requests the device? Well, you complained about having to "type --spec A:0" a lot, which is a natural for a shell script that starts your program--whether that program is written in C++ or Python, and simply pass in a fixed value for "the --spec" option to the program you're trying to run. For example, any of the setup parameters (well, *most*) of a uhd_usrp_source or uhd_usrp_sink can be taken from a variable or command-line parameter, using the "variables" section in GRC, so you make them come from command-line parameters, and default those parameters, and again, you can make it fancier with a shell script surrounding the invocation of the target program. In fact, I have one startup script that parses the output of "uhd_usrp_probe" to determine what cards I'm dealing with, and set command-line parameters appropriately from parsing the output of "uhd_usrp_probe". I'm also working on an easier-to-use little python program that is intended to set a bunch of shell variables based on probing the hardware and setting a bunch of standard variables--specifically to support better autoconfiguration from within shell scripts, etc. If the target program *doesn't support* the parameter you want as a command-line parameter, then *add it*, and submit it to be folded back in to the mainline. I recently did this for uhd_fft.py and rx_cfile.py to support the "sc8" alternative wire-format, which is necessary to support 33.33Msps and 50Msps sample rates out of USRP2/N2XX. -- 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
Re: [Discuss-gnuradio] UHD default subdevice.
I see what your saying but typing "--address 'type=usrp1' --spec 'A:0' --antenna 'TX/RX'" every time wasn't my problem. The problem is programs that let UHD pick the default device, I don't know how UHD chooses but it could check ~/.uhd/uhd.conf or something instead of guessing. As you said I could just fix the programs, but many of them are not maintained and why fix up useless old programs when I could be fixing UHD which is still maintained and would fix the old programs in the process. Same for main GNUradio programs, the default device/subdevice/antenna parser options could be read from a config file too. So does this already exist somewhere or how can I help implement it? On Fri, Dec 23, 2011 at 5:13 PM, Marcus D. Leech wrote: > Could you give me a hint? How do you interface with UHD before a >> C++/python program requests the device? >> >> >> Well, you complained about having to "type --spec A:0" a lot, which is a > natural for a shell script that starts your program--whether that > program is written in C++ or Python, and simply pass in a fixed value for > "the --spec" option to the program you're trying to run. > > For example, any of the setup parameters (well, *most*) of a > uhd_usrp_source or uhd_usrp_sink can be taken from a variable or > command-line > parameter, using the "variables" section in GRC, so you make them come > from command-line parameters, and default those > parameters, and again, you can make it fancier with a shell script > surrounding the invocation of the target program. In fact, > I have one startup script that parses the output of "uhd_usrp_probe" to > determine what cards I'm dealing with, and set command-line > parameters appropriately from parsing the output of "uhd_usrp_probe". > I'm also working on an easier-to-use little python program > that is intended to set a bunch of shell variables based on probing the > hardware and setting a bunch of standard variables--specifically > to support better autoconfiguration from within shell scripts, etc. > > If the target program *doesn't support* the parameter you want as a > command-line parameter, then *add it*, and submit it > to be folded back in to the mainline. I recently did this for uhd_fft.py > and rx_cfile.py to support the "sc8" alternative wire-format, which is > necessary to support 33.33Msps and 50Msps sample rates out of USRP2/N2XX. > > -- > 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
Re: [Discuss-gnuradio] UHD default subdevice.
On Fri, Dec 23, 2011 at 8:23 PM, Andrew Davis wrote: > I see what your saying but typing "--address 'type=usrp1' --spec 'A:0' > --antenna 'TX/RX'" every time wasn't my problem. > The problem is programs that let UHD pick the default device, I don't know > how UHD chooses but it could check ~/.uhd/uhd.conf > or something instead of guessing. As you said I could just fix the > programs, but many of them are not maintained and why > fix up useless old programs when I could be fixing UHD which is still > maintained and would fix the old programs in the process. > Same for main GNUradio programs, the default device/subdevice/antenna > parser options could be read from a config file too. > So does this already exist somewhere or how can I help implement it? An interesting proposition. The problem is that the modularity of the USRPs allows people to switch daughterboards easily and quickly. How would you propose to set the defaults if people change their d'boards? Some kind of a hash on the description of the device to see if it's the same USRP and d'board configuraiton? Tom > > > On Fri, Dec 23, 2011 at 5:13 PM, Marcus D. Leech wrote: > >> Could you give me a hint? How do you interface with UHD before a >>> C++/python program requests the device? >>> >>> >>> Well, you complained about having to "type --spec A:0" a lot, which is >> a natural for a shell script that starts your program--whether that >> program is written in C++ or Python, and simply pass in a fixed value >> for "the --spec" option to the program you're trying to run. >> >> For example, any of the setup parameters (well, *most*) of a >> uhd_usrp_source or uhd_usrp_sink can be taken from a variable or >> command-line >> parameter, using the "variables" section in GRC, so you make them come >> from command-line parameters, and default those >> parameters, and again, you can make it fancier with a shell script >> surrounding the invocation of the target program. In fact, >> I have one startup script that parses the output of "uhd_usrp_probe" to >> determine what cards I'm dealing with, and set command-line >> parameters appropriately from parsing the output of "uhd_usrp_probe". >> I'm also working on an easier-to-use little python program >> that is intended to set a bunch of shell variables based on probing the >> hardware and setting a bunch of standard variables--specifically >> to support better autoconfiguration from within shell scripts, etc. >> >> If the target program *doesn't support* the parameter you want as a >> command-line parameter, then *add it*, and submit it >> to be folded back in to the mainline. I recently did this for >> uhd_fft.py and rx_cfile.py to support the "sc8" alternative wire-format, >> which is >> necessary to support 33.33Msps and 50Msps sample rates out of USRP2/N2XX. >> >> -- >> 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
Re: [Discuss-gnuradio] UHD default subdevice.
That might work, but why worry about people who reconfigure just yet, us who use the device consistently still have to type several args every-time we run a program, the first step is a simple default device config file. On Fri, Dec 23, 2011 at 9:09 PM, Tom Rondeau wrote: > On Fri, Dec 23, 2011 at 8:23 PM, Andrew Davis wrote: > >> I see what your saying but typing "--address 'type=usrp1' --spec 'A:0' >> --antenna 'TX/RX'" every time wasn't my problem. >> The problem is programs that let UHD pick the default device, I don't >> know how UHD chooses but it could check ~/.uhd/uhd.conf >> or something instead of guessing. As you said I could just fix the >> programs, but many of them are not maintained and why >> fix up useless old programs when I could be fixing UHD which is still >> maintained and would fix the old programs in the process. >> Same for main GNUradio programs, the default device/subdevice/antenna >> parser options could be read from a config file too. >> So does this already exist somewhere or how can I help implement it? > > > An interesting proposition. The problem is that the modularity of the > USRPs allows people to switch daughterboards easily and quickly. How would > you propose to set the defaults if people change their d'boards? Some kind > of a hash on the description of the device to see if it's the same USRP and > d'board configuraiton? > > Tom > > > >> >> >> On Fri, Dec 23, 2011 at 5:13 PM, Marcus D. Leech wrote: >> >>> Could you give me a hint? How do you interface with UHD before a C++/python program requests the device? Well, you complained about having to "type --spec A:0" a lot, which is >>> a natural for a shell script that starts your program--whether that >>> program is written in C++ or Python, and simply pass in a fixed value >>> for "the --spec" option to the program you're trying to run. >>> >>> For example, any of the setup parameters (well, *most*) of a >>> uhd_usrp_source or uhd_usrp_sink can be taken from a variable or >>> command-line >>> parameter, using the "variables" section in GRC, so you make them come >>> from command-line parameters, and default those >>> parameters, and again, you can make it fancier with a shell script >>> surrounding the invocation of the target program. In fact, >>> I have one startup script that parses the output of "uhd_usrp_probe" to >>> determine what cards I'm dealing with, and set command-line >>> parameters appropriately from parsing the output of "uhd_usrp_probe". >>> I'm also working on an easier-to-use little python program >>> that is intended to set a bunch of shell variables based on probing the >>> hardware and setting a bunch of standard variables--specifically >>> to support better autoconfiguration from within shell scripts, etc. >>> >>> If the target program *doesn't support* the parameter you want as a >>> command-line parameter, then *add it*, and submit it >>> to be folded back in to the mainline. I recently did this for >>> uhd_fft.py and rx_cfile.py to support the "sc8" alternative wire-format, >>> which is >>> necessary to support 33.33Msps and 50Msps sample rates out of >>> USRP2/N2XX. >>> >>> -- >>> 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
Re: [Discuss-gnuradio] UHD default subdevice.
Capture your complex command line in a shell script seems an easy way to do this yesterday, today, and tomorrow. Bob On Friday, December 23, 2011, Andrew Davis wrote: > That might work, but why worry about people who reconfigure just yet, us who use the device consistently still have to type several args every-time we run a program, the first step is a simple default device config file. > > On Fri, Dec 23, 2011 at 9:09 PM, Tom Rondeau wrote: >> >> On Fri, Dec 23, 2011 at 8:23 PM, Andrew Davis wrote: >> -- Bob McGwier Facebook: N4HYBob ARS: N4HY ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UHD default subdevice.
On Fri, Dec 23, 2011 at 9:23 PM, Andrew Davis wrote: > That might work, but why worry about people who reconfigure just yet, us > who use the device consistently still have to type several args every-time > we run a program, the first step is a simple default device config file. > I'm more concerned that changing the default would screw up people who change their d'boards. Or are you suggesting we have a config file that you would enter as the parameter (-F ~/.gnuradio/usrp.conf)? Would you be up for outlining the process that would go in to creating and using the file? What exactly would be automated? How would people set the defaults and decide to use them or not? That type of thing. Of course, in the meantime, you could create a file that just contains a line of the standard parameters (-a, -A, --subdev, etc.) and use `cat file` in the command line to put it inline with command. Or make a shell script with the program with the parameters already specified (with the $* for any extras you want to put in). I'm not suggesting these as a real solution, but they might help you temporarily. Tom > On Fri, Dec 23, 2011 at 9:09 PM, Tom Rondeau wrote: > >> On Fri, Dec 23, 2011 at 8:23 PM, Andrew Davis wrote: >> >>> I see what your saying but typing "--address 'type=usrp1' --spec 'A:0' >>> --antenna 'TX/RX'" every time wasn't my problem. >>> The problem is programs that let UHD pick the default device, I don't >>> know how UHD chooses but it could check ~/.uhd/uhd.conf >>> or something instead of guessing. As you said I could just fix the >>> programs, but many of them are not maintained and why >>> fix up useless old programs when I could be fixing UHD which is still >>> maintained and would fix the old programs in the process. >>> Same for main GNUradio programs, the default device/subdevice/antenna >>> parser options could be read from a config file too. >>> So does this already exist somewhere or how can I help implement it? >> >> >> An interesting proposition. The problem is that the modularity of the >> USRPs allows people to switch daughterboards easily and quickly. How would >> you propose to set the defaults if people change their d'boards? Some kind >> of a hash on the description of the device to see if it's the same USRP and >> d'board configuraiton? >> >> Tom >> >> >> >>> >>> >>> On Fri, Dec 23, 2011 at 5:13 PM, Marcus D. Leech wrote: >>> Could you give me a hint? How do you interface with UHD before a > C++/python program requests the device? > > > Well, you complained about having to "type --spec A:0" a lot, which is a natural for a shell script that starts your program--whether that program is written in C++ or Python, and simply pass in a fixed value for "the --spec" option to the program you're trying to run. For example, any of the setup parameters (well, *most*) of a uhd_usrp_source or uhd_usrp_sink can be taken from a variable or command-line parameter, using the "variables" section in GRC, so you make them come from command-line parameters, and default those parameters, and again, you can make it fancier with a shell script surrounding the invocation of the target program. In fact, I have one startup script that parses the output of "uhd_usrp_probe" to determine what cards I'm dealing with, and set command-line parameters appropriately from parsing the output of "uhd_usrp_probe". I'm also working on an easier-to-use little python program that is intended to set a bunch of shell variables based on probing the hardware and setting a bunch of standard variables--specifically to support better autoconfiguration from within shell scripts, etc. If the target program *doesn't support* the parameter you want as a command-line parameter, then *add it*, and submit it to be folded back in to the mainline. I recently did this for uhd_fft.py and rx_cfile.py to support the "sc8" alternative wire-format, which is necessary to support 33.33Msps and 50Msps sample rates out of USRP2/N2XX. -- 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