[Discuss-gnuradio] Standalone USRP2 firmware app is not transmitting

[B. Sc. Dimitri Block]

Hello list,

I'm currently working on a firmware app for USRP2 which aims to send a 
signal in a standalone manner. I'm using the the following function. The 
serial interface returns, that it seems to work by outputting infinity 
"Done"s. But on the spectrum analyzer I didn't see anything, except the 
local oscillator.


Did I set the wrong flags/timestamp?

Do I have to care about the channel variable?

Did I initialize the buffer in the correct way?


#define DSP_TX_BUF_0 4 // cpu -> dsp tx

static void SEND_DATA () {
putstr("Waiting for the buffer pool.\n");

while((buffer_pool_status->status & BPS_IDLE(DSP_TX_BUF_0)) == 0)
;

putstr("Buffer pool idles. Filling buffer.\n");

// fill buffer
uint32_t *p = buffer_ram(DSP_TX_BUF_0);
uint32_t i;
uint32_t sample = (3200 << 16) | 0;

for (i = 0; i < BP_NLINES; i++) {
p[i] = sample;
}


// 1) 32-bit: word0 (flags, etc)
p[0] = 0 | U2P_TX_IMMEDIATE | U2P_TX_START_OF_BURST | 
U2P_TX_END_OF_BURST;


// 2) 32-bit: fpga timestamp (time of tx)
p[1] = -1;

putstr("Filled buffer. Start sending\n");

bp_clear_buf(DSP_TX_BUF_0);

// first xfer
bp_send_from_buf(DSP_TX_BUF_0, PORT_DSP, 1, 0, BP_LAST_LINE);

while(1) {

// fire it off
bp_send_from_buf(DSP_TX_BUF_0, PORT_DSP, 1, 0, BP_LAST_LINE);

// wait for xfer to complete
while ((buffer_pool_status->status &
  (BPS_DONE(DSP_TX_BUF_0) | BPS_ERROR(DSP_TX_BUF_0))) 
== 0)

;

putstr("Done.\n");

bp_clear_buf(DSP_TX_BUF_0);
}
}



I'm using the USRP2 with the daughterboard RFX2400. The antenna is 
connected to the "TX/RX" connector. The settings concerning frequency, 
interp, ... are set according:



double freq = 2400e6;
unsigned int interpolate = 4;
unsigned int scale_i = 1;
unsigned int scale_q = 1;

struct tune_result result;

printf("\nTune Request:\n");
u2_fxpt_freq_t tune_freq = U2_DOUBLE_TO_FXPT_FREQ(freq);
printf("  freq: %u\n", u2_fxpt_freq_round_to_uint(tune_freq));

bool tune_ok = db_tune(tx_dboard, tune_freq, &result);

int interp = interpolate;

int hb1 = 0;
int hb2 = 0;

if (!(interp & 1)){
hb2 = 1;
interp = interp >> 1;
}

if (!(interp & 1)){
hb1 = 1;
interp = interp >> 1;
}

if (interp < MIN_CIC_INTERP || interp > MAX_CIC_INTERP)
printf("Variable interp %d out of range",interp);
else {
dsp_tx_regs->interp_rate = (hb1<<9) | (hb2<<8) | interp;
printf("Interp: %d, register %d\n", interpolate, (hb1<<9) | 
(hb2<<8) | interp);

}

unsigned int scale_iq = (scale_i << 16) | scale_q;
dsp_tx_regs->scale_iq = scale_iq;

SEND_DATA();


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] FPE with FM Rcvr

[Tom Rondeau]

On Fri, Apr 1, 2011 at 1:49 AM, Ron Hall  wrote:

>  Adding to the following, a backtrace that points to the throw
> std::bad_alloc (), gr_buffer.cc (88)
>
> May have some association with another error addressed earlier this year by
> T. Rondeau: [Discuss-gnuradio] gr_vmcircbuf_sysv_shm: shmget (1): Invalid
> argument, Dated: Fri, 11 Feb 2011 09:52:04-0500
>


Ron, I took a look at your graph, and I see a few discrepancies. Where are
you getting your numbers for adc_rate, usrp_dec, and usrp_inter? Using a
sample rate for the USRP as 3.2 Msps doesn't work because it runs at 100
Msps with integer decimation, so you are really asking for a decimation of
31.25. Instead, it is giving you a decimation of 31 for a rate of 3.225, as
the warning in your original email said.

I then don't quite get what you are doing with the rational resampler and
how you are building the taps for the frequency translating filter, but
maybe I just haven't gone through the math properly.

Importantly, though, you have set the decimation of the filter to 0
(probably because you are doing integer division with audio_inter/audio_dec,
which is less than 1; I suspect you meant audio_rate/audio_dec or
something), which, while I haven't tested it, is probably where you're
problem is.


