On Wed, Sep 21, 2011 at 10:04:23AM -0400, Tom Rondeau wrote:
> On Sat, Sep 17, 2011 at 3:14 PM, Martin Braun wrote:
>
> I'd like to point out a disadvantage to get a discussion going:
> While you're developing, this might be an inconvenience because the
> files are physically separate
On Mon, Sep 26, 2011 at 3:39 AM, Martin Braun wrote:
> On Wed, Sep 21, 2011 at 10:04:23AM -0400, Tom Rondeau wrote:
> > On Sat, Sep 17, 2011 at 3:14 PM, Martin Braun
> wrote:
> >
> > I'd like to point out a disadvantage to get a discussion going:
> > While you're developing, this might b
On Sun, Sep 25, 2011 at 10:13 PM, Ben Reynwar wrote:
> On Sun, Sep 25, 2011 at 5:54 PM, Michael Dickens wrote:
> > On Sep 25, 2011, at 8:39 PM, Ben Reynwar wrote:
> >> It wasn't that python2.5 didn't work, rather that macports didn't
> >> attempt to install gnuradio for that version. Instead it
On Sun, Sep 25, 2011 at 10:58 PM, Josh Blum wrote:
> So there is a useful feature I think gnuradio is missing, and thats the
> ability to rapidly prototype signal processing in python. It would be
> great if a python block would have access to all the facilities
> available to a block written in
Because programs written for UHD and and raw ethernet drivers are not
compatible with each other.
usrp2_probe works only with raw ethernet drivers while uhd_find_devices
works only when UHD is on your SD card.
In case of UHD thing on your SD card the uhd_fft.py shd work fine.
If you are using T
Because programs written for UHD and and raw ethernet drivers are not
compatible with each other.
usrp2_probe works only with raw ethernet drivers while uhd_find_devices
works only when UHD is on your SD card.
In case of UHD thing on your SD card the uhd_fft.py shd work fine.
If you are using
On Sun, Sep 25, 2011 at 8:07 AM, Brett L. Trotter wrote:
> It seems my old patch that zeroed out the output of the USRP didn't make
> it into UHD- we're seeing a constant sine output between packets- and in
> our case this messes with the receiver unless we use some custom TX
> cards that have an
On Sat, Sep 24, 2011 at 10:40 AM, Jay Jones wrote:
> Hi,
>
> I am relatively new to gnuradio block-level development and am working with
> the gr-atsc module. I am specifically interested in the transmit portion and
> have a few [likely elementary] questions:
>
> 1) From what I can see the transm
Hi,
I just created an account (mbraun) on the wiki website, and found
out I can't edit pages with that. I guess the Wiki's configured to
not allow new accounts, but isn't that a bit pointless given that
everyone can use the 'guest' account anyway?
MB
--
Karlsruhe Institute of Technology (KIT)
C
Hey Marcus this was very very informative.This offset was really killing me
every time when I was running the OFDM example.I think I need to order some
GPSDO :)
Marcus D. Leech wrote:
>
> On 09/09/2011 07:26 PM, Tuan (Johnny) Ta wrote:
>> As far as I know there's no open source code for an OF
On Mon, Sep 26, 2011 at 9:08 AM, Martin Braun wrote:
> Hi,
>
> I just created an account (mbraun) on the wiki website, and found
> out I can't edit pages with that. I guess the Wiki's configured to
> not allow new accounts, but isn't that a bit pointless given that
> everyone can use the 'guest'
On Mon, Sep 26, 2011 at 9:02 AM, Arturo Rinaldi wrote:
> i attached the configure and the make log of the stdout on Ubuntu Maverick.
> If i disable the "volk" module the building goes smoothly :
>
> ./configure --disable-volk
> make
> make check
>
> thx in advance, Arturo.
>
I hate to be that gu
I don't know you seem pretty malicious to me
;-)
On Mon, Sep 26, 2011 at 9:37 AM, Tom Rondeau wrote:
> On Mon, Sep 26, 2011 at 9:08 AM, Martin Braun wrote:
>
>> Hi,
>>
>> I just created an account (mbraun) on the wiki website, and found
>> out I can't edit pages with that. I guess the W
On Mon, Sep 26, 2011 at 9:40 AM, Robert McGwier wrote:
> I don't know you seem pretty malicious to me
>
> ;-)
>
I've been fooling everyone for years! Really, I'm just that stupid :)
Martin,
You are set up as a reporter for the GNU Radio project and can now edit the
wiki.
Tom
> On Mo
On Sun, Feb 27, 2011 at 6:22 PM, Tom Rondeau wrote:
> On Sat, Feb 19, 2011 at 4:52 AM, ichigo.san wrote:
>>
>> Hi,
>>
>> I was wondering if there is a method to have a source block constantly
>> sending out "0" and once it recieves a message from python, e.g a packet,
>> it
>> will then stream th
On 09/26/2011 05:36 AM, Tom Rondeau wrote:
> On Sun, Sep 25, 2011 at 8:07 AM, Brett L. Trotter wrote:
>
>> It seems my old patch that zeroed out the output of the USRP didn't make
>> it into UHD- we're seeing a constant sine output between packets- and in
>> our case this messes with the receive
On Mon, Sep 26, 2011 at 05:24, Tom Rondeau wrote:
> On the other hand (I think I've run out of hands...)
...that would be "on the gripping hand."
(obscure SF reference of the week.)
Johnathan
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.or
On Mon, Sep 26, 2011 at 05:36, Tom Rondeau wrote:
> On Sun, Sep 25, 2011 at 8:07 AM, Brett L. Trotter
> wrote:
>>
>> It seems my old patch that zeroed out the output of the USRP didn't make
>> it into UHD- we're seeing a constant sine output between packets- and in
>> our case this messes with th
On Mon, Sep 26, 2011 at 11:48 AM, Ben Hilburn wrote:
> Restarting the discussion for a small point:
>
> > 1) It separates publicly installed headers vs private headers in the lib
> > directory.
>
> I think this, honestly, is the best argument for having the separate
> directory. In terms of proj
Hi everyone,
I'm trying to synchronize two E100 devices, both connecting to the
ethernet. According to the Synchronization Application Notes of UHD,
there are a couple of methods to do it. But the problem is that I don't
have access to either an external GPSDO or a reference clock signal.
I
On Mon, Sep 26, 2011 at 06:41, Tom Rondeau wrote:
> On Mon, Sep 26, 2011 at 9:02 AM, Arturo Rinaldi wrote:
>>
>> i attached the configure and the make log of the stdout on Ubuntu
>> Maverick. If i disable the "volk" module the building goes smoothly :
>>
>> ./configure --disable-volk
>> make
>> m
>
> Now, here's the question. Do we keep this as a separate project or put it
> into GNU Radio proper?
>
Id like it too see more testing. But I hope to get it in gnuradio.
The implementation is relying on a hairy thing like swig directors.
Shiver...
> If you want to keep it separate and on gi
On Mon, Sep 26, 2011 at 09:05, Josh Blum wrote:
> The implementation is relying on a hairy thing like swig directors.
> Shiver...
We've had mixed results with swig directors in the past. The bigger
issue here, though is the Python global interpreter lock. This is
released by the GNU Radio runt
I have converted atsc_field_sync_mux to type gr_block and added
atsc_symbol_mapper and atsc_weaver_mod_head. The rest can be done using
existing GR blocks; I don't frequency translate the signal away from complex
baseband (see 3 below):
[atsc stuff] => [float_to_complex] => [fir_filter_ccf] =>
[pf
On Mon, Sep 26, 2011 at 8:52 AM, ziyang wrote:
> Hi everyone,
>
> I'm trying to synchronize two E100 devices, both connecting to the ethernet.
> According to the Synchronization Application Notes of UHD, there are a
> couple of methods to do it. But the problem is that I don't have access to
> eit
On 09/26/2011 09:22 AM, Johnathan Corgan wrote:
> On Mon, Sep 26, 2011 at 09:05, Josh Blum wrote:
>
>> The implementation is relying on a hairy thing like swig directors.
>> Shiver...
>
> We've had mixed results with swig directors in the past. The bigger
> issue here, though is the Python gl
Hi Nick,
Thanks for your reply. In my application, a microsecond-order accuracy
will be enough for the synchronization right now. But I didn't manage to
issue set_time_now() to the other usrp because it seems only the usrp of
the host device is accessible. So I was wondering if there is a way
Dear all,
I am using USRP N200 with LFTX and LFRX plugged + UHD to design a transmitter
and a receiver. I am trying to toggle a GPIO pin high when the LFTX board is
transmitting and low otherwise, which is similar to the io_tx_06 pin on RFX
boards.
>From what I found, this I/O pin could be con
On 09/26/2011 02:32 PM, Yan Nie wrote:
> Dear all,
>
> I am using USRP N200 with LFTX and LFRX plugged + UHD to design a
> transmitter and a receiver. I am trying to toggle a GPIO pin high
> when the LFTX board is transmitting and low otherwise, which is
> similar to the io_tx_06 pin on RFX boar
Hi, all
I would like to transmit the modulated ( by gmsk, dqpsk, dbpsk) signals
by using USRP N210 + WBX.
Are there any benchmark_tx/rx programs
which is supporting UHD and
is similar to gnuradio/examples/digital/benchmark_tx/rx.py.
I tried the Tom's branch(gr-digital),
>https://github.com/tro
On Mon, Sep 26, 2011 at 10:36 PM, wrote:
> Hi, all
>
> I would like to transmit the modulated ( by gmsk, dqpsk, dbpsk) signals
> by using USRP N210 + WBX.
>
>
> Are there any benchmark_tx/rx programs
> which is supporting UHD and
> is similar to gnuradio/examples/digital/benchmark_tx/rx.py.
>
>
>
On 09/26/11, Josh Blum wrote:
>
> With gr-uhd you can call into the dboard iface from python. That
> includes USRP1 and N200.
>
> This is the dboard iface:
> http://files.ettus.com/uhd_docs/doxygen/html/classuhd_1_1usrp_1_1dboard__iface.html
>
> -Josh
Thank you so much for your reply, Josh.
32 matches
Mail list logo
