Dear, Marcus Thank you for your advice.
I will test it as soon as possible after fixing another problem in the entire module (not related with RLL.) And will report the result on the discuss-gnuradio. Regards, Jeon. 2015-03-28 21:50 GMT+09:00 Marcus Müller <[email protected]>: > Hi Jeon, > > this looks like good code; it's an excellent design choice to use a tagged > stream block here, where you'd want GNU Radio to make sure you get the > whole "packet" that you need to encode into a single work call. > > I think it should work; of course, I'm not your computer ;) . With the > existing tagged stream block framework, it should be quite straightforward > to define a python test case for this, so I'd encourage you to actually > test it! > > Best regards, > Marcus > > > On 03/27/2015 04:16 PM, Jeon wrote: > > 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 > [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
