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 >>>>>>> [email protected] >>>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>>> _______________________________________________ >>>>>> Discuss-gnuradio mailing list >>>>>> [email protected] >>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>> _______________________________________________ >>>>> Discuss-gnuradio mailing list >>>>> [email protected] >>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>> _______________________________________________ >>>> Discuss-gnuradio mailing list >>>> [email protected] >>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> _______________________________________________ >>> Discuss-gnuradio mailing list >>> [email protected] >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> _______________________________________________ >> Discuss-gnuradio mailing list >> [email protected] >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
