discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] FEC gnuradio 3.7.6 error


From: Hoang Ngo-Khac
Subject: Re: [Discuss-gnuradio] FEC gnuradio 3.7.6 error
Date: Mon, 13 Oct 2014 13:15:48 +0700

Yes. BPSK Mapper is custom block though it isn't written by me.
Both encoders and decode objects parallelism level are defined as 1. 
Actually when I rebuild the flow graph, connect each block in turn, it runs in the first time but then comes back to that situation.

Hoang Ngo-Khac
Research Assistant - Lab. of Signal and System, FET, UET, Vietnam National University-Hanoi (VNU-H)
Alternative email:  address@hidden, address@hidden
Mobilephone:  +84.163.682.7874



From: address@hidden
Date: Fri, 10 Oct 2014 16:02:50 -0400
Subject: Re: [Discuss-gnuradio] FEC gnuradio 3.7.6 error
To: address@hidden
CC: address@hidden



On Wed, Oct 8, 2014 at 11:12 PM, Hoang Ngo-Khac <address@hidden> wrote:
Dear all,

I am checking FEC Extended Encoder/Decoder in gnuradio-3.7.6 and would like to embed it in my OFDM transmission. 

First, I run the flowgraph below. It works and I can see how FEC improve the results.

 
 
However, when I change some blocks, for example, using BPSK Mapper (as below), it throws me the error: 

terminate called after throwing an instance of 'std::invalid_argument'
  what():  destination already in use by edge deinterleave0:0->fec_encoder0:0

 
 

When I modify the flow graph, this error happen regularly even when the new 
inserted block is not connected dirrectly to Encoder or Decoder block.  To make FEC work with my OFDM transmission, I need to make the Encoder and Decoder work compatibly with my blocks. But as you can see, it stops working with when I insert BPSK Mapper to the flow graph, let alone more complicated blocks like OFDM Modulation. 

Please help me to figure out the problem and fix it. Any clue would be appreciated.

Best,
Hoang Ngo 

I'm assuming that BPSK Mapper is your own block? I'm wondering if there's anything in there that would cause this problem. Connecting one block instead of another should not cause any different behavior in the preceding block.

For the encoder and decoder objects, are you defining them with any level of parallelism?

Tom
 


reply via email to

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