Hi Jeon,
could you paste the whole C++ file to the gist?
Basically, what I suspect is that you're not checking whether
get_tags_in_range() produced a tag at all, or/and might have an error in
your state machine that stores the "current" coder.
Greetings,
Marcus
On 03/27/2015 06:23 AM, Jeon wrote:
> After thinking about it for a couple of days, I've decided not to use
> two separated RLL blocks.
> Instead, I made a block as below:
>
> In work() function:
>
> get_tags_in_range(tags, 0, nitems_read(0),
> nitems_read(0) + ninput_items[0],
> pmt::mp("rll_coding"));
> RLL_CODE rll_code = (RLL_CODE)pmt::to_long(tags[0].value);
>
> // ... omitted trivial things
>
> switch (rll_code) {
> case RLLMANCHESTER:
> for(int i = 0; i < ninput_items[0]; i++) {
> out[2 * i] = !!in[i];
> out[2 * i + 1] = !in[i];
> }
> break;
> case RLL4B6B:
> for(int i = 0; i < ninput_items[0] / 4; i += 4) {
> int rll4B = 0;
> for (int j = 0; j < 4; j++) {
> // make four bits into one bytes
> rll4B |= (in[i + j] & 1) << j;
> }
> for (int j = 0; j < 6; j++) {
> // put six bits corresponding to rll4B
> out[6 * i + j] = !!(rll4B6B[rll4B] & (1 << j));
> }
> }
> break;
> }
>
> // mapping definition
>
> const char rll4B6B[16] = {
> 0b011100, 0b101100, 0b110010, 0b011010,
> 0b101010, 0b110001, 0b011001, 0b101001,
> 0b100110, 0b010110, 0b001110, 0b100011,
> 0b010011, 0b100101, 0b010101, 0b001101
> };
>
> If the code are not formatted well and hard to read, please refer:
> https://gist.github.com/gsongsong/f3e34991a55f29dac5d2
> There might be some syntax violation and variable definitions missing,
> I apologize for that.
> And please note that each in[i] is either 0b00000000 or 0b00000001.
>
> By using a tag, RLL coding scheme are not changing during the stream.
> Currently, I haven't built it and tested yet.
>
> What do you think of it?
>
> I will make some notes after build and test the entire system.
>
> Regrads,
> Jeon.
>
> 2015-03-26 23:17 GMT+09:00 Kevin Reid <[email protected]
> <mailto:[email protected]>>:
>
> On Mar 25, 2015, at 2:15, Marcus Müller <[email protected]
> <mailto:[email protected]>> wrote:
>
> > source -+--> custom_block0 ---> encoder0 ---> add -->
> > +--> custom_block1 ---> encoder1 ------^
> >
> > you'd need to implement custom_block in python or C++, that
> would either
> > pass through items, just like the block does that comes out of
> > gr_modtool add -l python -t sync
> > or set the output items to 0. You'd toggle that behavior exactly
> at the
> > sample that you get a tag.
>
> Note that if you don't actually need the switch to happen at a
> specific point in the stream, but you still want the switch to be
> atomic (guaranteed not to drop or repeat any items), the existing
> multiply_matrix block can do the switching in this flowgraph: it
> would be configured with one input and two outputs, and setting
> the matrix to either [[0, 1]] or [[1, 0]].
>
> (Of course, the disadvantage of either of these strategies is that
> you're paying the CPU cost of both encoders all of the time.)
>
> --
> Kevin Reid
> <http://switchb.org/kpreid/>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> [email protected] <mailto:[email protected]>
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> [email protected]
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
