Dear Dat, You are correct. When I create a new tagged stream block and connect to the flow graph the problem was fixed. Thank you for the suggestion. I will see how to write a similar block to handle the problem.
Damindra On Sat, Dec 24, 2016 at 3:43 PM, Dat Luu <[email protected]> wrote: > I think you use a set up like this * -- stream to tagged stream -- ofdm tx > -- * and then perform event triggering (time based by sleep function?) to > do reconfiguring? If yes, the problem is with the tagged stream block and > stop(); the block will not add any tag to data stream it was processing > upon stop(). Quick and dirty fix is to disconnect the current stream to > tagged stream block, create a new one and connect it to the flow graph; > losing data of course. I don't know the better fix, but you may have to > mess with that tagged stream block and make your own block to handle that > problem. > > On Sat, Dec 24, 2016 at 10:51 AM, Damindra Bandara < > [email protected]> wrote: > >> Dear Keven, >> >> Please consider the following flow graph. I have done some changes to the >> OFDM TX block and in the earlier file forgot to remove that. This file has >> all the original GNURadio blocks and running in no GUI mode. But still the >> problem is there. I appreciate if you could help me to figure out the >> problem. >> >> >> Thanks, >> Damindra >> >> On Sat, Dec 24, 2016 at 1:39 PM, Damindra Bandara < >> [email protected]> wrote: >> >>> Dear Kevin, >>> >>> Thank you for your response. Here are the answers to the questions you >>> asked. >>> >>> Does it happen if you only stop and start the flow graph without >>> actually changing any connections? Yes. It still gives the same error when >>> only stop and start the flow graph. When I do the reconfiguration without >>> stop and start I do not get any error. However, I do not see any >>> reconfigured parameters applied(i.e., it still runs with the previous >>> configuration) >>> >>> Does it happen if you lock(), change, unlock() — instead of stop(), >>> change, start()? Yes, still get the same error >>> >>> Does it happen if you do some reconfiguration but less than your >>> application actually needs — e.g. replace a block with a newly-constructed >>> identical block (should have no effect)? Yes, even for simpler applications >>> that use tag streams. (I have used the [stop--> change block --> start] >>> and [lock --> change parameter --> unlock] without any error before I >>> introduce OFDM blocks and tagged streams. I started to get the error after >>> introducing OFDM block and tagged streams. >>> >>> Herewith I have attached a flow graph where I simply try to lock the >>> flow graph print a statement and unlock it. I still get the same error. To >>> run please change the file name in the file source block and run the python >>> file. >>> >>> If you can help me to figure the problem I really appreciate it. >>> >>> Best regards, >>> Damindra >>> >>> On Sat, Dec 24, 2016 at 10:35 AM, Kevin Reid <[email protected]> wrote: >>> >>>> On Sat, Dec 24, 2016 at 9:46 AM, Damindra Bandara < >>>> [email protected]> wrote: >>>>> >>>>> Also, I get the error only when I try to reconfigure a flow graph. >>>>> Could you please let me know the correct way to reconfigure a flow graph >>>>> when they are using tags. >>>>> >>>> >>>> Both reconfiguration and tags are lesser-used features (reconfiguration >>>> even less), and based on my experience with reconfiguration, there might >>>> well be a bug in a particular block's interaction with reconfiguration. I >>>> would suggest taking a troubleshooting/debugging approach to finding out >>>> what is sufficient to cause the problem: >>>> >>>> - Does it happen if you only stop and start the flow graph without >>>> actually changing any connections? >>>> >>>> - Does it happen if you lock(), change, unlock() — instead of >>>> stop(), change, start()? >>>> >>>> - Does it happen if you do some reconfiguration but less than your >>>> application actually needs — e.g. replace a block with a >>>> newly-constructed >>>> identical block (should have no effect)? >>>> >>>> It would be great if (if there actually is a bug here) you can narrow >>>> it down to a simple example and file a bug report. >>>> >>>> I might be able to help with the narrowing down if you have some >>>> reasonably-sized Python/GRC code you could share, as I've gone through this >>>> process several times. (I develop a reconfiguration-heavy application.) >>>> >>> >>> >>> >>> -- >>> Damindra Savithri Bandara, >>> Ph.D. in Information Technology (Candidate) >>> George Mason University, >>> Fairfax, >>> Virginia >>> >> >> >> >> -- >> Damindra Savithri Bandara, >> Ph.D. in Information Technology (Candidate) >> George Mason University, >> Fairfax, >> Virginia >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> [email protected] >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > -- Damindra Savithri Bandara, Ph.D. in Information Technology (Candidate) George Mason University, Fairfax, Virginia
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
