Re: Byte Boundary alignment

[Artur Nogueira]

Hello Lannan,

As far as I could understand, you want to do the following operations:

(i) Generate bytes -> (ii) Modulate -> (iii) Transmit -> (iv) Receive ->
(v) Demodulate -> (vi) Recover bytes

and then you want to align the byte sequences from steps (i) and (vi).
Am I correct?
What hardware (model) are you using to transmit/receive?

I've been trying to solve a similar issue lately and I am convinced that my
signals are not aligned because of 3 main reasons: wave propagation time,
GNU Radio processing time (latency) and carrier frequency offset (CFO).
What I've been doing is: the two first issues are minimized by applying a
cross-correlation operator (not necessarily in GNU Radio; you can
post-process using another software if you want) to the transmitted and
received  base-band signals. The peak value allows you to find the lag
between them.
The third problem (CFO) comes from an unalignment between the transmitting
and receiving units (I use HackRF One) and can be solved with a mixer at
the receiver level tuned with the frequency offset value.

Best regards,
Artur








Em qua., 22 de jul. de 2020 às 12:56, lannan jiang 
escreveu:

> Hi everyone,
>(It's me again.)
>I am working on an audio channel using QPSK modulation. I currently am
> transmitting through a signal source that outputs bytes. I am looking for a
> method to align the byte boundaries so I am able to hear a clean audio at
> the receiver.
>Here is an idea of what I want to do: send packets that have, for
> example, 7 bytes of data and 1 byte of known pattern, and so I can sync
> with the receive block. However, I do not know how to implement this in GRC
> (I see a block named packet header generator, is this what I want to use?).
> Could someone please advise me on how to approach this?
>
>Thanks in advance.
>Lannan Jiang
>

Intermittent reception

[Artur Nogueira]

Hello all,

I'm analysing a pair of GMSK transmitted and received waveforms coming from
this process:
[image: image.png]

The transmitted data is a periodic sequence of 5 bits (11100) - File Source
"Repeat" option enabled.
While trying to synchronize the signals so I can get the BER, I found this:

[image: image.png]

Although the transmission is a continuous process, the reception is
intermittent.

Do you know what is going on?
Is there a way of post-processing this in order to evaluate the BER?

Best regards,
Artur

Re: Osmocom Source (frequency deviation)

[Artur Nogueira]

Just one more comment: there is an additional low-pass filter when I use
the mixer. The goal is to eliminate one of the frequencies resulting from
this process (i.e. 2 x f_offset).

Em qui., 25 de jun. de 2020 às 10:35, Artur Nogueira 
escreveu:

> Yes, you're right: 2000 samples is too much. I made measurements with
> different numbers of samples (2, 500 and 2000) because I was afraid a very
> slow number (e.g. 2) could cause aliasing in the base-band.
> Regarding the offset, it is indeed constant and for experimentation.
> I had not realized before this correction field on the Osmocom block -
> I'll take a look at it; thanks.
> What I'm trying to do is to apply a mixer tuned to the offset frequency
> after the Osmocom Source block. The result seems to be ok:
>
> Without the frequency correction:
> [image: image.png]
>
> With the frequency correction:
> [image: image.png]
>
> Do you think this is reasonable?
>
> Em qua., 24 de jun. de 2020 às 18:32, Jeff Long 
> escreveu:
>
>> By the way, 2000 samples per symbol is kind of high. It's usually
>> something like 4.
>>
>> Also, if the frequency offset is constant and this is just for
>> experimentation, you can use a frequency translating filter, or possibly
>> the frequency correction field on the osmocomm blocks (can't remember if
>> it's passed through to the hackrf code).
>>
>> On Wed, Jun 24, 2020 at 5:21 PM Jeff Long  wrote:
>>
>>> Depending on the bandwidth of your signal, that could be a lot of
>>> offset, and you might need a PLL to do frequency correction. That's 130
>>> ppm, which is a little more than you should see between two HackRFs.
>>>
>>> On Wed, Jun 24, 2020 at 5:13 PM Artur Nogueira 
>>> wrote:
>>>
>>>> Thanks a lot.
>>>> I'll read the block specifications.
>>>> And yes, the offset is small (120 kHz).
>>>>
>>>> Em qua., 24 de jun. de 2020 às 17:53, Jeff Long 
>>>> escreveu:
>>>>
>>>>> Assuming the difference is small enough, this is a normal RX problem
>>>>> that a GMSK demod should be able to handle. The labels on your frequency
>>>>> plot do not say what the offset is, but hint that it is small. Take a look
>>>>> at gmsk.py
>>>>> <https://github.com/gnuradio/gnuradio/blob/b76e8788687b4feef610e501c0c7d167c4f04a98/gr-digital/python/digital/gmsk.py#L165>
>>>>>  to
>>>>> see how it's handled in the built-in demod.
>>>>>
>>>>> On Wed, Jun 24, 2020 at 4:10 PM Artur Nogueira 
>>>>> wrote:
>>>>>
>>>>>> Hi Jeff,
>>>>>>
>>>>>> Thanks for the feedback.
>>>>>> I'm using GNU Radio Version 3.7.13.5 and two Great Scott Gadgets
>>>>>> HackRF units for the transmission/reception.
>>>>>> My workflow looks like this:
>>>>>>
>>>>>> [image: image.png]
>>>>>>
>>>>>> Do you usually use any artifact to compensate for this frequency
>>>>>> shift?
>>>>>> I'm afraid this could affect demodulation and therefore the BER.
>>>>>>
>>>>>> Best regards,
>>>>>> Artur
>>>>>>
>>>>>>
>>>>>> Em qua., 24 de jun. de 2020 às 16:31, Jeff Long 
>>>>>> escreveu:
>>>>>>
>>>>>>> Artur,
>>>>>>>
>>>>>>> You haven't mentioned what software you are using, how you have it
>>>>>>> configured, or what your flowgraph looks like.
>>>>>>>
>>>>>>> If you are using two SDRs and the frequency difference is a few kHz,
>>>>>>> then that is just oscillator differences.
>>>>>>>
>>>>>>> On Wed, Jun 24, 2020 at 3:12 PM Artur Nogueira <
>>>>>>> artur.no...@gmail.com> wrote:
>>>>>>>
>>>>>>>> Hi everyone,
>>>>>>>>
>>>>>>>> I'm comparing the spectra of a pair of transmitted/received GMSK
>>>>>>>> signals (carrier frequency = 923 MHz).
>>>>>>>> As expected, there is a certain channel attenuation.
>>>>>>>> Nevertheless, there is this frequency deviation at the Osmocom
>>>>>>>> Source output:
>>>>>>>> [image: image.png]
>>>>>>>>
>>>>>>>> I suppose this is something related to the receiver hardware.
>>>>>>>> Do you have a suggestion on how to compensate for this effect at a
>>>>>>>> software level?
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Artur
>>>>>>>>
>>>>>>>>

Re: Osmocom Source (frequency deviation)

[Artur Nogueira]

Yes, you're right: 2000 samples is too much. I made measurements with
different numbers of samples (2, 500 and 2000) because I was afraid a very
slow number (e.g. 2) could cause aliasing in the base-band.
Regarding the offset, it is indeed constant and for experimentation.
I had not realized before this correction field on the Osmocom block - I'll
take a look at it; thanks.
What I'm trying to do is to apply a mixer tuned to the offset frequency
after the Osmocom Source block. The result seems to be ok:

Without the frequency correction:
[image: image.png]

With the frequency correction:
[image: image.png]

Do you think this is reasonable?

Em qua., 24 de jun. de 2020 às 18:32, Jeff Long 
escreveu:

> By the way, 2000 samples per symbol is kind of high. It's usually
> something like 4.
>
> Also, if the frequency offset is constant and this is just for
> experimentation, you can use a frequency translating filter, or possibly
> the frequency correction field on the osmocomm blocks (can't remember if
> it's passed through to the hackrf code).
>
> On Wed, Jun 24, 2020 at 5:21 PM Jeff Long  wrote:
>
>> Depending on the bandwidth of your signal, that could be a lot of offset,
>> and you might need a PLL to do frequency correction. That's 130 ppm, which
>> is a little more than you should see between two HackRFs.
>>
>> On Wed, Jun 24, 2020 at 5:13 PM Artur Nogueira 
>> wrote:
>>
>>> Thanks a lot.
>>> I'll read the block specifications.
>>> And yes, the offset is small (120 kHz).
>>>
>>> Em qua., 24 de jun. de 2020 às 17:53, Jeff Long 
>>> escreveu:
>>>
>>>> Assuming the difference is small enough, this is a normal RX problem
>>>> that a GMSK demod should be able to handle. The labels on your frequency
>>>> plot do not say what the offset is, but hint that it is small. Take a look
>>>> at gmsk.py
>>>> <https://github.com/gnuradio/gnuradio/blob/b76e8788687b4feef610e501c0c7d167c4f04a98/gr-digital/python/digital/gmsk.py#L165>
>>>>  to
>>>> see how it's handled in the built-in demod.
>>>>
>>>> On Wed, Jun 24, 2020 at 4:10 PM Artur Nogueira 
>>>> wrote:
>>>>
>>>>> Hi Jeff,
>>>>>
>>>>> Thanks for the feedback.
>>>>> I'm using GNU Radio Version 3.7.13.5 and two Great Scott Gadgets
>>>>> HackRF units for the transmission/reception.
>>>>> My workflow looks like this:
>>>>>
>>>>> [image: image.png]
>>>>>
>>>>> Do you usually use any artifact to compensate for this frequency shift?
>>>>> I'm afraid this could affect demodulation and therefore the BER.
>>>>>
>>>>> Best regards,
>>>>> Artur
>>>>>
>>>>>
>>>>> Em qua., 24 de jun. de 2020 às 16:31, Jeff Long 
>>>>> escreveu:
>>>>>
>>>>>> Artur,
>>>>>>
>>>>>> You haven't mentioned what software you are using, how you have it
>>>>>> configured, or what your flowgraph looks like.
>>>>>>
>>>>>> If you are using two SDRs and the frequency difference is a few kHz,
>>>>>> then that is just oscillator differences.
>>>>>>
>>>>>> On Wed, Jun 24, 2020 at 3:12 PM Artur Nogueira 
>>>>>> wrote:
>>>>>>
>>>>>>> Hi everyone,
>>>>>>>
>>>>>>> I'm comparing the spectra of a pair of transmitted/received GMSK
>>>>>>> signals (carrier frequency = 923 MHz).
>>>>>>> As expected, there is a certain channel attenuation.
>>>>>>> Nevertheless, there is this frequency deviation at the Osmocom
>>>>>>> Source output:
>>>>>>> [image: image.png]
>>>>>>>
>>>>>>> I suppose this is something related to the receiver hardware.
>>>>>>> Do you have a suggestion on how to compensate for this effect at a
>>>>>>> software level?
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Artur
>>>>>>>
>>>>>>>

Re: Osmocom Source (frequency deviation)

[Artur Nogueira]

Thanks a lot.
I'll read the block specifications.
And yes, the offset is small (120 kHz).

Em qua., 24 de jun. de 2020 às 17:53, Jeff Long 
escreveu:

> Assuming the difference is small enough, this is a normal RX problem that
> a GMSK demod should be able to handle. The labels on your frequency plot do
> not say what the offset is, but hint that it is small. Take a look at
> gmsk.py
> <https://github.com/gnuradio/gnuradio/blob/b76e8788687b4feef610e501c0c7d167c4f04a98/gr-digital/python/digital/gmsk.py#L165>
>  to
> see how it's handled in the built-in demod.
>
> On Wed, Jun 24, 2020 at 4:10 PM Artur Nogueira 
> wrote:
>
>> Hi Jeff,
>>
>> Thanks for the feedback.
>> I'm using GNU Radio Version 3.7.13.5 and two Great Scott Gadgets HackRF
>> units for the transmission/reception.
>> My workflow looks like this:
>>
>> [image: image.png]
>>
>> Do you usually use any artifact to compensate for this frequency shift?
>> I'm afraid this could affect demodulation and therefore the BER.
>>
>> Best regards,
>> Artur
>>
>>
>> Em qua., 24 de jun. de 2020 às 16:31, Jeff Long 
>> escreveu:
>>
>>> Artur,
>>>
>>> You haven't mentioned what software you are using, how you have it
>>> configured, or what your flowgraph looks like.
>>>
>>> If you are using two SDRs and the frequency difference is a few kHz,
>>> then that is just oscillator differences.
>>>
>>> On Wed, Jun 24, 2020 at 3:12 PM Artur Nogueira 
>>> wrote:
>>>
>>>> Hi everyone,
>>>>
>>>> I'm comparing the spectra of a pair of transmitted/received GMSK
>>>> signals (carrier frequency = 923 MHz).
>>>> As expected, there is a certain channel attenuation.
>>>> Nevertheless, there is this frequency deviation at the Osmocom Source
>>>> output:
>>>> [image: image.png]
>>>>
>>>> I suppose this is something related to the receiver hardware.
>>>> Do you have a suggestion on how to compensate for this effect at a
>>>> software level?
>>>>
>>>> Best regards,
>>>> Artur
>>>>
>>>>

Re: Osmocom Source (frequency deviation)

[Artur Nogueira]

Hi Jeff,

Thanks for the feedback.
I'm using GNU Radio Version 3.7.13.5 and two Great Scott Gadgets HackRF
units for the transmission/reception.
My workflow looks like this:

[image: image.png]

Do you usually use any artifact to compensate for this frequency shift?
I'm afraid this could affect demodulation and therefore the BER.

Best regards,
Artur


Em qua., 24 de jun. de 2020 às 16:31, Jeff Long 
escreveu:

> Artur,
>
> You haven't mentioned what software you are using, how you have it
> configured, or what your flowgraph looks like.
>
> If you are using two SDRs and the frequency difference is a few kHz, then
> that is just oscillator differences.
>
> On Wed, Jun 24, 2020 at 3:12 PM Artur Nogueira 
> wrote:
>
>> Hi everyone,
>>
>> I'm comparing the spectra of a pair of transmitted/received GMSK signals
>> (carrier frequency = 923 MHz).
>> As expected, there is a certain channel attenuation.
>> Nevertheless, there is this frequency deviation at the Osmocom Source
>> output:
>> [image: image.png]
>>
>> I suppose this is something related to the receiver hardware.
>> Do you have a suggestion on how to compensate for this effect at a
>> software level?
>>
>> Best regards,
>> Artur
>>
>>

Osmocom Source (frequency deviation)

[Artur Nogueira]

Hi everyone,

I'm comparing the spectra of a pair of transmitted/received GMSK signals
(carrier frequency = 923 MHz).
As expected, there is a certain channel attenuation.
Nevertheless, there is this frequency deviation at the Osmocom Source
output:
[image: image.png]

I suppose this is something related to the receiver hardware.
Do you have a suggestion on how to compensate for this effect at a software
level?

Best regards,
Artur

GMSK bandwidth

[Artur Nogueira]

Hello guys,

I'm trying to generate a GMSK signal in accordance to the GSM
specifications. To do so, I've been trying with both "GMSK Mod" and "GMSK
Modulator" blocks, the last one with the following parameters:

[image: image.png]

To set these parameters, I considered (i) a sufficiently high base-band
sampling rate (samples/symbol) in order to avoid aliasing; (ii) the
well-known 0.3 BT product and (iii) a 156 bits GSM pulse, i.e. 1 time slot
(I considered that GMSK provides 1 bit/symbol).

Nevertheless, my signals have a bandwidth which is much larger than the 200
kHz requirement.
What am I doing wrong?

Best regards,
Artur

Re: [gnu.org #1520212] Problem with hidden addresses

[Artur Nogueira]

Dear Ms. Thérèse and Mr. Ian Kelling,

Thank you very much for the clarifications.

Best regards,
Artur

Em qui., 30 de abr. de 2020 às 09:58, Ian Kelling via RT 
escreveu:

> On Wed Apr 29 15:54:58 2020, artur.no...@gmail.com wrote:
> > Dear GNU Radio webmasters,
> >
> > I am a GNU Radio user, currently subscribed on the  > gnura...@gnu.org>
> > discussion list.
> > While trying to find some specific topics on the
> > 
> > website, I realized that inside a given discussion history (e.g.
> > https://lists.gnu.org/archive/html/qemu-devel/2020-04/index.html), the
> > e-mail addresses are hidden (address@hidden).
> > Nevertheless, if I type any name on the search engine here: <
> > https://lists.gnu.org/archive/html/discuss-gnuradio/>, then the
> > complete
> > e-mail address is available.
> >
> > Could you check that, please?
> >
> > Thanks in advance.
> >
> > Best regards,
> > Artur
>
> They are hidden only in the main html view, but have always been
> visibile in the mbox archive. See the link to the mbox archives at
> https://lists.gnu.org/archive/html/discuss-gnuradio/. The mbox archives
> are necessary for people to fully participate in conversations that
> happened before they were subscribed to the list, or who are not
> subscribed. It used to be that hiding email addresses in the html view
> was helpful against crawlers and spammers, but they have largely found
> the mbox archives and we plan to stop hiding them in the html view as it
> seems to mainly cause problems for normal people nowadays. If the list
> administrators/owners wanted to fully hide people's email addresses,
> they could turn on a setting for the list called anonymous_list. Note, I
> don't know who the list admin/owners are for gnu-radio-discuss, FSF is
> whats
> called the site administrators in GNU Mailman terms.
>
> --
> Ian Kelling | Senior Systems Administrator, Free Software Foundation
> GPG Key: B125 F60B 7B28 7FF6 A2B7  DF8F 170A F0E2 9542 95DF
> https://fsf.org | https://gnu.org
>
>
>

Problem with hidden addresses

[Artur Nogueira]

Dear GNU Radio webmasters,

I am a GNU Radio user, currently subscribed on the 
discussion list.
While trying to find some specific topics on the 
website, I realized that inside a given discussion history (e.g.
https://lists.gnu.org/archive/html/qemu-devel/2020-04/index.html), the
e-mail addresses are hidden (address@hidden).
Nevertheless, if I type any name on the search engine here: <
https://lists.gnu.org/archive/html/discuss-gnuradio/>, then the complete
e-mail address is available.

Could you check that, please?

Thanks in advance.

Best regards,
Artur

Re: Hidden e-mail address

[Artur Nogueira]

Sure, I'll do that. Shall I put this list in copy or it is not necessary?

Em qua., 29 de abr. de 2020 às 11:49, Andrej Rode 
escreveu:

> Good catch,
>
> seems like the address scrubbing to reduce the amount of crawlable mail
> addresses works for displaying single mails but is not done for
> presenting the results of the search query.
>
> Either a bug in mailman or in the GNU lists configuration. Worth
> reporting, will you do that? (the correct mail address should be at the
> bottom of the page)'
>
> Cheers
> Andrej
>
> On Wed, 29 Apr 2020 10:34:28 -0300
> Artur Nogueira  wrote:
>
> > The problem is: when I type my name on the search engine here:
> > https://lists.gnu.org/archive/html/discuss-gnuradio/, then it is
> > visible (I also typed other names and the same happens...)
> >
> > Em qua., 29 de abr. de 2020 às 04:56, Marcus Müller
> >  escreveu:
> >
> > > Looks pretty hidden to me:
> > >
> > >
> https://lists.gnu.org/archive/html/discuss-gnuradio/2020-04/msg00188.html
> > >
> > > or am I misinterpreting this?
> > >
> > > On 29.04.20 04:06, Artur Nogueira wrote:
> > > > Hello all,
> > > >
> > > > I was recently looking for some specific topics
> > > > on https://lists.gnu.org/ and I realized that many e-mail
> > > > addresses appear like address@hidden <mailto:address@hidden>
> > > > there. How do I do to get my e-mail address hidden in the same
> > > > way?
> > > >
> > > > Best regards,
> > > > Artur
> > >
>
>
>

Re: Hidden e-mail address

[Artur Nogueira]

The problem is: when I type my name on the search engine here:
https://lists.gnu.org/archive/html/discuss-gnuradio/, then it is visible (I
also typed other names and the same happens...)

Em qua., 29 de abr. de 2020 às 04:56, Marcus Müller 
escreveu:

> Looks pretty hidden to me:
>
> https://lists.gnu.org/archive/html/discuss-gnuradio/2020-04/msg00188.html
>
> or am I misinterpreting this?
>
> On 29.04.20 04:06, Artur Nogueira wrote:
> > Hello all,
> >
> > I was recently looking for some specific topics
> > on https://lists.gnu.org/ and I realized that many e-mail addresses
> > appear like address@hidden <mailto:address@hidden> there.
> > How do I do to get my e-mail address hidden in the same way?
> >
> > Best regards,
> > Artur
>

Hidden e-mail address

[Artur Nogueira]

Hello all,

I was recently looking for some specific topics on https://lists.gnu.org/ and
I realized that many e-mail addresses appear like address@hidden there.
How do I do to get my e-mail address hidden in the same way?

Best regards,
Artur

Re: Exporting 2d arrays

[Artur Nogueira]

Thank you very much for the suggestions, Marcus.
I'll consider all of them and I'll try to think on a solution to the
problem you mentioned about the other blocks.

Best regards,
Artur

Em seg., 27 de abr. de 2020 às 13:25, Marcus Müller 
escreveu:

> Hi Artur,
>
> Two options:
>
> 1.
>
> simply set your output signature to a single output, with the itemsize
> being the size of one element of your matrix. Use set_output_multiple to
> N·M, so that the scheduler knows you'll always produce as many items as
> fit into your matrix.
>
> 2.
>
> simply set your output signature to a single output, size
> N·M·sizeof(element of matrix) and always emit one item that contains all
> the data of your matrix.
>
> 3.¹
>
> combine. E.g. set your output size to a row size, and
> set_output_multiple(N_rows).
>
> Now, you're stuck with the fact that the downstream blocks can't know of
> "structure", e.g.  that these N·M items form from approach 1 form a
> unit, or that the matrix in approach 2 is N×M and not M×N or N/2×2M. For
> a few blocks, that doesn't matter (e.g., if you just want to scale
> things with multiply_const), for others it does. Either, you need to
> communicate that to these blocks beforehand (e.g. they take parameters
> in their constructors so that they know what kind of data to expect), or
> you use a stream tag in the very beginning to inform them.
>
> Best regards,
> Marcus
>
>
> ¹ ... nobody expects the Spanish Inquisition, just to quote Monty Python.
> On 24/04/2020 23.20, Artur Nogueira wrote:
> > Hi Marcus,
> >
> > By "variable", it means "the size is set by the user once and doesn't
> change
> > during runtime" and, most importantly, it can change from one simulation
> > to another. In my case, each output terminal from my Python Block is
> > connected to a Frequency Sink and therefore it would be unpractical to
> > remove or make new connections all the time. So I was wondering if it is
> > possible to export a 2-d array in a single output terminal rather than
> > exporting N 1-d arrays through N different ports (please find attached a
> > pdf file with a simple illustration of my question).
> >
> > And, by the way, I also have a question regarding the second point that
> > you've mentioned ("the same block outputs matrices of different
> > length"), but we can discuss it later or in another occasion.
> >
> > Best regards,
> > Artur
> >
> > Em sex., 24 de abr. de 2020 às 02:55, Marcus Müller  > <mailto:muel...@kit.edu>> escreveu:
> >
> > Hi Artur,
> >
> > does "variable" mean the size is set by the user once and doesn't
> > change
> > during runtime, or does it mean that the same block outputs matrices
> of
> > different length?
> >
> > Another way of thinking about this would be:
> > Is this a block that really produces a _stream of identical items_
> > or is
> > it rather a block that produces _messages of different content_?
> >
> > Best regards,
> > Marcus
> >
> > On 23/04/2020 17.43, Artur Nogueira wrote:
> >  > Hi all,
> >  >
> >  > I'm using the Python Block for signal processing and I need to
> > export a
> >  > matrix for further Fourier analysis.
> >  > I think I can 'slice' this matrix into several lines (or columns)
> > and
> >  > store each of them in an 1-d output_items[i][:] variable,
> >  > i=1,2...,number of lines (or columns).
> >  > But considering that the number of lines is user-defined (i.e. it
> > can be
> >  > large and variable), it would be unpractical to deal with the
> Python
> >  > Block outputs.
> >  >
> >  > Do you have a suggestion for this?
> >  > Is it possible to export a 2-d array into a single Python Block
> > output?
> >  >
> >  > Best regards,
> >  > Artur
> >  >
> >  >
> > <
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
> >
> >
> >  >   Livre de vírus. www.avast.com <http://www.avast.com>
> >  >
> > <
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
> >.
> >
> >  >
> >  >
> >  > <#m_7329815989545016753_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> >
>
>

Re: Exporting 2d arrays

[Artur Nogueira]

Hi Marcus,

By "variable", it means "the size is set by the user once and doesn't change
during runtime" and, most importantly, it can change from one simulation to
another. In my case, each output terminal from my Python Block is connected
to a Frequency Sink and therefore it would be unpractical to remove or make
new connections all the time. So I was wondering if it is possible to
export a 2-d array in a single output terminal rather than exporting N 1-d
arrays through N different ports (please find attached a pdf file with a
simple illustration of my question).

And, by the way, I also have a question regarding the second point that
you've mentioned ("the same block outputs matrices of different length"),
but we can discuss it later or in another occasion.

Best regards,
Artur


Em sex., 24 de abr. de 2020 às 02:55, Marcus Müller 
escreveu:

> Hi Artur,
>
> does "variable" mean the size is set by the user once and doesn't change
> during runtime, or does it mean that the same block outputs matrices of
> different length?
>
> Another way of thinking about this would be:
> Is this a block that really produces a _stream of identical items_ or is
> it rather a block that produces _messages of different content_?
>
> Best regards,
> Marcus
>
> On 23/04/2020 17.43, Artur Nogueira wrote:
> > Hi all,
> >
> > I'm using the Python Block for signal processing and I need to export a
> > matrix for further Fourier analysis.
> > I think I can 'slice' this matrix into several lines (or columns) and
> > store each of them in an 1-d output_items[i][:] variable,
> > i=1,2...,number of lines (or columns).
> > But considering that the number of lines is user-defined (i.e. it can be
> > large and variable), it would be unpractical to deal with the Python
> > Block outputs.
> >
> > Do you have a suggestion for this?
> > Is it possible to export a 2-d array into a single Python Block output?
> >
> > Best regards,
> > Artur
> >
> > <
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
>
> >   Livre de vírus. www.avast.com
> > <
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>.
>
> >
> >
> > <#m_7329815989545016753_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
>


question_gnuradio.pdf
Description: Adobe PDF document

Exporting 2d arrays

[Artur Nogueira]

Hi all,

I'm using the Python Block for signal processing and I need to export a
matrix for further Fourier analysis.
I think I can 'slice' this matrix into several lines (or columns) and store
each of them in an 1-d output_items[i][:] variable, i=1,2...,number of
lines (or columns).
But considering that the number of lines is user-defined (i.e. it can be
large and variable), it would be unpractical to deal with the Python Block
outputs.

Do you have a suggestion for this?
Is it possible to export a 2-d array into a single Python Block output?

Best regards,
Artur


Livre
de vírus. www.avast.com
.
<#m_7329815989545016753_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re: Output variables - Python Block

[Artur Nogueira]

Thank you very much, Derek! =)

Best regards
Artur

Em qua., 22 de abr. de 2020 às 05:55, Derek Kozel 
escreveu:

> Hi Artur,
>
> Yes, the Python Block follows the same API as other blocks so the
> input/output signatures can be defined as a list.
>
> in_sig = [np.complex64, np.float32, np.float32]
>
> On 22/04/2020 04:09, Artur Nogueira wrote:
> > Hi all,
> >
> > Is it possible to make the 'work' function from the Python Block to
> > export an arbitrary number of variables, with different associated
> > types? E.g. 3 output variables, 1 being complex64 and the other 2
> > being float32.
> >
> > Best regards,
> > Artur
>
>

Output variables - Python Block

[Artur Nogueira]

Hi all,

Is it possible to make the 'work' function from the Python Block to export
an arbitrary number of variables, with different associated types? E.g. 3
output variables, 1 being complex64 and the other 2 being float32.

Best regards,
Artur

Re: Phase plot

[Artur Nogueira]

Hello Kyeong,

Thank you very much for your feedback.
I was looking for an answer to "the phase response of the FFT outputs" and,
by following your instructions, it worked perfectly fine.

Best regards,
Artur

Em dom., 19 de abr. de 2020 às 03:17, Kyeong Su Shin 
escreveu:

> Hello Artur:
>
> "QT Frequency Sink" is basically FFT -> Mag^2 -> scaling, dB conversion ->
> QT GUI Vector Sink. I am not sure if that is what you wanted.
>
> If you are looking for the phase in the *time domain*, then you should do
> something like "Complex to Mag Phase" -> "QT GUI Time Sink" (and I guess
> this is what you wanted).
>
> If you are looking for the phase response of the *FFT outputs* (basically
> a phase version of the "QT Frequency Sink"), I guess you want to do
> something like "Stream to Vector" -> "FFT" -> "Complex to Mag Phase (vec
> len = fft size)" ->" QT GUI Vector Sink" (I think this is not what you were
> looking for, but maybe I misunderstood your application, so I am explaining
> this anyway).
>
> Regards,
> Kyeong Su Shin
> --
> *보낸 사람:* Artur Nogueira  대신 Discuss-gnuradio
> 
> *보낸 날짜:* 2020년 4월 19일 일요일 오전 7:40
> *받는 사람:* discuss-gnuradio@gnu.org 
> *제목:* Phase plot
>
> Hi all,
>
> I'm facing some difficulties while trying to get a phase plot of a signal.
> More specifically, I'm trying to get the phase difference between two
> signals.
> Since my signals are complex in the time domain (GMSK), I've tried to use
> the "Complex to Arg" and eventually the "Complex to Mag Phase" blocks
> before the "QT Frequency Sink".
> The results are expressed in dB rather than in radians and I'm not sure if
> they are correct.
>
> I'd like to know how you guys usually plot the phase spectra of signals.
>
> Thanks in advance.
>
> Best regards,
> Artur
>
>
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
>  Livre
> de vírus. www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>.
> <#m_-3940765543338399187_x_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>

Phase plot

[Artur Nogueira]

Hi all,

I'm facing some difficulties while trying to get a phase plot of a signal.
More specifically, I'm trying to get the phase difference between two
signals.
Since my signals are complex in the time domain (GMSK), I've tried to use
the "Complex to Arg" and eventually the "Complex to Mag Phase" blocks
before the "QT Frequency Sink".
The results are expressed in dB rather than in radians and I'm not sure if
they are correct.

I'd like to know how you guys usually plot the phase spectra of signals.

Thanks in advance.

Best regards,
Artur


Livre
de vírus. www.avast.com
.
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Re: Control of running time

[Artur Nogueira]

Thanks Michael and Marcus!

Regards
Artur

Em sex., 3 de abr. de 2020 às 16:01, Marcus D. Leech <
patchvonbr...@gmail.com> escreveu:

> On 04/03/2020 02:43 PM, Artur Nogueira wrote:
> > Hi all,
> >
> > Is there a way of precisely controlling the simulation/running time of
> > GNU Radio, i.e. initial and final time instants?
> >
> > Thanks.
> >
> > Regards,
> > Artur
> You can use a "head" block to control how many samples go through before
> the graph terminates.  But precisely control of start time? Nope.
>
>
>

Control of running time

[Artur Nogueira]

Hi all,

Is there a way of precisely controlling the simulation/running time of GNU
Radio, i.e. initial and final time instants?

Thanks.

Regards,
Artur

BER calculation - GMSK Demod

[Artur Nogueira]

Hello,

I am simulating a simple GMSK modulation/demodulation process, without any
channel model, in order to evaluate the BER under normal conditions and
with noise. I would like to have your opinion about the way I calculate the
BER: is it correct? Is there a better way to do it?

Here a brief description of the problem:
I created the following input binary sequence: 1110011100 as a .bin file
and I loaded it in the File Source block. Then, I fed the GMSK Mod block
with this binary sequence, I added noise to it and then I sent the
resulting signal to a GMSK Demod unit. Finally, I saved the output sequence
in a .bin file by means of File Sink block.

Apparently, the GMSK Demod block creates 8-bit packets for each input bit,
by allocating them in the LSB position. In this case, instead of
calculating the BER, I am calculating the PER (Packet Error Rate), by
comparing the 0's with  and 1's with 0001. And when I add noise
to the model, the output sequence is modified (as expected).

In this case, I am proceeding with the same methodology for the PER
calculation so every time a non-zero bit appears between the 1st and 7th
position of a byte (ex: 0100), I suppose this is caused by noise and I
count it as a wrong packet.

Does my analysis make sense? Is there a more practical or correct way of
evaluating the BER/PER?

Thanks.

Best regards,
Artur