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

[kronenpj]

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.

[randybuildsthings]

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]

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]

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]

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.