Re: gr-gpredict-doppler / 'gpredict' has no attribute 'doppler'

Hi Marcus,

here is some info about my system as you asked for:

Python 3.9.1 (default, Dec  8 2020, 07:51:42)

[GCC 10.2.0] on linux
>>> import gpredict
>>> print(gpredict.__file__)
/usr/local2/lib/python3/dist-packages/gpredict/__init__.py

That is ok for my configuration I think. I installed the newest version
but get the error again, even in the examples directory.

Then I deleted all .py files and the directory __pycache__and at the
moment it works.

I am wondering about the cause and will inform you again when there is a
more reproducible situation.

73, Tom



On 27.02.21 15:55, Marcus Müller wrote:
> Hi Tom,
>
> 1. Make sure your gr-gpredict-doppler checkout is recent enough to include Mike's 3.9-porting.
> Then: This error typically happens when you think you've imported something that contains
> a symbol, but didn't. In case of a C++ module, I'd assume there was something in the
> bindings missing, but as gr-gpredict-doppler is python only, and doppler.py is right
> there, my guess is you're accidentally importing an older installation or something else.
> open your python3, type in "import gpredict", then enter, then "print(gpredict.__file__)".
> Is that what you're hoping it is?
>
>
> Best regards,
> Marcus
>
> On 27.02.21 14:15, Tom Breyer wrote:
>> Hi to all,
>>
>> I work with grc 3.9.0.0 und linux Debian 11.
>>
>> Since the last days I am trying to find out some very mystic (in my eyes):
>>
>> I created a very simple flowgraph with
>>
>> Error:
>>
>> File "/home/tom/grc-data-3.9/gr-gpredict-doppler/examples/gpredict.py", line 81, in __init__
>>     self.gpredict_doppler_0 = gpredict.doppler('127.0.0.1', 4532, True)
>> AttributeError: type object '*gpredict' has no attribute 'doppler'*
>>
>> --------------------------------------------------------
>>
>> But:
>>
>> I want to get gr_predict-doppler running and it works, even it can communicate with the
>> GPredict satellite program.
>>
>> --------------------------------------------------------
>>
>> This works:
>>
>> Generating: '/home/tom/grc-data-3.9/gr-gpredict-doppler/examples/test_doppler.py'
>>
>> Executing: /usr/bin/python3 -u
>> /home/tom/grc-data-3.9/gr-gpredict-doppler/examples/test_doppler.py
>>
>> [doppler] Waiting for connection on: 127.0.0.1:4532
>> [doppler] Connected from: 127.0.0.1:46078
>> [doppler] New frequency: 145826597
>> [doppler] New frequency: 145826598
>> [doppler] New frequency: 145826599
>>
>> --------------------------------------------------------
>>
>> When starting the same flowgraph in my regular working directory I get an error:
>>
>> Generating: '/home/tom/grc-data-3.9/test_doppler.py'
>>
>> Executing: /usr/bin/python3 -u /home/tom/grc-data-3.9/test_doppler.py
>>
>> Traceback (most recent call last):
>>   File "/home/tom/grc-data-3.9/test_doppler.py", line 210, in <module>
>>     main()
>>   File "/home/tom/grc-data-3.9/test_doppler.py", line 188, in main
>>     tb = top_block_cls()
>>   File "/home/tom/grc-data-3.9/test_doppler.py", line 136, in __init__
>>     self.gpredict_doppler_0 = gpredict.doppler('127.0.0.1', 4532, True)
>> AttributeError: module '*gpredict' has no attribute 'doppler'*
>>
>> --------------------------------------------------------
>>
>> When moving it again to ...examples it works again.
>>
>> I find out that maybe the directory __pycache__ can have an impact on my trials...
>>
>> What is wrong in my setup (or thinking)?
>>
>> 73, Tom
>>
>>
>>
>>

Re: gr-gpredict-doppler / 'gpredict' has no attribute 'doppler'

Hi Tom,

1. Make sure your gr-gpredict-doppler checkout is recent enough to include Mike's 3.9-porting.
Then: This error typically happens when you think you've imported something that contains
a symbol, but didn't. In case of a C++ module, I'd assume there was something in the
bindings missing, but as gr-gpredict-doppler is python only, and doppler.py is right
there, my guess is you're accidentally importing an older installation or something else.
open your python3, type in "import gpredict", then enter, then "print(gpredict.__file__)".
Is that what you're hoping it is?


Best regards,
Marcus

On 27.02.21 14:15, Tom Breyer wrote:
> Hi to all,
>
> I work with grc 3.9.0.0 und linux Debian 11.
>
> Since the last days I am trying to find out some very mystic (in my eyes):
>
> I created a very simple flowgraph with
>
> Error:
>
> File "/home/tom/grc-data-3.9/gr-gpredict-doppler/examples/gpredict.py", line 81, in __init__
>     self.gpredict_doppler_0 = gpredict.doppler('127.0.0.1', 4532, True)
> AttributeError: type object '*gpredict' has no attribute 'doppler'*
>
> --------------------------------------------------------
>
> But:
>
> I want to get gr_predict-doppler running and it works, even it can communicate with the
> GPredict satellite program.
>
> --------------------------------------------------------
>
> This works:
>
> Generating: '/home/tom/grc-data-3.9/gr-gpredict-doppler/examples/test_doppler.py'
>
> Executing: /usr/bin/python3 -u
> /home/tom/grc-data-3.9/gr-gpredict-doppler/examples/test_doppler.py
>
> [doppler] Waiting for connection on: 127.0.0.1:4532
> [doppler] Connected from: 127.0.0.1:46078
> [doppler] New frequency: 145826597
> [doppler] New frequency: 145826598
> [doppler] New frequency: 145826599
>
> --------------------------------------------------------
>
> When starting the same flowgraph in my regular working directory I get an error:
>
> Generating: '/home/tom/grc-data-3.9/test_doppler.py'
>
> Executing: /usr/bin/python3 -u /home/tom/grc-data-3.9/test_doppler.py
>
> Traceback (most recent call last):
>   File "/home/tom/grc-data-3.9/test_doppler.py", line 210, in <module>
>     main()
>   File "/home/tom/grc-data-3.9/test_doppler.py", line 188, in main
>     tb = top_block_cls()
>   File "/home/tom/grc-data-3.9/test_doppler.py", line 136, in __init__
>     self.gpredict_doppler_0 = gpredict.doppler('127.0.0.1', 4532, True)
> AttributeError: module '*gpredict' has no attribute 'doppler'*
>
> --------------------------------------------------------
>
> When moving it again to ...examples it works again.
>
> I find out that maybe the directory __pycache__ can have an impact on my trials...
>
> What is wrong in my setup (or thinking)?
>
> 73, Tom
>
>
>
>

gr-gpredict-doppler / 'gpredict' has no attribute 'doppler'

Hi to all,

I work with grc 3.9.0.0 und linux Debian 11.

Since the last days I am trying to find out some very mystic (in my eyes):

I created a very simple flowgraph with

Error:

File "/home/tom/grc-data-3.9/gr-gpredict-doppler/examples/gpredict.py", line 81, in __init__
    self.gpredict_doppler_0 = gpredict.doppler('127.0.0.1', 4532, True)
AttributeError: type object 'gpredict' has no attribute 'doppler'

--------------------------------------------------------

But:

I want to get gr_predict-doppler running and it works, even it can communicate with the GPredict satellite program.

--------------------------------------------------------

This works:

Generating: '/home/tom/grc-data-3.9/gr-gpredict-doppler/examples/test_doppler.py'

Executing: /usr/bin/python3 -u /home/tom/grc-data-3.9/gr-gpredict-doppler/examples/test_doppler.py

