GSoC Introduction - DPD Project

[Z C]

Hi everyone,

I thought I'd introduce myself/my background discuss some aspects of the 
project I'd like to apply for with interested contributers before submitting a 
draft proposal. Apologies if it's a bit of an essay!

I'm a PhD student in Engineering at Cardiff University investigating linear and 
non-linear modelling techniques for RF/microwave power amplifiers, having also 
completed both the Wireless & Microwave Communication Engineering MSc and my 
electronics BEng at Cardiff. Outside of academia I've been "officially" 
involved in Amateur Radio for over 1 1/2 years now, although you could argue 
it's been longer just not under that banner. I'm now fully licensed in the UK 
and am heavliy involved in the university Amateur Radio society, which is what 
lead me to GNU Radio.

Of all of the GSoC ideas proposed so far, the DPD project is the natural choice 
for me as it's closely related to my interests and research subject in general, 
so that is the one I'd like to apply for. The current situation means I can't 
do any experiments at university, so I'd like to try and make use of my time 
the best I can and take on something challenging that will improve my wider 
skillset. I've mainly used GNU Radio with an RTL-SDR and (increasingly) with an 
ADALM PLUTO in an Amateur Radio context for demonstrations ect, but haven't 
contributed to the project in a meaningful way (yet...); this is a great way to 
start! I've incorporated basic version control (Git) into my workflow and am 
becoming more familiar with Linux (Ubuntu) by the day and this is a great 
excuse to engross myself in it further.

For my coding background, here's a link to my GitHub: 
https://github.com/ZCostello - I've put up a few small C++ sample codes that I 
wrote for some programming challenges, such as a basic RSA decryption tool, and 
I'll be uploading more to it in the next few days.

I've used Matlab quite extensively during my PhD but I'm not sure I'm able to 
put up most of that code on my GitHub until my paper that uses it is finished, 
submitted and (hopefully!) approved. I have, however, put up what I can, such 
as a script I wrote that parses MDIF files (crucially for both measurements and 
simulations which have varying parameters) and sorts them into a Matlab 
non-scalar structure. Apart from being essential for my work, this has also 
been of use for some of the other researchers in my group (especially with some 
minor modifications). Of more relevant langauges, I've mainly used Python, C++ 
and Embedded C. For example, for a summer placement at Merseburg University of 
Applied Sciences in 2015 I worked on designing a smart meter for testing 
purposes using a low-cost ARM Cortex MCU. The project involved porting (and 
finishing) previous work to the relevant platform and adapting it to use an 
RTOS.

The DPD project on your wiki lists 3 main objectives, which I've done a bit of 
research into so far. As power amplifier non-linearities and behavioural models 
are basically my PhD topic (and main headache cause...), I'd like to think I've 
got a solid grounding in the underlying RF/microwave theory required for the 
project and have a reasonable grasp of the literature, so I am confident that 
I'd have the "research phase" done well before the starting date. Regardless of 
whether my proposal is successful or not, I'd recommend the following starting 
points for this idea to people interested:

  *   Cripps, S.C., 2002. Advanced techniques in RF power amplifier design. 
Artech house <- Chapter 5, specifically

  *   Ghannouchi, F.M., Hammi, O. and Helaoui, M., 2015. Behavioral modeling 
and predistortion of wideband wireless transmitters. John Wiley & Sons

One objective I'd definitely like to add is producing clear wiki documentation 
(or in another format if that would be better) and grc files for each aspect as 
I think it would massively enhance the project outcome and increase its 
development prospects going forward.

This is getting a bit long now, so if you've got any feedback so far I'd be 
interested in hearing it.

Thanks,
Zack Costello
costell...@outlook.com

GSoC 2020 Introduction for "DPD implementations"

[Alekh]

Hello GNURadio Community!!

                                            First of all, sorry for 
