Order Tray | Contact Us | Home | SIG Lists

[aprssig] Burst after voice (was pointless text)

Robert Bruninga bruninga at usna.edu
Thu Jun 1 16:19:51 UTC 2006

Yes, I have pointed out this flaw from day one to all designers of
Mic-E's.  The PTT sense input from the Microphone must be 
*separate* from the Mic-E PTT output so that the Mic-E can 
hold the PTT down without any even a millisecond of transition.  

Else the whole advantage of the Mic-E (of avoiding ANY TXDdelay) is lost.
and you have just another packet on a voice channel that is very
anoying.  A Mic-E packet by itself should only be about 270 ms long
if done right.  Not very anoying compared to the usual 1500 ms
APRS non-Mic-E packet.  But adding 300 to 500 ms of TXD to what
is only a 270 ms packet really kills the PTT mode concept of the


>>> wa8lmf2 at aol.com 06/01/06 12:10 PM >>>
wes at kd4rdb.com wrote:
> I
> I _think_ I've also discovered a bug in the TT3's implementation of 
> the burst after voice too... my TT3 is hooked in series with the mic's 
> PTT and should assert PTT after my mic has pulled PTT low.  It should 
> continue to hold PTT low until I unkey, send data, then release PTT.  
> But instead it does not clamp PTT.  It seems to wait for me to unkey, 
> then assert PTT and send data.  This causes the radio to go thru a 
> full TX->RX->TX cycle and prevents me from running a TXDelay of less 
> than 150mS.  I think we should be able to run a TXD of 50mS in this 
> mode though.  On a nearby HT, I can hear a little static crash between 
> when I unkey and the data is squirted and on the radio I'm talking on, 
> I can see the PTT indicator do a little 'double dip'. I'm not sure if 
> this is a problem with _my_ TT3 or all of them.  I asked about this on 
> the TT yahoo group and got no answer and also have email Byon and he 
> said he's looking into it.  Does anyone here have any experience with 
> this?

I've observed the same thing using the TinyTrak in my APRN system where 
the APRS burst follows an SSTV transmission.  The radio definitely 
unkeys and then rekeys between the video and the packet burst.  

I'm considering adding a hardware pulse stretcher kludge downstream from 
the TT to bridge the unkey-rekey hiccup.  


Stephen H. Smith    wa8lmf (at) aol.com
EchoLink Node:      14400    [Think bottom of the 2M band]
Home Page:          http://wa8lmf.com 

NEW!   JavAPRS Filter Port 14580 Guide

UI-View Misc Notes and FAQ

"APRS 101"  Explanation of APRS Path Selection & Digipeating

Updated "Rev G" APRS            http://webs.lanset.com/wa8lmf/aprs 
Symbols Set for UI-View,
UIpoint and APRSplus:

aprssig mailing list
aprssig at lists.tapr.org 

More information about the aprssig mailing list