Re: FLL Band-Edge
I think the general idea is that some signals have no carrier that a PLL could lock onto. The FLL Band-Edge centers a signal using the shape of a specific signal (the matched filter being used). On Thu, Jan 14, 2021 at 6:55 PM Kristoff wrote: > Hi all, > > > I have been reading some more on PSK demodulation. > > > One of the PSK signals I can easily pick and and is available 24h/day is > the telemetry signal on QO100. > I found a flowgraph from Daniel Estevez that decodes the QO100 > telemetry, so I started examining how it works. > > In that flowgraph (which for some reason I do not seams to find any > more), the first block in the flow (i.e. right after downconverting and > a AGC) is a "FLL_Band-edge" block. > > > Can somebody explain what exactly this block does? > > I researching this, I found that it seams to shift the received signal > slightly up in frequency (at least, that is what it did in my tests). > > I tried reading the documentation, which kinds-of explain how it does > work, .. but not what it does and why it is there. > Can somebody explain the purpose of a "FLL with band-edge filter" block? > > > > Thx :-) > > 73 > kristoff - ON1ARF > > > >
Re: (gnuradio3.8) module 'gnuradio.blocks' has no attribute 'message_sink'
Hi Criss,
Unfortunately it seems there is no easy solution to this problem. But at
least I can go back to Ubuntu18 which installs gnuradio 3.7 and I can
still use my old codes.
Regards,
Ting Wu
On 2021/01/15 1:49, Criss Swaim wrote:
Hi Ting:
I have been working on this same issue for a couple of day and have
not found a solution. Did you find a solution to the missing
"message_sink"?
Criss Swaim
csw...@tpginc.net
cell: 505.301.5701
On 1/6/2021 8:46 PM, Ting Wu wrote:
Hi!
I recently upgraded to gnuradio 3.8 and my old code threw the
following error:
module 'gnuradio.blocks' has no attribute 'message_sink'
Is the 'message_sink' has been deprecated in the recent version of
gnuradio? If so, what should I use now for the message source and
sink? I really do not want to rewrite all the codes, so I would be
really grateful if there is a simple way to make the following code
work with the recent version of gnuradio. The code simply gets data
stream from a USRP N200 (LFRX daughterboard).
=
class my_block(gr.top_block):
def __init__(self):
gr.top_block.__init__(self)
self.source = uhd.usrp_source(device_addr="",
stream_args=uhd.stream_args('sc16', 'sc16', args="scalar=1024"))
self.source.set_samp_rate(samp_rate)
self.source.set_gain(gain)
self.source.set_center_freq(0)
self.queue = gr.msg_queue()
self.sink = blocks.message_sink(gr.sizeof_short*2,
self.queue, False) #This line throws the error
self.connect(self.source, self.sink)
===
Thanks in advance!
Ting Wu
FLL Band-Edge
Hi all, I have been reading some more on PSK demodulation. One of the PSK signals I can easily pick and and is available 24h/day is the telemetry signal on QO100. I found a flowgraph from Daniel Estevez that decodes the QO100 telemetry, so I started examining how it works. In that flowgraph (which for some reason I do not seams to find any more), the first block in the flow (i.e. right after downconverting and a AGC) is a "FLL_Band-edge" block. Can somebody explain what exactly this block does? I researching this, I found that it seams to shift the received signal slightly up in frequency (at least, that is what it did in my tests). I tried reading the documentation, which kinds-of explain how it does work, .. but not what it does and why it is there. Can somebody explain the purpose of a "FLL with band-edge filter" block? Thx :-) 73 kristoff - ON1ARF
Re: 3.9 Setup for OOT development
On 1/14/21 10:52 AM, Gavin Jacobs wrote: Cinaed (or anyone who has used gr_modtool in v3.9) 1. So, I can ignore mpir. Is this a bug in gr_modtool? i.e. why is it trying to find it if it isn't needed? You don't have MPIR - you have MPLIB instead. It's not a bug. 1. Per your suggestion, I installed python3-pygccxml and that eliminated that error. Thanks! 2. In my new module, the file: lib/CMakeLists.txt was created by gr_modtool, I didn't have any say in that file. I just barely know how to invoke cmake, let alone how to debug it. Does the output I can't help you with the gr_modtool. It depends on the inputs you provide and your requirements. And I've never used gr_modtool. -- CInaed Date: Wed, 13 Jan 2021 16:50:53 -0800 From: Cinaed Simson To: discuss-gnuradio@gnu.org Subject: Re: 3.9 Setup for OOT development Message-ID: <8a5878a2-b0d8-1e43-9836-ea58da17c...@gmail.com> Content-Type: text/plain; charset="windows-1252"; Format="flowed" Hi Gavin - you can probably ignore the first error - there are 2 possible entries for multiple precision libraries. And I believe you need pygccxml for OOT development in 3.9 Try apt install python3-pygccxml you can always uninstall it. Also it appears the you may be trying to use an old nonexistent path in lib/CMakeLists.txtfile? -- Cinaed On 1/13/21 12:32 PM, Gavin Jacobs wrote: > CMake Error in lib/CMakeLists.txt: > Imported target "gnuradio::gnuradio-runtime" includes non-existent path > "/include" > in its INTERFACE_INCLUDE_DIRECTORIES. Possible reasons include:
Re: 3.9 Setup for OOT development
Hi Gavin, On 14.01.21 19:52, Gavin Jacobs wrote: > Cinaed (or anyone who has used gr_modtool in v3.9) > > 1. So, I can ignore mpir. Is this a bug in gr_modtool? No! > i.e. why is it > trying to find it if it isn't needed? MPIR is one of two options for a specific functionality (GMP being the other option). > 2. Per your suggestion, I installed python3-pygccxml and that > eliminated that error. Thanks! Glad to hear this works out so well! Best regards, Marcus
Re: Problem initializing parameters in Gnuradio Python Block?
Hi Tim, Thank you very much! I followed your suggestions and have it working, I put v.self in the def __init(self, start = True) method (which means I can initialize all my vector parameters at start-of-program by placing them in the def __init() method and retrieve initial values in the work() function) To retrieve initialized parameters once in the work() method I did: global v # my one trivial param here if self.start == True v = self.v self.start = False This works wonderfully and I am able to change the values of v at runtime. Thanks again for the help! George On Thu, Jan 14, 2021 at 11:07 AM Tim Huggins wrote: > George, > > What is happening is that when you try to change the variable Python is > interpreting that as a local variable and has no value yet for the equation > you are attempting. I believe could use: > > global v > v[0] += v[0] > > (Research the Python global keyword) > > However, in the GNURadio universe I really think you may be better off > using self.v instead. > > Tim > > On Thursday, January 14, 2021, 11:42:46 AM EST, George Edwards < > gedwards@gmail.com> wrote: > > > Hell Tim and Jeff, > > Problem, so when I make v global in my_init() method and use it is the > work() method, it works good if I do not try to change the values in the > vector v, let's say v came down as v = np.array([1.0 , 1.0 , 1.0]). If I > try to change the values say v[0] += v[0], etc. the program breaks with > the message local variable v changes before assignment. I thought it was > global and already assigned. > > Thanks for your help. > > George > > > On Thu, Jan 14, 2021 at 9:17 AM George Edwards > wrote: > > Hi Tim and Jeff, > > Thanks for your help and insights. Being new to Python, I was looking at > some Python videos and found my solution, I will make the numpy parameter > vectors in the my_init() method "global" and that should solve the problem. > > Thank you! > > Regards, > George > > On Thu, Jan 14, 2021 at 9:57 AM Tim Huggins > wrote: > > George, > > "My understanding is the self.x, etc. is used to initialize param > arguments in the def __init__() method and in my case, the only argument in > this method is start" > > > This is not correct, you can add a self.v in there so it looks like: > > def __init__(self, start = True): # only default arguments here > gr.sync_block.__init__( > self, > name='text', # will show up in GRC > in_sig=[()], > out_sig=[()] > ) > # if an attribute with the same name as a parameter is found, > # a callback is registered (properties work, too). > self.start = start > self.v = self.my_init() #or whatever you want the initial value > to be > > Tim > > > On Thursday, January 14, 2021, 10:38:36 AM EST, George Edwards < > gedwards@gmail.com> wrote: > > > Hi Jeff, > > So I am new to Python programming, so some of the nuances I am not up on > yet. My understanding is the self.x, etc. is used to initialize param > arguments in the def __init__() method and in my case, the only argument in > this method is start, there is no v for me to use self.v = v. v is used the > work() and my_init() methods. At program startup work() calls my_init() > method to get the initial values for the numpy array v (my_init() function > will be called once only at startup when self.start is True). After > initialization and v is passed back to the work(), the values in the numpy > array v inside work will change on a sample to sample computation basis. My > problem is how do I assign v its initial seed value at start up. If my > program was simple with only one parameter v, I would initialize it inside > the work() method, however, I have a bunch of other vector variables to > initialize which is why I want to initialize all parameters inside a > my_init() method that work() calls at startup. > > Thanks for the help. > > George > > On Thu, Jan 14, 2021 at 8:14 AM Jeff Long wrote: > > You are already initializing self.start in exactly the same way you should > be initializing self.v, right? > > On Wed, Jan 13, 2021 at 10:46 PM George Edwards > wrote: > > Hi Jeff, > > Thanks for your answer. You are right, it crashes on the second call. > > So how do I write the program to initialize a bunch of vectors in a > "method strictly for initialization" when it first starts running? If this > cannot be done, then I guess the only solution is to initialize them in the > work() method even though it would make the work() method bulky? > > Thanks again for your help. > > Regards, > George > > On Wed, Jan 13, 2021 at 8:12 PM Jeff Long wrote: > > 'v' is a local variable in work(). It is probably crashing on the second > call, where my_init() is not called, and thus there is no 'v'. > > On Wed, Jan 13, 2021 at 7:38 PM George Edwards > wrote: > > Hello, > > I am using a Gnuradio Python Block in my GRC signal processing and am > having problems initializing my
Re: 3.9 Setup for OOT development
Cinaed (or anyone who has used gr_modtool in v3.9) 1. So, I can ignore mpir. Is this a bug in gr_modtool? i.e. why is it trying to find it if it isn't needed? 2. Per your suggestion, I installed python3-pygccxml and that eliminated that error. Thanks! 3. In my new module, the file: lib/CMakeLists.txt was created by gr_modtool, I didn't have any say in that file. I just barely know how to invoke cmake, let alone how to debug it. Does the output from gr_modtool v3.9 need to be edited? If so, can someone help me to identify what needs to be fixed? Gavin Date: Wed, 13 Jan 2021 16:50:53 -0800 From: Cinaed Simson To: discuss-gnuradio@gnu.org Subject: Re: 3.9 Setup for OOT development Message-ID: <8a5878a2-b0d8-1e43-9836-ea58da17c...@gmail.com> Content-Type: text/plain; charset="windows-1252"; Format="flowed" Hi Gavin - you can probably ignore the first error - there are 2 possible entries for multiple precision libraries. And I believe you need pygccxml for OOT development in 3.9 Try apt install python3-pygccxml you can always uninstall it. Also it appears the you may be trying to use an old nonexistent path in lib/CMakeLists.txtfile? -- Cinaed On 1/13/21 12:32 PM, Gavin Jacobs wrote: > CMake Error in lib/CMakeLists.txt: > Imported target "gnuradio::gnuradio-runtime" includes non-existent path > "/include" > in its INTERFACE_INCLUDE_DIRECTORIES. Possible reasons include:
Re: Problem initializing parameters in Gnuradio Python Block?
George, What is happening is that when you try to change the variable Python is interpreting that as a local variable and has no value yet for the equation you are attempting. I believe could use: global vv[0] += v[0] (Research the Python global keyword) However, in the GNURadio universe I really think you may be better off using self.v instead. Tim On Thursday, January 14, 2021, 11:42:46 AM EST, George Edwards wrote: Hell Tim and Jeff, Problem, so when I make v global in my_init() method and use it is the work() method, it works good if I do not try to change the values in the vector v, let's say v came down as v = np.array([1.0 , 1.0 , 1.0]). If I try to change the values say v[0] += v[0], etc. the program breaks with the message local variable v changes before assignment. I thought it was global and already assigned. Thanks for your help. George On Thu, Jan 14, 2021 at 9:17 AM George Edwards wrote: Hi Tim and Jeff, Thanks for your help and insights. Being new to Python, I was looking at some Python videos and found my solution, I will make the numpy parameter vectors in the my_init() method "global" and that should solve the problem. Thank you! Regards,George On Thu, Jan 14, 2021 at 9:57 AM Tim Huggins wrote: George, "My understanding is the self.x, etc. is used to initialize param arguments in the def __init__() method and in my case, the only argument in this method is start" This is not correct, you can add a self.v in there so it looks like: def __init__(self, start = True): # only default arguments here gr.sync_block.__init__( self, name='text', # will show up in GRC in_sig=[()], out_sig=[()] ) # if an attribute with the same name as a parameter is found, # a callback is registered (properties work, too). self.start = start self.v = self.my_init() #or whatever you want the initial value to be Tim On Thursday, January 14, 2021, 10:38:36 AM EST, George Edwards wrote: Hi Jeff, So I am new to Python programming, so some of the nuances I am not up on yet. My understanding is the self.x, etc. is used to initialize param arguments in the def __init__() method and in my case, the only argument in this method is start, there is no v for me to use self.v = v. v is used the work() and my_init() methods. At program startup work() calls my_init() method to get the initial values for the numpy array v (my_init() function will be called once only at startup when self.start is True). After initialization and v is passed back to the work(), the values in the numpy array v inside work will change on a sample to sample computation basis. My problem is how do I assign v its initial seed value at start up. If my program was simple with only one parameter v, I would initialize it inside the work() method, however, I have a bunch of other vector variables to initialize which is why I want to initialize all parameters inside a my_init() method that work() calls at startup. Thanks for the help. George On Thu, Jan 14, 2021 at 8:14 AM Jeff Long wrote: You are already initializing self.start in exactly the same way you should be initializing self.v, right? On Wed, Jan 13, 2021 at 10:46 PM George Edwards wrote: Hi Jeff, Thanks for your answer. You are right, it crashes on the second call. So how do I write the program to initialize a bunch of vectors in a "method strictly for initialization" when it first starts running? If this cannot be done, then I guess the only solution is to initialize them in the work() method even though it would make the work() method bulky? Thanks again for your help. Regards,George On Wed, Jan 13, 2021 at 8:12 PM Jeff Long wrote: 'v' is a local variable in work(). It is probably crashing on the second call, where my_init() is not called, and thus there is no 'v'. On Wed, Jan 13, 2021 at 7:38 PM George Edwards wrote: Hello, I am using a Gnuradio Python Block in my GRC signal processing and am having problems initializing my parameters. My system has a number of vector parameters to be initialized at startup. I will provide the gist of my goal in a scaled down version of my work. 1. In the def __init__(self, start = True) method, "start" is the parameter that will be used in the program to run the initialization process and is set as follows: self.start = start 2. In the work(self, input_items, output_items) method, I have the following at the start of the method: if self.start == True: v = self.my_init() # go initialize all vectors output_items[0][:] = in0*v[0] + in1*v[1] + in2*v[2] #computation using v # with 3-inputs to the block 3. In the my_init(self) method I have: self.start = False # set start to False v = np.array([1., 2., 3.]) #hypothetical to make this simple return v
Re: Problem initializing parameters in Gnuradio Python Block?
Hell Tim and Jeff, Problem, so when I make v global in my_init() method and use it is the work() method, it works good if I do not try to change the values in the vector v, let's say v came down as v = np.array([1.0 , 1.0 , 1.0]). If I try to change the values say v[0] += v[0], etc. the program breaks with the message local variable v changes before assignment. I thought it was global and already assigned. Thanks for your help. George On Thu, Jan 14, 2021 at 9:17 AM George Edwards wrote: > Hi Tim and Jeff, > > Thanks for your help and insights. Being new to Python, I was looking at > some Python videos and found my solution, I will make the numpy parameter > vectors in the my_init() method "global" and that should solve the problem. > > Thank you! > > Regards, > George > > On Thu, Jan 14, 2021 at 9:57 AM Tim Huggins > wrote: > >> George, >> >> "My understanding is the self.x, etc. is used to initialize param >> arguments in the def __init__() method and in my case, the only argument in >> this method is start" >> >> >> This is not correct, you can add a self.v in there so it looks like: >> >> def __init__(self, start = True): # only default arguments here >> gr.sync_block.__init__( >> self, >> name='text', # will show up in GRC >> in_sig=[()], >> out_sig=[()] >> ) >> # if an attribute with the same name as a parameter is found, >> # a callback is registered (properties work, too). >> self.start = start >> self.v = self.my_init() #or whatever you want the initial value >> to be >> >> Tim >> >> >> On Thursday, January 14, 2021, 10:38:36 AM EST, George Edwards < >> gedwards@gmail.com> wrote: >> >> >> Hi Jeff, >> >> So I am new to Python programming, so some of the nuances I am not up on >> yet. My understanding is the self.x, etc. is used to initialize param >> arguments in the def __init__() method and in my case, the only argument in >> this method is start, there is no v for me to use self.v = v. v is used the >> work() and my_init() methods. At program startup work() calls my_init() >> method to get the initial values for the numpy array v (my_init() function >> will be called once only at startup when self.start is True). After >> initialization and v is passed back to the work(), the values in the numpy >> array v inside work will change on a sample to sample computation basis. My >> problem is how do I assign v its initial seed value at start up. If my >> program was simple with only one parameter v, I would initialize it inside >> the work() method, however, I have a bunch of other vector variables to >> initialize which is why I want to initialize all parameters inside a >> my_init() method that work() calls at startup. >> >> Thanks for the help. >> >> George >> >> On Thu, Jan 14, 2021 at 8:14 AM Jeff Long wrote: >> >> You are already initializing self.start in exactly the same way you >> should be initializing self.v, right? >> >> On Wed, Jan 13, 2021 at 10:46 PM George Edwards >> wrote: >> >> Hi Jeff, >> >> Thanks for your answer. You are right, it crashes on the second call. >> >> So how do I write the program to initialize a bunch of vectors in a >> "method strictly for initialization" when it first starts running? If this >> cannot be done, then I guess the only solution is to initialize them in the >> work() method even though it would make the work() method bulky? >> >> Thanks again for your help. >> >> Regards, >> George >> >> On Wed, Jan 13, 2021 at 8:12 PM Jeff Long wrote: >> >> 'v' is a local variable in work(). It is probably crashing on the second >> call, where my_init() is not called, and thus there is no 'v'. >> >> On Wed, Jan 13, 2021 at 7:38 PM George Edwards >> wrote: >> >> Hello, >> >> I am using a Gnuradio Python Block in my GRC signal processing and am >> having problems initializing my parameters. My system has a number of >> vector parameters to be initialized at startup. I will provide the gist of >> my goal in a scaled down version of my work. >> 1. In the def __init__(self, start = True) method, "start" is the >> parameter that will be used in the program to run the initialization >> process and is set as follows: >> self.start = start >> 2. In the work(self, input_items, output_items) method, I have the >> following at the start of the method: >> if self.start == True: >> v = self.my_init()# go initialize all vectors >> >> output_items[0][:] = in0*v[0] + in1*v[1] + in2*v[2] >> #computation using v >> # with 3-inputs to >> the block >> >> 3. In the my_init(self) method I have: >> self.start = False# set start to False >> v = np.array([1., 2., 3.]) #hypothetical to make this simple >> return v >> >> When I run the GRC model, it tells me that "v" is referenced before >> assignment. I am confused because I thought that
Re: (gnuradio3.8) module 'gnuradio.blocks' has no attribute 'message_sink'
Hi
Ting:
I have
been working on this same issue for a couple of day and have
not found a solution. Did you find a solution to the missing
"message_sink"?
Criss Swaim
csw...@tpginc.net
cell: 505.301.5701
On 1/6/2021 8:46 PM, Ting Wu wrote:
Hi!
I recently upgraded to gnuradio 3.8 and my old code threw the
following error:
module 'gnuradio.blocks' has no attribute 'message_sink'
Is the 'message_sink' has been deprecated in the recent version of
gnuradio? If so, what should I use now for the message source and
sink? I really do not want to rewrite all the codes, so I would be
really grateful if there is a simple way to make the following
code work with the recent version of gnuradio. The code simply
gets data stream from a USRP N200 (LFRX daughterboard).
=
class my_block(gr.top_block):
def __init__(self):
gr.top_block.__init__(self)
self.source = uhd.usrp_source(device_addr="",
stream_args=uhd.stream_args('sc16', 'sc16', args="scalar=1024"))
self.source.set_samp_rate(samp_rate)
self.source.set_gain(gain)
self.source.set_center_freq(0)
self.queue = gr.msg_queue()
self.sink = blocks.message_sink(gr.sizeof_short*2,
self.queue, False) #This line throws the error
self.connect(self.source, self.sink)
===
Thanks in advance!
Ting Wu
Re: Stop making unneeded improvements
On 1/13/21 10:13 AM, Marcus D. Leech wrote: On 01/12/2021 02:51 PM, Lamar Owen wrote: I'm trying to debug and patch the UHD stack for USRP1 with DBS-RX daughterboard; it just quit working, and while I've reported to the UHD list no action has been taken to fix the regression. I was able to reproduce the regression issue with DBS-RX on my own ancient USRP1 hardware, and it has been reported. But I don't know how much engineering bandwidth will be devoted to fixing it. The regression goes back a few UHD release versions--I didn't go all the way "back in time" to figure out where it happened, but it isn't just with the latest release :( There's another module that had a similar problem, let's see, UHD Github Issue #304. I filed my issue as issue #394. It seems to be a similar issue with a simila construct; my C++ skills aren't keen enough to fix it myself, because the patch that fixed #304 was not obvious to me. But I'm not very experienced with C++ (regular C, some, Python a bit more, Z80 assembly language a whole lot (fat lot of good that language will do for me, right? :-) )). Someone who knows the code could probably fix it in less than an hour. Given enough time I can learn what the difference in the RFX code was and apply a similar patch to the DBS-RX code, just haven't had enough time to dig in to it yet; I figure it will take me, since I'll have to do a whole lot of reading to understand the constructs in this code first, four to eight hours. Just hasn't gotten back to the top of the pile yet. Anyway, thanks for confirm my issue isn't local to me, by the way.
Re: Problem initializing parameters in Gnuradio Python Block?
Hi Tim and Jeff, Thanks for your help and insights. Being new to Python, I was looking at some Python videos and found my solution, I will make the numpy parameter vectors in the my_init() method "global" and that should solve the problem. Thank you! Regards, George On Thu, Jan 14, 2021 at 9:57 AM Tim Huggins wrote: > George, > > "My understanding is the self.x, etc. is used to initialize param > arguments in the def __init__() method and in my case, the only argument in > this method is start" > > > This is not correct, you can add a self.v in there so it looks like: > > def __init__(self, start = True): # only default arguments here > gr.sync_block.__init__( > self, > name='text', # will show up in GRC > in_sig=[()], > out_sig=[()] > ) > # if an attribute with the same name as a parameter is found, > # a callback is registered (properties work, too). > self.start = start > self.v = self.my_init() #or whatever you want the initial value > to be > > Tim > > > On Thursday, January 14, 2021, 10:38:36 AM EST, George Edwards < > gedwards@gmail.com> wrote: > > > Hi Jeff, > > So I am new to Python programming, so some of the nuances I am not up on > yet. My understanding is the self.x, etc. is used to initialize param > arguments in the def __init__() method and in my case, the only argument in > this method is start, there is no v for me to use self.v = v. v is used the > work() and my_init() methods. At program startup work() calls my_init() > method to get the initial values for the numpy array v (my_init() function > will be called once only at startup when self.start is True). After > initialization and v is passed back to the work(), the values in the numpy > array v inside work will change on a sample to sample computation basis. My > problem is how do I assign v its initial seed value at start up. If my > program was simple with only one parameter v, I would initialize it inside > the work() method, however, I have a bunch of other vector variables to > initialize which is why I want to initialize all parameters inside a > my_init() method that work() calls at startup. > > Thanks for the help. > > George > > On Thu, Jan 14, 2021 at 8:14 AM Jeff Long wrote: > > You are already initializing self.start in exactly the same way you should > be initializing self.v, right? > > On Wed, Jan 13, 2021 at 10:46 PM George Edwards > wrote: > > Hi Jeff, > > Thanks for your answer. You are right, it crashes on the second call. > > So how do I write the program to initialize a bunch of vectors in a > "method strictly for initialization" when it first starts running? If this > cannot be done, then I guess the only solution is to initialize them in the > work() method even though it would make the work() method bulky? > > Thanks again for your help. > > Regards, > George > > On Wed, Jan 13, 2021 at 8:12 PM Jeff Long wrote: > > 'v' is a local variable in work(). It is probably crashing on the second > call, where my_init() is not called, and thus there is no 'v'. > > On Wed, Jan 13, 2021 at 7:38 PM George Edwards > wrote: > > Hello, > > I am using a Gnuradio Python Block in my GRC signal processing and am > having problems initializing my parameters. My system has a number of > vector parameters to be initialized at startup. I will provide the gist of > my goal in a scaled down version of my work. > 1. In the def __init__(self, start = True) method, "start" is the > parameter that will be used in the program to run the initialization > process and is set as follows: > self.start = start > 2. In the work(self, input_items, output_items) method, I have the > following at the start of the method: > if self.start == True: > v = self.my_init()# go initialize all vectors > > output_items[0][:] = in0*v[0] + in1*v[1] + in2*v[2] #computation > using v > # with 3-inputs to > the block > > 3. In the my_init(self) method I have: > self.start = False# set start to False > v = np.array([1., 2., 3.]) #hypothetical to make this simple > return v > > When I run the GRC model, it tells me that "v" is referenced before > assignment. I am confused because I thought that the method my_init() would > have been called before the computation and would return the values for > "v". On the other hand if I do the assignment in the work(...) method as v > = np.array([1., 2., 3.]), it works perfectly. > Question: Why was the my_init() method not called properly to get the > values for the numpy array v? > > Thanks for the help! > > Regards, > George > >
Re: Problem initializing parameters in Gnuradio Python Block?
Hi Jeff, So I am new to Python programming, so some of the nuances I am not up on yet. My understanding is the self.x, etc. is used to initialize param arguments in the def __init__() method and in my case, the only argument in this method is start, there is no v for me to use self.v = v. v is used the work() and my_init() methods. At program startup work() calls my_init() method to get the initial values for the numpy array v (my_init() function will be called once only at startup when self.start is True). After initialization and v is passed back to the work(), the values in the numpy array v inside work will change on a sample to sample computation basis. My problem is how do I assign v its initial seed value at start up. If my program was simple with only one parameter v, I would initialize it inside the work() method, however, I have a bunch of other vector variables to initialize which is why I want to initialize all parameters inside a my_init() method that work() calls at startup. Thanks for the help. George On Thu, Jan 14, 2021 at 8:14 AM Jeff Long wrote: > You are already initializing self.start in exactly the same way you should > be initializing self.v, right? > > On Wed, Jan 13, 2021 at 10:46 PM George Edwards > wrote: > >> Hi Jeff, >> >> Thanks for your answer. You are right, it crashes on the second call. >> >> So how do I write the program to initialize a bunch of vectors in a >> "method strictly for initialization" when it first starts running? If this >> cannot be done, then I guess the only solution is to initialize them in the >> work() method even though it would make the work() method bulky? >> >> Thanks again for your help. >> >> Regards, >> George >> >> On Wed, Jan 13, 2021 at 8:12 PM Jeff Long wrote: >> >>> 'v' is a local variable in work(). It is probably crashing on the second >>> call, where my_init() is not called, and thus there is no 'v'. >>> >>> On Wed, Jan 13, 2021 at 7:38 PM George Edwards >>> wrote: >>> Hello, I am using a Gnuradio Python Block in my GRC signal processing and am having problems initializing my parameters. My system has a number of vector parameters to be initialized at startup. I will provide the gist of my goal in a scaled down version of my work. 1. In the def __init__(self, start = True) method, "start" is the parameter that will be used in the program to run the initialization process and is set as follows: self.start = start 2. In the work(self, input_items, output_items) method, I have the following at the start of the method: if self.start == True: v = self.my_init()# go initialize all vectors output_items[0][:] = in0*v[0] + in1*v[1] + in2*v[2] #computation using v # with 3-inputs to the block 3. In the my_init(self) method I have: self.start = False# set start to False v = np.array([1., 2., 3.]) #hypothetical to make this simple return v When I run the GRC model, it tells me that "v" is referenced before assignment. I am confused because I thought that the method my_init() would have been called before the computation and would return the values for "v". On the other hand if I do the assignment in the work(...) method as v = np.array([1., 2., 3.]), it works perfectly. Question: Why was the my_init() method not called properly to get the values for the numpy array v? Thanks for the help! Regards, George >>>
Re: Problem initializing parameters in Gnuradio Python Block?
You are already initializing self.start in exactly the same way you should be initializing self.v, right? On Wed, Jan 13, 2021 at 10:46 PM George Edwards wrote: > Hi Jeff, > > Thanks for your answer. You are right, it crashes on the second call. > > So how do I write the program to initialize a bunch of vectors in a > "method strictly for initialization" when it first starts running? If this > cannot be done, then I guess the only solution is to initialize them in the > work() method even though it would make the work() method bulky? > > Thanks again for your help. > > Regards, > George > > On Wed, Jan 13, 2021 at 8:12 PM Jeff Long wrote: > >> 'v' is a local variable in work(). It is probably crashing on the second >> call, where my_init() is not called, and thus there is no 'v'. >> >> On Wed, Jan 13, 2021 at 7:38 PM George Edwards >> wrote: >> >>> Hello, >>> >>> I am using a Gnuradio Python Block in my GRC signal processing and am >>> having problems initializing my parameters. My system has a number of >>> vector parameters to be initialized at startup. I will provide the gist of >>> my goal in a scaled down version of my work. >>> 1. In the def __init__(self, start = True) method, "start" is the >>> parameter that will be used in the program to run the initialization >>> process and is set as follows: >>> self.start = start >>> 2. In the work(self, input_items, output_items) method, I have the >>> following at the start of the method: >>> if self.start == True: >>> v = self.my_init()# go initialize all vectors >>> >>> output_items[0][:] = in0*v[0] + in1*v[1] + in2*v[2] >>> #computation using v >>> # with 3-inputs to >>> the block >>> >>> 3. In the my_init(self) method I have: >>> self.start = False# set start to False >>> v = np.array([1., 2., 3.]) #hypothetical to make this simple >>> return v >>> >>> When I run the GRC model, it tells me that "v" is referenced before >>> assignment. I am confused because I thought that the method my_init() would >>> have been called before the computation and would return the values for >>> "v". On the other hand if I do the assignment in the work(...) method as v >>> = np.array([1., 2., 3.]), it works perfectly. >>> Question: Why was the my_init() method not called properly to get the >>> values for the numpy array v? >>> >>> Thanks for the help! >>> >>> Regards, >>> George >>> >>
