Re: [Discuss-gnuradio] Added functionality for pre and post samples to burst tagger

2011-12-23 Thread Daniel Bartel
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

2011-12-23 Thread John L DuBois
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

2011-12-23 Thread Evan Merewether
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

2011-12-23 Thread Naveen saini

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

2011-12-23 Thread Evan Merewether
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

2011-12-23 Thread Tom Rondeau
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

2011-12-23 Thread Marcus D. Leech
>
> 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

2011-12-23 Thread Philip Balister
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

2011-12-23 Thread Josh Blum


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.

2011-12-23 Thread Andrew Davis
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

2011-12-23 Thread Tom Rondeau
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.

2011-12-23 Thread Andrew Davis
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

2011-12-23 Thread shashank gaur
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.

2011-12-23 Thread Marcus D. Leech
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.

2011-12-23 Thread Andrew Davis
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.

2011-12-23 Thread Tom Rondeau
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.

2011-12-23 Thread Andrew Davis
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.

2011-12-23 Thread Robert McGwier
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.

2011-12-23 Thread Tom Rondeau
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