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 list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
