3

I am feeling Stream Tags, Message Passing, Packet Data Transmission are a bit of overkill, and I have hard time to understand.

I have a simple wish: starting from a stream of bytes I would like to "extract" only a fixed number of bytes) starting from a known pattern. For example from a stream like this: ...01h 55h XXh YYh ZZh..., it should extract XXh YYh ZZh.

I utilized Correlate Access Code Tag block -- Tagged Stream Align -- Pack K Bits to convert a bit stream into a byte stream and synch to the desired Access Code (01h 55h), but how do I tell gnuradio to only process 3 bytes after every time the code is found? Likely OOT block would solve, but is it there some combinatino of standard GRC block to do this?

Marcus Müller
  • 34,677
  • 4
  • 53
  • 94
aAWnSD
  • 124
  • 10

1 Answers1

2

I think with correllate_access_code_tag_bb you can actually build this, with a bit of brain-twisting, from existing blocks alone. (Note: this does rely on stream tags, because those are the right tool to mark special points in a sample flow.)

However, your simple case might really not be worth it. Simply follow the guided tutorials up to the point where you can write your own python block.

Use self.set_history(len(preamble)+len_payload) in the constructor of your new block to make sure you always see the last samples of the previous iteration in your current call to work, and simply search for the preamble in your sample stream, outputting only the len_payload following bytes when you find it, not producing anything if you don't find it.

Marcus Müller
  • 34,677
  • 4
  • 53
  • 94
  • Hi Marcus, thank you for the reply. What do you think **the (best/right) way** to do this in Gnuradio? I mean, if you had to do this, how would you do it? Cheers, aawnsd – aAWnSD Nov 26 '15 at 10:49
  • pretty much the way I described it! However, three bytes does sound like you might want to do message passing instead of generating a sample stream. Really: I'd read the guided tutorials, and try to understand the concepts of stream tags and message passing :) – Marcus Müller Nov 26 '15 at 11:45
  • PS: this is engineering; there's no single *right/best way to do* anything. Just things that are appropriate for your problem, which is the combination of what you want to achieve and the skills, tools and resources you have! – Marcus Müller Nov 26 '15 at 11:46
  • 1
    You mentioned that this might be possible with standard blocks alone; would you care to elaborate how? – Aleksi Torhamo Dec 15 '17 at 07:07
  • @AleksiTorhamo no. The tools of 2015 were (rightfully) deprecated, and this is **much** easier to implement in your own block. So don't be shy to read those guided tutorials (fixed the link above), and write your own 10 lines of python code to make this work. – Marcus Müller Dec 15 '17 at 07:24
  • 1
    @MarcusMüller Why is it so wrong to try to learn how you can do things with the standard blocks? The OP asked if there was any way to do it with just the standard blocks; You proceeded to say "yes", and then didn't even give a hint as to how. For the record: Personally, I already have what I'm trying to make in gnuradio fully working in pure python, from raw IQ to fully parsed packets. I've got the python part all figured out; what I can't figure out is how to do things in gnuradio, since most blocks seem to be totally undocumented - It's extremely frustrating. – Aleksi Torhamo Dec 15 '17 at 17:57
  • *Why is it so wrong to try to learn how you can do things with the standard blocks?* Not all standard blocks are good. And those that you'd have to use are really *bad* enough for them to be removed in the next version of GNU Radio. So, I simply won't teach you the complicated ways of using them. Instead, I recommend you learn how to write a block. That's the right way. Believe me. It's not easier to use the existing blocks. It's more complicated. It's slower. It's error-prone. It's less easy to adapt to your use case. Most blocks are documented.If not,ask on the GNU Radio discuss mailing list – Marcus Müller Dec 15 '17 at 19:21