Re: [Discuss-gnuradio] set_auto_tr(), gr_stall, and PTT

2007-09-10 Thread Michael Dickens
On Sep 10, 2007, at 10:07 PM, Eric Blossom wrote: There's no gr_stall. Currently auto_tr mode is used with the packet data examples. See gnuradio-examples/python/digital. There is no explicit "stall", the transmitter pipeline stalls when no packets are being fed into the PHY via the message so

Re: [Discuss-gnuradio] set_auto_tr(), gr_stall, and PTT

2007-09-10 Thread Eric Blossom
On Mon, Sep 10, 2007 at 03:19:53PM -0400, Michael Dickens wrote: > This email is to verify 2 items: > > A) As per emails (1) and (2) below, in order to use the set_auto_tr() > feature on RFX boards, I need to stall the TX path somehow since - > any- input on the TX path will result in no RX (ev

Re: [Discuss-gnuradio] FPGA sample timestamps

2007-09-10 Thread George Nychis
Hi Roshan, With the in-band signaling implementation we have added timestamps to all data across the USB bus. You can find the new packet structure here: http://gnuradio.org/trac/browser/gnuradio/trunk/usrp/doc/inband-signaling-usb I'm not sure what kind of application you want to create or u

[Discuss-gnuradio] FPGA sample timestamps

2007-09-10 Thread Roshan Baliga
Hi all, For one of our applications we think we need timestamps for some or all samples coming across the USB bus. I know there was some mention of this a while ago on the list, but I didn't find an open ticket on Trac. Obviously we would submit our changes back to gnuradio for inclusion in

Re: [Discuss-gnuradio] gnuradio-core/src/lib/runtime/gr_runtime.i missing

2007-09-10 Thread Berndt Josef Wulf
On Tuesday 11 September 2007 06:11:20 you wrote: > Berndt Josef Wulf wrote: > > G'day, > > > > building current source results in an error due to missing file > > gr_runtime.i. It appears runtime.i was renamed to gr_runtime.i which was > > missed in the trunk. > > > > cheerio Berndt > > > > > > ___

Re: [Discuss-gnuradio] gnuradio-core/src/lib/runtime/gr_runtime.i missing

2007-09-10 Thread Dan Halperin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Berndt Josef Wulf wrote: > G'day, > > building current source results in an error due to missing file gr_runtime.i. > It appears runtime.i was renamed to gr_runtime.i which was missed in the > trunk. > > cheerio Berndt > > > _

Re: [Discuss-gnuradio] Help needed with FPGA

2007-09-10 Thread Dhaval Shah
Thank you Brian and Mande. >> Something you may want to try to do is focus on the TX side of things. >> >> RX is generally the harder part of radio communications, and probably >> wouldn't work out too well inside of an FPGA that is already pretty >> full. TX on the other hand is all just simple

Re: [Discuss-gnuradio] QT Oscilloscope

2007-09-10 Thread Ian Larsen
You'll need gnuradio header files installed along with QT 4.2 with development headers. (QT 4.1 should also work, but is untested.) Fftw3 is also a dependency, but I'm pretty sure that that comes with gnuradio. -Ian On 9/10/07, Eng. Firas <[EMAIL PROTECTED]> wrote: > > Hi, > > Did anyone succe

[Discuss-gnuradio] gnuradio-core/src/lib/runtime/gr_runtime.i missing

2007-09-10 Thread Berndt Josef Wulf
G'day, building current source results in an error due to missing file gr_runtime.i. It appears runtime.i was renamed to gr_runtime.i which was missed in the trunk. cheerio Berndt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lis

[Discuss-gnuradio] set_auto_tr(), gr_stall, and PTT

2007-09-10 Thread Michael Dickens
This email is to verify 2 items: A) As per emails (1) and (2) below, in order to use the set_auto_tr() feature on RFX boards, I need to stall the TX path somehow since - any- input on the TX path will result in no RX (even all 0's). B) After searching through gnuradio-core/src/lib, I find no

Re: [Discuss-gnuradio] Fwd: [Commit-gnuradio] r6369 - gnuradio/trunk/gr-utils/src/python

2007-09-10 Thread Johnathan Corgan
Michael Dickens wrote: > Here is a patch to add this method to the base class, since this will > produce an error if trying "-A" on a subdev that's not an RFX. - MLD Thanks, this has been updated on the trunk. -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com ___

Re: [Discuss-gnuradio] LFRX Gain settings

2007-09-10 Thread Johnathan Corgan
Ed Criscuolo wrote: > Anyone know what the allowable gain settings are when using the USRP > with the LFRX daughterboard? I believe I read somewhere that 20 is > the default and units are dB, but what are the min/recommended/max > values? I tried digging them out of usrp1_source_c.cc, > usrp1_so

[Discuss-gnuradio] Fwd: [Commit-gnuradio] r6369 - gnuradio/trunk/gr-utils/src/python

2007-09-10 Thread Michael Dickens
Here is a patch to add this method to the base class, since this will produce an error if trying "-A" on a subdev that's not an RFX. - MLD Index: gr-usrp/src/db_base.py === --- gr-usrp/src/db_base.py (revision 6375) +++ gr-usr

[Discuss-gnuradio] LFRX Gain settings

2007-09-10 Thread Ed Criscuolo
Anyone know what the allowable gain settings are when using the USRP with the LFRX daughterboard? I believe I read somewhere that 20 is the default and units are dB, but what are the min/recommended/max values? I tried digging them out of usrp1_source_c.cc, usrp1_source_base.cc, and usrp_stand

Re: [Discuss-gnuradio] SDR & USRP

2007-09-10 Thread Sabu
Hello, I (Sabu) too is getting familiar with USRP in an inevitably slow pace. Hope the following will answer your question partly. This URL http://gnuradio.org/trac/wiki/TitleIndex gives important references that can be helpful for GNUradio s/w installation depending on your choice of OS. Once

Re: [Discuss-gnuradio] QT Oscilloscope

2007-09-10 Thread Eng. Firas
Hi, Did anyone successfully compiled it ? I have many compilation errors. Firas Ian Larsen wrote: > > All, > > As part of some thesis research, I've made a stand-alone > oscilloscope/spectrum analyzer that also shows AM and FM demodulated > signals, using the gnuradio C++ libraries. It uses

Re: [Discuss-gnuradio] What is the range of USRP complex sample values

2007-09-10 Thread Dan Halperin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The maximum (at 16 bits complex samples) data rate across USB on the USRP is 16 MHz; hence the minimum decimation rate of 4. My understanding is that this decimation gives more bits -- since you're combining 4 samples together, you can now extrapolate