gr_vmcircbuf_sysv_shm: shmget (1): Invalid argument
>
gr_buffer::allocate_buffer: failed to allocate buffer of size 18760 KB
> terminate called after throwing an instance of 'std::bad_alloc'
>   what():  std::bad_alloc
>
>
> Program received signal SIGABRT, Aborted.
> 0x00436416 in __kernel_vsyscall ()
> (gdb) bt
> #0  0x00436416 in __kernel_vsyscall ()
> #1  0x006c2941 in raise () from /lib/libc.so.6
> #2  0x006c5e42 in abort () from /lib/libc.so.6
> #3  0x008a3055 in __gnu_cxx::__verbose_terminate_handler() () from
> /usr/lib/libstdc++.so.6
> #4  0x008a0f35 in ?? () from /usr/lib/libstdc++.so.6
> #5  0x008a0f72 in std::terminate() () from /usr/lib/libstdc++.so.6
> #6  0x008a10e1 in __cxa_throw () from /usr/lib/libstdc++.so.6
> *#7  0x00ae4861 in gr_buffer::gr_buffer (this=0xb4ef478, nitems=2345,
> sizeof_item=8192, link=...) at gr_buffer.cc:88*
>

You are asking for a huge buffer here. It's throwing because it can't
properly allocate you the size buffer you are requesting. It's seeking a
buffer of 2345 items with a size of 8192 for each item. I'm not sure which
block is doing this, but it strikes me it could be due to the decimation of
0 in the filter.

Tom




> #8  0x00ae4908 in gr_make_buffer (nitems=2345, sizeof_item=8192, link=...)
> at gr_buffer.cc:96
> #9  0x00acec5f in gr_flat_flowgraph::allocate_buffer (this=0xb4ef458,
> block=..., port=0) at gr_flat_flowgraph.cc:121
> #10 0x00acf1af in gr_flat_flowgraph::allocate_block_detail (this=0xb4ef458,
> block=...) at gr_flat_flowgraph.cc:80
> #11 0x00ad1538 in gr_flat_flowgraph::setup_connections (this=0xb4ef458) at
> gr_flat_flowgraph.cc:62
> #12 0x00af7880 in gr_top_block_impl::start (this=0xab2dcd0) at
> gr_top_block_impl.cc:106
> #13 0x00af61b0 in gr_top_block::start (this=0xaa91c78) at
> gr_top_block.cc:59
> #14 0x00179128 in _wrap_gr_top_block_sptr_start (args=0xa7bdeec) at
> python/gnuradio_core_runtime.cc:15301
> #15 0x080ddd23 in PyEval_EvalFrameEx ()
> #16 0x080df04c in PyEval_EvalFrameEx ()
> #17 0x080df04c in PyEval_EvalFrameEx ()
> #18 0x080dfbb2 in PyEval_EvalCodeEx ()
> #19 0x080de145 in PyEval_EvalFrameEx ()
> #20 0x080dfbb2 in PyEval_EvalCodeEx ()
> #21 0x080dfca7 in PyEval_EvalCode ()
> #22 0x080fd956 in PyRun_FileExFlags ()
> #23 0x080d7d09 in ?? ()
> #24 0x080ddd23 in PyEval_EvalFrameEx ()
> #25 0x080dfbb2 in PyEval_EvalCodeEx ()
> #26 0x080dfca7 in PyEval_EvalCode ()
> #27 0x080fe460 in PyRun_StringFlags ()
> #28 0x080dee04 in PyEval_EvalFrameEx ()
> #29 0x080dfbb2 in PyEval_EvalCodeEx ()
> #30 0x080de145 in PyEval_EvalFrameEx ()
> #31 0x080df04c in PyEval_EvalFrameEx ()
> #32 0x080df04c in PyEval_EvalFrameEx ()
> #33 0x080dfbb2 in PyEval_EvalCodeEx ()
> #34 0x080dfca7 in PyEval_EvalCode ()
> #35 0x080df0d8 in PyEval_EvalFrameEx ()
> #36 0x080dfbb2 in PyEval_EvalCodeEx ()
> #37 0x080de145 in PyEval_EvalFrameEx ()
> #38 0x080dfbb2 in PyEval_EvalCodeEx ()
> #39 0x08168e3c in ?? ()
> #40 0x0805fd6a in PyObject_Call ()
> #41 0x0805aa53 in ?? ()
> #42 0x0805b295 in Py_Main ()
> #43 0x0805a8ab in main ()
> (gdb)
>
>
>
> > Date: Wed, 30 Mar 2011 22:25:42 -0700
> > From: j...@joshknows.com
> > To: discuss-gnuradio@gnu.org
> > Subject: Re: [Discuss-gnuradio] FPE with FM Rcvr
>
> >
> >
> >
> > On 03/30/2011 09:31 PM, Ron Hall wrote:
> > >
> > > Working the following issue...any ideas?
> > >
> > > System: Ubuntu 10.10, Gnuradio 3.3.0, uhd (Mar 2011), USRP2, TVRX
> > >
> > > Using the attached grc model results in a floating point exception:
> > >
> > >
> >
> > (process of elimination)
> >
> > it looks like its coming from the xlating filter
> >
> >
> > > It might be a memory issue. An attempt to sample at the 6Mz limit
> > > with the TVRX (board responds with ~5.88...) results in
> > > gr_buffe

Re: [Discuss-gnuradio] Standalone USRP2 firmware app is not transmitting

[B. Sc. Dimitri Block]

Hey,

I solved it by my own. After increasing the value of scale_i and scale_q 
(e.g. 2) I was able to transmit something.



On 04/01/2011 01:01 PM, B. Sc. Dimitri Block wrote:

Hello list,

I'm currently working on a firmware app for USRP2 which aims to send a 
signal in a standalone manner. I'm using the the following function. 
The serial interface returns, that it seems to work by outputting 
infinity "Done"s. But on the spectrum analyzer I didn't see anything, 
except the local oscillator.


