Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VCO and similar blocks #104

Closed
loic-fejoz opened this issue Dec 30, 2022 · 3 comments
Closed

VCO and similar blocks #104

loic-fejoz opened this issue Dec 30, 2022 · 3 comments

Comments

@loic-fejoz
Copy link
Contributor

Voltage Controlled Oscillator (VCO) and other similar blocks are missing.
I believe we can come with a common implementation for various use-cases.
At least propose implementation for:

It should also be a base for Phase Shift Keying (PSK, eg BPSK, GMSK, QPSK) and other constellations handling.

Implementation experimentation started in my branch: https://github.com/loic-fejoz/FutureSDR/blob/feature/vco/src/blocks/signal_source/controlled_oscillator.rs

@bastibl
Copy link
Member

bastibl commented Jan 8, 2023

Would be really nice to have. I just wonder how we should proceed in the future. Add this in-tree? Add this as an example that comes with some blocks? Have it as separate crate (for example maintained by you)? Maybe, we have examples from the FutureSDR project and 3rd party ones; and all are just git submodules in the example directory?

I'd say it's clear that a new users should find a PSK example, either as example in-tree, a git submodule, or a readme in the examples directory with a list of pointers to external examples.

Just trying to balance "batteries included" vs maintainability. Do you have any input/ideas?

@loic-fejoz
Copy link
Contributor Author

I was also having the exact same question.

I believe the underlying block should be included because it is a basis for a lot of graph. Yet I am trying to build one that is very generic and not tied to a particular scheme (modulation), said otherwise, everything consuming a stream and using a numerically controlled oscillator.
So I am shifting the question to the builders: should the builders (for different modulations) be part of FutureSDR or external crates? And the more I think, the more I think it should be part of another crate/project.

Somehow, I would defined the threshold based on technical difficulties of correct implementation. The difficulty to come up with a correct NCO is a one-order higher than defining modulation...

But this is just my 2 cents. What do you think?

@bastibl bastibl mentioned this issue Jan 16, 2023
@loic-fejoz
Copy link
Contributor Author

Should be "closed as not planned" as it will be handle by pull request FutureSDR/fsdr-blocks#4 and issue FutureSDR/fsdr-blocks#2

@loic-fejoz loic-fejoz closed this as not planned Won't fix, can't repro, duplicate, stale Mar 19, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants