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, MarcusYeah, that's it: WITHThanks 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, MarcusBest regards, MarcusI'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 Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
No comments:
Post a Comment