Did I set the wrong flags/timestamp?

Do I have to care about the channel variable?

Did I initialize the buffer in the correct way?


#define DSP_TX_BUF_0 4 // cpu -> dsp tx

static void SEND_DATA () {
putstr("Waiting for the buffer pool.\n");

while((buffer_pool_status->status & BPS_IDLE(DSP_TX_BUF_0)) == 0)
;

putstr("Buffer pool idles. Filling buffer.\n");

// fill buffer
uint32_t *p = buffer_ram(DSP_TX_BUF_0);
uint32_t i;
uint32_t sample = (3200 << 16) | 0;

for (i = 0; i < BP_NLINES; i++) {
p[i] = sample;
}


// 1) 32-bit: word0 (flags, etc)
p[0] = 0 | U2P_TX_IMMEDIATE | U2P_TX_START_OF_BURST | 
U2P_TX_END_OF_BURST;


// 2) 32-bit: fpga timestamp (time of tx)
p[1] = -1;

putstr("Filled buffer. Start sending\n");

bp_clear_buf(DSP_TX_BUF_0);

// first xfer
bp_send_from_buf(DSP_TX_BUF_0, PORT_DSP, 1, 0, BP_LAST_LINE);

while(1) {

// fire it off
bp_send_from_buf(DSP_TX_BUF_0, PORT_DSP, 1, 0, BP_LAST_LINE);

// wait for xfer to complete
while ((buffer_pool_status->status &
  (BPS_DONE(DSP_TX_BUF_0) | BPS_ERROR(DSP_TX_BUF_0))) 
== 0)

;

putstr("Done.\n");

bp_clear_buf(DSP_TX_BUF_0);
}
}



I'm using the USRP2 with the daughterboard RFX2400. The antenna is 
connected to the "TX/RX" connector. The settings concerning frequency, 
interp, ... are set according:



double freq = 2400e6;
unsigned int interpolate = 4;
unsigned int scale_i = 1;
unsigned int scale_q = 1;

struct tune_result result;

printf("\nTune Request:\n");
u2_fxpt_freq_t tune_freq = U2_DOUBLE_TO_FXPT_FREQ(freq);
printf("  freq: %u\n", u2_fxpt_freq_round_to_uint(tune_freq));

bool tune_ok = db_tune(tx_dboard, tune_freq, &result);

int interp = interpolate;

int hb1 = 0;
int hb2 = 0;

if (!(interp & 1)){
hb2 = 1;
interp = interp >> 1;
}

if (!(interp & 1)){
hb1 = 1;
interp = interp >> 1;
}

if (interp < MIN_CIC_INTERP || interp > MAX_CIC_INTERP)
printf("Variable interp %d out of range",interp);
else {
dsp_tx_regs->interp_rate = (hb1<<9) | (hb2<<8) | interp;
printf("Interp: %d, register %d\n", interpolate, (hb1<<9) | 
(hb2<<8) | interp);

}

unsigned int scale_iq = (scale_i << 16) | scale_q;
dsp_tx_regs->scale_iq = scale_iq;

SEND_DATA();


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Implementing digital-bert with UHD

[Tom Rondeau]

On Wed, Mar 30, 2011 at 2:12 AM,  wrote:

> Hi,
>
> I am currently new to the GNU Radio project and are currently trying to get
> the digital-bert scripts (gnuradio-examples) working with UHD (for my USRP
> N210).
>
> At the beginning I have swapped the existing USRP sinks in
> 'benchmark_tx.py' and 'benchmark_rx.py' with the code below.
> Therefore I changed some command line arguments (ip...IP address of the
> board, gain...Gain of the d'board).
>
> def _setup_usrp(self, interp, freq, gain, ip):
>   # Setup single usrp sink
>   self._usrp = uhd.single_usrp_sink(
>   device_addr="addr="+ip,
>   io_type=uhd.io_type.COMPLEX_FLOAT32,
>   num_channels=1,
>   )
>
>   # Tune to center frequency
>   tr = self._usrp.set_center_freq(freq, 0)
>
>   if not (tr):
>   print "Failed to tune to center frequency!"
>   else:
>   print "Actual intermediate frequency:", n2s(tr.actual_inter_freq)
>
>   # Set TX gain
>   self._usrp.set_gain(gain, 0)
>   print "Gain d'board:", n2s(self._usrp.get_gain()), "dB"
>
> Afterward I executed the scripts and everything seems to work,
> but the terminal output shows:
>
> Freq. Offset:  -945 Hz  Timing Offset:   3.7 ppm  Estimated SNR:  6.8 dB
>  BER: 0.182979
> Freq. Offset: -1011 Hz  Timing Offset:   4.0 ppm  Estimated SNR:  6.8 dB
>  BER: 0.182914
> Freq. Offset: -1102 Hz  Timing Offset:   3.9 ppm  Estimated SNR:  6.9 dB
>  BER: 0.18345
> Freq. Offset: -3122 Hz  Timing Offset:   3.5 ppm  Estimated SNR:  7.0 dB
>  BER: 0.183047
> Freq. Offset:  -748 Hz  Timing Offset:   3.5 ppm  Estimated SNR:  6.9 dB
>  BER: 0.184062
>
> So the SNR and BER are quite bad and the values aren't changing, while
> modifying the signal energie (amplitude) for transmition.
>
> Does have anybody an explanation or hint for this behavior? Or are there
> working scripts for UHD available?
>
> Thanks,
> Daniel
>

Perhaps you are in a particularly bad multipath environment? Although I
agree that changing the power should have more than a tenth of a dB effect
on the SNR. Have you tried turning it down? Or really, can your plot the
spectrum at the receiver and verify that the power is actually changing?

Also, the SNR estimator in gr_probe_mpsk_snr_c is not the most robust
estimator at low SNR. It gets biased when calculating the mean by any
samples over the decision boundaries with the effect of having an
"irreducible" SNR (that's not really the right word for it, but I'm relating
it to being the opposite of an irreducible BER in multipath channels). But I
think this point is around 3 - 4 dB, but it's been a while since I've looked
at it.

This reminds me that I have three other SNR estimators that do an excellent
job at low SNR (theoretically, in the mythical AWGN channels) that I really
need to put into GNU Radio. They are increasingly better at their estimates
at the expense of computational complexity (e.g., one uses the skewness
while another uses the kurtosis).

Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How to decode the convolutional code, in the GRC

[Achilleas Anastasopoulos]

The matrices PS and PI are documented in the fsm class and in the
gr-trellis documentation: PS[s] is a vector of "previous states"
that will result in state "s" and PI[s] is the corresponding vector of
"input symbols" that will result in state "s" from a previous state.
This is useful in the VA because you have this info precalculated (see
the fsm.cc) and thus you don't need to do this backwards lookup every
time in the VA execution--> saves time!

The vector alpha is a temporary vector that holds the accumulated path
metrics in the VA. You do not need to store ALL of them for a block of K
steps, but only two of them and then alternate between the two: read
from one/write to the other (this is what the variable alphai points to!)

The function calc_metric(O, D, TABLE, &(in[k*D]), metric,TYPE)
calculates the metrics required for the viterbi algorithm in each
step: depending on the "TYPE" this can be Euclidean, Hamming etc.
In the code, for every chunk of observation corresponding to step "k"
in[k*D]...in[k*D+D-1]
it evaluates the metric between this observation and EVERY possible
output symbol of the trellis and puts the results in the vector
"metric". Observe that there are "O" (this is a big o not a zero)
possible output symbols for the fsm, and each one of them is translated
to a signal through the D-dimensional lookup table TABLE, so :
output symbol 0 will be translated (modulated) to TABLE[0]...TABLE[D-1]
output symbol 1 will be translated (modulated) to TABLE[D]...TABLE[2D-1]
..
output symbol O-1 will be translated (modulated) to
TABLE[(O-1)D]...TABLE[OD-1]

eg, in the case of euclidean metrics the calc_metric() will form O
numbers, each being the euclidean distance between the input
in[k*D]...in[k*D+D-1]
and EACH of the translated signals:
TABLE[0]...TABLE[D-1]
TABLE[D]...TABLE[2D-1]
...
TABLE[(O-1)D]...TABLE[OD-1]

Regarding references, I am just implementing the standard (block)
Viterbi algorithm...

Achilleas


On 4/1/2011 4:33 AM, intermilan wrote:
> hi Achilleas:
> I recently had read the code in the trellis_viterbi_combined_fb.cc want 
> to understand how you use the viterbi algorithm.But there is something 
> that I can not understand.
> for(int k=0;k calc_metric(O, D, TABLE, &(in[k*D]), metric,TYPE); // calc metrics
> norm=INF;
> for(int j=0;j minm=INF;
> minmi=0;
> for(unsigned int i=0;i //int i0 = j*I+i;
> if((mm=alpha[alphai*S+PS[j][i]]+metric[OS[PS[j][i]*I+PI[j][i]]]) minm=mm,minmi=i;
> }
> trace[k*S+j]=minmi;
> alpha[((alphai+1)%2)*S+j]=minm;
> if(minm }
> for(int j=0;j alpha[((alphai+1)%2)*S+j]-=norm; // normalize total metrics so they do 
> not explode
> alphai=(alphai+1)%2;
> }
> I think above code perform the Add-Compare-Select operations.
> I do not understand is the function of the matrix metric.I saw the code 
> in the calc_metric.cc,it is calculate the ! euclidean between
> the data output the chunks_to_symbols block and the point in the 
> symbol_table.So what is the function of this metric in your viterbi 
> algorithm?
> Besides,what is the function of the PS and PI which is generated by the 
> fsm file? and what is the function of the alpah[] in your code?
> Is there some reference when you write these codes.if there is some 
> ,please tell me.I appreciate your hlep.
> Thanks.
> 
> 
>  > Date: Mon, 14 Mar 2011 10:11:44 -0400
>  > From: anas...@umich.edu
>  > To: tianxia...@hotmail.com; discuss-gnuradio@gnu.org
>  > Subject: Re: [Discuss-gnuradio] How to decode the convolutional code, 
> in the GRC
>  >
>  > inter,
>  >
>  > as i said in my previous email, you just have to consider the equivalent
>  > channel (the fact that it is noiseless is irrelevant in this discussion)
>  > from the output of the FSM encoder to the input of the VA.
>  > It seems you prefer to call it equivalent "modulato! r"; that's fine!
>  > Once you realize what this equivalent channel/modulator is
>  > (what is its input/output alphabet and what kind of symbols it
>  > inputs/outputs) then it will be strainghtforward to see what the viterbi
>  > decoder block should look like.
>  > If I were to guess from your description, i would say that your
>  > equivallent channel
>  > has input/output alphabet equal to the output alphabet of the FSM.
>  > Its input is a coded symbol from the FSM encoder and its output is also
>  > such a symbol from the packet decoder.
>  > So all you need is to do VA with symbol-wise hamming distance as your
>  > metric. You can achieve that using the viterbi_combined block with
>  > a trivial 1-D chunks to symbols block (identity) and the appropriate
>  > parameter for the metric_type.
>  >
>  >
>  > Achilleas
>  >
>  > On 3/14/2011 6:45 AM, intermilan wrote:
>  > > Achilleas:
>  > >
>  > &g! t; What I want to do is want to see the BER when the 
> convolutional code is
>  > > used in different modulator in the GRC,but I had not put the noise
>  > > source in the flow graph so there is no noise between the modulator 
> and
>  > > demodulator.
>  > > Besides,in my opinion, we can 

[Discuss-gnuradio] PyQwt5 and RHEL-6

[Brett L. Trotter]

Who do we petition to get PyQwt5 included in RHEL-6? It compiles
straightforwardly from Fedora 15 SRPM, so it shouldn't be a problem.
This new build requirement means one can't build GnuRadio with stock
RPMs even on RHEL 6 now otherwise.

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How to decode the convolutional code in the GRC

[Feng Andrew Ge]

Achilleas,

I have looked at the gr-trellis code and my understanding is that the 
code is used mainly for simulation in GNU Radio (signals don't go over 
the air).  I was thinking about integrating the code into the digital 
examples, e.g., transmit_path.py and receiver_path.py. However, I have 
two concerns: (a) its computational complexity might be too high at a 
high data rate, e.g., 500kb/s, therefore introducing big delays; (b) 
there is no synchronization for recognizing the start and end bits of 
encoded bit blocks.  Further, I also want to introduce interleaver for 
handling burst errors.


To resolve the computational complexity, as alternative to trellis code, 
I am thinking about linear block code. I found your 2007 online 
discussion with Eric and Johnathan about using BCH code for the packet 
header (two lengths) --- unfortunately it seems that no following work 
happened after the discussion.  Would you please give some comments 
about using BCH code in the digital examples? For example, what might be 
a good code, BCH(31, 16), BCH(127, 36), or extended Golay codes?


Further, do you have any thought about interleaver implementation 
together with a linear block code?


Finally, in the 2007 discussion between you and Eric, Eric preferred 
that the access code should not be encoded. Currently the access coded 
is recognized in the receiver_path.py by a correlator with a default 
threshold of 12  based on Hamming distance. Is this a good approach if 
we introduce coding for the packet header plus the payload with CRC?


Of course, any other comments/thought will be quite welcomed.

Regards,
Andrew




On 03/14/2011 12:00 PM, discuss-gnuradio-requ...@gnu.org wrote:

Date: Mon, 14 Mar 2011 10:11:44 -0400
From: Achilleas Anastasopoulos
Subject: Re: [Discuss-gnuradio] How to decode the convolutional code,
in the  GRC
To: intermilan,   gnuradio mailing list

Message-ID:<4d7e2220.8020...@umich.edu>
Content-Type: text/plain; charset=GB2312

inter,

as i said in my previous email, you just have to consider the equivalent
channel (the fact that it is noiseless is irrelevant in this discussion)
from the output of the FSM encoder to the input of the VA.
It seems you prefer to call it equivalent "modulator"; that's fine!
Once you realize what this equivalent channel/modulator is
(what is its input/output alphabet and what kind of symbols it
inputs/outputs) then it will be strainghtforward to see what the viterbi
decoder block should look like.
If I were to guess from your description, i would say that your
equivallent channel
has input/output alphabet equal to the output alphabet of the FSM.
Its input is a coded symbol from the FSM encoder and its output is also
such a symbol from the packet decoder.
So all you need is to do VA with symbol-wise hamming distance as your
metric. You can achieve that using the viterbi_combined block with
a trivial 1-D chunks to symbols block (identity) and the appropriate
parameter for the metric_type.


Achilleas




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] opengl "persistence" error

[Arturo Rinaldi]

Every time I tick the "Persistence" box in one of the scopes i get this 
error :


Traceback (most recent call last):
  File 
"/usr/local/lib/python2.6/dist-packages/gnuradio/wxgui/plotter/plotter_base.py", 
line 192, in _on_paint

GL.glAccum(GL.GL_LOAD, 1.0)
  File "/usr/lib/pymodules/python2.6/OpenGL/error.py", line 208, in 
glCheckError

baseOperation = baseOperation,
OpenGL.error.GLError: GLError(
err = 1282,
description = 'invalid operation',
baseOperation = glAccum,
cArguments = (GL_LOAD, 1.0)
)

i have correctly installed my ati catalyst drivers on my laptop (latest 
version). My laptop GPU is a Radeon HD4570 and my OS Ubuntu 10.10. I 
compiled and installed from source gnuradio v. 3.3.0.


Regards

 Arturo Rinaldi

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] How to decode the convolutional code in the GRC

[Achilleas Anastasopoulos]

Regarding interleaver, this is already implemented in gr-trellis in
a very general (block) form (any kind of permutation of n units of 
arbitrary byte length. See interleaver.h/cc and 
trellis_permitation.h/cc/i files for details.


Regarding BCH it would be nice to have a gnuradio "module"
with general block coding including BCH codes.
If the code exists out there, it should
be pretty straightforward to import it as gnuradio "blocks".
But someone has to do it...

I do not remember the 2007 discussions but one point to be made is the 
following: gr_trellis as well as some other blocks in gnuradio are 
providing generic modules to do things. The examples you mention provide 
complete transmission "systems" and thus there is no ONE BEST way to do 
things...


For example, synchronization is NOT the task of the viterbi algorithm.
If you want to do joint decoding and synchronization you have to write a 
different block and it is bound to be specific to the application 
(wellto a large extend...)
These are more complex systems and i don't think that SDR is at this 
level of sophistication at this point: just take a look at how
simple DPSK transmission/reception is implemented: all tasks 
(frequency/phase sync, timing sync, decoding, etc) are implemented 
separately; forget about joint decoding and synchronization...


Achilleas


On 4/1/2011 10:14 AM, Feng Andrew Ge wrote:

Achilleas,

I have looked at the gr-trellis code and my understanding is that the
code is used mainly for simulation in GNU Radio (signals don't go over
the air). I was thinking about integrating the code into the digital
examples, e.g., transmit_path.py and receiver_path.py. However, I have
two concerns: (a) its computational complexity might be too high at a
high data rate, e.g., 500kb/s, therefore introducing big delays; (b)
there is no synchronization for recognizing the start and end bits of
encoded bit blocks. Further, I also want to introduce interleaver for
handling burst errors.

To resolve the computational complexity, as alternative to trellis code,
I am thinking about linear block code. I found your 2007 online
discussion with Eric and Johnathan about using BCH code for the packet
header (two lengths) --- unfortunately it seems that no following work
happened after the discussion. Would you please give some comments about
using BCH code in the digital examples? For example, what might be a
good code, BCH(31, 16), BCH(127, 36), or extended Golay codes?

Further, do you have any thought about interleaver implementation
together with a linear block code?

Finally, in the 2007 discussion between you and Eric, Eric preferred
that the access code should not be encoded. Currently the access coded
is recognized in the receiver_path.py by a correlator with a default
threshold of 12 based on Hamming distance. Is this a good approach if we
introduce coding for the packet header plus the payload with CRC?

Of course, any other comments/thought will be quite welcomed.

Regards,
Andrew




On 03/14/2011 12:00 PM, discuss-gnuradio-requ...@gnu.org wrote:

Date: Mon, 14 Mar 2011 10:11:44 -0400
From: Achilleas Anastasopoulos
Subject: Re: [Discuss-gnuradio] How to decode the convolutional code,
in the GRC
To: intermilan, gnuradio mailing list

Message-ID:<4d7e2220.8020...@umich.edu>
Content-Type: text/plain; charset=GB2312

inter,

as i said in my previous email, you just have to consider the equivalent
channel (the fact that it is noiseless is irrelevant in this discussion)
from the output of the FSM encoder to the input of the VA.
It seems you prefer to call it equivalent "modulator"; that's fine!
Once you realize what this equivalent channel/modulator is
(what is its input/output alphabet and what kind of symbols it
inputs/outputs) then it will be strainghtforward to see what the viterbi
decoder block should look like.
If I were to guess from your description, i would say that your
equivallent channel
has input/output alphabet equal to the output alphabet of the FSM.
Its input is a coded symbol from the FSM encoder and its output is also
such a symbol from the packet decoder.
So all you need is to do VA with symbol-wise hamming distance as your
metric. You can achieve that using the viterbi_combined block with
a trivial 1-D chunks to symbols block (identity) and the appropriate
parameter for the metric_type.


Achilleas



--
___
Achilleas Anastasopoulos
Associate Professor
EECS Department   Voice : (734)615-4024
UNIVERSITY OF MICHIGANFax   : (734)763-8041
Ann Arbor, MI 48109-2122  E-mail: anas...@umich.edu
URL: http://www.eecs.umich.edu/~anastas/
___

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] opengl "persistence" error

[Josh Blum]

On 04/01/2011 07:43 AM, Arturo Rinaldi wrote:
> Every time I tick the "Persistence" box in one of the scopes i get this
> error :
> 
> Traceback (most recent call last):
>   File
> "/usr/local/lib/python2.6/dist-packages/gnuradio/wxgui/plotter/plotter_base.py",
> line 192, in _on_paint
> GL.glAccum(GL.GL_LOAD, 1.0)
>   File "/usr/lib/pymodules/python2.6/OpenGL/error.py", line 208, in
> glCheckError
> baseOperation = baseOperation,
> OpenGL.error.GLError: GLError(
> err = 1282,
> description = 'invalid operation',
> baseOperation = glAccum,
> cArguments = (GL_LOAD, 1.0)
> )
> 

It happens on all of my computers too. I think the persistence uses a
hardware feature that is not widely implemented. -Josh

> i have correctly installed my ati catalyst drivers on my laptop (latest
> version). My laptop GPU is a Radeon HD4570 and my OS Ubuntu 10.10. I
> compiled and installed from source gnuradio v. 3.3.0.
> 
> Regards
> 
>  Arturo Rinaldi
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] doubt in thesis of Danny Gracia

[ranjini ram]

hi

i ve some doubts in Danny Gracia's thesis work on NTSC_RECEIVER,if any body
ve come across this please be kind enough to clear my doubts.o
1)i didnt understand the modules scaline_detector and max-min detector
mainly calculation of parameters like state,scan
width,max_scanline_buffer_length and long pulse interval in matlab files
2)and is this feasible of pal signals

