Hi Miguel,
:)
Having had a night of sleep:
Normally in GNU Radio, you've got input- and output buffers, and if
there's no space in your output buffer, you can't process input, so
you stall until there's space in your output buffer.
That's how the throttle block works: by not taking samples from its
input buffer faster than specified by the "throttle rate", it not
only slows down the blocks downstream in the flow graph, but it also
keeps the input buffer full. Its input buffer is the output buffer
of the block upstream, and so, that block can't run arbitrarily fast
(that mechanism is called backpressure, by the way).
But: The packet_encoder, old as it is, internally uses an old-style
message sink. Which means it takes samples out of its input buffer,
processes them somehow, and shoves them into a FIFO.
That FIFO does not have a way of saying "I'm full", but just grows
and grows and grows... So, the packet_encoder breaks up the
backpressure chain, and that's a bad thing, architecturally, as you
can see, because the block upstream (i.e. the vector source) can now
run as fast as it can – that is, as fast as the packet_encoder
consumes the items it produces, and as fast as the file sink
consumes them, whatever is slower.
Without the packet_encoder, backpressure from the throttle block
works, so that's why your file is smaller.
Hope that explains the observation, at least a bit :)
Best regards,
Marcus
On 23.03.2016 00:11, Miguel Santos
wrote:
Sadly, we all need some sleep...
Well, thanks, A LOT! I'll try that.
Have a good night, you deserve a statue or a Nobel or something
like that!
Best regards,
Miguel
On 22-03-2016 22:41, Marcus Müller
wrote:
Indeed,
there seems to be a problem here; sadly, I'll really need some
sleep tonight ;)
To answer your question, yes, Packet Encoder is really old and
IMHO should be deprecated in favor of the architecture you'd
find in the ofdm_tx.grc example (should be installed somewhere
like /usr/(local/)share/gnuradio/examples/gnuradio/digital/ofdm
)
However, if you just need a preamble:
use a second vector source for the preamble (or something else),
and use the "patterned interleaver", e.g. with something like
pattern = [1]*header_len + [0]*payload_len
Best regards,
Marcus
On 22.03.2016 23:17, Miguel Santos
wrote:
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
_______________________________________________
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
|