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

OWR 1.0 bookmarks - option to define receive bandwidth #242

Open
G8JNJ opened this issue May 14, 2021 · 4 comments
Open

OWR 1.0 bookmarks - option to define receive bandwidth #242

G8JNJ opened this issue May 14, 2021 · 4 comments
Labels
feature feature requests

Comments

@G8JNJ
Copy link

G8JNJ commented May 14, 2021

With the introduction of the new bookmark editor, would it be possible to include the ability to define the receiver bandwidth other than by the default for the mode

@G8JNJ G8JNJ added the feature feature requests label May 14, 2021
@jketterl
Copy link
Owner

Precondition: Bandwidth must no longer be limited by the client environment / connection parameters.

@G8JNJ
Copy link
Author

G8JNJ commented May 18, 2021

OK in this case would it be possible to add a additional modes such as NFM and NAM in order to provide a narrower bandwidth receive option.

The current 8KHz FM option is a bit too wide for 12.5KHz channel spacing and +/- 2.5KHz deviation and a bit too narrow for the 25KHz and wider channel spacings using greater deviation. Likewise AM is a bit too wide for speech communications and too narrow for broadcast stations.

As an example the KiWi steps through different bandwidth modes on each button press.

@jketterl
Copy link
Owner

too much confusion here. all my comment is saying that bandwidths on bookmarks only make sense if the bandwidth can be handled by all connections. otherwise, i would need to put the maximum bandwidth on bookmarks to the lowest potential bandwidth of any client, which would be only +/- 4kHz.

i'm not going to discuss addition of modes here simply because that's not covered by the original issue.

and please stop referring to the kiwisdr. it is a terrible example from a UX standpoint.

@G8JNJ
Copy link
Author

G8JNJ commented May 18, 2021

OK, I understand if there is a constraint regarding bandwidth.

I only mentioned the KiWi because it's a fork of Andras's original OWR so there was once some commonality.

"it is a terrible example from a UX standpoint" I think that's a personal observation, all software has it's own quirk's, and is generally loved by it's creators, even if the users choose to disagree.

Generally speaking software engineers are too closely invested in their projects and tend to overlook obvious flaws as they have lived with them from conception. I speak from the experience of supervising teams of developers who produced software for domestic products, but who tended to miss really obvious problems with the UI as "it has always been like that" :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature feature requests
Projects
None yet
Development

No branches or pull requests

2 participants