Question about data types while creating blocks

Hello

I’m trying to create a new block, which one of its output variables is
string. I would like to know if that it’s possible or if i should
convert it
to a integer type.
This output is a vector of size 8, each with three characters:
v[1] = ‘222’
v[2] =‘223’
v[3] =‘232’
v[4] =‘233’
v[5] =‘333’
v[6] =‘322’
v[7] =‘323’
v[8] =‘332’

Also, i would like to know if i can transmit a double variable using the
float type output.

Thank you
David.


View this message in context:
http://gnuradio.4.n7.nabble.com/question-about-data-types-while-creating-blocks-tp54075.html
Sent from the GnuRadio mailing list archive at Nabble.com.

Hi David,

I’m trying to create a new block, which one of its output variables is
string.

to be honest, processing strings does sound more like a message passing
instead of a sample streaming kind of thing.
But:

This output is a vector of size 8, each with three characters:
aha! Your strings aren’t the typical, variable length string! their
8-tuples of 3-tuples of characters!
Basically, what you want seems to be a block that emits bytes, in
multiples of 24.
There’s two ways to achieve that: you can either define the io_signature
of the block to let the item size be 1 byte (==sizeof(char), and then
use set_output_multiple(24), or you can have an io_signature with an
item size of 24.

But: I don’t think you’re giving us the whole picture, considering your
example strings look all very specific. Maybe you want to explain a bit
of what your block should do?

Also, i would like to know if i can transmit a double variable using the
float type output.
No. But you can still have a block outputting doubles!

To explain: GNU Radio doesn’t actually care about what kind of data you
put into your block’s output items. It just needs to know how big (in
bytes) each item is. Floats are 4 byte long, doubles (well…) 8 bytes.
Hence, a double is worth two float output items.
You can just set the io_signature of your block to sizeof(double)
instead of (float) and GNU Radio will know that you want to exchange 8
byte items instead of4 byte items.

However, there’s a reason you don’t see the double type being used very
often in GNU Radio: SNR and dynamic range of the systems described are
seldom limited by the single precision floating point’s numerical
accuracy, and so almost all things just work on floats. Again: Maybe you
have some insight in what you want to do, that you might want to share?

Best regards,
Marcus

Hi Marcus

Thank you very much for your response.

What i want to do in general, is a chaotic channel coding scheme (based
in
Lorenz system) that works in lte, and compare it with the channel coding
schemes using conventionally (convolutional coding and turbocoding).
That’s
why i wrote you last week (May 31) doing some questions about the
connection
between a trellis encoder block (or pccc encoder block) with the ofdm
mod
and ofdm demod blocks and then with the viterbi combo block (or pccc
decoder
combo block).

So, returning to the chaotic coding… The method i’m using requires
first a
learning process which consists in obtain 2^n sequences (in this case n=
3)
each corresponding to 2^n values of the variable z crossing with 2
Poincare
surfaces sections (also a vector) of the Lorenz system.
Hence, each coordinate of the vector (v) is really a sequence of
symbols.
For example, z[1] corresponds to the v[1] sequence, z[2] with the v[2]
sequence, and so on.
I want to send this two vectors to a third block (explained below).

On the other hand, i have to create a second block that makes a
differential
encoding; associating the bit 0 with a change of symbol in two
consecutive
crossing with the Poincare surfaces of section (i.e., ‘23’ or ‘32’) and
the
bit 1 with the repetition of the same symbol (i.e., ‘22’ or ‘33’).

The second blocks output will entry in a third block, i should convert
it to
a string so i can compare it with the 2^n string sequences. This bock
will
send the z values, which are double (that’s why i was asking about the
output type float) that are needed to represent the sequences required
(based on the inputs from the second block).

So, I was trying to create the first block, which makes the learning
process.
If n = 3, i guess i could simply define 8 vectors of size 3 for the
symbol
sequences and another vector of size 8 for the z values directly in the
third block, this because there will be the same all the time. This way,
i
only have 2 blocks (the second and the third).
But in the case n = 8), i would have to define more vectors manually
(256
vectors each of size 8)
and that is what i wanted to avoid. I want to probe with several values
of n
so i can compare the behavior.
I have thought and i could do it till n = 6. it’s no to much to write 64
vectors of size 6 manually.

If you see a easier way to do all this, i’m all ears.

I don’t know if i explained myself but thank you very much anyway. Again
i’m
sorry for my English.

David.


View this message in context:
http://gnuradio.4.n7.nabble.com/question-about-data-types-while-creating-blocks-tp54075p54078.html
Sent from the GnuRadio mailing list archive at Nabble.com.

Hello again.

Maybe i could use n as a parameter on the block and do what yo suggest;
define in the io_signature of the block to let the item size to be 1
byte
and then maybe use the set_output_multiple(n*2^n).
Can i do something like this?

Thank you.

David


View this message in context:
http://gnuradio.4.n7.nabble.com/question-about-data-types-while-creating-blocks-tp54075p54079.html
Sent from the GnuRadio mailing list archive at Nabble.com.

Hi David,

yes, that’s absolutely possible. Just use n as a parameter of the
constructor :slight_smile:

Best regards,
Marcus

Thank you very much Marcus.

And to save the vectors in the third block, should i use the
set_history(n*2^n)? how do i set the input i want to save? because i
have 2
inputs


View this message in context:
http://gnuradio.4.n7.nabble.com/question-about-data-types-while-creating-blocks-tp54075p54081.html
Sent from the GnuRadio mailing list archive at Nabble.com.

That sounds great, I will do that.

Thank you very much Marcus, You really helped me.


View this message in context:
http://gnuradio.4.n7.nabble.com/question-about-data-types-while-creating-blocks-tp54075p54083.html
Sent from the GnuRadio mailing list archive at Nabble.com.

On Sun, Jun 7, 2015 at 3:02 PM, Marcus Müller [email protected]
wrote:

[1] you need to have a vector of history lengths instead of a single
integer; maybe Tom has some input on that.

I think a change as invasive as this needs someone to identify a serious
need for it that’s beyond one use-case that can be solved in other ways.

Tom

you’re right, set_history works on all inputs simultaneously. That’s an
architectural constraint; I don’t think it would be /impossible/ to fix
that, i.e. to make GNU Radio have different history per input buffer,
but it’s going to break API and therefore it’s not going to be easy
finding a good solution [1].
But unless you want to do upstream development (which is always welcome,
by the way!), I’d recommend that you “emulate” additional history by
overriding your block’s forecast() method and telling GNU Radio that you
need the additional number of items to produce a given amount of output;
there’s no obligation to always consume all your input.

I must admit that I can’t really follow your coding scheme; that has
nothing to do with your English (which is very good), but with the fact
that I haven’t ever heard anything about chaotic coding.

At any rate, it might be helpful if you made a sketch of how your flow
graph should look like, and put short descriptions what each stream
transports in there.

Best regards,
Marcus

[1] you need to have a vector of history lengths instead of a single
integer; maybe Tom has some input on that.