[doppler] Waiting for connection on: 127.0.0.1:4532
[doppler] Connected from: 127.0.0.1:46078
[doppler] New frequency: 145826597
[doppler] New frequency: 145826598
[doppler] New frequency: 145826599

--------------------------------------------------------

When starting the same flowgraph in my regular working directory I get an error:

Generating: '/home/tom/grc-data-3.9/test_doppler.py'

Executing: /usr/bin/python3 -u /home/tom/grc-data-3.9/test_doppler.py

Traceback (most recent call last):
  File "/home/tom/grc-data-3.9/test_doppler.py", line 210, in <module>
    main()
  File "/home/tom/grc-data-3.9/test_doppler.py", line 188, in main
    tb = top_block_cls()
  File "/home/tom/grc-data-3.9/test_doppler.py", line 136, in __init__
    self.gpredict_doppler_0 = gpredict.doppler('127.0.0.1', 4532, True)
AttributeError: module 'gpredict' has no attribute 'doppler'

--------------------------------------------------------

When moving it again to ...examples it works again.

I find out that maybe the directory __pycache__ can have an impact on my trials...

What is wrong in my setup (or thinking)?

73, Tom

Re: gr-satellites

El 21/2/21 a las 8:58, Cinaed Simson escribió:
> Hi - all the tests were all failing for make test in gr-satellite - and
> test.sh.
>
> There was no module 'construct' installed.
>
> I downloaded it and installed in /usr/local and  then all the tests
> passed - including the test.sh script.
>
> Also, there was no contact email address in the "satellite_teams.md"
> file - just a name.
>
> -- Cinaed

Hi Cinaed,

Thanks for sharing your thoughts, and sorry for the delay in replying. I
only read the mailing list every now and then.

construct is a required dependency for gr-satellites, as explained in
the documentation. I'm glad that you have all the tests passing after
installing construct.

As stated in satellite_teams.md:

"[...] You are more than welcome to write in Github issues a heads-up
message [...]"

The preferred form of communication is through Github issues rather than
by email, so that all the community is able to engage in the discussion.

In any case, my email address is listed in my Github profile (apparently
it only shows it to logged in users), in my webpage, which is linked
from my Github profile and easy to find in Google, and in several other
places, I guess.

Best regards,

Daniel.

On OFDM Symbols and OFDM Frames

Hi all,

I hope you are doing well.

I am trying to understand how many OFDM symbols I'll have per OFDM frame.

I am using exactly these .grc:

https://github.com/gnuradio/gnuradio/blob/master/gr-digital/examples/ofdm/tx_ofdm.grc

https://github.com/gnuradio/gnuradio/blob/master/gr-digital/examples/ofdm/rx_ofdm.grc

Some info: fft_len = 64, packet_len = 96, payload_mod = QPSK, header_mod = BPSK.

Since here https://wiki.gnuradio.org/index.php/Basic_OFDM_Tutorial

it says that "the OFDM frame is thus in the memory in matrix form" I made a custom block to check (and save) the whole OFDM frame after the OFDM Carrier Allocator in the transmitter and after the FFT block in the receiver.

I was surprised to see that after the OFDM Carrier Allocator, what is passed does not have a fixed shape, it keeps varying. For example: 

...
(12, 64)
(24, 64)
(36, 64)
(48, 64)
(12, 64)
(36, 64)
(24, 64)
(24, 64)
...

But in the receiver, the FFT in the Payload stream, we have a stream of matrices with a (almost) not changing shape 

...
(9, 64)
(9, 64)
(18, 64)
(9, 64)
(9, 64)
(9, 64)
(9, 64)
(9, 64)

...

I don't understand why the Carrier Allocator output keeps changing shape.
And I really would appreciate it if anyone could elucidate how many OFDM symbols I should expect in the receiver. How can I calculate that number?

I'd like to thank you in advance for your help.

Many thanks.
Best regards,
Vinicius.

Re: Question re Adalm-Pluto, HackRFOne

apt install gr-iio

apt install gr-osmosdr

On Tue, Feb 23, 2021 at 3:17 PM geraldfenkell <geraldfenkell@computechnics.ca> wrote:

2021-02-23

 

Thank you for your reply.

 

Could you please supply the "apt commands" required that you refer to as being in

existence.

 

regards

 

Jerry

 

--------------------------

 

PLUTO should be supported by gr-iio, and HackRF by gr-osmosdr. Both of those can be install via apt.

 

On Tue, Feb 23, 2021 at 12:53 PM geraldfenkell <geraldfenkell@computechnics.ca> wrote:

2021-02-23

 