late introduction. I am Alekh Gupta, a C.S.E. undergraduate at NIT 
Hamirpur. I have been using GNU Radio since last 6 months and have done 
mini projects using it. I have been involved with it on github since 
February,2020.I have done some contributions too and am well versed with 
the coding style and source code of the gnuradio, grc and various 
modules. I have got my CLA process completed too.


   I am interested in working on implementation of "Digital Pre- 
Distortion" Algorithms and create a new OOT module consisting of blocks 
for Pre-Distortion to compensate for  using the gr_modtool and a GUI 
tool to observe the AM-AM and AM-PM responses as well. I am quite used 
to programming in C++, Python and has done some GUI projects and others 
too using Qt Creator and PyQt.My Github profile 
is-https://github.com/alekhgupta1441.


My Potential mentor is - Derek Kozel.

I have gone through the works of my potential mentor available in form 
of slides at: 
https://www.derekkozel.com/talks/FOSDEM2019_Digital_PreDistortion.pdf . 
I am also interested in integrating or involving the mentioned work at 
https://github.com/SrikanthPagadarai/gr-dpd 
 
if feasible since it has many extra dependencies than GNU Radio.I am 
also going to get my own USRP B210 soon!


I am interesting in implementing three algorithms :
1. RLS Algorithm
2.LMSN 
Algorithm
3. LUT 
Based Algorithm
I am interested in working on this even without the GSoC too. I will be 
sharing my GSoC Proposal ASAP.


Regards,
Alekh Gupta
B.Tech. C.S.E.
NIT Hamirpur

Re: Stucked on a trivial interpolation issue

[Brian Padalino]

On Mon, Mar 23, 2020 at 1:57 PM Christophe Seguinot <
christophe.segui...@orange.fr> wrote:

> Great I was searching for this feature.
>
> Nevertheless, they are some things I don't understand in the interpolation
> bloc!!
>

Mathematically, zero stuffing is the correct interpolation mode when
dealing with spectrum.  What the repeat block does is a zero-order hold,
and distorts the spectrum.

Brian

>

Re: Stucked on a trivial interpolation issue

[Christophe Seguinot]

  
  
Great I was searching for this feature. 

Nevertheless, they are some things I don't understand in the
  interpolation bloc!! 



On 23/03/2020 18:32, Brian Padalino
  wrote:


  
  
On Mon, Mar 23, 2020 at 1:26 PM Christophe
  Seguinot 
  wrote:


  

  First answer to myself : 
  
  
I should have used an empty value for parameter
  taps. This only works for Rational resampler, not for
  interpolation.
  
  Question: 
  
  
How can I interpolate without filtering to obtain a
  linear interpolation giving 

 1 1 1 / 1 1 1 / 1 1 1 / 1 1 1 / -1 -1 -1/ -1 -1 -1/
  -1 -1 -1/
  

  
  Try the repeat block:
  
  
    https://wiki.gnuradio.org/index.php/Repeat
  
  
  Brian

  

  

Re: Stucked on a trivial interpolation issue

[Brian Padalino]

On Mon, Mar 23, 2020 at 1:26 PM Christophe Seguinot <
christophe.segui...@orange.fr> wrote:

> First answer to myself :
>
>- I should have used an empty value for parameter taps. This only
>works for Rational resampler, not for interpolation.
>
> Question:
>
>- How can I interpolate without filtering to obtain a linear
>interpolation giving
>- 1 1 1 / 1 1 1 / 1 1 1 / 1 1 1 / -1 -1 -1/ -1 -1 -1/ -1 -1 -1/
>
> Try the repeat block:

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

Brian

Re: Stucked on a trivial interpolation issue

[Christophe Seguinot]

  
  
First answer to myself : 


  I should have used an empty value for parameter taps. This
only works for Rational resampler, not for interpolation.

Question: 


  How can I interpolate without filtering to obtain a linear
