Re: [Discuss-gnuradio] Passing a USRP pointer
On Fri, Jan 17, 2014 at 5:40 PM, Tom Rondeau t...@trondeau.com wrote: On Tue, Jan 14, 2014 at 9:09 PM, Dan CaJacob dan.caja...@gmail.com wrote: Hey Tom, The block worked fine with the right symblic name passed! The amp is getting PTTed now in 3.7 Thanks for your help with this! Great! It still seems weird that the USRP Sink symbolic name was formatted differently, though. Hm, yes, that is odd. Would you open a ticket about it? Low priority and a change in behavior that might have to wait for 3.8. Will do! Also, would it be possible to automatically register symbolic name aliases that are based on the block names created in GRC/python? That would make the lookup a little more obvious. Which names, exactly? Are you talking about the variable name itself? I'm not sure what the nomenclature is, but I am talking about the name that is auto-generated by GRC when a block is placed, but which can be modified by the user. This name becomes the blocks object name in the python file. For that, there's no way for the block to know that information. On the other hand, you can actually set the block alias yourself so you don't have to ask/guess/know what it is in advance using the set_block_alias(string) function. I am aware of the alias function. The question is - can we use that somewhere so that the block automatically gets aliased as the name the block instance is given in GRC? Probably, this needs to live in GRC itself, specifically in the code that generates a python file from the FG. Does that make sense? I assume the alias function is a method of the block objects in python. Thanks for your help with this, Tom! I'm really excited about 3.7! I'm already using it on one of my flatsat setups. Tom Thanks! Very Respectfully, Dan CaJacob On Fri, Jan 10, 2014 at 3:28 PM, Dan CaJacob dan.caja...@gmail.com wrote: Hey Tom, We've been working on this, but we ran into a snag. We couldn't seem to look up the usrp sink block's key. Other blocks could be looked up with the keys we expected, just not the uhd sink. I just un-commented a print statement in block_registry.cc so that we could see how each block actually gets registered, built it and ran a simple flowgraph. The flowgraph is just a signal source - throttle - uhd sink. Here's the output: register_symbolic_name: top_block0 register_symbolic_name: gr uhd usrp sink0 register_symbolic_name: throttle0 register_symbolic_name: sig_source_c0 The UHD sink block gets an unexpected gr pre-pended and the underscores are replaced with spaces. We are going to attempt our OOT blocks with this in mind, but I thought I'd give you a heads up on this behavior. Thanks! Very Respectfully, Dan CaJacob On Tue, Jan 7, 2014 at 2:18 PM, Tom Rondeau t...@trondeau.com wrote: On Tue, Jan 7, 2014 at 12:21 PM, Dan CaJacob dan.caja...@gmail.com wrote: Hey Tom, Here's some more detail into our problem. When running the flowgraph, we get the following error: File /usr/local/lib/python2.7/dist-packages/sq/sq_swig.py, line 679, in make return _sq_swig.usrp_pa_control_make(*args, **kwargs) TypeError: in method 'usrp_pa_control_make', argument 1 of type 'gr::uhd::usrp_sink::sptr' When setting up a FG, the pa-control block accepts a reference to the downstream UHD sink. I have attached the specific block source. Thanks! Very Respectfully, Dan CaJacob It's probably the difference between a gr::uhd::usrp_sink and a gr::uhd::usrp_sink_impl. A safer way to handle this might be to use the new(ish) block_registry that we implemented to handle the message passing infrastructure. You can get a basic_block_sptr from global_block_registry.block_lookup; you should then be able to cast this to a usrp_sink_sptr. You'll pass it a PMT symbol containing the alias name of the UHD sink itself. Take a look at basic_block.cc for a look at how the global_block_registry is used. I've not done exactly this before, so it might not go completely smoothly, and I'd be interested in your experience. In general, this sounds like something more appropriately implemented as a message, though, but that would mean changing the gr-uhd code. Having a message handler for the GPIO stuff would probably be useful if done generically enough. Tom On Mon, Jan 6, 2014 at 11:25 AM, Dan CaJacob dan.caja...@gmail.com wrote: Thanks Tom, No problem. I hope you and the rest of the community had relaxing holidays! I hope to have some better info for you by tomorrow, if not before. Another way to look at this is: does it make sense to keep doing things this way? Is there a better way to reference the downstream USRP and toggle the IO? I could imagine an async message stream or specific stream-tags, but both would probably
Re: [Discuss-gnuradio] Passing a USRP pointer
On Tue, Jan 14, 2014 at 9:09 PM, Dan CaJacob dan.caja...@gmail.com wrote: Hey Tom, The block worked fine with the right symblic name passed! The amp is getting PTTed now in 3.7 Thanks for your help with this! Great! It still seems weird that the USRP Sink symbolic name was formatted differently, though. Hm, yes, that is odd. Would you open a ticket about it? Low priority and a change in behavior that might have to wait for 3.8. Also, would it be possible to automatically register symbolic name aliases that are based on the block names created in GRC/python? That would make the lookup a little more obvious. Which names, exactly? Are you talking about the variable name itself? For that, there's no way for the block to know that information. On the other hand, you can actually set the block alias yourself so you don't have to ask/guess/know what it is in advance using the set_block_alias(string) function. Tom Thanks! Very Respectfully, Dan CaJacob On Fri, Jan 10, 2014 at 3:28 PM, Dan CaJacob dan.caja...@gmail.com wrote: Hey Tom, We've been working on this, but we ran into a snag. We couldn't seem to look up the usrp sink block's key. Other blocks could be looked up with the keys we expected, just not the uhd sink. I just un-commented a print statement in block_registry.cc so that we could see how each block actually gets registered, built it and ran a simple flowgraph. The flowgraph is just a signal source - throttle - uhd sink. Here's the output: register_symbolic_name: top_block0 register_symbolic_name: gr uhd usrp sink0 register_symbolic_name: throttle0 register_symbolic_name: sig_source_c0 The UHD sink block gets an unexpected gr pre-pended and the underscores are replaced with spaces. We are going to attempt our OOT blocks with this in mind, but I thought I'd give you a heads up on this behavior. Thanks! Very Respectfully, Dan CaJacob On Tue, Jan 7, 2014 at 2:18 PM, Tom Rondeau t...@trondeau.com wrote: On Tue, Jan 7, 2014 at 12:21 PM, Dan CaJacob dan.caja...@gmail.com wrote: Hey Tom, Here's some more detail into our problem. When running the flowgraph, we get the following error: File /usr/local/lib/python2.7/dist-packages/sq/sq_swig.py, line 679, in make return _sq_swig.usrp_pa_control_make(*args, **kwargs) TypeError: in method 'usrp_pa_control_make', argument 1 of type 'gr::uhd::usrp_sink::sptr' When setting up a FG, the pa-control block accepts a reference to the downstream UHD sink. I have attached the specific block source. Thanks! Very Respectfully, Dan CaJacob It's probably the difference between a gr::uhd::usrp_sink and a gr::uhd::usrp_sink_impl. A safer way to handle this might be to use the new(ish) block_registry that we implemented to handle the message passing infrastructure. You can get a basic_block_sptr from global_block_registry.block_lookup; you should then be able to cast this to a usrp_sink_sptr. You'll pass it a PMT symbol containing the alias name of the UHD sink itself. Take a look at basic_block.cc for a look at how the global_block_registry is used. I've not done exactly this before, so it might not go completely smoothly, and I'd be interested in your experience. In general, this sounds like something more appropriately implemented as a message, though, but that would mean changing the gr-uhd code. Having a message handler for the GPIO stuff would probably be useful if done generically enough. Tom On Mon, Jan 6, 2014 at 11:25 AM, Dan CaJacob dan.caja...@gmail.com wrote: Thanks Tom, No problem. I hope you and the rest of the community had relaxing holidays! I hope to have some better info for you by tomorrow, if not before. Another way to look at this is: does it make sense to keep doing things this way? Is there a better way to reference the downstream USRP and toggle the IO? I could imagine an async message stream or specific stream-tags, but both would probably require changes to the actual UHD sinks. I'm not sure our use case is generic enough to warrant that. Very Respectfully, Dan CaJacob On Mon, Jan 6, 2014 at 10:46 AM, Tom Rondeau t...@trondeau.com wrote: On Sat, Dec 21, 2013 at 6:29 PM, Dan CaJacob dan.caja...@gmail.com wrote: We are upgrading some of our custom blocks for 3.7 and have run into a snag. Our 3.6 era blocks included one that PTTed an external amplifier based on stream tags. The IO was generated from the extra GPIO available on the WBX. One of the inputs to the block was a reference to the USRP sink downstream in the FG. The block then calls the necessary methods to enable and disable the GPIO. Everything worked nicely, but when we ported our blocks to 3.87, there seemed to be a problem with this. I did not personally do the testing, so I don't have the exact error, but I can probably
Re: [Discuss-gnuradio] Passing a USRP pointer
Hey Tom, The block worked fine with the right symblic name passed! The amp is getting PTTed now in 3.7 Thanks for your help with this! It still seems weird that the USRP Sink symbolic name was formatted differently, though. Also, would it be possible to automatically register symbolic name aliases that are based on the block names created in GRC/python? That would make the lookup a little more obvious. Thanks! Very Respectfully, Dan CaJacob On Fri, Jan 10, 2014 at 3:28 PM, Dan CaJacob dan.caja...@gmail.com wrote: Hey Tom, We've been working on this, but we ran into a snag. We couldn't seem to look up the usrp sink block's key. Other blocks could be looked up with the keys we expected, just not the uhd sink. I just un-commented a print statement in block_registry.cc so that we could see how each block actually gets registered, built it and ran a simple flowgraph. The flowgraph is just a signal source - throttle - uhd sink. Here's the output: register_symbolic_name: top_block0 register_symbolic_name: gr uhd usrp sink0 register_symbolic_name: throttle0 register_symbolic_name: sig_source_c0 The UHD sink block gets an unexpected gr pre-pended and the underscores are replaced with spaces. We are going to attempt our OOT blocks with this in mind, but I thought I'd give you a heads up on this behavior. Thanks! Very Respectfully, Dan CaJacob On Tue, Jan 7, 2014 at 2:18 PM, Tom Rondeau t...@trondeau.com wrote: On Tue, Jan 7, 2014 at 12:21 PM, Dan CaJacob dan.caja...@gmail.com wrote: Hey Tom, Here's some more detail into our problem. When running the flowgraph, we get the following error: File /usr/local/lib/python2.7/dist-packages/sq/sq_swig.py, line 679, in make return _sq_swig.usrp_pa_control_make(*args, **kwargs) TypeError: in method 'usrp_pa_control_make', argument 1 of type 'gr::uhd::usrp_sink::sptr' When setting up a FG, the pa-control block accepts a reference to the downstream UHD sink. I have attached the specific block source. Thanks! Very Respectfully, Dan CaJacob It's probably the difference between a gr::uhd::usrp_sink and a gr::uhd::usrp_sink_impl. A safer way to handle this might be to use the new(ish) block_registry that we implemented to handle the message passing infrastructure. You can get a basic_block_sptr from global_block_registry.block_lookup; you should then be able to cast this to a usrp_sink_sptr. You'll pass it a PMT symbol containing the alias name of the UHD sink itself. Take a look at basic_block.cc for a look at how the global_block_registry is used. I've not done exactly this before, so it might not go completely smoothly, and I'd be interested in your experience. In general, this sounds like something more appropriately implemented as a message, though, but that would mean changing the gr-uhd code. Having a message handler for the GPIO stuff would probably be useful if done generically enough. Tom On Mon, Jan 6, 2014 at 11:25 AM, Dan CaJacob dan.caja...@gmail.com wrote: Thanks Tom, No problem. I hope you and the rest of the community had relaxing holidays! I hope to have some better info for you by tomorrow, if not before. Another way to look at this is: does it make sense to keep doing things this way? Is there a better way to reference the downstream USRP and toggle the IO? I could imagine an async message stream or specific stream-tags, but both would probably require changes to the actual UHD sinks. I'm not sure our use case is generic enough to warrant that. Very Respectfully, Dan CaJacob On Mon, Jan 6, 2014 at 10:46 AM, Tom Rondeau t...@trondeau.com wrote: On Sat, Dec 21, 2013 at 6:29 PM, Dan CaJacob dan.caja...@gmail.com wrote: We are upgrading some of our custom blocks for 3.7 and have run into a snag. Our 3.6 era blocks included one that PTTed an external amplifier based on stream tags. The IO was generated from the extra GPIO available on the WBX. One of the inputs to the block was a reference to the USRP sink downstream in the FG. The block then calls the necessary methods to enable and disable the GPIO. Everything worked nicely, but when we ported our blocks to 3.87, there seemed to be a problem with this. I did not personally do the testing, so I don't have the exact error, but I can probably re-create it given some time. I started the porting of the blocks myself and did notice that getting the pointer to a USRP object had changed. But the blocks built without error when updated appropriately. Is there anything in principle that would prevent this from working in 3.7? Or, is there a better approach to controlling the WBX GPIO based on stream tags that we should consider? I apologize for the vagueness on the actual error. I'll try to reproduce it myself in the meantime. I can
Re: [Discuss-gnuradio] Passing a USRP pointer
Hey Tom, We've been working on this, but we ran into a snag. We couldn't seem to look up the usrp sink block's key. Other blocks could be looked up with the keys we expected, just not the uhd sink. I just un-commented a print statement in block_registry.cc so that we could see how each block actually gets registered, built it and ran a simple flowgraph. The flowgraph is just a signal source - throttle - uhd sink. Here's the output: register_symbolic_name: top_block0 register_symbolic_name: gr uhd usrp sink0 register_symbolic_name: throttle0 register_symbolic_name: sig_source_c0 The UHD sink block gets an unexpected gr pre-pended and the underscores are replaced with spaces. We are going to attempt our OOT blocks with this in mind, but I thought I'd give you a heads up on this behavior. Thanks! Very Respectfully, Dan CaJacob On Tue, Jan 7, 2014 at 2:18 PM, Tom Rondeau t...@trondeau.com wrote: On Tue, Jan 7, 2014 at 12:21 PM, Dan CaJacob dan.caja...@gmail.com wrote: Hey Tom, Here's some more detail into our problem. When running the flowgraph, we get the following error: File /usr/local/lib/python2.7/dist-packages/sq/sq_swig.py, line 679, in make return _sq_swig.usrp_pa_control_make(*args, **kwargs) TypeError: in method 'usrp_pa_control_make', argument 1 of type 'gr::uhd::usrp_sink::sptr' When setting up a FG, the pa-control block accepts a reference to the downstream UHD sink. I have attached the specific block source. Thanks! Very Respectfully, Dan CaJacob It's probably the difference between a gr::uhd::usrp_sink and a gr::uhd::usrp_sink_impl. A safer way to handle this might be to use the new(ish) block_registry that we implemented to handle the message passing infrastructure. You can get a basic_block_sptr from global_block_registry.block_lookup; you should then be able to cast this to a usrp_sink_sptr. You'll pass it a PMT symbol containing the alias name of the UHD sink itself. Take a look at basic_block.cc for a look at how the global_block_registry is used. I've not done exactly this before, so it might not go completely smoothly, and I'd be interested in your experience. In general, this sounds like something more appropriately implemented as a message, though, but that would mean changing the gr-uhd code. Having a message handler for the GPIO stuff would probably be useful if done generically enough. Tom On Mon, Jan 6, 2014 at 11:25 AM, Dan CaJacob dan.caja...@gmail.com wrote: Thanks Tom, No problem. I hope you and the rest of the community had relaxing holidays! I hope to have some better info for you by tomorrow, if not before. Another way to look at this is: does it make sense to keep doing things this way? Is there a better way to reference the downstream USRP and toggle the IO? I could imagine an async message stream or specific stream-tags, but both would probably require changes to the actual UHD sinks. I'm not sure our use case is generic enough to warrant that. Very Respectfully, Dan CaJacob On Mon, Jan 6, 2014 at 10:46 AM, Tom Rondeau t...@trondeau.com wrote: On Sat, Dec 21, 2013 at 6:29 PM, Dan CaJacob dan.caja...@gmail.com wrote: We are upgrading some of our custom blocks for 3.7 and have run into a snag. Our 3.6 era blocks included one that PTTed an external amplifier based on stream tags. The IO was generated from the extra GPIO available on the WBX. One of the inputs to the block was a reference to the USRP sink downstream in the FG. The block then calls the necessary methods to enable and disable the GPIO. Everything worked nicely, but when we ported our blocks to 3.87, there seemed to be a problem with this. I did not personally do the testing, so I don't have the exact error, but I can probably re-create it given some time. I started the porting of the blocks myself and did notice that getting the pointer to a USRP object had changed. But the blocks built without error when updated appropriately. Is there anything in principle that would prevent this from working in 3.7? Or, is there a better approach to controlling the WBX GPIO based on stream tags that we should consider? I apologize for the vagueness on the actual error. I'll try to reproduce it myself in the meantime. I can probably post the code for the PTT-controlling block if that would be any help. Very Respectfully, Dan CaJacob Hi Dan, Sorry for the silence. Partly due to the holidays, partly due to me not having a good answer for you. Most likely, your problem is related in some way to the public/private implementations that we are enforcing in 3.7 now. If you have more information or have figured this out, let us know and we can see where we need to go from here. Tom ___
Re: [Discuss-gnuradio] Passing a USRP pointer
On Tue, Jan 7, 2014 at 12:21 PM, Dan CaJacob dan.caja...@gmail.com wrote: Hey Tom, Here's some more detail into our problem. When running the flowgraph, we get the following error: File /usr/local/lib/python2.7/dist-packages/sq/sq_swig.py, line 679, in make return _sq_swig.usrp_pa_control_make(*args, **kwargs) TypeError: in method 'usrp_pa_control_make', argument 1 of type 'gr::uhd::usrp_sink::sptr' When setting up a FG, the pa-control block accepts a reference to the downstream UHD sink. I have attached the specific block source. Thanks! Very Respectfully, Dan CaJacob It's probably the difference between a gr::uhd::usrp_sink and a gr::uhd::usrp_sink_impl. A safer way to handle this might be to use the new(ish) block_registry that we implemented to handle the message passing infrastructure. You can get a basic_block_sptr from global_block_registry.block_lookup; you should then be able to cast this to a usrp_sink_sptr. You'll pass it a PMT symbol containing the alias name of the UHD sink itself. Take a look at basic_block.cc for a look at how the global_block_registry is used. I've not done exactly this before, so it might not go completely smoothly, and I'd be interested in your experience. In general, this sounds like something more appropriately implemented as a message, though, but that would mean changing the gr-uhd code. Having a message handler for the GPIO stuff would probably be useful if done generically enough. Tom On Mon, Jan 6, 2014 at 11:25 AM, Dan CaJacob dan.caja...@gmail.com wrote: Thanks Tom, No problem. I hope you and the rest of the community had relaxing holidays! I hope to have some better info for you by tomorrow, if not before. Another way to look at this is: does it make sense to keep doing things this way? Is there a better way to reference the downstream USRP and toggle the IO? I could imagine an async message stream or specific stream-tags, but both would probably require changes to the actual UHD sinks. I'm not sure our use case is generic enough to warrant that. Very Respectfully, Dan CaJacob On Mon, Jan 6, 2014 at 10:46 AM, Tom Rondeau t...@trondeau.com wrote: On Sat, Dec 21, 2013 at 6:29 PM, Dan CaJacob dan.caja...@gmail.com wrote: We are upgrading some of our custom blocks for 3.7 and have run into a snag. Our 3.6 era blocks included one that PTTed an external amplifier based on stream tags. The IO was generated from the extra GPIO available on the WBX. One of the inputs to the block was a reference to the USRP sink downstream in the FG. The block then calls the necessary methods to enable and disable the GPIO. Everything worked nicely, but when we ported our blocks to 3.87, there seemed to be a problem with this. I did not personally do the testing, so I don't have the exact error, but I can probably re-create it given some time. I started the porting of the blocks myself and did notice that getting the pointer to a USRP object had changed. But the blocks built without error when updated appropriately. Is there anything in principle that would prevent this from working in 3.7? Or, is there a better approach to controlling the WBX GPIO based on stream tags that we should consider? I apologize for the vagueness on the actual error. I'll try to reproduce it myself in the meantime. I can probably post the code for the PTT-controlling block if that would be any help. Very Respectfully, Dan CaJacob Hi Dan, Sorry for the silence. Partly due to the holidays, partly due to me not having a good answer for you. Most likely, your problem is related in some way to the public/private implementations that we are enforcing in 3.7 now. If you have more information or have figured this out, let us know and we can see where we need to go from here. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Passing a USRP pointer
Thanks Tom, No problem. I hope you and the rest of the community had relaxing holidays! I hope to have some better info for you by tomorrow, if not before. Another way to look at this is: does it make sense to keep doing things this way? Is there a better way to reference the downstream USRP and toggle the IO? I could imagine an async message stream or specific stream-tags, but both would probably require changes to the actual UHD sinks. I'm not sure our use case is generic enough to warrant that. Very Respectfully, Dan CaJacob On Mon, Jan 6, 2014 at 10:46 AM, Tom Rondeau t...@trondeau.com wrote: On Sat, Dec 21, 2013 at 6:29 PM, Dan CaJacob dan.caja...@gmail.com wrote: We are upgrading some of our custom blocks for 3.7 and have run into a snag. Our 3.6 era blocks included one that PTTed an external amplifier based on stream tags. The IO was generated from the extra GPIO available on the WBX. One of the inputs to the block was a reference to the USRP sink downstream in the FG. The block then calls the necessary methods to enable and disable the GPIO. Everything worked nicely, but when we ported our blocks to 3.87, there seemed to be a problem with this. I did not personally do the testing, so I don't have the exact error, but I can probably re-create it given some time. I started the porting of the blocks myself and did notice that getting the pointer to a USRP object had changed. But the blocks built without error when updated appropriately. Is there anything in principle that would prevent this from working in 3.7? Or, is there a better approach to controlling the WBX GPIO based on stream tags that we should consider? I apologize for the vagueness on the actual error. I'll try to reproduce it myself in the meantime. I can probably post the code for the PTT-controlling block if that would be any help. Very Respectfully, Dan CaJacob Hi Dan, Sorry for the silence. Partly due to the holidays, partly due to me not having a good answer for you. Most likely, your problem is related in some way to the public/private implementations that we are enforcing in 3.7 now. If you have more information or have figured this out, let us know and we can see where we need to go from here. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
