Hi Marcus, I'm not sure about the steps required to translate the bit stream from the RF receiver into a tagged stream.
I looked at the ofdm_rx example and from what I understand I'll need a first block that takes the output of the demod/Clock Recovery/bit slicer and find the packets inside the stream and tag it so the other blocks can work with the tagged stream. This first block is a normal one that inherit from the generic Block class it that it? Does this first block need to output anything while waiting for the preamble of a packet to prevent the downstream block from freezing? Once the stream is packetized and tagged it seems pretty straight forward. Thanks On Tue, May 20, 2014 at 10:37 AM, Francois Gervais < francoisgerv...@gmail.com> wrote: > Thanks I'll take a closer look. > > > On Tue, May 20, 2014 at 10:34 AM, Marcus Müller > <marcus.muel...@ettus.com>wrote: > >> Hi, >> >> PDU blocks are a *type* of blocks. Basically, you tag your sample stream >> so that the blocks downstream know how long your packet is. >> The tagged stream infrastructure is an innovation meant to simplify the >> design of blocks dealing with packetized data. >> Lool in the gr-digital/examples subfolder for how some implementations of >> that principle are used. >> >> Greetings, >> Marcus >> >> >> On Tue, May 20, 2014 at 4:23 PM, Francois Gervais < >> francoisgerv...@gmail.com> wrote: >> >>> Sorry about that I'll try to clarify thing. >>> >>> I'm using an rtl-sdr adapter to receive an RF signal. I demodulate it >>> and send it through the MM clock recovery and bit slicer. Then the binary >>> signal enters the block I'm talking about here. >>> >>> This block find a valid packet by matching the preamble and the sync >>> pattern and translates the packet into another format that is understood by >>> a software stack designed for these type of packets. >>> >>> Normally this stack would take it's input from a serial port but in my >>> case I output the packets in the correct serial protocol through a file >>> sink that is binded to a FIFO. >>> >>> I'll take a look at the PDU block but this translation needs to be done >>> between two very specific protocol. I don't think a generic block can >>> achieve that. >>> >>> Right now the development is mostly finished. All I need to make sure is >>> that my block interface correctly with the scheduler since I don't have a >>> fixed input to output number relationship. It's mostly 8:1 but that not >>> always exactly the case. >>> >>> Hope it makes sense. >>> >>> >>> On Tue, May 20, 2014 at 10:06 AM, Marcus Müller <mar...@hostalia.de>wrote: >>> >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> Hi Francois, >>>> >>>> as Activecat, I'm kind of having a hard time understanidng your >>>> requirements. >>>> If you're emulating a hardware signal source, go for the source >>>> approach. >>>> If you're basically taking input from anywhere and packing it into >>>> packets of varying length, that's exactly what the PDU block >>>> infrastructure is for: >>>> http://gnuradio.org/doc/doxygen/page_tagged_stream_blocks.html >>>> >>>> Greetings, >>>> Marcus >>>> >>>> On 20.05.2014 15:59, Francois Gervais wrote: >>>> > Thanks Activecat you actually answered quite well to my question. I >>>> > thought it might be better to send 0s, i'm glad you confirmed that. >>>> > And thanks for the output algorithm. >>>> > >>>> > Could you tell me more about forecast? Most of the time I need 8 >>>> > input samples to produce one byte output so I set the forecast like >>>> > so: >>>> > >>>> > ninput_items_required[0] = noutput_items*8; >>>> > >>>> > It seems pretty straight forward. Is this correct? >>>> > >>>> > >>>> > On Mon, May 19, 2014 at 9:32 PM, Activecat <active...@gmail.com> >>>> > wrote: >>>> > >>>> >> On Tue, May 20, 2014 at 2:17 AM, Francois Gervais < >>>> >> francoisgerv...@gmail.com> wrote: >>>> >> >>>> >>> Hi, >>>> >>> >>>> >>> I'm making a block which takes bit from a bit slicer and output >>>> >>> packets as input comes in. My block will output bytes so it can >>>> >>> emulate a usb adapter that receives the RF signal and output a >>>> >>> packet stream through an FTDI. That way I can use the stack >>>> >>> that comes with the adapter without owning one. I'll use a FIFO >>>> >>> file so other than not issuing the serail configuration the >>>> >>> stack should be used pretty much as is. >>>> >>> >>>> >>> However, I'm not sure what I should do about the the number of >>>> >>> outputs. Let say I'm waiting for the preamble, I won't output >>>> >>> anything. When I get the preamble and the sync I'll send a sync >>>> >>> byte of my own. From here every 8 inputs I'll output a byte. So >>>> >>> basically my block will output 0 or 1 output. >>>> >>> >>>> >>> Can someone help me a little with the use of forecast and >>>> >>> noutput_items in my case? Also do I need to use the >>>> >>> consume_each function? >>>> >>> >>>> >> >>>> >> If your block emulates a USB adapter, defines it as a source >>>> >> block, then you don't need to touch forecast(). If your block >>>> >> takes input from another block, then it is not source block. I >>>> >> don't really understand your requirements. >>>> >> >>>> >> The number of outputs (referred as noutput_items) is determined >>>> >> by the scheduler, not yourself. Says, when you have X bytes to >>>> >> send out, if X > noutput_items: Send out noutput_items number of >>>> >> output, and return noutput_items if X < noutput_items: Send out >>>> >> X number of output, and return X if X == noutput_items: (either >>>> >> one of above) >>>> >> >>>> >> When you send out a sync byte, add that to the output count. >>>> >> >>>> >> When you are waiting for the preamble, you may want to send out a >>>> >> series of zeros, rather than just producing no output. Producing >>>> >> no output may cause the downstream blocks to become >>>> >> unresponsive. >>>> >> >>>> >> _______________________________________________ Discuss-gnuradio >>>> >> mailing list Discuss-gnuradio@gnu.org >>>> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>> >> >>>> >> >>>> > >>>> > >>>> > >>>> > _______________________________________________ Discuss-gnuradio >>>> > mailing list Discuss-gnuradio@gnu.org >>>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>> > >>>> -----BEGIN PGP SIGNATURE----- >>>> Version: GnuPG v1 >>>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >>>> >>>> iQEcBAEBAgAGBQJTe2FKAAoJEBQ6EdjyzlHtrvsH/3EhTVbESphbUfNeWmZe/rNU >>>> YYOVD7XVYVndHzstznIwvYlNVRLugjJw74pPJ0DS050b1ggc9mDK/mW4975BICau >>>> hQQktHxN3QReWk5qKwpAx6Y/+3bVpC+phyFzZO0+1TBwHNYexsVA+Zw0mkGrOuvA >>>> 3pInPREkJxqxcMrbZZhMTYVVDfOpB5MEjxHSKOMWyAQqop2fg1ahlEwpKjVqDmmV >>>> 9NhjSbIy29kpayTcEq525ha0QPMb5bRkRiP1sw4GqHDJZSHyUR4RWYYHiVfD3CvP >>>> /Bmx74UyS69gnP6NmMxun3OjWngpNHkJNC0lN/GGHVhz7YjwVXINuXNkbYuEVaM= >>>> =x2qL >>>> -----END PGP SIGNATURE----- >>>> >>>> _______________________________________________ >>>> Discuss-gnuradio mailing list >>>> Discuss-gnuradio@gnu.org >>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>> >>> >>> >>> _______________________________________________ >>> Discuss-gnuradio mailing list >>> Discuss-gnuradio@gnu.org >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> >> >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
