Not as of yet. The short-term objective for me in terms of this project has
shifted more from learning the process of compiling one's own signal
processing block (in the event my project requires it) to bidirectional
communication with DBPSK, which seems to use entirely preexisting modules. I
will
On Thu, Nov 13, 2008 at 02:20:19PM -0800, Francesco B. wrote:
>
> A fair amount of the RF-specific resources there are textbooks I don't have
> access to, though it's probably a transmission issue, honestly. However, the
> code consists a modified version of gr_sig_source_c (saved under an
> alter
A fair amount of the RF-specific resources there are textbooks I don't have
access to, though it's probably a transmission issue, honestly. However, the
code consists a modified version of gr_sig_source_c (saved under an
alternate name) and usrp_siggen.py, with hard-coded values for all wave
prope
On Thu, Nov 13, 2008 at 12:51 PM, Francesco B. <[EMAIL PROTECTED]> wrote:
>
> This post is a bit old... but I'm having a similar problem. Created a
> modified gr_sig_source_c block such that attributes are assigned by
> pseudo-randomly generated numbers (restricted to ranges such as would be
> prop
This post is a bit old... but I'm having a similar problem. Created a
modified gr_sig_source_c block such that attributes are assigned by
pseudo-randomly generated numbers (restricted to ranges such as would be
proper, as well as swapping waveform types for integers 0-5 and randomly
assigning one)
Hi fellows
We are trying to transmit and receive train of square wave over
wireless using RFX 2400. We modified the usrp_siggen.py file
accordingly to generate square wave. We used
./usrp_siggen.py -f 2450M -w 10
Is the value with -f option correct? We assume that -f option refers
to center