discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] problem with packet encoder block


From: Marcus Müller
Subject: Re: [Discuss-gnuradio] problem with packet encoder block
Date: Tue, 22 Mar 2016 21:32:44 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0

Hi Miguel,

On 22.03.2016 17:14, Miguel Santos wrote:
> Yes, it's set to repeat. 
oh!
> My real flow graph ends with a file sink, but 
> here, as an example to test which block was the problem, I used a number 
> sink just to be able to run it and test it.
But then, how does your flow graph decide it's done?

Best regards,
Marcus
> I've made more tests and if I switch Throttle with Packet Encoder, it's 
> all good. The same happens if I connect File Sink to Throttle (when they 
> are switched).
> So maybe the problem is with the position of throttle? After watching 
> the tutorials I thought that its position was irrelevant...
>
> On 22-03-2016 08:02, Marcus Müller wrote:
>> Hi Miguel,
>>
>> I assume your Vector Source is not set to "Repeat"? Or how does your
>> Flow graph Terminate?
>> Generally, no block can modify its input buffer; hence, what File Sink
>> "sees" as an input number sequence must be identical (unless we really
>> have a bad memory access bug at hand, which I don't think).
>>
>> Bet regards,
>> Marcus
>>
>> On 22.03.2016 00:39, Miguel Santos wrote:
>>> Hi all!
>>> While I was using the block Packet Encoder I realized that my input file
>>> (saved before that block) becomes a lot bigger.
>>> So I made a simple example to show that problem.
>>>
>>> Vector Source ---> Packet Encoder ---> Throttle ---> Number Sink
>>>                 ---> File Sink
>>>
>>> Just to make it clear, File Sink is connected to Vector Source, BEFORE
>>> Packet Encoder.
>>> Running the flow graph the same amount of time, I get an input file of
>>> 700~800 MB for this flow graph and ~3MB for the same flow graph with
>>> Packet Encoder bypassed.
>>> Is this a bug? Could it be a larger processing time of that block that's
>>> delaying the data flow? Am I missing something? How can I solve that?
>>> Any help would be nice.
>>>
>>> Thanks for your time,
>>> Miguel
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>
> _______________________________________________
> 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]