[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Attempting DBPSK again

From: Francesco B.
Subject: Re: [Discuss-gnuradio] Attempting DBPSK again
Date: Thu, 11 Dec 2008 20:42:36 -0800 (PST)

Scratch that... I just realized that with clever placement of the read()
function I could read file contents as the payload string. Also found
mod_pkts() and can modify that to accommodate any new modulation schemes or
remove it entirely.

Just one question remains though, to put it to good use. Where do the actual
packet contents go when benchmark_rx is unmodified? I'm getting
acknowledgment that packets are received, but they aren't stored in a file.

I'm currently trying to work a file sink into receiver_path.py. Is that the
proper course of action?

Francesco B. wrote:
> I've lost the previous thread amidst other threads, and figured enough new
> developments and different issues have arisen to warrant another.
> I've written a simple pipeline, which generates a signal, sends it through
> the dbpsk modulation block, and transmits it over the USRP. A receiving
> USRP intercepts this and transmits anything it receives. Finally, the
> original computer is also waiting to receive from the USRP, and stores the
> results in a file sink.
> The results leave much to be desired, though. Even assuming the most basic
> sort of transmission, where all USRP input is monitored and stored rather
> than detecting when data is incoming (generating a constant signal by
> removing gr.head() from the transmission executable), it still doesn't
> function properly. It compiles, and runs, and outputs... but I get a file
> of significantly smaller size than what has been transmitted. And even
> more curiously, the received file isn't playable by audio_play.py. It
> runs, but there is no sound. Even if audio_play.py were given
> pseudo-random numbers (supplied by urandom), it would still output sound,
> even if white noise.
> This would all be far simpler if I were aware of how to remove the
> modulation aspect from benchmark_tx. The goal here is to have the
> capability to supply a modulated bitstream from another source, and have
> that transmitted, rather than GNU Radio handling modulation. We would
> probably get better results in the end anyway, if we made modifications to
> a previously tried method. But... knowing what's wrong here is still quite
> helpful.
> Code is as follows:
>  http://www.nabble.com/file/p20964979/loopback_transmitter.py
> loopback_transmitter.py 
>  http://www.nabble.com/file/p20964979/loopback_reciever.py
> loopback_reciever.py 
>  http://www.nabble.com/file/p20964979/loopback.py loopback.py 

View this message in context: 
Sent from the GnuRadio mailing list archive at Nabble.com.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]