Dear, Marcus Here's my codes
include/rll.h: https://gist.github.com/gsongsong/07e28c797bb65572982b lib/rll_impl.h: https://gist.github.com/gsongsong/615649f628262c44c8cf lib/rll_impl.cc: https://gist.github.com/gsongsong/14e7bdab27216bbe7a17 Please excuses some typos and syntax violation if any. Regards, Jeon. 2015-03-27 16:30 GMT+09:00 Marcus Müller <[email protected]>: > 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]>: > >> On Mar 25, 2015, at 2:15, Marcus Müller <[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] >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > > > > _______________________________________________ > Discuss-gnuradio mailing > [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