expecting reply from those who ve came across this thesis

Thanks

Ranjini
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] opengl "persistence" error

[Arturo Rinaldi]

Il 01/04/2011 17:21, Josh Blum ha scritto:


On 04/01/2011 07:43 AM, Arturo Rinaldi wrote:

Every time I tick the "Persistence" box in one of the scopes i get this
error :

Traceback (most recent call last):
   File
"/usr/local/lib/python2.6/dist-packages/gnuradio/wxgui/plotter/plotter_base.py",
line 192, in _on_paint
 GL.glAccum(GL.GL_LOAD, 1.0)
   File "/usr/lib/pymodules/python2.6/OpenGL/error.py", line 208, in
glCheckError
 baseOperation = baseOperation,
OpenGL.error.GLError: GLError(
 err = 1282,
 description = 'invalid operation',
 baseOperation = glAccum,
 cArguments = (GL_LOAD, 1.0)
)


It happens on all of my computers too. I think the persistence uses a
hardware feature that is not widely implemented. -Josh


i have correctly installed my ati catalyst drivers on my laptop (latest
version). My laptop GPU is a Radeon HD4570 and my OS Ubuntu 10.10. I
compiled and installed from source gnuradio v. 3.3.0.

Regards

  Arturo Rinaldi

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

In fact on my nvidia GF 6800GT i have never experienced such an error. 
Maybe an nVidia cards hardware feature ?


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] UHD memory leak?

