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
No comments:
Post a Comment