On Oct 16, 2009, at 9:22 PM, Woodrick, Ed wrote:
> The “ignoring the call if it can’t be decoded” IS the attempt to
> assure that the protocol works. That allows subsequent transmissions
> to follow the initial transmission. If this didn’t occur, then there
> would be a lot more “dropped transmissions” It’s only when the two
> stations have different routing in which it becomes a big issue. And
> in general, subsequent transmissions should all have the same
> routing, just maybe a different source callsign.
>
>
>
> So as much as you think that it’s broken, I think that Icom did the
> right thing.
I didn't say they did the wrong thing in the context of how they
handle it -- once they were stuck with the protocol.
I'm saying they did the only thing they could with a busted underlying
protocol. One that once put into the field, is shown to not take
enough "care" of the 2nd most important data in the transmission other
than the voice... the routing data.
Since Internet GW seems MAYBE to not have been an initial design goal,
since RPT1 and RPT2 are just "fields" to be used as desired... and
it's likely the GW implementation came along much later after the
protocol was designed... there probably was little forethought to how
important the routing fields would someday be.
Since the GW is after all, a proprietary software package from Icom...
there may have never been any thought to how weak signals would
destroy the information needed to implement such a connectivity
system. And by the time they try it out, they realize...
"Oh no... we have to pretend a mangled header is a continuation of the
last transmission, because it might just be mobile flutter/dropouts.
Bummer!"
So yes, you can see how an Icom engineer backed into a corner by a
protocol that drops header information like water out of a bucket that
has holes drilled in the bottom... would have to do exactly what they
did.
All I'm saying is that if you look far enough back, ultimately... the
only CORRECT fix -- was always to fix the protocol's handling of
header information to make it more robust..
In other words, if the on-air protocol is weak, the rest of the system
above it, suffers.
(Depending on WHEN we think Icom and JARL really started work the D-
STAR specification, there may already have been published studies that
interlacing the "routing" data was the correct way to go. Was it in
development before the APCO P-25 folks published their protocol? I
don't know. If it was the same timeframe, that's embarassing... they
ignored other group's test data. Never a good idea when building a
new type of tech.)
As far as D-STAR "the protocol" goes, the proper root-cause fixes
can't be done now, without obsoleting rigs -- so I'm just discussing
this in light of learning how to build the NEXT protocol. If there
ever is a next one... for Amateur Radio.
Again not a "good/bad" emotional judgment, just analysis of the good/
bad points of the protocol, as implemented... and compared to others
attempting similar end-results.
--
Nate Duehr, WY0X
n...@natetech.com
------------------------------------
Please TRIM your replies or set your email program not to include the original
message in reply unless needed for clarity. ThanksYahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/dstar_digital/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/dstar_digital/join
(Yahoo! ID required)
<*> To change settings via email:
mailto:dstar_digital-dig...@yahoogroups.com
mailto:dstar_digital-fullfeatu...@yahoogroups.com
<*> To unsubscribe from this group, send an email to:
dstar_digital-unsubscr...@yahoogroups.com
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
