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: Miguel Santos
Subject: Re: [Discuss-gnuradio] problem with packet encoder block
Date: Tue, 22 Mar 2016 22:17:23 +0000

As an attachment I send the .grc on which I'm doing tests.
So:
     - with head and/or throttle between source and packet encoder -> fine
     - bypassing Head and Throttle -> huge file
     - bypassing Head, Throttle and Encoder -> fine
I answered your questions below.

Another question: I'm using Packet Encoder only to add a preamble to 
perform frame sync. Is it the only way?

On 22-03-2016 21:42, Marcus Müller wrote:
> Hi Miguel,
>
> On 22.03.2016 21:54, Miguel Santos wrote:
>> On 22-03-2016 20:32, Marcus Müller wrote:
>>> 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?
>> It doesn't. For now, I'm dealing with transmitting and receiving
>> problems, so I don't really care about the message. For testing purposes
>> I'm transmitting an infinite amount of 0s and 1s (the same repeated
>> sequence defined in Vector Source block) and I manually stop the flow
>> graph after a certain amount of time.
> Ah, so there's no "right" amount of samples. It all depends on when you
> decide to manually stop, and on the speed at which samples are processed.
> I'd recommend adding a "head" block somewhere. That will signal "hey,
> we're done" as soon as the specified amount of samples have passed.

Exactly! I tested with the Head block and it behaves as it should. I 
think the problem occurs only when vector source is connected directly 
to packet encoder.
By the way, why does the file becomes empty if "Num items"<4096? I'm new 
to this world and there's a LOT of things I don't understand.

>>   The differences between the two
>> cases I presented were noted running the flow graph for, for instance, 5
>> seconds (counted by me). It's not very accurate, I know, but we're
>> talking of a big difference (like a few KB or MB to hundreds of MB or
>> even a few GB), so it's not important.
> So, sorry for asking again, but I really want to be sure: *with* the
> packet_encoder, the file is much much larger than without, right?
>
> Best regards,
> Marcus

Yeah, that's it: WITH

>> Thanks for your time and sorry for not being explicit enough.
> Don't worry! If this is a bug, it's really worth figuring out.
> Also, we're a helpful bunch of people.
>
> Best regards,
> Marcus
>>> 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
>>> _______________________________________________
>>> 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

Attachment: packetencoder.grc
Description: packetencoder.grc


reply via email to

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