Yeah, I'm on Linux Mint 18 aka Ubuntu 16.04 (xenial). I've been meaning to upgrade. I'm not familiar with check_topology, I basically just copied the gr-dtv reed Solomon decoder implementation and tried to extend the io_signature. I probably copied pasted things into my OOT module in a way that its likely still looking at the original reed Solomon decoded which has only one output and complains since my implementation has two outputs. At least that's my uneducated guess.
Federico's version does what I was looking for so I've been playing around it. I was able successfully drop it in to the dvb-t example in place of the stock RS decoder (re-compiled fedrico's version to support block size of 8 from hard coded default of 1). I did notice that if the transport stream packet was degraded enough, it would cause the flowgraph to crash with the following error:
gnuradio-runtime/include/gnuradio/buffer.h:170: > unsigned int gr::buffer::index_add(unsigned int, unsigned int): Assertion `s > < d_bufsize' failed.
I commented out "consume_each(i+1) in this section of his code and no longer got the error
Line 140: // if nerrors_corrected=-1 it means that the decoder gave up on the word if(nerrors_corrected==-1) { // In order to generate a useable TS, we will not ouput these TSP. //printf("RS: impossible to correct\n"); // We also reset the BER average. d_last_ber_out = 0.5; //consume_each(i+1); return i; }
On Wed, Jul 24, 2019 at 3:27 PM Federico 'Larroca' La Rocca <flarroca@gmail.com> wrote:
Hi,I think it is very possible to merge them, specially in the RS decoder which I didn't modify much. The viterbi took me quiet some thinking and testing, but it's possible too.If it would make sense, that's another question :-). I use it mostly as another indicator that the flowgraph is correctly configured (sometimes the constellation is good enough, but if you have misspecified for instance the time interleaver length you will get garbage). Performance-wise it has negligible impact.If you are interested I can try to make a couple of PRs.best_______________________________________________El mié., 24 jul. 2019 a las 14:21, Müller, Marcus (CEL) (<mueller@kit.edu>) escribió:Hi Federico,
would it make sense to merge that extension back to mainline GNU Radio?
Best regards,
Marcus
On Wed, 2019-07-24 at 12:41 -0300, Federico 'Larroca' La Rocca wrote:
> Hi,
> If you are interested in measuring the number of errors in the Reed-Solomon block of DTV, you may take a look at our OOT module gr-isdbt (https://github.com/git-artes/gr-isdbt) which includes modifications to the RS (and the viterbi) decoder to outputs the BER (but is easily modifiable to output the number of errors).
> best
> Federico
>
> El mié., 24 jul. 2019 a las 12:39, Müller, Marcus (CEL) (<mueller@kit.edu>) escribió:
> > Hi Alex!
> > Hm, interesting. Would you happen to have the full verbatim error?
> >
> > As a complete aside:
> > I know we're not doing any of that consistently in the tree, but
> > especially when handling things like polynomials "packed" into
> > integers, and amounts of bits, I always recommend people explicitly use
> > "unsigned int", or directly go for an explicitly sized integer type,
> > e.g. "uint64_t gfpoly" for their polynomial representations, so that
> > there's no arithmetic surprises – signed integer overflow, for example,
> > is way less well-defined than unsigned.
> >
> > Best regards,
> > Marcus
> >
> > On Wed, 2019-07-24 at 10:30 -0500, Alex Roberts wrote:
> > > So I tried re-implementing the gr-dtv Reed Solomon decoder with an additional output so I could monitor/output the number of errors corrected.
> > > I used gr-modtool, created new block with new name so it wouldn't conflict with the existing and made sure to update the markup language for the grc block.
> > >
> > > I get an error about Number of outputs 1 exceed max 0. I'm not sure why that is.
> > >
> > > Here is my impl declaration with io_signatures.
> > >
> > > custom_reed_solomon_dec_impl::custom_reed_solomon_dec_impl(int p, int m, int gfpoly, int n, int k, int t, int s, int blocks)
> > > : block("custom_reed_solomon_dec",
> > > io_signature::make(1, 1, sizeof(unsigned char) * blocks * (n - s)),
> > > io_signature::make2(1, 2, sizeof(unsigned char) * blocks * (k - s), sizeof(int) )), // Change to make2 to support outputting nerrors_corrected in the general_work() function
> > > d_n(n), d_k(k), d_s(s), d_blocks(blocks)
> > > {
> > > ...
> > > }
> > >
> > >
> > > On Tue, Jul 23, 2019 at 3:44 PM Alex Roberts <arob109@gmail.com> wrote:
> > > > Marcus,
> > > >
> > > > I think what you said makes sense. I was initially thinking I would have a synchronous block with a message port output, but if I can keep it as simple as a sync block with two outputs just with different sizes, then that is where I will start.
> > > >
> > > > Thanks,
> > > > Alex.
> > > >
> > > > On Tue, Jul 23, 2019 at 9:16 AM Müller, Marcus (CEL) <mueller@kit.edu> wrote:
> > > > > Hi Alex,
> > > > >
> > > > > to get this straight: on your monitoring output, you get one item of
> > > > > output per item of input? (an input item being a vector, and a
> > > > > monitoring output item being a number)
> > > > >
> > > > > Then, everything is well: The thing is still a sync block, just one
> > > > > where not all output item sizes are identical, and not all are
> > > > > identical to the input item sizes.
> > > > >
> > > > > Even if that's not the case, the right way here would be to write a
> > > > > general block with streams, not an asynchronous messaging block, since
> > > > > the monitoring data is "synchronous" to the other data.
> > > > >
> > > > > Best regards,
> > > > > Marcus
> > > > >
> > > > > On Tue, 2019-07-23 at 09:10 -0500, Alex Roberts wrote:
> > > > > > I'd like to monitor an internal variable on a DSP block. have not made a custom block before but have read through some tutorials.
> > > > > >
> > > > > > Since the DSP inputs and outputs are vectors, and the variable is a single item whose value is dependent on the processing of the vector, the number of outputs does not match the number of inputs. The value is updated after each input vector is processed. Does this mean I should use the message port to asynchronously output the variable, or can I simply add another port and output the value as say a float or integer that is synchronously updated with the block?
> > > > > >
> > > > > > For example, in a Reed-Solomon implementation, how could I add an output to monitor the number of errors corrected?
> > > > > > _______________________________________________
> > > > > > Discuss-gnuradio mailing list
> > > > > > Discuss-gnuradio@gnu.org
> > > > > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > >
> > > _______________________________________________
> > > Discuss-gnuradio mailing list
> > > Discuss-gnuradio@gnu.org
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > _______________________________________________
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
No comments:
Post a Comment