Re: Could not find a Constellation Demod that goes with the Constellation Modulator

[Cinaed Simson]

Hi George - please don't send me private email - please keep the 
discussion on the mailing list.


It's called Constellation Decoder or Receiver - depending - see the 
TutoriaksSimulations link.


-- Cinaed

On 7/22/20 9:23 PM, George Edwards wrote:
Thanks Cinaed! I could not find a demod block that goes with the 
constellation mod block. George


On Wed, Jul 22, 2020, 12:50 PM Cinaed Simson > wrote:


Hi George - use the search window near the top of the GUI near the
right
hand side -  third block in from the right.  When you the mouse
pointer
on it and should say "Search for a block by name (or key)" - then
type
in your request.

You can also find more information in the guided tutorials under
simulations

https://wiki.gnuradio.org/index.php/TutorialsSimulations


-- Cinaed


On 7/22/20 9:51 AM, George Edwards wrote:
> Hello,
>
> Is there a constellation Demodulator that goes with the
Constellation
> Modulator in the Gnuradio blocks? Any suggestions on how to
build one
> with the available blocks?
>
> Building it will be tricky because the available blocks would
need to
> do the signal processing that captures the correct sampling time at
> 1-sample per symbol.
>
> Thanks for your help.
>
> Regards,
> George

Re: laptop recommendations

[lists]

  Though I'm currently on a ThinkPad, I like Dell Latitude as well. I prefer their corporate line over XPS, mostly because if you break something, say a keyboard, they have service manuals and parts. https://www.dell.com/learn/us/en/70/campaigns/xps-vs-latitude-heaI bought my last Dell Latitude from their refurb store. It was a full blown ATG cop car notebook. Over a thousand nits of illumination. It was also a full kilobuck off of list and from what I could tell, brand new. What happened is someone configured it oddly. The drive was small and it had very little ram. I put in a SSD and maxed out the RAM. Very simple to do when you have service manuals. The problem I had with the Dell was Intel just screwed up the GPU driver. Now with Linux, you can  run on open source drivers, but they were dog slow. The notebook still lives but if you can't Google Earth (or other graphics), it is no good. However my point still stands in that these Latitude notebooks can last longer because they are designed to be repaired. Break a keyboard, not problem. I actually added a second SSD to it because you could pull the optical drive and replace it with another hard drive. The Latitudes tend to be thicker, having bigger fans. Now I am currently on a ThinkPad. This is basically Lenovo corporate instead of Dell corporate. You get a full service manual and a source for parts. The big advantage is AMD graphics. I am using a T495 on opensuse 15.1, soon to upgrade to 15.2. With Dell your GPU choice is Intel or Nvidia. Nvidia graphics can be trouble on Linux. With  AMD Ryzen, the open source driver for the GPU is pretty good. You don't have to use the closed source driver which is the case with Nvidia and thus Dell.    You do have the option of using the AMD closed source drivers as well.      I bought the T495 with just the upgraded display as my only special option. It is only 400 nits but suitable for outdoor use. The stock display was 200 nits I think. I got the smallest ram and SSD. I put in a 16GByte ram module for way less than Lenovo would charge, taking it up to 24Gbytes of RAM. I replace the SSD with a rather expensive Samsung high endurance 1Tbyte nvme2 SSD. You can dual boot the notebook but you need a special version of grub suitable for EFI.                                                                            Note Linus himself has gone AMD. https://www.theregister.com/2020/05/24/linus_torvalds_adopts_amd_threadripper/I have no issues with Intel CPUs, but I don't want to use their GPUs and absolutely don't want Nvidia. You may recall Linus commenting on Nvidia with his middle finger.  From: noahthurs...@email.arizona.eduSent: July 22, 2020 2:08 PMTo: discuss-gnuradio@gnu.orgSubject: laptop recommendations  Hello, I’m looking to buy a linux laptop specifically for gnuradio with pybombs. Does anyone have specific hardware recommendations that work well or to avoid? Similarly, is it safe to use the most recent version of Ubuntu (20.04 LTS)? I’ve been mostly considering Dells because of their extensive ubuntu support. Any feedback or advice is appreciated! Thank you,Noah 

Re: laptop recommendations

[Jeff Dumps]

Hi Noah,

As far as Ubuntu goes, before you purchase - check compatibility here:
https://certification.ubuntu.com/desktop
You might start out at 18.04 and try upgrading to see how things do, but if
it worked for 18.04 chances are you'll be okay on 20.04.

Pay close attention to the chipsets listed and make sure you verify that
the specific laptop you are purchasing has the supported chipsets listed.
I have made the mistake of buying a Dell 5579 laptop and it had a different
network adapter chipset than the 5579 that was listed on the Ubuntu
certification.
Some retailers don't make the chipset information available which can be a
huge pain when trying to ID the correct hardware. The lesson learned is
that not all 5579s will be fully compatible.

You will want to verify requirements that your SDR will need if you plan on
connecting an SDR to the laptop. I wanted to use an Ettus USRP N200 with
that 5579, but since the networking chipset wasn't compatible I had to
resort to using an ethernet to USB dongle.
The USB dongle didn't play nice with the USRP (degraded performance) but it
worked for the specific application.

You can also special order the laptop preloaded with Ubuntu directly from
the manufacturer - it may take a little longer to get. I am not sure what
version they are shipping with, you'll have to check.
I would try to go for an i7 and 16G RAM minimum. You'll want more
cores/power/memory if you plan on compiling from source. For example; I'm
currently using a Lenovo IdeaPad with an i3 and 8GB ram to run GRC and SDRs
from, but not doing really heavy DSP. Runs smooth but starts to slow down a
little if I'm recording IQ data and displaying Fosphor at the same time.

I hope that helps.

Jeff

On Wed, Jul 22, 2020 at 3:08 PM Noah Riley Thurston <
noahthurs...@email.arizona.edu> wrote:

> Hello,
>
> I’m looking to buy a linux laptop specifically for gnuradio with pybombs.
> Does anyone have specific hardware recommendations that work well or to
> avoid? Similarly, is it safe to use the most recent version of Ubuntu
> (20.04 LTS)? I’ve been mostly considering Dells because of their extensive
> ubuntu support.
>
> Any feedback or advice is appreciated!
>
> Thank you,
> Noah
>

Re: laptop recommendations

[Alex Humberstone]

The Dell XPS are really nice laptops. I'm using one right now, and I love
it. I'm running Ubuntu 20.04 and GNU Radio, and I got an Ettus USRP B210
and X310 connected up to it, and it's 100% solid. I definitely recommend
it. I'd also suggest that you run Ubuntu 20.04 to get all the latest
drivers and latest kernel, which you might need or want if you're buying a
brand new XPS. Dell hardware runs well with Linux, so you should not have
any problems, especially with Ubuntu 20.04. The only negative was price.
For me at least it was an expensive laptop, but you get what you pay for,
and I'm still very happy with it, and it was worth the price, but damn
they're not cheap. Hope this helps.



On Wed, 22 Jul 2020 at 16:08, Noah Riley Thurston <
noahthurs...@email.arizona.edu> wrote:

> Hello,
>
> I’m looking to buy a linux laptop specifically for gnuradio with pybombs.
> Does anyone have specific hardware recommendations that work well or to
> avoid? Similarly, is it safe to use the most recent version of Ubuntu
> (20.04 LTS)? I’ve been mostly considering Dells because of their extensive
> ubuntu support.
>
> Any feedback or advice is appreciated!
>
> Thank you,
> Noah
>


-- 
Sincerely,
Alex-M-Humberstone
PhD Student
Klipsch School of Electrical Engineering
New Mexico State University
Las Cruces, New Mexico

laptop recommendations

[Noah Riley Thurston]

Hello,

I’m looking to buy a linux laptop specifically for gnuradio with pybombs.
Does anyone have specific hardware recommendations that work well or to
avoid? Similarly, is it safe to use the most recent version of Ubuntu
(20.04 LTS)? I’ve been mostly considering Dells because of their extensive
ubuntu support.

Any feedback or advice is appreciated!

Thank you,
Noah

Re: Could not find a Constellation Demod that goes with the Constellation Modulator

[Cinaed Simson]

Hi George - use the search window near the top of the GUI near the right 
hand side -  third block in from the right.  When you the mouse pointer 
on it and should say "Search for a block by name (or key)" - then type 
in your request.


You can also find more information in the guided tutorials under 
simulations


  https://wiki.gnuradio.org/index.php/TutorialsSimulations

-- Cinaed


On 7/22/20 9:51 AM, George Edwards wrote:

Hello,

Is there a constellation Demodulator that goes with the Constellation 
Modulator in the Gnuradio blocks? Any suggestions on how to build one 
with the available blocks?


Building it will be tricky because the available blocks would need to 
do the signal processing that captures the correct sampling time at 
1-sample per symbol.


