Typo's + Question

[lejafar]

Hi Joseph!

Besides the typo's I wanted to ask you for any reference or reasoning that went into picking these bandwidth calculating factors inside symtrack.c, or is it solely based on experience?

// set bandwidths accordingly
// TODO: set bandwidths based on input bandwidth
float agc_bandwidth     = 0.02f  * _bw;
float symsync_bandwidth = 0.001f * _bw;
float eq_bandwidth      = 0.02f  * _bw;
float pll_bandwidth     = 0.001f * _bw;

What also got me going for a while is the following statement inside modem_qam.c

EDIT: after dubble checking it does gives the expected result so I must have looked over something

// re-modulate symbol (subtract residual) and store state
_q->x_hat = _x - (res_i + _Complex_I*res_q);

Because the value that is put into _q->x_hat is not an estimate or re-modulation of _x right? For 16-QAM, the thing that is being put into res_i is cimagf(_x) - _ref[1] - _ref[0] , same for res_q and crealf(_x). Because _ref[0] is just 0, _q->x_hat will contain _ref[1], but that still works as an indication of the error calculated by modem_get_demodulator_evm, so that might be how it is supposed to be?

Thanks in advance!

[jgaeddert]

lejafar, Mostly just experience. The tricky part about having multiple control loops within one another is that they can cause instability. See, for example, the symtrack object's loop here at http://liquidsdr.org/doc/symtrack/:

The remodulated symbol value is a bit of ugly code... but I didn't come up with a better way to handle it so that's what I ended up committing. Thanks!

[jgaeddert]

with respect to the unused num_symbols variable, my original intent was to use that as a way to determine when to stop the loop, rather than the number of samples. It's actually the number of symbols that determines loop convergence as the signal could be highly over-sampled (many samples, but few symbols).

[lejafar]

Thanks for the clarification! And thanks for making this awesome library and putting together all the examples and documentation, it really helped me a lot in understanding how some of these DSP elements are implemented!

[jgaeddert]

You're absolutely welcome! It's been a lot of fun working on this, but I know liquid-dsp has a long, long way to go!