I am offering advice without looking at the flowgraph, so take this with a grain of salt, but sps usually stands for samples per *symbol*, not seconds.
On Sat, Aug 26, 2017 at 4:04 AM Marcus Müller <[email protected]> wrote: > Hi Mehtap, > > huh, if increasing sps = 100 is all that it takes to trigger this, then > this is probably¹ a bug. And as such, we should fix it. Just to confirm: If > you take a totally unmodified packet_loopback_hier.grc and **only** change > sps=100, then you get this? > > Generally, sps=100 seems… unintuitive. Use something like sps=20 and > interpolate by 5? The ISI suppression gain you get from a longer RRC will > decrease with growing RRC length. > > Best regards, > > Marcus > ¹: I say "probably", because I don't have packet_rx in front of me right > now, and there might be a "logical" limitation, where something else > depends on sps and another factor, and you'd have to adjust that other > factor, too, for the flow graph to "make sense". > On 25.08.2017 21:33, mehtap özkan wrote: > > Thanks to Marcus Müller I became aware of the Packet TX and RX blocks. > I use the Packet_loopback_hier.grc example. However the example is set to > 2 samples per seconds=sps. When I try to increase sps=100, the number of > taps of the RRC filter becomes( 5*sps*nfilts) exceeds its limit. > I get > ../.grc_gnuradio\packet_rx.py", line 49, in __init__ > self.mark_delay = mark_delay = mark_delays[sps] > IndexError: list index out of range > > Is there another way to increase the speed limit? > > Thanks > > > _______________________________________________ > Discuss-gnuradio mailing > [email protected]https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > -- Very Respectfully, Dan CaJacob
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