interpolation giving 
  
   1 1 1 / 1 1 1 / 1 1 1 / 1 1 1 / -1 -1 -1/ -1 -1 -1/ -1 -1 -1/

On 23/03/2020 17:46, Christophe
  Seguinot wrote:


  
  Hi 
  
  I'm stucked on a trivial interpolation problem. 
  
  I was trying to interpolate a binary source ( in the attached
flowgraph I've witched to a rectangular wave source to analyse
and explain my problem). 
  
  
So I've a rectangular source with 4 sample/period : 1 1 1 1
  -1 -1 -1-1 1... .
I interpolate whith a 3 interpolation factor
I was guessiong to obtain : 1 1 1 / 1 1 1 / 1 1 1 / 1 1 1 /
  -1 -1 -1/ -1 -1 -1/ -1 -1 -1/ ...(/ used to separate group of
  3 samples)

Instead I get: 1 0 0 / 1 0 0 /1 0 0 /1 0 0 /-1 0 0 /-1 0 0
  /-1 0 0 /-1 0 0 /
  
  This seems wrong as compared to paragraph "E2.3. A Note on
Resampling" on this GNURadio Wiki  tutorial
  Does I made something wrong, or Does I've been infected by
Covid19. 
  
  Sincerely,
  Christophe confined at home since 7 days (North of France)
  
  
  
  
  

  

Stucked on a trivial interpolation issue

[Christophe Seguinot]

  
  
Hi 

I'm stucked on a trivial interpolation problem. 

I was trying to interpolate a binary source ( in the attached
  flowgraph I've witched to a rectangular wave source to analyse and
  explain my problem). 


  So I've a rectangular source with 4 sample/period : 1 1 1 1 -1
-1 -1-1 1... .
  I interpolate whith a 3 interpolation factor
  I was guessiong to obtain : 1 1 1 / 1 1 1 / 1 1 1 / 1 1 1 / -1
-1 -1/ -1 -1 -1/ -1 -1 -1/ ...(/ used to separate group of 3
samples)
  
  Instead I get: 1 0 0 / 1 0 0 /1 0 0 /1 0 0 /-1 0 0 /-1 0 0 /-1
0 0 /-1 0 0 /

This seems wrong as compared to paragraph "E2.3. A Note on
  Resampling" on this GNURadio Wiki  tutorial
Does I made something wrong, or Does I've been infected by
  Covid19. 

Sincerely,
Christophe confined at home since 7 days (North of France)





  

options:
  parameters:
author: ''
category: '[GRC Hier Blocks]'
cmake_opt: ''
comment: ''
copyright: ''
description: ''
gen_cmake: 'On'
gen_linking: dynamic
generate_options: qt_gui
hier_block_src_path: '.:'
id: test_interpolation
max_nouts: '0'
output_language: python
placement: (0,0)
qt_qss_theme: ''
realtime_scheduling: ''
run: 'True'
run_command: '{python} -u {filename}'
run_options: prompt
sizing_mode: fixed
thread_safe_setters: ''
title: test_interpolation
window_size: ''
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [8, 8]
rotation: 0
state: enabled

blocks:
- name: interpol
  id: variable
  parameters:
comment: ''
value: '3'
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [288, 12.0]
rotation: 0
state: enabled
- name: samp_rate
  id: variable
  parameters:
comment: ''
value: '32000'
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [184, 12]
rotation: 0
state: enabled
- name: analog_sig_source_x_0
  id: analog_sig_source_x
  parameters:
affinity: ''
alias: ''
amp: '2'
comment: ''
freq: '4000'
maxoutbuf: '0'
minoutbuf: '0'
offset: '-1'
phase: '0'
samp_rate: samp_rate
type: float
waveform: analog.GR_SQR_WAVE
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [88, 268.0]
rotation: 0
state: enabled
- name: analog_sig_source_x_0_0
  id: analog_sig_source_x
  parameters:
