Many of the default blocks in GNU Radio Companion have their Sample Rate parameter set to samp_rate, and as such, when the blocks are added on to the canvas, they immediately take the value of the samp_rate variable (assuming it exists of course).
When creating your own hierarchical block, how can we specify that a parameter references an external/global variable? The Parameter block only accepts values.
There is no proper (unhacky) way to reference a "global variable" in the code.
You can always access the .py of the block and make it read a global variable.
The proper way to do this is to use the parameter block, and put in a variable name as the value. While editing the hierarchical block, the parameter block cannot access any variables. But you can still set the value of a parameter block to that of a variable, and by default it will read a variable on the top level with that variable name.
Say you have a parameter called "my_samp_rate". You can set the value of it to samp_rate (no quotes, not a string, rather the variable name). Inside the block it won't recognize any samp_rate value (because none was set).
HOWEVER when you place the new block inside a flowgraph, its default-value (which can be changed, mind you) would be samp_rate. If there is a variable in the flowgraph with the value of samp_rate, it will read the value and pass it as a parameter to the block. That way you can create a block that has a value that, by default, is bound to a variable on the top level.
The good thing about this approach is that it doesn't force anyone who uses the block to do so by using the variable you suggested. It's the default value, but if you want to bind the value of your parameter to that of a different variable, it's completely configurable.
The way I've done it is to use a Parameter block in the hierarchical block. I give this an ID of, e.g, freq_ratio, type float, default value of 0.5. Whereever I use a block (e.g. a Signal Source) that has a sample rate parameter (which, as you say, commonly defaults to samp_rate), I replace that with a 1.0, and I set the frequency to freq_ratio.
To use the block in a top level flow chart, the hierarchical block's freq_ratio has that default value of 0.5, but here in the top level that can be replaced with 1000.0 / samp_rate. That will have the Signal Source block inside produce me a signal at 1kHz, assuming the top block's samp_rate is used in a real device (e.g. an Audio Out block).
The point is that "sample rate" doesn't really mean anything as such in a GNU radio flowchart, except where it's used by a block that represents something physical (e.g. and Audio Out block, or a real SDR). So one can quite happily work with ratios.
Another way you can do it is to use two parameters in the hierarchical block. The first can be called samp_rate; give it a default value. The second can be called freq; again give it a default value. The Signal Source block in the hierarchical block can then use those two parameters for its sample rate and frequency. In the top level, you replace the default value for the hierachical block's sample rate parameter with samp_rate, and the default value for its frequency with what ever you want (a constant, some other variable, a Qt Range Widget's i.d, etc). The samp_rate you've typed here in the top block will be the top block's sample rate variable.
I've Not Really Answered Your Question Yet
Basically everything above is how it can be done for maximum convenience, but I'm afraid it's not possible to automagically directly use the top block's samp_rate for a block in hierarchical block. That's the answer, I'm afraid.
This makes sense; if you were writing source code, you'd not expect a function to be able to access a global variable that hadn't been defined in a scope that the function access.
What anerisgreat was saying in their second para:
You can always access the .py of the block and make it read a global variable.
is that, once GRC has generated all the .py source code files for you, you can then manually edit them so that the hierarchical block does use a samp_rate global variable instead of the value of one of its Parameter blocks.
That works because, by then, the function (or class + methods) that has been generated from the hierarchical block can now be given (by manually editting the .py files) sight of the scope where the top block's samp_rate has been defined. But this is a pretty unmaintainable approach to take.
