search

jketterl / openwebrx

Open source, multi-user SDR receiver software with a web interface
https://www.openwebrx.de
GNU Affero General Public License v3.0
996 stars 145 forks source link

OWR 1.0 bookmarks - option to define receive bandwidth #242

Open G8JNJ opened 3 years ago

G8JNJ commented 3 years ago

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

jketterl commented 3 years ago

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

G8JNJ commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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" :-)