Re: [Discuss-gnuradio] PFB mapping: M < N?

2017-12-06 Thread Michael Dickens
Hi John - You are certainly correct that the documentation could be more
clear. I recall from reviewing the GR-core provided PFB blocks just a
few months ago that either a synthesizer or channelizer existed that
correctly handled the M < N and a mapping, but that the other version
didn't exist and/or didn't work as advertised. I ended up writing my own
Python heir blocks for both PFB versions that did the minimum required
for both PFB channels and mapping. They are not complex scripts, and
they do what you seem to be looking for: 1 input -> M < N outputs with
mapping, and the reverse. I'm happy to share if you'd like to try them
out. Cheers! - MLD

On Mon, Dec 4, 2017, at 10:54 AM, John Ackermann N8UR wrote:
> I find the documentation about PFB channel mapping to be confusing. 
> I've extracted it below.
> 
> The first paragraph seems to say the channel map has to have as many 
> elements "M" as the number of outputs "N".
> 
> But the second and third paragraphs talk about cases where M < N, and 
> only "M out of N channels are driven to an output stream."  This seems 
> to contradict the first paragraph.
> 
> GRC allows me to make a channel map with M elements where M < N, but it 
> still requires me to connect all N ports to a sink.  If that's so, why 
> would one ever want map less than N elements?  There seems to be no 
> benefit to doing so.
> 
> Is this documentation contradictory, or confusing, or am I missing 
> something?
> 
> Thanks,
> John
> 
>  From https://gnuradio.org/doc/sphinx-3.7.0/filter/channelizers_blk.html:
> "
> The map should have the same number of elements as the number of output 
> connections from the block. The minimum value of the map is 0 (for the 
> 0th channel) and the maximum number is N-1 where N is the number of 
> channels.
> 
> We specify M as the number of output connections made where M <= N, so 
> only M out of N channels are driven to an output stream. The number of 
> items in the channel map should be at least M long. If there are more 
> channels specified, any value in the map over M-1 will be ignored. If 
> the size of the map is less than M the behavior is unknown (we don’t 
> wish to check every entry into the work function).
> 
> This means that if the channelizer is splitting the signal up into N 
> channels but only M channels are specified in the map (where M <= N), 
> then M output streams must be connected and the map and the channel 
> numbers used must be less than N-1. Output channel number can be reused, 
> too. By default, the map is [0...M-1] with M = N."

___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] OFDM frame equalizer length tag

2017-12-06 Thread Michael Dickens
Hi Alice - If I had to guess, it would be that the tag for the
frame_equalizer_alix block is "frame_len", while that for the Pseudo-
Random Generator is "frame len" ... without the "_" joining the words.
Or, that's what it looks like in the image. The tagged_stream_block is
picky about these names; they really have to be identical!
A word of advice: Assign a variable that holds this string value, and
set all of the blocks that use it to the variable. Make the variable
name and it's value something other than "frame_len" alone ... for
example, "frame_len_alix" or the like ... a name that will be clear in
debugging that it is either there and correct or not (and thus
incorrect).
Hope this helps! - MLD

On Wed, Dec 6, 2017, at 05:54 PM, Alice Lo Valvo wrote:
> Hi,


> I duplicated the OFDM Frame Equalizer block, and all it works, I added
> a second input port which is connect with another block that is a
> tagged_stream block. I don't understand the reason of this error:> 
>> gr::log :FATAL: frame_equalizer_alix0 - Missing a required length tag
>> on port 1 at item #0>>  thread[thread-per-block[49]: > frame_equalizer_alix (17)>]:
>>  Missing length tag.> Length tag is there.. any ideas?
> 
>  Thanks in advance.
>  Alice
> 
> _
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> Email had 1 attachment:


>  * Schermata 2017-12-06 alle 23.51.39.png 497k (image/png)
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio