The system as designed works fine; it's the end user that wants the same convenience as analog that caused problems.
Correct; these were a "reflection" on how users wanted the system to work.
Incorrect; it's embedded in the data stream every 21 frames. Documented in the JARL specification as well.
If that's true then Icom didn't build their gateways to read it.
Take this scenario:
User source routes to another repeater and drops out (mobile flutter, signal loss, multipath, whatever) in the middle of a one minute long transmission. 60 seconds.
What will come out the other side is 30 seconds of audio. It will not pick back up and recover any of the remaining 30 seconds unless they've changed something in the latest gateway code.
In addition, unlike any other trunking or digital linking system out there, ther radios on either end and the gateways in between do not pass "repeater busy" status to the radios themselves. The radios can be set not to step on an active transmission but that's not what I'm speaking of here...
The user that was transmitting keeps talking, and the user on the far end will probably key up after guessing how long the other guy talked to tell him he fell out.
The remote user will step on the first guy if he keys up at say 45 seconds and have no idea he did it. The first user will unkey thinking his entire transmission went through.
Comparatively in the analog linking world there would be enough audio queues for the users on both ends to know what had just happened.
Anything designed to replace analog has to, not optional, provide at least a modicum of user feedback that the transmission didn't make it or block the remote user from transmitting back. Easily accomplished with a protocol that uses a header (Icom did this.) continuously interlaced routing information to pick up where the signal dropout left off (Icom put it in the OTA protocol apparently per your note but didn't utilize it in the gateway software correctly).
This of course doesn't even go into the detection and feedback of packet loss on the gateway to gateway link and a way to notify the end user that the gateways are having trouble. None of the popular systems do this very well today, but it's certainly possible to code it in. And it should have been there in all of them.
These failure scenarios aren't even that difficult to come up with.
I did some minor testing of an EFJ IP dispatch console a long time ago to help some friends in the biz out. My first - FIRST - test was to simply walk over and unplug the Ethernet cable while the simulated "dispatcher" (a radio tech in a lab) was "transmitting" and asked him to keep the console keyed down.
Repeater stopped transmitting immediately of course. No indication to the listener on the RF side that the dispatch console disconnected.
Looked at the radio tech: "Did you get any indication as the dispatcher that you're not going out over the air anymore?"
"Nope."
"I wouldn't deploy that thing in a life safety system until EFJ fixes that."
"Yeah. That isn't right. In fact that's dangerous."
Additionally neither that version of the dispatch console nor the repeater have any indication at all that they weren't communicating when the system was idle. None.
This was a commercial product INTENDED for sales into Public Safety systems.
I mention that test because ALL digital linking systems need these features as a default MINIMUM feature set. Not as a "oh we will sell you an upgrade later at your cost to make it work properly".
Perhaps Icom fixed the source routing oversights in their product in their newer gateway software?
Are they still compiling binary bits on Unix from six year old source code full of security holes? They definitely didn't have a clue on the first version how to properly package Unix software. Not even a teeny tiny bit of clue. Worst commercial software packaging of the software itself that I've seen yet in a career of doing Unix.
When I approached some folks and recommended how to fix it and also that I'd be willing to actually DO it, I was told to pound sand by Icom directly. Their loss. I lost all interest and haven't keyed a D-Star radio in anything other than analog mode in years.
I've also been explaining that dropout scenario to various folks running all types of digital linked systems for somewhere around ten years now. DMR comes the closest with at least a check that you can hit the repeater prior to a "go ahead" beep for the user.
That functionality where the radio can ask the repeater "am I good to go?" can easily be leveraged into a mobile flutter lockout if the firmware and linking code is done right.
Icom radios simply don't have the ability to check, and may never.
Granted, the DMR rigs can't do it continuously, only at initial key up. Even if they're in a trunked environment and listening to a control channel.
Nothing on the market that I'm aware of attempts to do a duplexed health check throughout a transmission. Well, other than a cell phone. Hah.
Fun stuff to analyze. None of it is perfect. Icom's stuff was a nice "first try". P25 is better. DMR gets a tiny bit closer to ideal.
It'll be another 10-20 years for someone to do it right.
Someone mentioned the "R2D2" effect. That's the best the Icom system has for user feedback as to what's happening.
All of the above was easy in the analog domain. There were auditory cues to what was happening. It's not easy in a half-duplex digital system.
The benefit to digital is saving spectrum. If it does that job and performs poorly on the rest, it's not "fully baked" yet. Stick it back in the oven.
Has Yaesu figured out what emission designator their new mixed mode system is? They failed miserably on the one thing digital brings to the table... Spectrum conservation.
Why they even bothered doing a mixed system is a head scratcher. Late to the game by a decade and they take up the same spectrum as analog? At least in DMR you get two channels from the same repeater for that. They just needed a product to say they could compete. Pushed WIRES on analog as their differentiator for WAY too long. And what a joke THAT is/was!