1. I have now got gnu radio installed on a computer using ubuntu 20.04 . I am using       version 3.8 of gnu radio ( I think 3.8.13 but not sure

     which I installed using sudo apt-get .....  

 

2. My question is:   Is there in existence

a. a package that I can add to version 3.8 using a similar sudo apt-get command

    that will add (with all required dependencies) the blocks for the Adalm-Pluto.

b. a package that I can add to version 3.8 using a similar sudo apt-get command

    that will add (with all required dependencies) the blocks for HackRFOne.

 

 

Thank you

 

Jerry

 

 

 

 

European GNU Radio Days: call for contributions @ https://gnuradio-eu-21.sciencesconf.org/

The European GNU Radio Days will be held *virtually* from June 24 to 26, 2021 with
the core organizers located in Poitiers, France. The objective of the meeting is to
foster collaboration between GNU Radio users, developers, hackers and enthusiasts
*from all around the world* thanks to the virtual format.

As such, you are welcome to submit a presentation proposal: due to the virtual format,
presentations will be recorded and broadcast with hopefully some live interaction with
the speakers at the end of the presentation (similar to those who attended FOSDEM,
but with humans and not a robot stopping abruptly at the end of the schedule). Demonstrations
of practical use cases of GNU Radio would be favored.

Registration and proposal submission (deadline: *April 15*): https://gnuradio-eu-21.sciencesconf.org/

The tentative set of tutorials is scheduled and described at
https://gnuradio-eu-21.sciencesconf.org/resource/page/id/2

The third day (Saturday) will be a joint meeting with the German Software Defined Radio
Academy (SDRA) with our contribution focusing on using GNU Radio for ham radio applications.
Again contributions in this field will be broadcast during this joint meeting.

We favor complementing the oral presentation demo with a proceeding manuscript to be uploaded
to pubs.gnuradio.org if complying with the GRCon template found at https://www.gnuradio.org/grcon.tar.gz

For the European GNU Radio organization committee,
looking forward to meeting you virtually in June, JM

--
JM Friedt, FEMTO-ST Time & Frequency, 26 rue de l'Epitaphe, 25000 Besancon, France

Re: Question re Adalm-Pluto, HackRFOne

PLUTO should be supported by gr-iio, and HackRF by gr-osmosdr. Both of those can be install via apt.

On Tue, Feb 23, 2021 at 12:53 PM geraldfenkell <geraldfenkell@computechnics.ca> wrote:

2021-02-23

 

1. I have now got gnu radio installed on a computer using ubuntu 20.04 . I am using       version 3.8 of gnu radio ( I think 3.8.13 but not sure

     which I installed using sudo apt-get .....  

 

2. My question is:   Is there in existence

a. a package that I can add to version 3.8 using a similar sudo apt-get command

    that will add (with all required dependencies) the blocks for the Adalm-Pluto.

b. a package that I can add to version 3.8 using a similar sudo apt-get command

    that will add (with all required dependencies) the blocks for HackRFOne.

 

 

Thank you

 

Jerry

 

 

 

 

Question re Adalm-Pluto, HackRFOne

2021-02-23

 

1. I have now got gnu radio installed on a computer using ubuntu 20.04 . I am using       version 3.8 of gnu radio ( I think 3.8.13 but not sure

     which I installed using sudo apt-get .....  

 

2. My question is:   Is there in existence

a. a package that I can add to version 3.8 using a similar sudo apt-get command

    that will add (with all required dependencies) the blocks for the Adalm-Pluto.

b. a package that I can add to version 3.8 using a similar sudo apt-get command

    that will add (with all required dependencies) the blocks for HackRFOne.

 

 

Thank you

 

Jerry

 

 

 

 

Re: More on IQ modulation

About the Hilbert transform, it's a mathematical operator which is quite complex don't loose time for this if you don't have the math background. Just remind it has the effect of shifting the phase of the negative frequency components of by +90° (​^π⁄₂ radians) and the phase of the positive frequency components by −90° (my first post was not correct)

When we have 2 sidebands in an AM modulated signal, these two sidebands carry the same information based on I and Q signals. We can recover I(t) and q(t) from only one sideband. This is why transmitting AM can be made with 2 or 1 (SSB) sideband to  lower the spectrum bandwith.  Using only 1 sideband to recover the signal while 2 are present in the spectrum will simply be less efficient then using the 2 sideband from the noise point of view.

And Yes the mixer a quite a complex hardware too. Me have numerous type of mixers ( Mixer Basics Primer ) and upconversion is quite different them downcovnversion. Some uses direct conversion (FIF=0) some use an Intermediate Frequency (IF)...

• the ideal basic mixer is similar to a mathematical product of input signal and Carrier sine wave. Hardware realization use a non linear component such as diode, this is quite far from the mathematical product since is generated o lot of undesired harmonics at nFLO+mFIF (n,m being any positive or negative integer).
  
• in figure 1 the shift betweeen LO and RF is used to get and IF at FIF=|FLO-FRF|. Suppose our "IF" is at 0 Hz FLO=FRF.
  

The SSB mixer is obtained by combining several mixers whose input signal and/or carrier are shifted by 90° or -90°. Suppose we get 2 mixers having each 2 side band "correctly shifted", adding the mixed signal of these 2 mixers can result in an USB SSB, and substracting them to an LSB SSB. Corresponding hardware are Double and Triple balanced mixers (figure 6 and 7 in my first reference).

These is no silly question, we all have to learn things we don't learned before from those who know and like to share.

On 22/02/2021 23:58, John Byrne wrote:

Thanks for putting all this together! Unfortunately it sounds like I have massively underestimated the complexity of the whole thing. I don't know what the Hilbert transform is so I have a lot of reading to do before I can really understand most of what you wrote, or the grc file.

But let me ask this for now: when a receiver uses an LO that's the same as the carrier centre frequency, does't that result in the two sidebands being superimposed on each other? That's what I thought generally happens, because we have the sum and the difference for both sidebands. If the sidebands happen to be identical, then all is well. But if the signal in question was generated IQ modulation, then the sidebands are different, and they would interfere with each other. You'd lose the Q information right? That's why I thought the carrier would have to be offset. But you're saying it doesn't. Have I completely misunderstood how down-mixing works?

Sorry if these are silly questions.

On Mon, 22 Feb 2021, at 5:21 PM, Christophe Seguinot wrote:

Hi

Some rapid answers inside the original email

Christophe

On 22/02/2021 19:48, John Byrne wrote:

 As someone with not much radio knowledge, I'm trying to understand IQ modulation. I have a few questions if anyone can help. I recently read the interesting thread on IQ signals, and I also came across this site which has a few articles that helped (https://www.markimicrowave.com/blog/the-why-and-when-of-iq-mixers-for-beginners/).

this article is only related to SSB

But there's still a few things that confuse me. The way I understand it now is in terms of how the sidebands of the modulated I and Q signals add to produce the final RF signal: on the upper side of the carrier, Q is added to I, but on the lower side, Q is subtracted from I (due to the -sin term in the trig identify for cosA*sinB).

You conclusion is quite right, however, this is not due to -sin term. This can be obtained only if I and Q signal are related to each other by a constant phase shift  of -90° at ALL frequencies including positive and negative frequencies .This correspond to Hilbert transform as explained here figure 1  which is not physically existing.

So if Q(t) is the Hilbert transform of I(t), the output of the IQ modulator is and Upper or lower side band SSB.

So we end up with a signal that has two sidebands, but they contain different info. At the receiver, the process happens again: the signal coming out of the I mixer has 2 positive copies of I (one in each sideband), and one positive copy of Q and one negative copy of Q. Combining all these gives 2I, and the opposite thing happens with the Q mixer, so we end up with 2I and 2Q (or maybe they're not x2 because the original signal's power was divided between 2 sidebands?)

Is that the gist of it? I hope so because it makes sense to me. But what's giving me trouble now is this: what happens if either the Tx or the Rx don't use IQ modulation?

 Regarding your reference https://www.markimicrowave.com/blog/the-why-and-when-of-iq-mixers-for-beginners/  we found 3 methods of obtaining an SSB signal. You can combine any modulator (1 out of 3) with any demodulator (1 out of 3) to correctly demodulate the incoming signal.

It can be shown that an AM demodulator can be used to demodulate an SSB modulated signal

The best answer I can come up with is as follows: if the Tx uses IQ but the Rx doesn't, then the Rx would have to use a local oscillator that's offset from the carrier so that the whole signal appears as a single sideband - otherwise the 2 different sidebands will interfere with each other. Is that right? And conversely, if the Tx just produces 2 identical sidebands, but the Rx uses IQ, then the I and Q signals in the Rx will be identical to each other, except for a phase difference right? And we need to combine them to get the full power?

In any case I mentioned above, the carrier frequency should be the same in modulator and demodulator without any shift.

Thanks

John

Graticule for constellation sink

Hello fellow gnuradio citizens.

Hope this day finds you well.

Have an sine/cosine potentiometer attached to an Arduino to serve as an I/Q source. 

Are there other graticule built-in besides the square?

Can a background image be used constellation sink? (adding background-image: ./bg.img; into default QT GUI Theme qss file does not appear to work.

This is working but seems QUITE crude 

Any advise from all you brilliant folks is greatly appreciated.

Thank you for such an amazing tool.

--

If something is requisite, how can it possibly be, prerequisite? 

vanitas vanitatum omnia vanitas
later, steve
http://umn.edu/~barbo

Re: More on IQ modulation

Thanks for putting all this together! Unfortunately it sounds like I have massively underestimated the complexity of the whole thing. I don't know what the Hilbert transform is so I have a lot of reading to do before I can really understand most of what you wrote, or the grc file.

But let me ask this for now: when a receiver uses an LO that's the same as the carrier centre frequency, does't that result in the two sidebands being superimposed on each other? That's what I thought generally happens, because we have the sum and the difference for both sidebands. If the sidebands happen to be identical, then all is well. But if the signal in question was generated IQ modulation, then the sidebands are different, and they would interfere with each other. You'd lose the Q information right? That's why I thought the carrier would have to be offset. But you're saying it doesn't. Have I completely misunderstood how down-mixing works?

Sorry if these are silly questions.

On Mon, 22 Feb 2021, at 5:21 PM, Christophe Seguinot wrote:

Hi

Some rapid answers inside the original email

Christophe

On 22/02/2021 19:48, John Byrne wrote:

 As someone with not much radio knowledge, I'm trying to understand IQ modulation. I have a few questions if anyone can help. I recently read the interesting thread on IQ signals, and I also came across this site which has a few articles that helped (https://www.markimicrowave.com/blog/the-why-and-when-of-iq-mixers-for-beginners/).

this article is only related to SSB

But there's still a few things that confuse me. The way I understand it now is in terms of how the sidebands of the modulated I and Q signals add to produce the final RF signal: on the upper side of the carrier, Q is added to I, but on the lower side, Q is subtracted from I (due to the -sin term in the trig identify for cosA*sinB).

You conclusion is quite right, however, this is not due to -sin term. This can be obtained only if I and Q signal are related to each other by a constant phase shift  of -90° at ALL frequencies including positive and negative frequencies .This correspond to Hilbert transform as explained here figure 1  which is not physically existing.

So if Q(t) is the Hilbert transform of I(t), the output of the IQ modulator is and Upper or lower side band SSB.

So we end up with a signal that has two sidebands, but they contain different info. At the receiver, the process happens again: the signal coming out of the I mixer has 2 positive copies of I (one in each sideband), and one positive copy of Q and one negative copy of Q. Combining all these gives 2I, and the opposite thing happens with the Q mixer, so we end up with 2I and 2Q (or maybe they're not x2 because the original signal's power was divided between 2 sidebands?)

Is that the gist of it? I hope so because it makes sense to me. But what's giving me trouble now is this: what happens if either the Tx or the Rx don't use IQ modulation?

 Regarding your reference https://www.markimicrowave.com/blog/the-why-and-when-of-iq-mixers-for-beginners/  we found 3 methods of obtaining an SSB signal. You can combine any modulator (1 out of 3) with any demodulator (1 out of 3) to correctly demodulate the incoming signal.

It can be shown that an AM demodulator can be used to demodulate an SSB modulated signal

The best answer I can come up with is as follows: if the Tx uses IQ but the Rx doesn't, then the Rx would have to use a local oscillator that's offset from the carrier so that the whole signal appears as a single sideband - otherwise the 2 different sidebands will interfere with each other. Is that right? And conversely, if the Tx just produces 2 identical sidebands, but the Rx uses IQ, then the I and Q signals in the Rx will be identical to each other, except for a phase difference right? And we need to combine them to get the full power?

In any case I mentioned above, the carrier frequency should be the same in modulator and demodulator without any shift.

Thanks

John

Re: More on IQ modulation

Beginner error, I forgot the throttle !

On 22/02/2021 23:21, Christophe Seguinot wrote:

Hi

Some rapid answers inside the original email

Christophe

On 22/02/2021 19:48, John Byrne wrote:

 As someone with not much radio knowledge, I'm trying to understand IQ modulation. I have a few questions if anyone can help. I recently read the interesting thread on IQ signals, and I also came across this site which has a few articles that helped (https://www.markimicrowave.com/blog/the-why-and-when-of-iq-mixers-for-beginners/).

this article is only related to SSB

But there's still a few things that confuse me. The way I understand it now is in terms of how the sidebands of the modulated I and Q signals add to produce the final RF signal: on the upper side of the carrier, Q is added to I, but on the lower side, Q is subtracted from I (due to the -sin term in the trig identify for cosA*sinB).

You conclusion is quite right, however, this is not due to -sin term. This can be obtained only if I and Q signal are related to each other by a constant phase shift  of -90° at ALL frequencies including positive and negative frequencies .This correspond to Hilbert transform as explained here figure 1  which is not physically existing.

So if Q(t) is the Hilbert transform of I(t), the output of the IQ modulator is and Upper or lower side band SSB.

So we end up with a signal that has two sidebands, but they contain different info. At the receiver, the process happens again: the signal coming out of the I mixer has 2 positive copies of I (one in each sideband), and one positive copy of Q and one negative copy of Q. Combining all these gives 2I, and the opposite thing happens with the Q mixer, so we end up with 2I and 2Q (or maybe they're not x2 because the original signal's power was divided between 2 sidebands?)

Is that the gist of it? I hope so because it makes sense to me. But what's giving me trouble now is this: what happens if either the Tx or the Rx don't use IQ modulation?

 Regarding your reference https://www.markimicrowave.com/blog/the-why-and-when-of-iq-mixers-for-beginners/  we found 3 methods of obtaining an SSB signal. You can combine any modulator (1 out of 3) with any demodulator (1 out of 3) to correctly demodulate the incoming signal.

It can be shown that an AM demodulator can be used to demodulate an SSB modulated signal

The best answer I can come up with is as follows: if the Tx uses IQ but the Rx doesn't, then the Rx would have to use a local oscillator that's offset from the carrier so that the whole signal appears as a single sideband - otherwise the 2 different sidebands will interfere with each other. Is that right? And conversely, if the Tx just produces 2 identical sidebands, but the Rx uses IQ, then the I and Q signals in the Rx will be identical to each other, except for a phase difference right? And we need to combine them to get the full power?

In any case I mentioned above, the carrier frequency should be the same in modulator and demodulator without any shift.

Thanks

John

Re: More on IQ modulation

A GR 3.8/3.9 flowgraph to see it in action.

the Hilbert filter output is :

• real part : input signal delayed
• Imag part hilbert transform of input + the same delay

the spectrum show the SSB signal (they are some low peak which can be neglected)

if you enable the sine source:

• real and imaginary part are 90 shifted, whatever the frequency is
  

If you enable the triangle source (with a mean DC value)

• the imaginary part is no longer a triangle, it's the Hilbertrasform of the triangle

On 22/02/2021 19:48, John Byrne wrote:

 As someone with not much radio knowledge, I'm trying to understand IQ modulation. I have a few questions if anyone can help. I recently read the interesting thread on IQ signals, and I also came across this site which has a few articles that helped (https://www.markimicrowave.com/blog/the-why-and-when-of-iq-mixers-for-beginners/).

But there's still a few things that confuse me. The way I understand it now is in terms of how the sidebands of the modulated I and Q signals add to produce the final RF signal: on the upper side of the carrier, Q is added to I, but on the lower side, Q is subtracted from I (due to the -sin term in the trig identify for cosA*sinB).

So we end up with a signal that has two sidebands, but they contain different info. At the receiver, the process happens again: the signal coming out of the I mixer has 2 positive copies of I (one in each sideband), and one positive copy of Q and one negative copy of Q. Combining all these gives 2I, and the opposite thing happens with the Q mixer, so we end up with 2I and 2Q (or maybe they're not x2 because the original signal's power was divided between 2 sidebands?)

Is that the gist of it? I hope so because it makes sense to me. But what's giving me trouble now is this: what happens if either the Tx or the Rx don't use IQ modulation?

The best answer I can come up with is as follows: if the Tx uses IQ but the Rx doesn't, then the Rx would have to use a local oscillator that's offset from the carrier so that the whole signal appears as a single sideband - otherwise the 2 different sidebands will interfere with each other. Is that right? And conversely, if the Tx just produces 2 identical sidebands, but the Rx uses IQ, then the I and Q signals in the Rx will be identical to each other, except for a phase difference right? And we need to combine them to get the full power?

Thanks

John

Re: More on IQ modulation

Hi

Some rapid answers inside the original email

Christophe

On 22/02/2021 19:48, John Byrne wrote:

 As someone with not much radio knowledge, I'm trying to understand IQ modulation. I have a few questions if anyone can help. I recently read the interesting thread on IQ signals, and I also came across this site which has a few articles that helped (https://www.markimicrowave.com/blog/the-why-and-when-of-iq-mixers-for-beginners/).

this article is only related to SSB

But there's still a few things that confuse me. The way I understand it now is in terms of how the sidebands of the modulated I and Q signals add to produce the final RF signal: on the upper side of the carrier, Q is added to I, but on the lower side, Q is subtracted from I (due to the -sin term in the trig identify for cosA*sinB).

You conclusion is quite right, however, this is not due to -sin term. This can be obtained only if I and Q signal are related to each other by a constant phase shift  of -90° at ALL frequencies including positive and negative frequencies .This correspond to Hilbert transform as explained here figure 1  which is not physically existing.

So if Q(t) is the Hilbert transform of I(t), the output of the IQ modulator is and Upper or lower side band SSB.

So we end up with a signal that has two sidebands, but they contain different info. At the receiver, the process happens again: the signal coming out of the I mixer has 2 positive copies of I (one in each sideband), and one positive copy of Q and one negative copy of Q. Combining all these gives 2I, and the opposite thing happens with the Q mixer, so we end up with 2I and 2Q (or maybe they're not x2 because the original signal's power was divided between 2 sidebands?)

Is that the gist of it? I hope so because it makes sense to me. But what's giving me trouble now is this: what happens if either the Tx or the Rx don't use IQ modulation?

 Regarding your reference https://www.markimicrowave.com/blog/the-why-and-when-of-iq-mixers-for-beginners/  we found 3 methods of obtaining an SSB signal. You can combine any modulator (1 out of 3) with any demodulator (1 out of 3) to correctly demodulate the incoming signal.

It can be shown that an AM demodulator can be used to demodulate an SSB modulated signal

The best answer I can come up with is as follows: if the Tx uses IQ but the Rx doesn't, then the Rx would have to use a local oscillator that's offset from the carrier so that the whole signal appears as a single sideband - otherwise the 2 different sidebands will interfere with each other. Is that right? And conversely, if the Tx just produces 2 identical sidebands, but the Rx uses IQ, then the I and Q signals in the Rx will be identical to each other, except for a phase difference right? And we need to combine them to get the full power?

In any case I mentioned above, the carrier frequency should be the same in modulator and demodulator without any shift.

Thanks

John

More on IQ modulation

 As someone with not much radio knowledge, I'm trying to understand IQ modulation. I have a few questions if anyone can help. I recently read the interesting thread on IQ signals, and I also came across this site which has a few articles that helped (https://www.markimicrowave.com/blog/the-why-and-when-of-iq-mixers-for-beginners/).

But there's still a few things that confuse me. The way I understand it now is in terms of how the sidebands of the modulated I and Q signals add to produce the final RF signal: on the upper side of the carrier, Q is added to I, but on the lower side, Q is subtracted from I (due to the -sin term in the trig identify for cosA*sinB).

So we end up with a signal that has two sidebands, but they contain different info. At the receiver, the process happens again: the signal coming out of the I mixer has 2 positive copies of I (one in each sideband), and one positive copy of Q and one negative copy of Q. Combining all these gives 2I, and the opposite thing happens with the Q mixer, so we end up with 2I and 2Q (or maybe they're not x2 because the original signal's power was divided between 2 sidebands?)

Is that the gist of it? I hope so because it makes sense to me. But what's giving me trouble now is this: what happens if either the Tx or the Rx don't use IQ modulation?

The best answer I can come up with is as follows: if the Tx uses IQ but the Rx doesn't, then the Rx would have to use a local oscillator that's offset from the carrier so that the whole signal appears as a single sideband - otherwise the 2 different sidebands will interfere with each other. Is that right? And conversely, if the Tx just produces 2 identical sidebands, but the Rx uses IQ, then the I and Q signals in the Rx will be identical to each other, except for a phase difference right? And we need to combine them to get the full power?

Thanks

John

Re: Issue reporting and Pull Request rules?

I suggest documenting the immediately relevant parts of these procedures using Github's pull request and issue templates:

https://docs.github.com/en/github/building-a-strong-community/about-issue-and-pull-request-templates

The way I've seen it work in other communities is that the templates use commented text to describe the desired best practices. That way everybody opening an issue or PR will have the guidelines right in front of them, but because it's in the template as a comment, it won't show up in the resulting issue/PR description. Checklists can also be useful to nudge people in the direction of doing particular things with every PR. I've found that it helps a lot to on-board new contributors to the way things are done.

Cheers,
Ryan

On 2/22/21 5:00 AM, Martin Braun wrote:
> I think it might help if we rename those labels. Maybe something like "PleasePortThisTo3.9". A less verbose label would also work as long as it conveys the intent.
>
> On Sun, Feb 21, 2021 at 2:33 PM Jeff Long <willcode4@gmail.com <mailto:willcode4@gmail.com>> wrote:
>
> The backport-3.8 label would mean "this PR is against a non-3.8 branch and needs to be ported to 3.8", though it hasn't been used that way consistently. A PR for 3.8 would already be targeted at that branch, so there's no need to also tag it that way. There will also be forward ports. It's likely that, since 3.8 is going to be usable for a while, people will submit bug fixes for it. A PR could be tagged (3.10,3.9,port-3.8) potentially.
>
> Here are some ideas about the process, to get a discussion started:
>
> * TBD: clearly define the meaning of version numbers, with respect to API, ABI and even GRC changes/compatibility.
> * Decide whether the PR is eligible for backporting, and to what branch. This is kind of rough due to the number of different ways changes can affect compilation/linking/runtime.
> o Simple fixes with no API or runtime behavior change can go in the next a.b.c.d version. These version can be tagged often. An example is an internal fix to a calculation.
> o Changes that do not affect the API (except addition of blocks), but that change runtime behavior for the better would go in the next a.b.c version. Block yml may change, causing the need to regenerate a flowgraph, though this would be avoided if possible. Autogenerated code messes up nice versioning rules, so this may continue to be a grey area.
> o API changes (except maybe serious bug fixes?) go in the next minor (a.b) version.
> o Things that cause OOTs a lot of work go in next major version.
> * For smaller, easily understandable changes, a PR could be marked "Backport-a.b", implying that it would be easier for a maintainer to figure out the correct backport. Maintainers can then say "sorry, need more help from the author" if it's a bigger deal than the PR author though it was, it requires testing, etc.
> * For larger changes, the PR author would make separate PRs and work with maintainers to get everything settled. This implies that the PR author builds/tests against each each targeted branch.
> * Issues can be tagged with version numbers. The issue should contain the version (and other info) in text, explaining the environment where the issue was found. The minor versions (a.b) known to be affected would appear as tags.
>
> Any ideas from other projects that have complex dependencies and a small crew of maintainers?
>
> On Sat, Feb 20, 2021 at 6:01 PM Christophe Seguinot <christophe.seguinot@orange.fr <mailto:christophe.seguinot@orange.fr>> wrote:
>
> Hi
>
> As a regular user of GNURadio, I sometime trying to improve the code and made some PR. I came to these questions and observations :
>
> I think It would be a good practice to encourage those reporting issues (and also posting email on this list) to clearly indicates which GR version(s) is (are) concerned. I don't remember having seen such recommendations on GNURadio Github.
>
> And for those making PR, may be we need to propose or expose some rules.
>
> I made a PR for another issue this evening, and was not really aware of what should be done since it concerned 3.8 3.9 and master. So I made 3 PR.
>
> * Is this the right method ?
> * How to avoid fixing a bug on one branch while forgetting that other branches could have the same bug not fixed (which seems to be the case in #4251 <https://github.com/gnuradio/gnuradio/issues/4251>)
> * What is the best method to reduce maintainer work ?
>
> A related question: what is the real meaning of issue label "backport-3.8" ? does it means we must check if this issue is present in GR 3.8, or, something similar?
>
> In case code modifications are light and identical or similar for both branches, is there a simpler methods than sending 3 PR ?
>
> Once again, many thanks to the maintainers and Marcus for his (passed) Mainternership. Gnuradio is really becoming a great tool for SDR and radiocommunications
>
> Regards, Christophe
>

Re: installing from PPA gnuradio 3.9 under Ubuntu 18.04 : libvolk dependence issue

I understand maintaining PPA is also a huge work. Unfortunately, I'm not able to help at this.

As I use school computers I Can't switch to Ubuntu 20.04.

Don't worry for my students, they will use GR 3.8

On 22/02/2021 15:36, Josh wrote:

Christophe,

There are some dependencies I have not yet sorted out in the PPA for Ubuntu 18.04 which is why 3.9 is only readily available for 20.04.  Namely volk - in the cmake for gnuradio, the min version of volk is 2.4.1 which is not packaged for Ubuntu.  The way I have approached volk to this point in the PPA is just backporting the amazing work that @mait does for Debian.  But since Ubuntu (and especially the previous release of Ubuntu) stays a bit behind Debian, it makes it more difficult to just backport packages over.  For volk, 2.4.1 introduced a dependence on libcpufeatures which does not backport directly.  Are you able to have your students work on 20.04?

To get 3.9 packaged for 18.04 I think would require packaging volk (rather than just copying it over) which is possible, just work that I haven't had time to do.

Improving the ability to install GNU Radio through package managers is one of the key areas we want to focus on in the near future (and Ubuntu is a big part of that), so if anyone in the community is interested in getting involved to help out on this front, please let me know!

Thanks,

Josh

On Mon, Feb 22, 2021 at 7:54 AM Christophe Seguinot <christophe.seguinot@orange.fr> wrote:

Hi

I would like for my students to install from PPA, gnuradio 3.9 under Ubuntu 18.04 (I prefer 3.9 which I could use for a longer term, if not possible I will switch to 3.8)

I made this numerous times under Ubuntu 20.04 but get the following issue for Ubuntu 18.04.

From installingGR page

• To access the current released version (3.9), add the gnuradio/gnuradio-releases ppa (removing other gnuradio ppas if already configured)
• $ sudo add-apt-repository ppa:gnuradio/gnuradio-releases

First issue: ppa:gnuradio/gnuradio-master contains 3.9 for focal but 3.8 for bionic . This is not consistent with installingGR page

    3.9.0.0-0~gnuradio~focal-1
    3.8.2.0-0~gnuradio~bionic-1

then switched to ppa:gnuradio/gnuradio-master (also removed ppa:gnuradio/gnuradio-releases)

• sudo add-apt-repository ppa:gnuradio/gnuradio-master
  
• sudo apt-get update

then tried to install 3.9.0.0git~master~14059~bionic

• sudo apt install gnuradio

which yield the second issue

• Depend: libvolk2.2 (>= 2.2.0) uninstallable (message translated from french)

Tried to

• sudo apt install libvolk : not found 

Succeeded in installing libvolk2.3

• sudo apt install libvolk2.3

But sudo apt install gnuradio continue failing

• Depend: libvolk2.2 (>= 2.2.0) uninstallable (message translated from french)

Does anyone know how to install from PPA gnuradio 3.9 under Ubuntu 18.04 ?

regards, Christophe

Re: installing from PPA gnuradio 3.9 under Ubuntu 18.04 : libvolk dependence issue

Christophe,

There are some dependencies I have not yet sorted out in the PPA for Ubuntu 18.04 which is why 3.9 is only readily available for 20.04.  Namely volk - in the cmake for gnuradio, the min version of volk is 2.4.1 which is not packaged for Ubuntu.  The way I have approached volk to this point in the PPA is just backporting the amazing work that @mait does for Debian.  But since Ubuntu (and especially the previous release of Ubuntu) stays a bit behind Debian, it makes it more difficult to just backport packages over.  For volk, 2.4.1 introduced a dependence on libcpufeatures which does not backport directly.  Are you able to have your students work on 20.04?

To get 3.9 packaged for 18.04 I think would require packaging volk (rather than just copying it over) which is possible, just work that I haven't had time to do.

Improving the ability to install GNU Radio through package managers is one of the key areas we want to focus on in the near future (and Ubuntu is a big part of that), so if anyone in the community is interested in getting involved to help out on this front, please let me know!

Thanks,

Josh

On Mon, Feb 22, 2021 at 7:54 AM Christophe Seguinot <christophe.seguinot@orange.fr> wrote:

Hi

I would like for my students to install from PPA, gnuradio 3.9 under Ubuntu 18.04 (I prefer 3.9 which I could use for a longer term, if not possible I will switch to 3.8)

I made this numerous times under Ubuntu 20.04 but get the following issue for Ubuntu 18.04.

From installingGR page

• To access the current released version (3.9), add the gnuradio/gnuradio-releases ppa (removing other gnuradio ppas if already configured)
• $ sudo add-apt-repository ppa:gnuradio/gnuradio-releases

First issue: ppa:gnuradio/gnuradio-master contains 3.9 for focal but 3.8 for bionic . This is not consistent with installingGR page

    3.9.0.0-0~gnuradio~focal-1
    3.8.2.0-0~gnuradio~bionic-1

then switched to ppa:gnuradio/gnuradio-master (also removed ppa:gnuradio/gnuradio-releases)

• sudo add-apt-repository ppa:gnuradio/gnuradio-master
  
• sudo apt-get update

then tried to install 3.9.0.0git~master~14059~bionic

• sudo apt install gnuradio

which yield the second issue

• Depend: libvolk2.2 (>= 2.2.0) uninstallable (message translated from french)

Tried to

• sudo apt install libvolk : not found 

Succeeded in installing libvolk2.3

• sudo apt install libvolk2.3

But sudo apt install gnuradio continue failing

• Depend: libvolk2.2 (>= 2.2.0) uninstallable (message translated from french)

Does anyone know how to install from PPA gnuradio 3.9 under Ubuntu 18.04 ?

regards, Christophe

GNU Radio amateur group meeting

Remember this Saturday!

Amateur Radio group meeting
**27 February 2021 16:00 UTC**
Subject: A Look at Project 25 (P25) Digital Radio
Presenter: Aaron Rossetto, National Instruments
See the details at https://wiki.gnuradio.org/index.php/Talk:HamRadio
No registration required.

73,
--
Barry Duggan KV4FV
https://github.com/duggabe

[Announcement] Even More Shift in Maintainership

Hi all,

and also thanks to Marcus from our side for taking over this huge role
the last few years. Many of us have been giving Marcus our best wishes
over in chat (in case you were wondering why this thread was quiet), and
you can join in there as well if you like.

But that's not why I'm writing this email! In fact, my tenure as interim
maintainer has already ended.
We have not one, but two people stepping up into these big shoes:

Josh Morman will become the new master branch maintainer. That means the
buck stops with him on all decisions regarding the future development of
GNU Radio. This is particularly fortunate, since Josh is also the lead
developer on the future GNU Radio runtime (see his talk with Basti B. at
FOSDEM, or our newsched repository).

Jeff Long (you might know him as willcode4) will become the maintainer
for our stable branches (maint-3.8 and maint-3.9). This is another
evolution for us, since we've never had a dedicated stable branch
maintainer. The role of stable branch maintainer is different from the
master branch maintainer, since on those branches, we need to make sure
we don't break anyone's software, rather than incorporating all the new
features.

I am very happy about to welcome Josh and Jeff in these roles, and I
hope everyone else here will join me in doing so. Please give them all
ther respect and help they need to keep pushing our great project forward!

Cheers,
Martin

On 2/18/21 7:13 PM, Marcus Müller wrote:
> Dear GNU Radio community,
>
> at FOSDEM 2018, I was asked whether I'd be happy to take over maintainership of the GNU
> Radio project, something I've been very eager to do; by then, I had known the community
> for a little more than 8 years, and the project had grown to be an important factor in
> what I did on a day-to-day scale. It's been basically become family, anyways, and I was
> asked to play a decisive role in that.
>
> That maintainership came with a role as an software, and what's more important, ecosystem
> architect. That's something I quite enjoyed, as it means that as long as there's direction
> and progress towards that, I got to shape what my favourite software project looks like.
> Pair that with the incredible amount of talent and resources that go into the most
> prolific SDR framework in the solar system, and you've got really quite a grand thing
> going on there! It's really been more akin to asking giants to move hills in a way that
> suits the scenery than wielding a hoe to shape one's own garden. And it's really been a
> fun, rewarding, and hopefully productive time:
>
> In these three years, we've managed to finally move from the 3.7 era to a modern 3.8 era,
> by which we succeeded to get the GNU Radio cart out stasis, and we've even went another
> step and started the 3.9 era, where I hope modern tools and perspectives on software
> development allow GNU Radio to move at a high speed.
>
> This might be a good time to give the authority to be the one to make calls back to the
> project. This means the General Assembly and the GNU Radio board will figure out how to
> find a successor for my former position. For the meantime, Derek Kozel and Martin Braun
> will take that power and use it for the best of the project for the near future.
>
> I'll of course still be involved with GNU Radio (wouldn't know which other project could
> stand me...), but will be able to focus on concrete aspects, which might both be on the
> community side, as well as on technical projects. It's just that we're shifting away from
> me being a bottleneck to development!
>
> I'm very grateful that Martin and Derek found the time to take over this responsibility,
> especially since I know they share my enthusiasm for the project, SDR and its users.
>
> Best regards,
> Marcus
>

installing from PPA gnuradio 3.9 under Ubuntu 18.04 : libvolk dependence issue

Hi

I would like for my students to install from PPA, gnuradio 3.9 under Ubuntu 18.04 (I prefer 3.9 which I could use for a longer term, if not possible I will switch to 3.8)

I made this numerous times under Ubuntu 20.04 but get the following issue for Ubuntu 18.04.

From installingGR page

• To access the current released version (3.9), add the gnuradio/gnuradio-releases ppa (removing other gnuradio ppas if already configured)
• $ sudo add-apt-repository ppa:gnuradio/gnuradio-releases

First issue: ppa:gnuradio/gnuradio-master contains 3.9 for focal but 3.8 for bionic . This is not consistent with installingGR page

    3.9.0.0-0~gnuradio~focal-1
    3.8.2.0-0~gnuradio~bionic-1

then switched to ppa:gnuradio/gnuradio-master (also removed ppa:gnuradio/gnuradio-releases)

• sudo add-apt-repository ppa:gnuradio/gnuradio-master
  
• sudo apt-get update

then tried to install 3.9.0.0git~master~14059~bionic

• sudo apt install gnuradio

which yield the second issue

• Depend: libvolk2.2 (>= 2.2.0) uninstallable (message translated from french)

Tried to

• sudo apt install libvolk : not found 

Succeeded in installing libvolk2.3

• sudo apt install libvolk2.3

But sudo apt install gnuradio continue failing

• Depend: libvolk2.2 (>= 2.2.0) uninstallable (message translated from french)

Does anyone know how to install from PPA gnuradio 3.9 under Ubuntu 18.04 ?

regards, Christophe

Re: Issue reporting and Pull Request rules?

I think it might help if we rename those labels. Maybe something like "PleasePortThisTo3.9". A less verbose label would also work as long as it conveys the intent.

On Sun, Feb 21, 2021 at 2:33 PM Jeff Long <willcode4@gmail.com> wrote:

The backport-3.8 label would mean "this PR is against a non-3.8 branch and needs to be ported to 3.8", though it hasn't been used that way consistently. A PR for 3.8 would already be targeted at that branch, so there's no need to also tag it that way. There will also be forward ports. It's likely that, since 3.8 is going to be usable for a while, people will submit bug fixes for it. A PR could be tagged (3.10,3.9,port-3.8) potentially.

Here are some ideas about the process, to get a discussion started:

• TBD: clearly define the meaning of version numbers, with respect to API, ABI and even GRC changes/compatibility.
• Decide whether the PR is eligible for backporting, and to what branch. This is kind of rough due to the number of different ways changes can affect compilation/linking/runtime.
• Simple fixes with no API or runtime behavior change can go in the next a.b.c.d version. These version can be tagged often. An example is an internal fix to a calculation.
• Changes that do not affect the API (except addition of blocks), but that change runtime behavior for the better would go in the next a.b.c version. Block yml may change, causing the need to regenerate a flowgraph, though this would be avoided if possible. Autogenerated code messes up nice versioning rules, so this may continue to be a grey area.
• API changes (except maybe serious bug fixes?) go in the next minor (a.b) version.
• Things that cause OOTs a lot of work go in next major version.
• For smaller, easily understandable changes, a PR could be marked "Backport-a.b", implying that it would be easier for a maintainer to figure out the correct backport. Maintainers can then say "sorry, need more help from the author" if it's a bigger deal than the PR author though it was, it requires testing, etc.
• For larger changes, the PR author would make separate PRs and work with maintainers to get everything settled. This implies that the PR author builds/tests against each each targeted branch.
• Issues can be tagged with version numbers. The issue should contain the version (and other info) in text, explaining the environment where the issue was found. The minor versions (a.b) known to be affected would appear as tags.

Any ideas from other projects that have complex dependencies and a small crew of maintainers?

On Sat, Feb 20, 2021 at 6:01 PM Christophe Seguinot <christophe.seguinot@orange.fr> wrote:

Hi

As a regular user of GNURadio, I sometime trying to improve the code and made some PR. I came to these questions and observations :

I think It would be a good practice to encourage those reporting issues (and also posting email on this list) to clearly indicates which GR version(s) is (are) concerned. I don't remember having seen such recommendations on GNURadio Github.

And for those making PR, may be we need to propose or expose some rules.

I made a PR for another issue this evening, and was not really aware of what should be done since it concerned 3.8 3.9 and master. So I made 3 PR.

• Is this the right method ?
  
• How to avoid fixing a bug on one branch while forgetting that other branches could have the same bug not fixed (which seems to be the case in #4251)
• What is the best method to reduce maintainer work ?
  

A related question: what is the real meaning of issue label "backport-3.8" ? does it means we must check if this issue is present in GR 3.8, or, something similar?

In case code modifications are light and identical or similar for both branches, is there a simpler methods than sending 3 PR ?

Once again, many thanks to the maintainers and Marcus for his (passed) Mainternership. Gnuradio is really becoming a great tool for SDR and radiocommunications

Regards, Christophe

Re: Correlation Estimator corr_est_cc "threshold" meaning

Achilleas,

Thank you for the detailed analysis of the threshold parameter - I know I have been tripped up using this block in the past and made various workarounds to have a settable threshold.  It is probably worth updating the documentation and parameter descriptions in the code so that users - just created an issue (https://github.com/gnuradio/gnuradio/issues/4273) in the github tracker so we don't lose sight of this.

Thanks,

Josh

On Fri, Feb 19, 2021 at 8:34 PM Achilleas Anastasopoulos <anastas@umich.edu> wrote:

Hi all,

I have been playing a bit with the "corr_est_cc" block and I was banging my head to understand the meaning of the parameter "threshold".

In all examples it seems to be a number VERY close to 1.

The documentation is cryptic:

" Threshold of correlator, relative to a 100% correlation (1.0). Default is 0.9."

Upon inspection of the code it is clear that there is a mixup between the 

quantities "threshold" and "1-probability of false alarm".

The code defines

d_pfa = -logf(1.0f-threshold);

which is clearly not the intended use: the pfa cannot be the log of something!

In fact, what is meant is that

===>     THRESHOLD = -logf(PFA);  

The smaller the PFA the larger the threshold should be.

This explains why we need to put a number close to 1 as "threshold" (which is actually 1-PFA).

Further down the code it shows how THRESHOLD is meant to be used:

float detection = 0;
for(int i = 0; i < noutput_items; i++) {
        detection += d_corr_mag[i];
 }
 detection /= static_cast<float>(noutput_items);
 detection *= d_pfa;   <========================

Clearly, the average magnitude is evaluated and then it is multiplied by "d_pfa"

which is meaningless, unless (as mentioned above) you interpret this as

detection *= THRESHOLD;

To summarize:

-------------------

What is shown as "pfa" in the code is actually a THRESHOLD

What is shown as "threshold" in the code is actually 1-PFA.

The user actually inputs 1-PFA (erroneously named "threshold").

I hope this will help anyone having similar issues understanding how this block works.

best

Achilleas

Re: Issue reporting and Pull Request rules?

The backport-3.8 label would mean "this PR is against a non-3.8 branch and needs to be ported to 3.8", though it hasn't been used that way consistently. A PR for 3.8 would already be targeted at that branch, so there's no need to also tag it that way. There will also be forward ports. It's likely that, since 3.8 is going to be usable for a while, people will submit bug fixes for it. A PR could be tagged (3.10,3.9,port-3.8) potentially.

Here are some ideas about the process, to get a discussion started:

• TBD: clearly define the meaning of version numbers, with respect to API, ABI and even GRC changes/compatibility.
• Decide whether the PR is eligible for backporting, and to what branch. This is kind of rough due to the number of different ways changes can affect compilation/linking/runtime.
• Simple fixes with no API or runtime behavior change can go in the next a.b.c.d version. These version can be tagged often. An example is an internal fix to a calculation.
• Changes that do not affect the API (except addition of blocks), but that change runtime behavior for the better would go in the next a.b.c version. Block yml may change, causing the need to regenerate a flowgraph, though this would be avoided if possible. Autogenerated code messes up nice versioning rules, so this may continue to be a grey area.
• API changes (except maybe serious bug fixes?) go in the next minor (a.b) version.
• Things that cause OOTs a lot of work go in next major version.
• For smaller, easily understandable changes, a PR could be marked "Backport-a.b", implying that it would be easier for a maintainer to figure out the correct backport. Maintainers can then say "sorry, need more help from the author" if it's a bigger deal than the PR author though it was, it requires testing, etc.
• For larger changes, the PR author would make separate PRs and work with maintainers to get everything settled. This implies that the PR author builds/tests against each each targeted branch.
• Issues can be tagged with version numbers. The issue should contain the version (and other info) in text, explaining the environment where the issue was found. The minor versions (a.b) known to be affected would appear as tags.

Any ideas from other projects that have complex dependencies and a small crew of maintainers?

On Sat, Feb 20, 2021 at 6:01 PM Christophe Seguinot <christophe.seguinot@orange.fr> wrote:

Hi

As a regular user of GNURadio, I sometime trying to improve the code and made some PR. I came to these questions and observations :

I think It would be a good practice to encourage those reporting issues (and also posting email on this list) to clearly indicates which GR version(s) is (are) concerned. I don't remember having seen such recommendations on GNURadio Github.

And for those making PR, may be we need to propose or expose some rules.

I made a PR for another issue this evening, and was not really aware of what should be done since it concerned 3.8 3.9 and master. So I made 3 PR.

• Is this the right method ?
  
• How to avoid fixing a bug on one branch while forgetting that other branches could have the same bug not fixed (which seems to be the case in #4251)
• What is the best method to reduce maintainer work ?
  

A related question: what is the real meaning of issue label "backport-3.8" ? does it means we must check if this issue is present in GR 3.8, or, something similar?

In case code modifications are light and identical or similar for both branches, is there a simpler methods than sending 3 PR ?

Once again, many thanks to the maintainers and Marcus for his (passed) Mainternership. Gnuradio is really becoming a great tool for SDR and radiocommunications

Regards, Christophe

Re: Suggestion for an SDR computer

Hi Moses,

2GSps sounds like a lot of samples. Assuming you have 16bit I and Q that
would be around 64Gbit/s (4 * 8bit * 2e9) if streamed continuously.
Thus, I'd focus on whatever interface you need to get your samples in
and out of your CPU.

In my experience GNU Radio flowgraphs do not require a lot of RAM. I
focused on core count and high CPU frequency.

Cheers
Johannes

On 20.02.21 22:27, Moses Browne Mwakyanjala wrote:
> Hi everyone,
> I will be acquiring a frontend that could receive up to 2 Gsps. The
> frontend has an FPGA that could host user-defined VHDL signal processing
> RTL. It can also stream data directly to the CPU or GPU. I understand
> that using the FPGA or the GPU could be quite efficient. BUT, I want the
> signal processing functions done in the CPU whereby the waveform is
> processed in GNU Radio (or other C++ implementations). I'm currently
> looking for a computer that could handle this sample rate. What kind of
> specs do you think I could look for (RAM, CPU frequency, cache size
> etc).? What specific products would you recommend?
>
> Regards,
> Moses.

gr-satellites

Hi - all the tests were all failing for make test in gr-satellite - and
test.sh.

There was no module 'construct' installed.

I downloaded it and installed in /usr/local and  then all the tests
passed - including the test.sh script.

Also, there was no contact email address in the "satellite_teams.md"
file - just a name.

-- Cinaed

Issue reporting and Pull Request rules?

Hi

As a regular user of GNURadio, I sometime trying to improve the code and made some PR. I came to these questions and observations :

I think It would be a good practice to encourage those reporting issues (and also posting email on this list) to clearly indicates which GR version(s) is (are) concerned. I don't remember having seen such recommendations on GNURadio Github.

And for those making PR, may be we need to propose or expose some rules.

I made a PR for another issue this evening, and was not really aware of what should be done since it concerned 3.8 3.9 and master. So I made 3 PR.

• Is this the right method ?
  
• How to avoid fixing a bug on one branch while forgetting that other branches could have the same bug not fixed (which seems to be the case in #4251)
• What is the best method to reduce maintainer work ?
  

A related question: what is the real meaning of issue label "backport-3.8" ? does it means we must check if this issue is present in GR 3.8, or, something similar?

In case code modifications are light and identical or similar for both branches, is there a simpler methods than sending 3 PR ?

Once again, many thanks to the maintainers and Marcus for his (passed) Mainternership. Gnuradio is really becoming a great tool for SDR and radiocommunications

Regards, Christophe

Re: Suggestion for an SDR computer

There is essentially no way on gods little green planet that you will process 2Gsps on the CPU. You will really need to pre-process within your FPGA framework.

Sent from my iPhone

> On Feb 20, 2021, at 4:29 PM, Moses Browne Mwakyanjala <mbkitine@gmail.com> wrote:
>
> 
> Hi everyone,
> I will be acquiring a frontend that could receive up to 2 Gsps. The frontend has an FPGA that could host user-defined VHDL signal processing RTL. It can also stream data directly to the CPU or GPU. I understand that using the FPGA or the GPU could be quite efficient. BUT, I want the signal processing functions done in the CPU whereby the waveform is processed in GNU Radio (or other C++ implementations). I'm currently looking for a computer that could handle this sample rate. What kind of specs do you think I could look for (RAM, CPU frequency, cache size etc).? What specific products would you recommend?
>
> Regards,
> Moses.