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

[Robert Bruninga]

>> 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