[Brett L. Trotter]

swig/python detected a memory leak of type 'uhd::usrp::multi_usrp::sptr
*', no destructor found.

Anyone seen this before?

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Re: questions on SNR estimation from digital-bert examples

[William Cox]

Here's an image of the BER vs. SNR plot plotted along with the theoretical
BPSK line.
http://www.flickr.com/photos/gallamine/5580109538/

 You can see that the
experimental data is 3-4 dB greater than the theoretical BPSK values.

My setup looks like:
GNURadio -> USRP -> LED -> water -> photodiode -> USRP -> GNURadio.

I'm using the "benchmark_tx.py" and "benchmark_rx.py" code with default
settings. Carrier is 5e6 hz and rate is 1e6 symbol/sec. Decimation at the
receiver is 32.

Above 12 dB the BER values saturate down at 1.85e-11.

Any ideas why the experimental results are so far off theoretical?
Thanks.
-William


On Tue, Mar 29, 2011 at 7:52 PM, William Cox  wrote:

> Newbie here. I have some questions regarding the example programs under
> gnuradio-examples/python/digital-bert. I just ran a link and swept my signal
> power. I recorded the estimated snr and ber and I'm trying to plot them and
> verify things are working properly. Is the SNR estimation done at baseband
> or passband? When I plot the theoretical BPSK snr vs. ber curve, there's a
> significant offset between my experimental data and theoretical plot (and
> yes, I'm ignoring SNR values below 7 dB). Also, a more basic question is
> what is the best method to find documentation for the code? The class
> documentation under the wiki seems rather overwhelming and I have a hard
> time finding what I need.
>
> My second question is how the BER is calculated? I'm seeing values < 1e-11.
> But this is entirely unreasonable, as I'd have to be sending > 100 gb of
> data to be getting a BER close to that value. Looking at the code, its not
> clear to me over what packet size the BER is calculated and what the actual
> BER confidence value should be.
>
> Thanks for any help that can be offered.
> -William
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] UHD memory leak?

