discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Random number of output items


From: Francois Gervais
Subject: Re: [Discuss-gnuradio] Random number of output items
Date: Tue, 20 May 2014 13:13:35 -0400

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 <address@hidden> wrote:
Thanks I'll take a closer look.


On Tue, May 20, 2014 at 10:34 AM, Marcus Müller <address@hidden> 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 <address@hidden> 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 <address@hidden> 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 <address@hidden>
> wrote:
>
>> On Tue, May 20, 2014 at 2:17 AM, Francois Gervais <
>> address@hidden> 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 address@hidden
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
>
>
> _______________________________________________ Discuss-gnuradio
> mailing list address@hidden
> 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
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio





reply via email to

[Prev in Thread] Current Thread [Next in Thread]