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