Thanks for your help.

Regards,
George

Re: Byte Boundary alignment

[lannan jiang]

Hi Kevin,
   Thank you for your reply. Your simple method is what I am trying to do here. 
However, I do not know how to prepend each message with a preamble of known 
bytes in GNU Radio. Could you please elaborate on this? Did you mean that you 
are doing this in Python? Is it with the embedded python block? 
   I have been looking at the Packet Header Generator, i was thinking adding a 
preamble using that, but haven’t had any luck so far. 

   Best regards,
   Lannan 
> On Jul 22, 2020, at 1:59 PM, Kevin McQuiggin (SFU)  wrote:
> 
> Hi Lannan:
> 
> I am working on a similar project in the digital not audio domain.
> 
> There are two approaches.  The simple one, which I am currently using, is to 
> prepend each message with a preamble of known bytes.  Then you recover byte 
> alignment from the received bitstream by using a sliding window over the 
> received bitstream looking for the known pattern.  This gives you an offset 
> and you can recover bytes from there.  
> 
> I am currently doing this realignment in a small Python program that I will 
> eventually integrate into a custom block.
> 
> This method is simple but it has no error detection or correction.  It works 
> for my project, however!  I can transfer megabytes of data successfully at 
> about 130M bps.
> 
> As it’s a learning project, however, I am currently working on a more 
> sophisticated approach.  Please read the gnuradio tutorial on packet 
> transmission and recovery.  Just Google “gnuradio packet” and the article 
> will be near the top.
> 
> This article covers adding proper headers, CRCs, forward error correction et 
> cetera and moving to use of a burst transmission approach.  It is quite 
> complicated but I have the basic techniques “sort of” working with my 
> project.  My goal is to integrate the discussed techniques into the project 
> so I can make my data transfers more robust.
> 
> The article Co es with example flowgraphs which are complicated at first look 
> but through reading the (excellent) explanatory text it becomes clear as to 
> which parts do what, and why.
> 
> Hope this helps.  If you want to discuss the sliding window basic approach 
> then let me know.  As another responder noted you could also conceivably use 
> a Correlation block for this, but you might have to move your data stream 
> into the gnuradio messaging side first.
> 
> Kevin
> 
> 
> 
> 
> 
> Sent from my iPad
> 
> On Jul 22, 2020, at 08:40, lannan jiang  > wrote:
> 
>> 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 



smime.p7s
Description: S/MIME cryptographic signature

Re: Correlation Estimator Questions

[Andy Walls]

> Date: Sat, 18 Jul 2020 12:06:11 -0400
> From: Nicholas Savka 
> To: discuss-gnuradio@gnu.org
> Subject: Correlation Estimator Questions
> 
> Hello,
> 
> My ultimate goal is to use the correlation estimator block for
> synchronization using a preamble in order to send packets of digital
> data
> from one sdr to another, both running gnu-radio. In order to
> understand how
> the correlation estimator works, I am looking at the provided example
> "example_corr_est_and_phase_sync." It looks like this example is
> using a
> BPSK modulation scheme and I am trying to modify it to work with QPSK
> instead to make sure I know how it works, but I am running into
> problems. I
> have four questions:
> 
> 1.)
> I do not understand the purpose of the "tag marking delay" entry in
> the
> correlation estimator block. How should this value be determined?

The block will output a tag on the output sample stream when it detects
a correlation.

By default (delay of 0) this tag will be set at the start of your
preamble.

The tag marking delay lets you adjust the position of the output tag in
units of samples.  You should set this empirically to be at the center
of the first symbol in the preamble.


> 2.)
> How does the correlation estimator "talk to" the costas loop and
> Polyphase
> Clock Sync blocks? Is there something going on behind the scenes here
> that
> I cannot see? Is it somehow passing the frequency/phase correction
> information to these blocks?

Using the time_est tag on the output sample stream, to tell the clock
sync blocks, "This is the approximate center of a symbol, reset your
symbol clock timing recovery".

A CPO estimate is also output on the "phase_est", but I don't think any
block uses it.


> 3.)
> I think my main issue is that I do not understand how to format the
> "Data
> Vector" entry in the "Modulate Vector" block. This is my (probably
> incorrect) understanding:
> 
> I want my preamble symbols to be [1+1j, 1+1j, 1+1j, -1-1j, -1-1j,
> 1+1j,
> -1-1j]
> 
> My constellation object has the following parameters:
> Symbol Map: [0,1,2,3]
> Constellation Points: [(-1-1j),(-1+1j),(1-1j),(1+1j)]
> 
> Therefore, my desired preamble would map to: [3,3,3,0,0,3,0]
> So, in the "Data Vector" box in the "Modulate Vector" block, I should
> enter:  [0x3,0x3,0x3,0x0,0x0,0x3,0x0]



> 4.)
> Why is the Modulate Vector block needed at all? Why can I not simply
> enter
> [1+1j, 1+1j, 1+1j, -1-1j, -1-1j, 1+1j, -1-1j] into the field for
> "Symbols"
> in the correlation estimator block?

The corr_est block "Symbols" input wants the correlation/matched filter
taps (*before* time-reversal and conjugation) for the preamble it is
trying to match.

It can't use symbols from the constellation, because it doesn't make
any assumptions about your pulse filter, you modulation, or how you
truncate the transient of pulse filtering your preamble symbols.

I suggest that you do not use the Modulate Vector block, as it doesn't
give you insight or much control into what it is actually producing.

Instead, produce your correlation/matched filter taps yourself using
MatLab or Octave or Python.  See the attached Octave scripts for a QPSK
example with your preamble and symbol mapping.

BTW, the GNURadio Constallation object will silently scale your
constellation so that the constellation points have an average radius
of 1.  So your constealltion points are really 1/sqrt(2) * [(-1-1j),(-
1+1j),(1-1j),(1+1j)], as far as GNURadio is concerned.


Regards,
Andy

pkg load signal;  % Octave needs this
Fs = 2;  % sample rate
fc = Fs/4 * 1; % optional IF frequency
Rs = 2000;   % symbol rate
sps = Fs/Rs; % samples per symbol

%
% Root raised cosine pulse filter
% https://www.michael-joost.de/rrcfilter.pdf
%
r = 0.22; % bandwidth factor

ntaps = 8 * sps + 1;
st = [-floor(ntaps/2):floor(ntaps/2)] / sps;
hpulse = 1/sqrt(sps) * (sin ((1-r)*pi*st) + 4*r*st.*cos((1+r)*pi*st)) ./ (pi*st.*(1-(4*r*st).^2));

% fix the removable singularities
hpulse(ceil(ntaps/2)) = 1/sqrt(sps) * (1 - r + 4*r/pi); % t = 0 singulatiry
sing_idx = find(abs(1-(4*r*st).^2) < 0.01);
for k = [1:length(sing_idx)]
hpulse(sing_idx) = 1/sqrt(sps) * r/sqrt(2) * ((1+2/pi)*sin(pi/(4*r))+(1-2/pi)*cos(pi/(4*r)));
endfor

% normalize to 0 dB gain
hpulse = hpulse / sum(hpulse);
delay_hpulse = (ntaps-1)/2;

%
% Create a correlation filter for a QPSK preamble
%

% 
preamble_symbols = [3 3 3 0 0 3 0];
constellation_map = 1/sqrt(2) * [-1-1j -1+1j 1-1j 1+1j];

% Map the preamble symbols to the constellation points
preamble_qpsk = constellation_map(preamble_symbols+1);

% Upsample and pulse shape the preamble
x = sps*[upsample(preamble_qpsk, sps), zeros(1, delay_hpulse)];
preamble_bb_init = filter(hpulse, [1], x);

% Discard the most of the transient
preamble_bb = preamble_bb_init(floor(delay_hpulse*0.70)+1:end);
% Set the correlation preak ref to the middle of the last symbol
preamble_bb = preamble_bb(1:(end-ceil(sps*0.75)));

% Modulate the preamble up to IF and then create the correla

Re: Byte Boundary alignment

[Kevin McQuiggin (SFU)]

Hi Lannan:

I am working on a similar project in the digital not audio domain.

There are two approaches.  The simple one, which I am currently using, is to 
prepend each message with a preamble of known bytes.  Then you recover byte 
alignment from the received bitstream by using a sliding window over the 
received bitstream looking for the known pattern.  This gives you an offset and 
you can recover bytes from there.  

I am currently doing this realignment in a small Python program that I will 
eventually integrate into a custom block.

This method is simple but it has no error detection or correction.  It works 
for my project, however!  I can transfer megabytes of data successfully at 
about 130M bps.

As it’s a learning project, however, I am currently working on a more 
sophisticated approach.  Please read the gnuradio tutorial on packet 
transmission and recovery.  Just Google “gnuradio packet” and the article will 
be near the top.

This article covers adding proper headers, CRCs, forward error correction et 
cetera and moving to use of a burst transmission approach.  It is quite 
complicated but I have the basic techniques “sort of” working with my project.  
My goal is to integrate the discussed techniques into the project so I can make 
my data transfers more robust.

The article Co es with example flowgraphs which are complicated at first look 
but through reading the (excellent) explanatory text it becomes clear as to 
which parts do what, and why.

Hope this helps.  If you want to discuss the sliding window basic approach then 
let me know.  As another responder noted you could also conceivably use a 
Correlation block for this, but you might have to move your data stream into 
the gnuradio messaging side first.

Kevin





Sent from my iPad

> On Jul 22, 2020, at 08:40, lannan jiang  wrote:
> 
> 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 

Could not find a Constellation Demod that goes with the Constellation Modulator

[George Edwards]

Hello,

Is there a constellation Demodulator that goes with the Constellation
Modulator in the Gnuradio blocks? Any suggestions on how to build one with
the available blocks?

Building it will be tricky because the available blocks would need to do
the signal processing that captures the correct sampling time at 1-sample
per symbol.

Thanks for your help.

Regards,
George

Re: Byte Boundary alignment

[lannan jiang]

Hi Artur,
   
Thank you for your suggestions! 
And yes, that’s exactly what I am doing. At the receiver, I have a 
polyphase clock sync, CMA equalizer, and a costa loop to correct phase and 
frequency offset. 
I am using Adalm Pluto, which is looping back right now. I am able to align 
the bytes manually by adding delay blocks and compare the bit streams from the 
transmitter and receiver. However, I want to make the bytes align automatically.
I also have been trying to do cross-correlation to find the peak values, 
but the first step for me right now is to find the byte boundary to transmit 
audio.

Best regards,
Lannan 

> On Jul 22, 2020, at 12:13 PM, Artur Nogueira  wrote:
> 
> 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 



smime.p7s
Description: S/MIME cryptographic signature

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
>

Byte Boundary alignment

[lannan jiang]

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

Re: Ubuntu PPA gnuradio-releases doesn't actually install

[Josh]

This should be resolved now in the PPA for Ubuntu 20.04 - thanks to Paul
coming up with the correct naming structure for the package!

Josh

On Thu, Jul 16, 2020 at 9:06 AM Paul Boven  wrote:

> Hi everyone,
>
> Ubuntu 20.04 (Focal) ships with GNU Radio 3.8.1.0~rc1-2build2. I have
> added the gnuradio-releases PPA on my machine, assuming that it would
> get me the slightly newer release version of 3.8.1.0. However, after
> adding the PPA, the Ubuntu provided release candidate version still gets
> installed, not the PPA version.
>
> apt policy gnuradio:
>Installed: 3.8.1.0~rc1-2build2
>Candidate: 3.8.1.0~rc1-2build2
>Version table:
>   *** 3.8.1.0~rc1-2build2 500
>  500 http://nl.archive.ubuntu.com/ubuntu focal/universe amd64
> Packages
>  100 /var/lib/dpkg/status
>   3.8.1.0~gnuradio~focal-1 500
>  500 http://ppa.launchpad.net/gnuradio/gnuradio-releases/ubuntu
> focal/main amd64 Packages
>
> So the package is seen as available, but the OS prefers the rc1 version.
> Is this because the version number string is considered 'higher'
> alphabetically than the version string of the PPA version?
> (3.8.1.0~rc1-2build2 against 3.8.1.0~gnuradio~focal-1). Did we get the
> naming or version numbering convention wrong in the PPA?
>
> After some research, I managed to install the PPA version:
> sudo apt install gnuradio=3.8.1.0~gnuradio~focal-1
>
> This fails at first, because all of the Ubuntu provided gnuradio library
> packages have 3.8.1.0 in their name, whereas the PPA packages don't - so
> they are not seen as up/downgrades, and instead, massive file conflicts
> ensue. These can be resolved by first removing the gnuradio package, and
> all its dependencies, and then installing the gnuradio from the PPA.
> This will then pull in all the dependencies from the PPA as well.
>
> But on the next 'apt upgrade', the PPA version will be replaced again by
> the OS version (causing the same level of mayhem), unless I start
> pinning stuff.
>
> (I don't particularly need anything that's in the release version,
> versus the release candidate version, as far as I know - I was just
> surprised that when switching to this PPA, I didn't actually get the
> release version and had to investigate).
>
> Regards, Paul Boven.
>
>