[Josh Blum]

On 04/01/2011 09:44 AM, Brett L. Trotter wrote:
> swig/python detected a memory leak of type 'uhd::usrp::multi_usrp::sptr
> *', no destructor found.
> 

How can I replicate this error? What program/command did you run?

-Josh

> Anyone seen this before?
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Re: questions on SNR estimation from digital-bert examples

[Alexandru Csete]

On Fri, Apr 1, 2011 at 7:07 PM, William Cox  wrote:
> Here's an image of the BER vs. SNR plot plotted along with the theoretical
> BPSK line.
> http://www.flickr.com/photos/gallamine/5580109538/
> You can see that the experimental data is 3-4 dB greater than the
> theoretical BPSK values.
> My setup looks like:
> GNURadio -> USRP -> LED -> water -> photodiode -> USRP -> GNURadio.
> I'm using the "benchmark_tx.py" and "benchmark_rx.py" code with default
> settings. Carrier is 5e6 hz and rate is 1e6 symbol/sec. Decimation at the
> receiver is 32.
> Above 12 dB the BER values saturate down at 1.85e-11.
> Any ideas why the experimental results are so far off theoretical?

Hi William,

What would you consider to be a reasonable deviation from the theoretical value?
In my limited experience, 3-4 dB "implementation loss" is not that bad
when using hardware and software that haven't been tuned and optimized
for the specific purpose.
Also note that you compare your results with the theoretical values
for transmission over an AWGN channel
http://en.wikipedia.org/wiki/AWGN - does water qualify as such?