affinity: ''
alias: ''
amp: '2'
comment: ''
freq: '1000'
maxoutbuf: '0'
minoutbuf: '0'
offset: '-1'
phase: '0'
samp_rate: samp_rate
type: float
waveform: analog.GR_SIN_WAVE
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [88, 396.0]
rotation: 0
state: disabled
- name: blocks_throttle_0
  id: blocks_throttle
  parameters:
affinity: ''
alias: ''
comment: ''
ignoretag: 'True'
maxoutbuf: '0'
minoutbuf: '0'
samples_per_second: samp_rate*interpol
type: float
vlen: '1'
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [616, 404.0]
rotation: 0
state: true
- name: blocks_vector_source_x_0
  id: blocks_vector_source_x
  parameters:
affinity: ''
alias: ''
comment: ''
maxoutbuf: '0'
minoutbuf: '0'
repeat: 'True'
tags: ''
type: float
vector: '[1,0,1,0,1,0,1,1,0,1,0,0,0,1,1,0,1,0,0,0]'
vlen: '1'
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [88, 180.0]
rotation: 0
state: disabled
- name: interp_fir_filter_xxx_0_0
  id: interp_fir_filter_xxx
  parameters:
affinity: ''
alias: ''
comment: ''
interp: interpol
maxoutbuf: '0'
minoutbuf: '0'
samp_delay: '0'
taps: '1'
type: fff
  states:
bus_sink: false
bus_source: false
bus_structure: null
coordinate: [344, 340.0]
rotation: 0
state: disabled
- name: qtgui_time_sink_x_0
  id: qtgui_time_sink_x
  parameters:
affinity: ''
alias: ''
alpha1: '1.0'
alpha10: '1.0'
alpha2: '1.0'
alpha3: '1.0'
alpha4: '1.0'
alpha5: '1.0'
alpha6: '1.0'
alpha7: '1.0'
alpha8: '1.0'
alpha9: '1.0'
autoscale: 'True'
axislabels: 'True'
color1: blue
color10: dark blue
color2: red
color3: green
color4: black
color5: cyan
color6: magenta
color7: yellow
color8: dark red
color9: dark green
comment: ''
ctrlpanel: 'False'
entags: 'True'
grid: 'True'
gui_hint: ''
label1: Signal 1
label10: Signal 10
label2: Signal 2
label3: Signal 3
label4: Signal 4
label5: Signal 5
label6: Signal 6
label7: Signal 7
label8: Signal 8
label9: Signal 9
legend: 'True'
marker1: 

Re: New OOT module gr-latency

[Marcus Müller]

This is awesome, thanks, Johannes!

On 23.03.20 11:35, Johannes Demel wrote:
> Hi everyone,
> 
> I'd like to share a new module `gr-latency` that I created and use[0].
> 
> Sometimes it would be great to be able to measure latency in a
> flowgraph. With this module this should be easier. I have questions in
> mind like:
> 
> * Which blocks delay processing?
> * How long does it take a packet to propagate through the DSP chain?
> 
> This module is inspired by [1]
> "latency: Tag samples or messages with timestamps and measure how long
> it takes to propagate them through the flowgraph."
> 
> Cheers
> Johannes
> 
> [0] https://github.com/ant-uni-bremen/gr-latency
> [1] https://github.com/bastibl/gr-sched#metrics
> 

New OOT module gr-latency

[Johannes Demel]

Hi everyone,

I'd like to share a new module `gr-latency` that I created and use[0].

Sometimes it would be great to be able to measure latency in a 
flowgraph. With this module this should be easier. I have questions in 
mind like:


* Which blocks delay processing?
* How long does it take a packet to propagate through the DSP chain?

This module is inspired by [1]
"latency: Tag samples or messages with timestamps and measure how long 
it takes to propagate them through the flowgraph."


Cheers
Johannes

[0] https://github.com/ant-uni-bremen/gr-latency
[1] https://github.com/bastibl/gr-sched#metrics