Update tracking

[odrisci]

[DO NOT MERGE YET!]
This pull request updates the dll_pll_conf class to read from a ConfigurationInterface, refactors the implementation of dll_pll_veml_tracking and adds carrier aided code tracking as an option.

This addresses #335 and is open for discussion on the right way forward with the refactoring.

[carlesfernandez]

Thanks @odrisci !

I love the removing of duplicated code. This is definitely the way we should go. Needs more work, but I’m totally in about making these changes.

I also like the renamings gr_complex -> fc32, cshort -> ic16 and cbyte -> ic8. However, this is a big change that impacts the configuration files, the documentation, and many other source files in order to make it consistent, and we should proceed carefully about it. At least, we should define alias for the current nomenclature in order to make a soft transition (that is, without breaking existing configurations), but promoting from now on the new nomenclature, which should also include byte -> i8, short -> i16 and float -> f32. Another option could be to adopt the Volk nomenclature (8i, 16i, 8ic, 16ic, …) defined in the table at https://gnss-sdr.org/docs/tutorials/understanding-data-types/#data-types-in-gnss-sdr The aim should be to make it the most intuitive and most “standard practice” as possible.

Still another issue: how do we rename ibyte and ishort (interleaved byte and interleaved short) formats? They are equivalent to ic8 and ic16 in terms of how data is stored, but it has other implications (i.e, data rate). The Volk nomenclature makes no distiction between those types, but I think having them defined makes sense in the GNSS context. In your proposal, iic8and iic16 would look kind of weird.

I'm still processing other very intesresting changes you made :-)

[odrisci]

Good points Carles. In fact the change in nomenclature is just a "leakage" from code that I use in other contexts, so I'm quite happy to revert the "item_type_helpers" to use the standard gnss-sdr names. As it stands the "fc32" style was supposed to be an internal naming convention in the helper context. The table at the link you sent is great, somehow I missed this before, so I can modify the code to use the nomenclature from that table consistently. Sorry to dump all these PRs on you right now, I'm rolling up a lot of little changes that I have made over the last couple of years. Maybe not all of them are appropriate for merging into the main code base, so don't hesitate to get in touch if you have any questions. I have one or two more PRs that might be interesting that I'm working on right now. I'll push them to github in the coming days

…

On Thu 14 Nov 2019, 19:53 Carles Fernandez, ***@***.***> wrote: Thanks @odrisci <https://github.com/odrisci> ! I love the removing of duplicated code. This is definitely the way we should go. Needs more work, but I’m totally in about making these changes. I also like the renamings gr_complex -> fc32, cshort -> ic16 and cbyte -> ic8. However, this is a big change that impacts the configuration files, the documentation, and many other source files in order to make it consistent, and we should proceed carefully about it. At least, we should define alias for the current nomenclature in order to make a soft transition (that is, without breaking existing configurations), but promoting from now on the new nomenclature, which should also include byte -> i8, short -> i16 and float -> f32. Another option could be to adopt the Volk nomenclature (8i, 16i, 8ic, 16ic, …) defined in the table at https://gnss-sdr.org/docs/tutorials/understanding-data-types/#data-types-in-gnss-sdr The aim should be to make it the most intuitive and most “standard practice” as possible. Still another issue: how do we rename ibyte and ishort (interleaved byte and interleaved short) formats? They are equivalent to ic8 and ic16 in terms of how data is stored, but it has other implications (i.e, data rate). The Volk nomenclature makes no distiction between those types, but I think having them defined makes sense in the GNSS context. In your proposal, iic8and iic16 would look kind of weird. I'm still processing other very intesresting changes you made :-) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#336?email_source=notifications&email_token=ABZMLEPJPFME6NPLOMLG7S3QTWUDZA5CNFSM4JKZMKSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEDCU7Q#issuecomment-554052222>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABZMLEOZHGEEJGMVPCDAHM3QTWUDZANCNFSM4JKZMKSA> .

[odrisci]

I've rebased this onto the #332, hence the force push. This now uses the gnss-sdr style item type names (byte, ibyte, cbyte, etc)

[carlesfernandez]

I've merged this branch and odrisci:fix_discriminator_normalization into gnss-sdr:odrisci-fix_discriminator_normalization, including the latest additions to next.

I'm starting testing from there.

[carlesfernandez]

Hi @odrisci

This PR contained a lot of great ideas and improvements, it was just too much to be merged into the next branch without breaking things (I don't think that was your intention, either).

Most of them have already been merged into next at smaller steps, either by cherry-picking or by unshameless copy & paste (of course respecting your copyright on files). This is the list of new additions based on your PR:

• Added the item_type_helpers class.
• Fix computation of acquisition threshold.
• Refactoring of Acquisition and Tracking adapters to avoid code duplication.
• Fixed the normalization of the DLL discriminator for BPSK signals.
• Addition of a unit test for discriminators.
• Option to enable/disable carrier aiding to the code tracking loop.

There are still other interesting additions (e.g., frequency lock detector) which are not on next, so let's keep this PR open to keep them in mind. This comment is just for keeping track of the changes and acknowledging your work.

[odrisci]

Thanks Carles!

I appreciate the work you did on this, I must try and update my local repo and rebase against your changes - maybe I can see if there are some more (smaller!) commits I can push back up. It will be a few weeks before I get a chance to have a look, but I'll let you know.

Thanks again