[aprssig] PIC processor for APRS info for D-STAR mobiles?

[Scott Miller]

I can't help but think that if D-STAR had been designed with some input 
from the worldwide amateur community a lot of this could have been built 
into the standard.

I don't understand all of the fuss about interleaving other data with a 
user's transmission, if there is unused bandwidth there.  You could 
simply tag it as having originated elsewhere - maybe prefix it with the 
repeater's own callsign.

Scott
N1VG

Robert Bruninga wrote:
>>> But if we cannot find a clever way to get access 
>>> to the repeater's idle DV bits when it is not in 
>>> use, then I can see your issues.
>> 
>> There are no "repeater's idle DV bits".  A repeater 
>> is just that, a repeater.  It is repeating someone 
>> else's signal and that is how it is presented to all 
>> listeners.  Hope this helps clear things up.
> 
> Thanks. It does.  So now then can the following summarise and
> maybe conclude this thread:
> 
> 1) D-PRS can translate D-STAR GPS data into APRS for
> distribution on APRS.
> 2) D-PRS can also translate APRS packets into GPS-A format
> 3) There is no inherent displays on D-STAR radios of any of this
> information
> 4) An external display system could be developed to display this
> information
> 5) D-STAR repeaters have no independent DV bit stream inputs.
> 6) The only thing that comes out of a D-STAR repeater is what
> goes in on the RF input.
> 7) Modifying D-STAR repeater functionality is impossible
> 8) Therefore, there is no way to inject local information to the
> repeater DV outgoing bits without sending it in on the RF input
> thereby unacceptibly blocking other voice users.
> 
> This of course is what Pete has said all along, but now we have
> seen the basis of the why's and wherefores... The only
> workarounds (no matter how impractical) would require?
> 
> 0) Not using a D-STAR repeater, but a bi-directional D-GATE...
> -OR-
> 
> 1) Modification of the repeaters for independent streaming of
> the DV bits while the repeater was idle.
> 
> 2) Something in those bits to carry a MUTE signal telling the
> user radios that there is no VOICE and to keep the speaker
> quiet.
> 
> 3) #2 might require modifications to all participating user
> radios to accept the MUTE?
> 3a) are any of these radios field flashable?
> 
> The above (no matter how impractical) would be needed to allow
> the streaming of local information on the DV bits of the
> repeater while the repeater was idle.  But when it was in use
> then none of this data is passed. And a voice repeater is
> usually in use for voice...  And we cannot interleave other data
> while one person is talking because it would modify his data
> without his permission.  So this suggests that we have one more
> requirement:
> 
> 4) Add a permission bit in the GPS originated data.  Currently
> the D-PRS recommended format is something like "SSS text*CK".
> Maybe the SPACE  between the symbol bytes and the text could be
> changed to an underline or something.  This signals that this
> user is willing to have his data periodically interleaved with
> other APRS data when he goes through a D-STAR repeater so
> configured..
> 
> If Pete can confirm this simplification and/or clean this up,
> then we can let it be the resulting final summary of this thread
> as to the difficulties of supplying local information to the
> D-STAR mobile user via the DV bits.
> 
> Maybe?
> 
> Bob, WB4APR
> 
> 
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
> 
>