discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Reconfiguring OFDM flow graph at run time gives "


From: Dat Luu
Subject: Re: [Discuss-gnuradio] Reconfiguring OFDM flow graph at run time gives "FATAL: Missing a required length tag on port 0 at item" error
Date: Sat, 24 Dec 2016 12:43:40 -0800

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 <address@hidden> 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 <address@hidden> 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 <address@hidden> wrote:
On Sat, Dec 24, 2016 at 9:46 AM, Damindra Bandara <address@hidden> 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
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



reply via email to

[Prev in Thread] Current Thread [Next in Thread]