|
From: | Jeon |
Subject: | Re: [Discuss-gnuradio] Switching flow between two paths. |
Date: | Sat, 28 Mar 2015 23:55:16 +0900 |
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:
Jeon.lib/rll_impl.h: https://gist.github.com/gsongsong/615649f628262c44c8cflib/rll_impl.cc: https://gist.github.com/gsongsong/14e7bdab27216bbe7a17
Please excuses some typos and syntax violation if any.
Regards,
2015-03-27 16:30 GMT+09:00 Marcus Müller <address@hidden>:
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 <address@hidden>:
On Mar 25, 2015, at 2:15, Marcus Müller <address@hidden> 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
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________ Discuss-gnuradio mailing list address@hidden https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________ Discuss-gnuradio mailing list address@hidden https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Prev in Thread] | Current Thread | [Next in Thread] |