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

WIP: Seeking input - I'm looking to get a consistent CW ID, every {interval} minutes, only when in use #549

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

kronenpj
Copy link

@kronenpj kronenpj commented Jan 3, 2020

This set of mods seems to work, most of the time. I have noticed two problems and I'd like some guidance.

  1. At times it switches to CW ID, but without transmitting, when the hotspot is receiving.
  2. Some times the hotspot goes to CW ID but it doesn't transmit even though the channel is clear (no red LED).
    I've removed many instances where the CW ID Timer was stopped because that resets the timer and, in the US at least, resetting the timer when restarting isn't acceptable. I toyed with the idea of changing the behaviour of the Timer class to allow stop/start without reset, but haven't convinced myself that's needed yet.

@kronenpj kronenpj requested a review from g4klx January 16, 2020 00:31
@randybuildsthings
Copy link
Contributor

This seems directly related to #671

I would think that @g4klx might be more inclined to look at this if there was a configuration switch that enabled this behavior. It's apparently a very well-worn subject about how the CW ID works (or doesn't) and apparently there isn't much appetite for changing the default behavior. Having this exist as an optional setting that enables this kind of behavior would perhaps be more likely to get reviewed.

My two cents.

@kronenpj
Copy link
Author

Agreed. That will require a bit more digging into the code to learn how the configuration and implementation are tied together. There is a setting for ID or no ID, but I'd guess you're suggesting something a little more granular.

@randybuildsthings
Copy link
Contributor

randybuildsthings commented Apr 10, 2021

Agreed. That will require a bit more digging into the code to learn how the configuration and implementation are tied together. There is a setting for ID or no ID, but I'd guess you're suggesting something a little more granular.

I think because this is an international project, there are constituencies that have different needs/preferences/requirements. @g4klx said that in the old OpenDV forum on Yahoo, they argued about CWID and what's in the code right now was the compromise solution.

The problem is that the compromise solution is way out of compliance with what repeater operators in the U.S. expect to have in place.

So, I think the deltas should leave in the existing CWID regime, but based on a configuration value, swap that functionality for what you've created instead. Configuration values are trucked around as global variables, if memory serves. I would have to go back and look again, and I don't have time right now.

Funny enough, hams in the US are starting to realize that busy MMDVM repeaters are not transmitting CWID enough, and I had to fill them in on the fact that CWID is working as the software intends it to work -- that is, not often enough for U.S. repeater operators.

@randybuildsthings
Copy link
Contributor

I'll leave this here as possible implementation notes:

  • You might consider making a separate (parallel) CWID timer for this, rather than try to patch the existing one. Not sure how well that might fly, but it would be easier to do an exclusive one-or-the-other timer selection IMO
  • The MMDVM can only do one thing at a time, obviously. If the modem is doing CWID transmission and some traffic comes in over the network, what happens to it? Is it buffered or just dropped?
  • How well do different modes handle the loss of the first network traffic that might come in? Seeing that all of it is UDP/connectionless, there is a non-zero probability that voice headers/first packets for a voice stream of ANY mode might not reach the MMDVMHost, so the worst-case outcome is that an entire voice stream that would've been sent over the air by MMDVMHost if CWID wasn't happening doesn't end up being transmitted at all. Some folks here might not be okay with that, but I guarantee you that every U.S. repeater operator would be okay with that.
  • CWID in the U.S. is not joke; we should treat it like any other MMDVM mode, but with priority (as in every time the main loop in MMDVMHost comes up, CWID timer is checked first, and if the timer expires, the CWID goes out no matter what.
  • The flip side is that if the last thing the MMDVM did was CWID, the timer doesn't get restarted until there's new traffic being transmitted outward. If there's no transmission and the MMDVM remains idle, CWID would not go out. That's how I know a lot of common repeater controllers in the U.S. behave.

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

Successfully merging this pull request may close these issues.

2 participants