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] 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, RS, 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 dan.bar.mailingl...@gmx.atwrote: 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 phi...@balister.org 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 mle...@ripnet.com 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 mle...@ripnet.com 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 glneolistm...@gmail.comwrote: 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 mle...@ripnet.comwrote: 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 trondeau1...@gmail.com wrote: On Fri, Dec 23, 2011 at 8:23 PM, Andrew Davis glneolistm...@gmail.comwrote: 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 mle...@ripnet.comwrote: 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 glneolistm...@gmail.com 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 trondeau1...@gmail.com wrote: On Fri, Dec 23, 2011 at 8:23 PM, Andrew Davis glneolistm...@gmail.com wrote: -- Bob McGwier Facebook: N4HYBob ARS: N4HY ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
