Re: [DSTAR_DIGITAL] Re: Beeps

[Nate Duehr]

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/

RE: [DSTAR_DIGITAL] Re: Beeps

[Woodrick, Ed]

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.

From: dstar_digital@yahoogroups.com [mailto:dstar_digi...@yahoogroups.com] On 
Behalf Of Nate Duehr
Sent: Friday, October 16, 2009 7:49 PM
To: dstar_digital@yahoogroups.com
Subject: Re: [DSTAR_DIGITAL] Re: Beeps


Okay, interesting. Please review and note that I never said a receiving station 
gets a CORRUPTED callsign.  The result is actually that the receiving station 
gets *no callsign* at all.  Then the firmware in the controller or the software 
in the GW was programmed in such a way as to treat that missing header as if 
the prior transmission had never unkeyed, EVEN THOUGH there was a 
non-corrupted, perfectly copyable END to the prior transmission.

(D-STAR does end-of-transmission correctly by the way, transmissions don't just 
stop, there's a defined "I'm done transmitting" pattern.  But if the overlying 
network ignores that data, or it isn't passed far enough up the stack to where 
things like the GW have visibility to it, it's wasted.)

The result is the same, the system breaks and has no way to self-recover.

Streaming protocols that include routing information in the stream 
(source-routed) need to try a little harder to get the required information for 
the system to work, to the far-end.  Especially over a physical medium as 
unpredictable as RF.  That or they need to throw out the ENTIRE transmission 
and try again.  (Which of course, would be completely annoying and non-workable 
for people used to analog FM.)

Basically, I'm saying this isn't Ethernet/copper wire this data's passing over, 
and a protocol designed for a noisy medium can't just send the header/routing 
information once, or it's bound to be a very "brittle" protocol as most 
protocol engineers would state it.  It is. Very brittle.  There are plenty of 
protocols that do work in heinous amounts of physical layer noise... D-STAR's 
not one of them.

That's not a bad/good judgment against D-STAR, it just "is"...



--

  Nate Duehr, WY0X

  n...@natetech.com

On Fri, 16 Oct 2009 22:32 +, "Jonathan Naylor" 
mailto:naylo...@yahoo.com>> wrote:


Nate,

If you look at the D-Star protocol you'll see in AP2 (in the file shogen.pdf) 
the details of the FEC applied to the header, doubling its length to 660 bits. 
It's a convolution code as opposed to concatenated block codes as used by AMBE.

The checksum in the header is then used to ensure that the header FEC has done 
its job. The header data is repeated in the slow data throughout the 
transmission but without FEC but with the checksum. There is no excuse for a 
receiving station to get a corrupted callsign bar bad programming.

Jonathan G4KLX

Re: [DSTAR_DIGITAL] Re: Beeps

[Nate Duehr]

Okay, interesting. Please review and note that I never said a
receiving station gets a CORRUPTED callsign.  The result is
actually that the receiving station gets *no callsign* at all.
Then the firmware in the controller or the software in the GW was
programmed in such a way as to treat that missing header as if
the prior transmission had never unkeyed, EVEN THOUGH there was a
non-corrupted, perfectly copyable END to the prior transmission.


(D-STAR does end-of-transmission correctly by the way,
transmissions don't just stop, there's a defined "I'm done
transmitting" pattern.  But if the overlying network ignores that
data, or it isn't passed far enough up the stack to where things
like the GW have visibility to it, it's wasted.)

The result is the same, the system breaks and has no way to
self-recover.

Streaming protocols that include routing information in the
stream (source-routed) need to try a little harder to get the
required information for the system to work, to the far-end.
Especially over a physical medium as unpredictable as RF.  That
or they need to throw out the ENTIRE transmission and try again.
 (Which of course, would be completely annoying and non-workable
for people used to analog FM.)

Basically, I'm saying this isn't Ethernet/copper wire this data's
passing over, and a protocol designed for a noisy medium can't
just send the header/routing information once, or it's bound to
be a very "brittle" protocol as most protocol engineers would
state it.  It is. Very brittle.  There are plenty of protocols
that do work in heinous amounts of physical layer noise...
D-STAR's not one of them.

That's not a bad/good judgment against D-STAR, it just "is"...
--
  Nate Duehr, WY0X
  n...@natetech.com


On Fri, 16 Oct 2009 22:32 +, "Jonathan Naylor"
 wrote:


Nate,
If you look at the D-Star protocol you'll see in AP2 (in the file
shogen.pdf) the details of the FEC applied to the header,
doubling its length to 660 bits. It's a convolution code as
opposed to concatenated block codes as used by AMBE.
The checksum in the header is then used to ensure that the header
FEC has done its job. The header data is repeated in the slow
data throughout the transmission but without FEC but with the
checksum. There is no excuse for a receiving station to get a
corrupted callsign bar bad programming.
Jonathan G4KLX


References

1. 
http://groups.yahoo.com/group/dstar_digital/message/9044;_ylc=X3oDMTM1b3E1YzFwBF9TAzk3MzU5NzE0BGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARtc2dJZAM5MDkwBHNlYwNmdHIEc2xrA3Z0cGMEc3RpbWUDMTI1NTczMjQxMAR0cGNJZAM5MDQ0
2. 
http://groups.yahoo.com/group/dstar_digital/post;_ylc=X3oDMTJxOTRjY2k3BF9TAzk3MzU5NzE0BGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARtc2dJZAM5MDkwBHNlYwNmdHIEc2xrA3JwbHkEc3RpbWUDMTI1NTczMjQxMA--?act=reply&messageNum=9090
3. 
http://groups.yahoo.com/group/dstar_digital/post;_ylc=X3oDMTJmcTlodTFqBF9TAzk3MzU5NzE0BGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDZnRyBHNsawNudHBjBHN0aW1lAzEyNTU3MzI0MTA-
4. 
http://groups.yahoo.com/group/dstar_digital/messages;_ylc=X3oDMTJmNGg0bTNyBF9TAzk3MzU5NzE0BGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDZnRyBHNsawNtc2dzBHN0aW1lAzEyNTU3MzI0MTA-
5. 
http://groups.yahoo.com/group/dstar_digital/files;_ylc=X3oDMTJnMm9kYmQ5BF9TAzk3MzU5NzE0BGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDZnRyBHNsawNmaWxlcwRzdGltZQMxMjU1NzMyNDEw
6. 
http://groups.yahoo.com/group/dstar_digital/photos;_ylc=X3oDMTJmcmtodGIzBF9TAzk3MzU5NzE0BGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDZnRyBHNsawNwaG90BHN0aW1lAzEyNTU3MzI0MTA-
7. 
http://groups.yahoo.com/group/dstar_digital/links;_ylc=X3oDMTJnM2hqbnE5BF9TAzk3MzU5NzE0BGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDZnRyBHNsawNsaW5rcwRzdGltZQMxMjU1NzMyNDEw
8. 
http://groups.yahoo.com/group/dstar_digital/database;_ylc=X3oDMTJkM2ZpbDM1BF9TAzk3MzU5NzE0BGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDZnRyBHNsawNkYgRzdGltZQMxMjU1NzMyNDEw
9. 
http://groups.yahoo.com/group/dstar_digital/polls;_ylc=X3oDMTJnZ3Y5Z2xmBF9TAzk3MzU5NzE0BGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDZnRyBHNsawNwb2xscwRzdGltZQMxMjU1NzMyNDEw
  10. 
http://groups.yahoo.com/group/dstar_digital/calendar;_ylc=X3oDMTJlNXUxa2QxBF9TAzk3MzU5NzE0BGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDZnRyBHNsawNjYWwEc3RpbWUDMTI1NTczMjQxMA--
  11. 
http://groups.yahoo.com/;_ylc=X3oDMTJlODBqYTdrBF9TAzk3MzU5NzE0BGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDZnRyBHNsawNnZnAEc3RpbWUDMTI1NTczMjQxMA--
  12. 
http://groups.yahoo.com/group/dstar_digital/join;_ylc=X3oDMTJnYnU4cXI2BF9TAzk3MzU5NzE0BGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDZnRyBHNsawNzdG5ncwRzdGltZQMxMjU1NzMyNDEw
  13. 
mailto:dstar_digital-dig...@yahoogroups.com?subject=email%20delivery:%20Digest
  14. 
mailto:dstar_digital-traditio...@yahoogroups.com?subject=change%20delivery%20format:%20Traditional
  15. 
http://groups.yahoo.com/group/dstar_digital;_ylc=X3oDMTJlMG85b245BF9TAzk3MzU5NzE0BGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDZnRyBHNsawNocGYEc3RpbWUDMTI1NTczM

[DSTAR_DIGITAL] Re: Beeps

[Jonathan Naylor]

Nate,

If you look at the D-Star protocol you'll see in AP2 (in the file shogen.pdf) 
the details of the FEC applied to the header, doubling its length to 660 bits. 
It's a convolution code as opposed to concatenated block codes as used by AMBE.

The checksum in the header is then used to ensure that the header FEC has done 
its job. The header data is repeated in the slow data throughout the 
transmission but without FEC but with the checksum. There is no excuse for a 
receiving station to get a corrupted callsign bar bad programming.

Jonathan  G4KLX

RE: [DSTAR_DIGITAL] Re: Beeps

[Nate Duehr]

I see empty callsigns displayed all the time on weak signals
(HT's usually) on the receiving radio (error detection... it was
bad, so... chuck it), and in the D-Plus logs on the W0CDS
Gateway, all the time.  Never on strong signals.

In fact, seeing the callsign go "missing" is a great way for me
(as a system admin of a Gateway, but there's no visibility to
people who can't see the D-Plus log, maybe I should figure out a
way to publish that on the web) to tell someone's NEVER going to
be able to pass D-RATS traffic... their data is already far too
mangled.

A way for users to test this (although possibly annoying for
those listening) is to send DIFFERENT commands to D-Plus back to
back.  If you send a command and get the expected message back
for the PREVIOUS command you sent... your headers are mangled.

(I've run into this taking down a D-Plus link while mobile and
heard it happen to a number of people.  Send the command, then
switch back to CQCQCQ and get "Not currently linked" after
transmission #2.  This means D-Plus thought you sent the original
command over again, and didn't "see" CQCQCQ.  Sadly, this is
HIGHLY confusing for users.)
--
  Nate Duehr, WY0X
  n...@natetech.com


On Fri, 16 Oct 2009 21:25 +, "Woodrick, Ed"
 wrote:



And you can tell that there is some error detection/correction
because how often do you see a bad call sign displayed? If there
wasn’t, you’d see also sorts of crap in the Last Heard list.


Ed WA4YIH


From: dstar_digi...@yahoogroups.
com [mailto:dstar_digi...@yahoogroups.com] On Behalf Of Tony
Langdon
Sent: Friday, October 16, 2009 5:09 PM
To: dstar_digi...@yahoogroups.comsubject: Re: [DSTAR_DIGITAL] Re:
Beeps



At 07:20 AM 10/17/2009, you wrote:
>That is not what I read in previous discussions by folks who
were
>actually doing protocol-level work, but if you insist that the
>headers are encapsulated inside the portion of the stream that's
>covered by FEC, I can't really refute it technically.
My understanding is that the voice uses the FEC built into the
AMBE
vocoder, which the headers don't have access to.
73 de VK3JED / VK3IRL
[1]http://vkradio.com




References

1. http://vkradio.com/
2. 
http://groups.yahoo.com/group/dstar_digital/message/9044;_ylc=X3oDMTM1NDA5anFtBF9TAzk3MzU5NzE0BGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARtc2dJZAM5MDg4BHNlYwNmdHIEc2xrA3Z0cGMEc3RpbWUDMTI1NTcyODMyNAR0cGNJZAM5MDQ0
3. 
http://groups.yahoo.com/group/dstar_digital/post;_ylc=X3oDMTJxYnNxNDQ1BF9TAzk3MzU5NzE0BGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARtc2dJZAM5MDg4BHNlYwNmdHIEc2xrA3JwbHkEc3RpbWUDMTI1NTcyODMyNA--?act=reply&messageNum=9088
4. 
http://groups.yahoo.com/group/dstar_digital/post;_ylc=X3oDMTJmZmVraWhvBF9TAzk3MzU5NzE0BGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDZnRyBHNsawNudHBjBHN0aW1lAzEyNTU3MjgzMjQ-
5. 
http://groups.yahoo.com/group/dstar_digital/messages;_ylc=X3oDMTJmdWxyaWhsBF9TAzk3MzU5NzE0BGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDZnRyBHNsawNtc2dzBHN0aW1lAzEyNTU3MjgzMjQ-
6. 
http://groups.yahoo.com/group/dstar_digital/files;_ylc=X3oDMTJnZWFpdnJqBF9TAzk3MzU5NzE0BGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDZnRyBHNsawNmaWxlcwRzdGltZQMxMjU1NzI4MzI0
7. 
http://groups.yahoo.com/group/dstar_digital/photos;_ylc=X3oDMTJmOW9oNHNvBF9TAzk3MzU5NzE0BGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDZnRyBHNsawNwaG90BHN0aW1lAzEyNTU3MjgzMjQ-
8. 
http://groups.yahoo.com/group/dstar_digital/links;_ylc=X3oDMTJnY2dmcW0xBF9TAzk3MzU5NzE0BGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDZnRyBHNsawNsaW5rcwRzdGltZQMxMjU1NzI4MzI0
9. 
http://groups.yahoo.com/group/dstar_digital/database;_ylc=X3oDMTJkcjMzZWJiBF9TAzk3MzU5NzE0BGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDZnRyBHNsawNkYgRzdGltZQMxMjU1NzI4MzI0
  10. 
http://groups.yahoo.com/group/dstar_digital/polls;_ylc=X3oDMTJnNHExNHNoBF9TAzk3MzU5NzE0BGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDZnRyBHNsawNwb2xscwRzdGltZQMxMjU1NzI4MzI0
  11. 
http://groups.yahoo.com/group/dstar_digital/calendar;_ylc=X3oDMTJlbzEybHZvBF9TAzk3MzU5NzE0BGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDZnRyBHNsawNjYWwEc3RpbWUDMTI1NTcyODMyNA--
  12. 
http://groups.yahoo.com/;_ylc=X3oDMTJlZjdqOW45BF9TAzk3NDc2NTkwBGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDZnRyBHNsawNnZnAEc3RpbWUDMTI1NTcyODMyNA--
  13. 
http://groups.yahoo.com/group/dstar_digital/join;_ylc=X3oDMTJnMGJuZXZpBF9TAzk3NDc2NTkwBGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDZnRyBHNsawNzdG5ncwRzdGltZQMxMjU1NzI4MzI0
  14. 
mailto:dstar_digital-dig...@yahoogroups.com?subject=email%20delivery:%20Digest
  15. 
mailto:dstar_digital-traditio...@yahoogroups.com?subject=change%20delivery%20format:%20Traditional
  16. 
http://groups.yahoo.com/group/dstar_digital;_ylc=X3oDMTJlMWMwc2QxBF9TAzk3NDc2NTkwBGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDZnRyBHNsawNocGYEc3RpbWUDMTI1NTcyODMyNA--
  17. http://docs.yahoo.com/info/terms/
  18. mailto:dstar_digital-unsubscr...@yahoogroups.com?subject=
  19. 
http://groups.yahoo.com/group/dstar_digital/members;_ylc=X3oDMTJnc3RzMGNk

RE: [DSTAR_DIGITAL] Re: Beeps

[Woodrick, Ed]

And you can tell that there is some error detection/correction because how 
often do you see a bad call sign displayed? If there wasn't, you'd see also 
sorts of crap in the Last Heard list.

Ed WA4YIH

From: dstar_digital@yahoogroups.com [mailto:dstar_digi...@yahoogroups.com] On 
Behalf Of Tony Langdon
Sent: Friday, October 16, 2009 5:09 PM
To: dstar_digital@yahoogroups.com
Subject: Re: [DSTAR_DIGITAL] Re: Beeps



At 07:20 AM 10/17/2009, you wrote:

>That is not what I read in previous discussions by folks who were
>actually doing protocol-level work, but if you insist that the
>headers are encapsulated inside the portion of the stream that's
>covered by FEC, I can't really refute it technically.

My understanding is that the voice uses the FEC built into the AMBE
vocoder, which the headers don't have access to.

73 de VK3JED / VK3IRL
http://vkradio.com

Re: [DSTAR_DIGITAL] Re: Beeps

[John Hays]

My reading of the protocol specification is that the header has a  
checksum (2.1.1 (11) page 4 - http://www.arrl.org/FandES/field/regulations/techchar/D-STAR.pdf) 
  for error detection, but forward error correction (FEC) only  
applies to the "audio" portion of the AMBE payload (and performed by  
the AMBE chip).





On Oct 16, 2009, at 2:09 PM, Tony Langdon wrote:


At 07:20 AM 10/17/2009, you wrote:

>That is not what I read in previous discussions by folks who were
>actually doing protocol-level work, but if you insist that the
>headers are encapsulated inside the portion of the stream that's
>covered by FEC, I can't really refute it technically.

My understanding is that the voice uses the FEC built into the AMBE
vocoder, which the headers don't have access to.

73 de VK3JED / VK3IRL
http://vkradio.com





John D. Hays
Amateur Radio Station K7VE
PO Box 1223
Edmonds, WA 98020-1223 VOIP/SIP: j...@hays.org
 Email: j...@hays.org

Re: [DSTAR_DIGITAL] Re:callsign routing

[Tony Langdon]

At 10:31 PM 10/16/2009, you wrote:

>A few questions
>I've used Callsign Routing as well as most of the other methods 
>available on the system. All have been both successful and at other 
>times not so much.
>Here are the questions as well as my thoughts to date which are 
>subject to correction.
>1. If the repeater I am using is connected to a reflector is 
>Callsign Routing processed or does it fail because of the active link.
>Probably not accepted or processed?

Callsign routing still works in this situation, though there can be 
audio issues for audio coming FROM the end that's connected to the reflector.

>2. If the system attempts to forward the call to a destination 
>repeater that may be in use or linked within the system what is the result.
>Probably not processed at the far end?

If the repeater is in use, you will get a busy indication (the usual 
cryptic response code).  If it's linked, but there is no traffic, 
routing will work.

>3. In each of these cases is there any indication on my side as to 
>whether my attempt to call my party was properly processed or 
>failed. I may be missing something there.

Yes, cryptic indications in the response from the local gateway 
(someone else can elaborate on the specifics).

>??
>4. If the answer to question 1. is that I cannot route by callsign 
>while the repeater is linked, is it proper to disconnect the link 
>considering that I may not have the privledge to re-establish it 
>even if I know where it was previously linked.
>  I've not attempted to disconnect in order not to bother other 
> users or listeners

If you can, it is better to disconnect the link.  I have occasionally 
heard weird things happen on a reflector when someone was 
transmitting with a callsign in the UR field.

73 de VK3JED / VK3IRL
http://vkradio.com

Re: [DSTAR_DIGITAL] Re: Beeps

[Tony Langdon]

At 07:20 AM 10/17/2009, you wrote:


>That is not what I read in previous discussions by folks who were 
>actually doing protocol-level work, but if you insist that the 
>headers are encapsulated inside the portion of the stream that's 
>covered by FEC, I can't really refute it technically.

My understanding is that the voice uses the FEC built into the AMBE 
vocoder, which the headers don't have access to.

73 de VK3JED / VK3IRL
http://vkradio.com

Re: [DSTAR_DIGITAL] Re: More open source D-Star repeater progress

[Tony Langdon]

At 11:18 PM 10/16/2009, you wrote:
>Hi Robbie
>
>I have a Yahoo group to distribute and support the software, which 
>also includes an analogue repeater controller, and eventually a full 
>dual-mode repeater. It's located at 
>.
>
>The current hardware support is for the Velleman K8055 for control 
>and the cheapest USB sound card you can find! (The lack of filtering 
>in them is ideal).

Interesting Jonothan, and as luck would have it, I have a K8055 
kicking around somewhere, left over from a work project. :)

73 de VK3JED / VK3IRL
http://vkradio.com

Re: [DSTAR_DIGITAL] callsign routing

[Nate Duehr]

The information is in a table on the local GW that's updated
periodically from the central Trust Server.  The user radios
aren't involved at all, other than sending the callsign(s)
required.

The local GW's don't update often enough to make jumping from GW
to GW always feasible.  Various update times have been used over
the "history" of D-STAR all the way back to Gateway v1 software.
 Right now, I believe it's about 5 minutes, but don't quote me on
that.  I lost interest in chasing this design flaw by trying to
change timing values, long ago, because it's not the right way to
fix it.

So, right now, if you hit it at "the right time", when a GW has
just updated from the Trust Server, it'll seem quick.  If you
switch GW's right after an update, you're "stuck" until the next
update, though.  Catch-22.

To do it closer to "real-time" would probably require a re-design
of the GW/Trust Server environment. Right now, all GW's update
constantly. This is not the correct way to design a system for
growth.  It's called a "centralized" or "clearinghouse" design
methodology, and puts heavy load on the central servers doing
updates that no GW actually needs.

To do it differently, updates should be dynamic and pulled only
when needed, but announcements made of users moving between
systems (which isn't ALL that common, so traffic of that type
would be very low, overall)... thus, available immediately if a
user switches GW's.

Better yet, the best design for this type of network would be to
decentralize the whole thing, with the only data necessary in a
centralized location being the list of GW's, and have GW's query
each other, directly.  Similar to DNS.

In fact, it could all be done with DNS TXT records with the
NOTIFY feature of bind.  No need to have an RDBMS at all, nor
take the performance penalty of having to run an entire RDBMS
engine for the tiny number of records that actually need to be
"known" at any one time, by each GW.

Bind even has DNSSEC if someone were worried about security.  All
traffic in the network of machines could be encrypted.

Anyway, making it work right would be easy.  Plenty of other ways
even if not done with BIND.

Getting the politics done to get Icom to change it?  I have no
dog in that fight.
--
  Nate Duehr, WY0X
  n...@natetech.com


On Wed, 14 Oct 2009 19:40 -0400, "Fran Miele"
 wrote:



I frequently talk with my son in Dallas, N1GAT and use call sign
routing as he does when he calls me. The questions I have are:
where is the information stored that is used for his radio to
find which repeater I last transmitted? How long does it stay
there? How long does it take to update?


I have noticed a couple of things. Sometimes when he calls me I
am on one of our repeaters that is linked to a reflector so I try
not to talk with him there. I usually go to our stand alone
repeater, transmit there and then wait for him to call. However,
sometimes he calls me before I have switch. So I tell him to
wait, I switch repeaters and call him. On some occasions the
switch is almost instantaneous and sometimes it takes a while. In
fact one night I switched before he called and his call to me
still went to the other repeater, not the one I had last
transmitted on 30 minutes earlier.


Fran





References

1. 
http://groups.yahoo.com/group/dstar_digital/message/9044;_ylc=X3oDMTM1M2ViOWJhBF9TAzk3MzU5NzE0BGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARtc2dJZAM5MDYzBHNlYwNmdHIEc2xrA3Z0cGMEc3RpbWUDMTI1NTU2MzY1OAR0cGNJZAM5MDQ0
2. 
http://groups.yahoo.com/group/dstar_digital/post;_ylc=X3oDMTJxbHZiMWhpBF9TAzk3MzU5NzE0BGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARtc2dJZAM5MDYzBHNlYwNmdHIEc2xrA3JwbHkEc3RpbWUDMTI1NTU2MzY1OA--?act=reply&messageNum=9063
3. 
http://groups.yahoo.com/group/dstar_digital/post;_ylc=X3oDMTJmMTk1bnFuBF9TAzk3MzU5NzE0BGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDZnRyBHNsawNudHBjBHN0aW1lAzEyNTU1NjM2NTg-
4. 
http://groups.yahoo.com/group/dstar_digital/messages;_ylc=X3oDMTJmcmppNG1rBF9TAzk3MzU5NzE0BGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDZnRyBHNsawNtc2dzBHN0aW1lAzEyNTU1NjM2NTg-
5. 
http://groups.yahoo.com/group/dstar_digital/files;_ylc=X3oDMTJnYWx1bm5hBF9TAzk3MzU5NzE0BGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDZnRyBHNsawNmaWxlcwRzdGltZQMxMjU1NTYzNjU4
6. 
http://groups.yahoo.com/group/dstar_digital/photos;_ylc=X3oDMTJmajZobmwzBF9TAzk3MzU5NzE0BGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDZnRyBHNsawNwaG90BHN0aW1lAzEyNTU1NjM2NTg-
7. 
http://groups.yahoo.com/group/dstar_digital/links;_ylc=X3oDMTJncmJ0cTYyBF9TAzk3MzU5NzE0BGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDZnRyBHNsawNsaW5rcwRzdGltZQMxMjU1NTYzNjU4
8. 
http://groups.yahoo.com/group/dstar_digital/database;_ylc=X3oDMTJkNTVibmIxBF9TAzk3MzU5NzE0BGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDZnRyBHNsawNkYgRzdGltZQMxMjU1NTYzNjU4
9. 
http://groups.yahoo.com/group/dstar_digital/polls;_ylc=X3oDMTJnajBzcGZ0BF9TAzk3MzU5NzE0BGdycElkAzIwNTEwNTI2BGdycHNwSWQDMTcwNTA2MzEwOARzZWMDZnRyBHNsawNwb2xscwRzdGltZQMxMjU1NTYzN

Re: [DSTAR_DIGITAL] Re: Beeps

[Nate Duehr]

That is not what I read in previous discussions by folks who were
actually doing protocol-level work, but if you insist that the
headers are encapsulated inside the portion of the stream that's
covered by FEC, I can't really refute it technically.

What I can be sure of, is that the statement makes no sense.  If
a voice is copyable in a signal, but the header was mangled, that
would certainly appear that either:

a) FEC wasn't applied to the header.
b) The way the FEC was applied to the header/the way the protocol
handles header/callsign information is... well, busted.
c) Voice is copyable by the human ear even with artifacts from
errors.

But we all already knew the b) version of that, anyway.  Headers
should have been continuously interlaced in the slow data field
or actually designed into the protocol as a continuous repetitive
stream, so the GW software and controller firmware could have
been designed to "pick up mid-stream" if a copyable version of
the callsigns were to pass a CRC (or other mathematical) check in
the middle of a transmission, after missing the header completely
at the beginning of one.

It's also "too bad" that the repeaters weren't designed for field
firmware updates.  If they were, they could at least be patched
to watch the slow-speed data callsigns, but my understanding is
that only Your Call is sent in that way, not the UR, RPT1, or
RPT2... so I can see why it wouldn't really matter if the
Controller or GW had visibility to it.  It seems to have been
added only to help the receiving radio.
In layman's terms, and in how we all know the system behaves in
the wild: "Callsign headers from mobile/weak stations get missed,
far too often."

And that led to the GW design allowing "tailgating" to handle
mobile drop out at the critical time at the beginning of the
transmission.

Those two statements pretty much cover it without getting overly
technical for those not interested...

D-STAR is a great learning experience for the NEXT major mobile
digital mode.  Nothing "wrong" with it that couldn't easily be
fixed with protocol changes to match current telecom protocol
"best practices".

--
Nate Duehr, WY0X
n...@natetech.com

On Wed, 14 Oct 2009 21:23 +, "Jonathan Naylor"
 wrote:


Hi Nate
You're wrong about the callsigns in the header not having FEC,
they are. In fact they're probably better protected than the AMBE
data if you equate the amount of protection with the extra data
added for the FEC. What is not protected is the header data that
is repeated in the slow data field, but AFAIK the repeater itself
doesn't use that.
Jonathan G4KLX
__._,_._

RE: [DSTAR_DIGITAL] Re: callsign routing

[Woodrick, Ed]

AFAIK, the ONLY updating that occurs is to the Trust Server and then replicated 
out. So one repeater will not update another repeater system.

The only exception, with the latest gateway software, is that if you move 
between modules on the same system, the local system will redirect the call to 
the module that you are on.

Ed WA4YIH


From: dstar_digital@yahoogroups.com [mailto:dstar_digi...@yahoogroups.com] On 
Behalf Of Dave Cooley
Sent: Friday, October 16, 2009 7:50 AM
To: dstar_digital@yahoogroups.com
Subject: [DSTAR_DIGITAL] Re: callsign routing



Tony and John ,

I agree fully.

And yes it is best to announce how you are coming in.

*/Here is a question for the Gateway Experts:/*

On the issue of Update Latency;

When a user call sign routes into a repeater does that repeater update

the users table with their current information?

Example: Lets say I have been on W1AW and now switch to W2AW. I make a

(call sign route) call to N2LZ who is on W3AW . Will W3AW update my

location information immediately with my new location (W2AW) or does it

have to wait until the trust server update? If it would update from the

traffic information, the mobile user could just make a callsign routed

call back to their home repeater (or in Frans case, his sons home

repeater), and this would immediately update their location on that

repeater. I realize this doesn't correct the problem of update latency,

but I think in many situations would provide an acceptable work around

as most users only communicate with one or two repeaters on a regular basis.

Food For Thought!
Dave Cooley
Brandon, Fl.

RE: [DSTAR_DIGITAL] Re:callsign routing

[Woodrick, Ed]

I'll start with what might be an enlightening description...

Repeater linking is not performed by the Icom software, it is provided by 
AA4RC's DPLUS. Call sign routing is performed by the Icom software and has no 
concept that DPLUS is running . So, in short, since the Icom Software doesn't 
know that DPLUS is running, all call sign routing has no idea that a repeater 
is linked or not.

Answers embedded.

From: dstar_digital@yahoogroups.com [mailto:dstar_digi...@yahoogroups.com] On 
Behalf Of larryhayter
Sent: Friday, October 16, 2009 7:32 AM
To: dstar_digital@yahoogroups.com
Subject: [DSTAR_DIGITAL] Re:callsign routing



A few questions
I've used Callsign Routing as well as most of the other methods available on 
the system. All have been both successful and at other times not so much.
Here are the questions as well as my thoughts to date which are subject to 
correction.
1. If the repeater I am using is connected to a reflector is Callsign Routing 
processed or does it fail because of the active link.
Probably not accepted or processed?

It works just as if the repeater wasn't linked. This can get confusing if you 
(A) are having a callsign routed conversation to B while the repeater is linked 
to a reflector, then only you (and the people on your system) hear B. So, no 
one else on the reflector hears B. They all assume that you are talking to 
yourself.

2. If the system attempts to forward the call to a destination repeater that 
may be in use or linked within the system what is the result.
Probably not processed at the far end?

It works as if the repeater wasn't linked.

3. In each of these cases is there any indication on my side as to whether my 
attempt to call my party was properly processed or failed. I may be missing 
something there.
??

There is an indication on the radio if the call sign route fails for some 
reason. But in case 1 or 2, the call didn't fail. The only way that it can fail 
is if the call sign that you are routing to doesn't exist, or the repeater that 
you are talking to is currently transmitting.

4. If the answer to question 1. is that I cannot route by callsign while the 
repeater is linked, is it proper to disconnect the link considering that I may 
not have the privledge to re-establish it even if I know where it was 
previously linked.
I've not attempted to disconnect in order not to bother other users or 
listeners


Check with your local administrator for recommendations. Not all systems follow 
the same guidelines. On an "Open Repeater" the common courtesy would be to ask 
if anyone is using the link first. Then drop it if no one responds and then 
make your call. If the system administrator indicates that you should relink a 
repeater afterwards, the do so.



I do enjoy the whole system congratulate everyone on there work and successes 
to date. I really enjoy watching the progress the system has seen over the last 
year.

Larry
VE3LGH

[DSTAR_DIGITAL] Re: More open source D-Star repeater progress

[Jonathan Naylor]

Hi Robbie

I have a Yahoo group to distribute and support the software, which also 
includes an analogue repeater controller, and eventually a full dual-mode 
repeater. It's located at .

The current hardware support is for the Velleman K8055 for control and the 
cheapest USB sound card you can find! (The lack of filtering in them is ideal).

Jonathan  G4KLX

Re: [DSTAR_DIGITAL] More open source D-Star repeater progress

[Robbie De Lise]

Where to find more information about this ?
(software/hardware etc)

73s
Robbie ON4SAX

On Fri, Oct 16, 2009 at 1:00 PM, Jonathan Naylor  wrote:

>
>
> I'm happy to report that last night a QSO was made on D-Star using a
> combination of my open source repeater software and the open source gateway
> and reflector from Scott KI4LKF. The QSO was between Jon G4TSN and Scott
> KI4LKF via the GB3IN dual-mode repeater and the XREF005A reflector. I expect
> that my software would also work together with the official Icom G2 gateway
> software.
>
> D-Star is still a long way from being truly open, but it has taken a step
> closer, and a fully functional D-Star repeater can now be built by anyone
> using nothing but software and a small amount of readily available hardware.
>
> Jonathan G4KLX
>
>  
>

[DSTAR_DIGITAL] Re: callsign routing

[Dave Cooley]

Tony and John ,

I agree fully.

And yes it is best to announce how you are coming in.

*/Here is a question for the Gateway Experts:/*

On the issue of Update Latency;

When a user call sign routes into a repeater does that repeater update

the users table with their current information?

Example: Lets say I have been on W1AW and now switch to W2AW. I make a

(call sign route) call to N2LZ who is on W3AW . Will W3AW update my

location information immediately with my new location (W2AW) or does it

have to wait until the trust server update? If it would update from the

traffic information, the mobile user could just make a callsign routed

call back to their home repeater (or in Frans case, his sons home

repeater), and this would immediately update their location on that

repeater. I realize this doesn't correct the problem of update latency,

but I think in many situations would provide an acceptable work around

as most users only communicate with one or two repeaters on a regular basis.

Food For Thought!

Dave Cooley
Brandon, Fl.

[DSTAR_DIGITAL] Re: callsign routing

[Dave Cooley]

Dave Cooley
Brandon, Fl.

[DSTAR_DIGITAL] Re:callsign routing

[larryhayter]

A few questions
I've used Callsign Routing as well as most of the other methods available on 
the system. All have been both successful and at other times not so much.
Here are the questions as well as my thoughts to date which are subject to 
correction.
1. If the repeater I am using is connected to a reflector is Callsign Routing 
processed or does it fail because of the active link.
   Probably not accepted or processed?
2. If the system attempts to forward the call to a destination repeater that 
may be in use or linked within the system what is the result.
   Probably not processed at the far end?
3. In each of these cases is there any indication on my side as to whether my 
attempt to call my party was properly processed or failed. I may be missing 
something there.
   ??
4. If the answer to question 1. is that I cannot route by callsign while the 
repeater is linked, is it proper to disconnect the link considering that I may 
not have the privledge to re-establish it even if I know where it was 
previously linked.
 I've not attempted to disconnect in order not to bother other users or 
listeners

I do enjoy the whole system congratulate everyone on there work and successes 
to date. I really enjoy watching the progress the system has seen over the last 
year.

Larry
VE3LGH

[DSTAR_DIGITAL] More open source D-Star repeater progress

[Jonathan Naylor]

I'm happy to report that last night a QSO was made on D-Star using a
combination of my open source repeater software and the open source gateway and 
reflector from Scott KI4LKF. The QSO was between Jon G4TSN and Scott KI4LKF via 
the GB3IN dual-mode repeater and the XREF005A reflector. I expect that my 
software would also work together with the official Icom G2 gateway software.

D-Star is still a long way from being truly open, but it has taken a step 
closer, and a fully functional D-Star repeater can now be built by anyone using 
nothing but software and a small amount of readily available hardware.

Jonathan G4KLX