GSoC 2020 : gr-dpd - New Blog Post for Week 1

[Alekh]

Hello Everyone,

                        I have updated my blog 
 for GSoC 2020 project with updates 
regarding work progress of Week 1 and proposed further tasks.


                        Here is the blogpost link: 
grdpd.wordpress.com/2020/05/22/week-1-creation-of-gr-dpd-addition-of-pa-blocks.



                        Major Week 1 highlights:

                     - Work plan analysis.

                     - Creation of gr-dpd using gr_modtool.

                     - Addition of two PA (Power Amplifier) blocks: 
MP_model_PA and GMP_model_PA.


                     - Addition of example flowgraphs for above two 
blocks.


                       Week 2 Proposed tasks:

                          - Going through the complete workflow and 
mathematical aspects of Learning algorithms.


                          - Trying to implement some basic working code 
on some raw input for Pre-Distortion.


                        Link to gr-dpd 
 GNU Radio GitHub repo.


Regards,

Alekh Gupta,

National Institute of Technology, Hamirpur

Re: Which guarantees, if any, do messages provide?

[Sylvain Munaut]

Hi,

> For example, I use "Message Strobe" to create a message every 10ms. A custom 
> blocks creates a pulse when the message is received (it does so by putting 
> the message into a std::queue in the message handler and retrieving it in the 
> work function).
> When I trigger on one pulse and zoom out, I ideally would see one pulse 
> exactly every 100ms. However, the pulses jump around (i.e., the period always 
> changes).

Yeah, that's why they're called asynchronous messages.


> 1.) What is the typical latency of messages?

Too dependent on too many factors to provide any meaningful answer.
They're not artificially delayed ... so "as fast as possible" is the
only thing I can say.


> 2.) Related, what is typically the maximum speed for sending messages? Is 
> sending messages at >1kHz (i.e., "Message Strobe" with interval <1ms) 
> meaningful?

As fast as you can process them.
I've had bursts decoder use message for decoded bursts and that was
for sure reaching 1k packet per second.

I thought there was a back pressure mechanism to block senders if the
queue was too long, but I can't find it in the code :/  So if there
really isn't any, be careful of your memory footprint could grow
without bounds.


> 3.) Are there any "guarantees" on maximum/minimum delay? (for example, I read 
> that the message handler is guaranteed to be executed when work() is not. Is 
> an upper bound of delay (in samples) given by the worst case execution of the 
> work function, i.e. the size of the output buffer?)

None whatsoever.


> 4.) Can I be sure that all messages are received or does gnuradio silently 
> drop messages under certain conditions?

It won't drop messages.


> 5.) Are messages always received in correct order?

Yes


Cheers,

 Sylvain