Alex

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Re: questions on SNR estimation from digital-bert examples

[William Cox]

Alex,
Yes, for what I'm doing, the optical link will be AWGN. I'm doing direct
detection (lots of photons) with a uncooled Si photodiode.

Thanks for the feedback. I have limited (none) experience with realtime
receivers so it's hard for me to judge how much loss I'll experience from
the realtime snr estimation, timing recovery, etc. For other experiments
I've done, using a ML snr estimator and offline timing recovery, we can get
nearly perfect agreement with theoretical curves, so I really wasn't sure
what to expect from this setup.

I was mostly checking to see if people would say, "woah somethings wrong",
or "that's close enough".
Thanks.
-William

PS. I've made good use of your gstreamer streaming video program. Very
helpful. Thanks!


On Fri, Apr 1, 2011 at 2:52 PM, Alexandru Csete  wrote:

> On Fri, Apr 1, 2011 at 7:07 PM, William Cox  wrote:
> > Here's an image of the BER vs. SNR plot plotted along with the
> theoretical
> > BPSK line.
> > http://www.flickr.com/photos/gallamine/5580109538/
> > You can see that the experimental data is 3-4 dB greater than the
> > theoretical BPSK values.
> > My setup looks like:
> > GNURadio -> USRP -> LED -> water -> photodiode -> USRP -> GNURadio.
> > I'm using the "benchmark_tx.py" and "benchmark_rx.py" code with default
> > settings. Carrier is 5e6 hz and rate is 1e6 symbol/sec. Decimation at the
> > receiver is 32.
> > Above 12 dB the BER values saturate down at 1.85e-11.
> > Any ideas why the experimental results are so far off theoretical?
>
> Hi William,
>
> What would you consider to be a reasonable deviation from the theoretical
> value?
> In my limited experience, 3-4 dB "implementation loss" is not that bad
> when using hardware and software that haven't been tuned and optimized
> for the specific purpose.
> Also note that you compare your results with the theoretical values
> for transmission over an AWGN channel
> http://en.wikipedia.org/wiki/AWGN - does water qualify as such?
>
> Alex
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] gnuradio.org gerbils

[Philip Balister]

Could someone feed the gerbils? The website is down.

Philip

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gnuradio.org gerbils

[Tom Rondeau]

It should be coming back up.

Has anyone else noticed this always happens around the first few days of the
month? I suspect this will be a problem for a few more days, and I'll try to
keep an eye on it. Ping if you see it down, though.

Tom



On Fri, Apr 1, 2011 at 4:58 PM, Philip Balister  wrote:

> Could someone feed the gerbils? The website is down.
>
> Philip
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] UHD Announcement - April 01st 2011

[Josh Blum]

Hello list,

As promised, we have official releases for UHD and binary installers.

http://code.ettus.com/redmine/ettus/projects/uhd/wiki

---
-- Binary installers
---
Installers are available for ubuntu, fedora, apple, and windows os. See
the link for detail about what OS versions are specifically supported.

http://code.ettus.com/redmine/ettus/projects/uhd/wiki#Binary-downloads

---
-- Images
---
Firmware and FPGA images now come included with the binary installers.
However, they are also available individually for download for users who
are running UHD from a source checkout. The master branch of the UHD
will work with the images provided in the latest release.

---
-- Other mentionables
---
* There is now a gui app available for the USRP-N Series image burner.

* Windows users, the uhd.dll is now installed into the runtime path.
Your %PATH% should now include /bin and not /lib. I
recommend to clean the old install.

* Redhat linux family 64 bit users, the LIB_SUFFIX is now automatically
set to 64. There may be some confusion if you were not manually setting
this and your libs were installed into /usr/local/lib, they will now
show up in /usr/local/lib64. I recommend to clean the old install.

Other mentionables here:
http://code.ettus.com/redmine/ettus/projects/uhd/wiki/ChangeLog

---
Testing and feedback is always welcome!

Thanks,
-Josh

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] PyQwt5 and RHEL-6

[Tom Rondeau]

On Fri, Apr 1, 2011 at 10:08 AM, Brett L. Trotter wrote:

> Who do we petition to get PyQwt5 included in RHEL-6? It compiles
> straightforwardly from Fedora 15 SRPM, so it shouldn't be a problem.
> This new build requirement means one can't build GnuRadio with stock
> RPMs even on RHEL 6 now otherwise.
>

I wish I knew. It's a great product, but it and the rest of the QWT stuff
leaves a bit to be desired in the installation.

Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] opengl "persistence" error

[Marcus D. Leech]

On 04/01/2011 12:29 PM, Arturo Rinaldi wrote:

It happens on all of my computers too. I think the persistence uses a
hardware feature that is not widely implemented. -Josh



Reinforces my notion that OpenGL is broken in so many fundamental ways.

You can't reliably predict what an OpenGL app is going to do on any 
random hardware.  The implementations seem to
  routinely break the traditions of abstraction.  It's downright 
infuriating.  Simple 2D graphics such as is used in Gnu Radio
  should "just work", regardless of the hardware.  I mean, if the 
freaking login window can render, then Gnu Radio apps

  should be able to.


--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio