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 <[email protected]> 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 <[email protected]> > > wrote: > > > >> On Tue, May 20, 2014 at 2:17 AM, Francois Gervais < > >> [email protected]> 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 [email protected] > >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >> > >> > > > > > > > > _______________________________________________ Discuss-gnuradio > > mailing list [email protected] > > 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 > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
