Mic-E TYPE CODES                                         20 Oct 2009
--------------------------------------------------------------------

See also www.aprs.org/aprs12/mic-e-examples.txt for formatting help!

Revised  20 Oct 09 to add Yaesu FTM-350
Revised  21 Oct 08 to clarify and add notes on D710 present decoding
Revised  18 Aug 08 to reverse order of MFR and Version bytes:
Revised  15 Aug 08 to set up OTHER category and use ENDING bytes.
Original 14 Jul 08

Old idea:  T.......vM   Prior to 18 August 08
New idea:  T.......Mv   allows more flexibiilty in use of "v"

BACKGROUND:  When the APRS SPEC was written, there were only a few 
Mic-E products in use.  These were the original Mic-E prototype, the 
TAPR Mic-E kit, and the two Kenwood radios, D7 and D700.  The first
byte of the original free-text field was designated as a TYPE 
identifier to identify different devices.

It is important that the type of Mic-E device be identified, since 
some may have very important distinct properties.  For example we
need to know which devices are message capable or not.  In the 
future, we may want to know which models can auto-tune or not.

ORIGINAL TYPE CODE:  The first byte of the original free-field text 
was set-aside for use in indicating the type of Mic-E device.  On 
page 55 of chapter 10 of the spec, the first two of these TYPE CODES 
">" and "]" were defined for the D7 and D700.  In addition, the 
statement was made:

"It is envisioned that other Mic-E compatible devices will be
allocated their own type-codes in the future."

The future has arrived, but unfortunately, the many thousands of 
existing D7 and D700's only recognize other D7, D700's and the
original Mic-E.  Luckily, the Kenwood also seems to recognize two
additional TYPE CODE characters ` and ' which we can now use to 
define the category called "OTHER Mic-E".  The ` character will 
define message capable Mic-E devices and the ' will identify 
Trackers only.

D710 VERSION CODE:  For backwards compatibility, the D710 uses the
same "]" Type byte as the D700 but adds a special "=" byte on the
end to distinguish the new radio.  We will use the abbreviated
syntax of ]......= to represent this Mic-E TYPE code.  The seven
dots represent free text but it can also contain the special
"aaa}" altitude.

VALID TYPE CODE AND VERSION CODES.  For the purpose of this Mic-E
update to the spec, the written format for the free-field text 
defined in the original APRS spec will be referred to as 

Mic-E TEXT FORMAT:   "T......Mv".

Where T is the Mic-E TYPE byte (" ",">","]","`","'")
Where ........ is free field text
Where aaa}.... like Taaa}....Mv is optional altitude
Where "M" represents the Manufacturer Byte 
Where "v" represents a version number

Using this definition, all of the following examples have been 
tested to work with existing D7 and D700 radios.  The D710 also
decodes them, (but there is a minor bug to be fixed later).  The
Yaesu VX-8 and FTM-350 will be compatible.

LEGACY FORMATS (to be recognized always in all models)

 .......  Original Mic-E (leading space)  (not message capable)
>.......  TH-D7A walkie Talkie            (message capable)
>......v  *future TH-D7A upgrade version
].......  TM-D700 MObile Radio            (message capable)
]......=  TM-D710 Mobile Radio            (message capable)
]......v  *future D7xx models version

NEW FORMATS FOR ALL FUTURE APPLICATIONS:

`......Mv  OTHER Mic-E  - display "McE-msg" if limited to 7 bytes
'......Mv  OTHER Mic-E  - display "McE-trk" if limited to 7 bytes
`......Mv  OTHER Mic-E  - display "MicE-msg" if 8 bytes available
'......Mv  OTHER Mic-E  - display "McTrackr" if 8 bytes available

As combinations of "Mv" bytes are added to this table, manufacturers
are encouraged to display the correct radio type if known.  The
following additional bytes have been declared:

`......_b  Yaesu VX-8R (b = SPACE) (message capable)
`......_"  Yaesu FTM-350 (message capable)
'......|3  Byonics TinyTrack3 (TT3)  
'......|4  Byonics TinyTrack4 (TT4)
T......\v  Hamhud  ? (awaiting confirmation?)
T....../v  Argent  ? (awaiting confirmation?)
T......~v  OTHER (to be used when all other "M" MFR's are used up)

Other manufacturer type codes could be:

T......`v
T......'v
T....../v
T......\v
T......^v
T......-v
T......:v
T......;v
T.......v
T......*v

Or any other ending bytes that will not cause confusion on the end
of any random text.  Designers of Mic-E type devices are encouraged 
to advise their intent to use a specific ENDING code (M) and  so 
that other designers can include them in their code for display.

DELIMTER BYTE:  As one last afterthought, if the MFR wants to 
really make sure that his "Mv" code on the end of any random text
does not add confusion to the text, maybe we should consider 
preceeding it with a forced SPACE byte.  This way the Mv code of 
"-3" would not be too confusing on the end of this "...text-3", 
but would  look cleaner as "...text -3".

RECEIVING AND DISPLAY OF MIC-E TEXT (STATUS):   Since the leading
TYPE byte "T" was not as well defined as it could have been in the 
original Mic-E spec, this byte will be displayed as part of the text 
on some existing receiving applications that display the received 
Mic-E text.  It is recommended that all future RECEIPT and DISPLAY 
software consider that this leading TYPE byte will usually be one 
of the above TYPE characters " ", ">", "]", "'", or "`" and 
should not display it with the text.  This is essential to maintain 
the common 10x10x8 text formatting of local information for best 
display on mobile displays.

So, suppress the T-TYPE byte from the text display if it is 
recognized.  But use this information to display the radio type
elsewhere as appropriate.  Similarly, if the ending "....Mv"
bytes are both recognized and matched and decoded and displayed
elsewhere, then these two bytes may be suppressed from the display
if desired.  If these two bytes are not decoded and are not 
recognized, then they need to be displayed for older radios so 
the operator can interpret their meaning until his firmware is 
updated.

When a new type is not recognized, then display "McE-Msg" for a 
two-way system and "McE-Trk" for a tracker without message 
capability.  If 8 bytes are available for this display, then 
display "MicE-Msg or McTrackr" etc...

This table is maintained on the APRS web page:
www.aprs.org/aprs12/mic-e-types.txt

Adding these two new "'" and "`" OTHER MIC-E TYPE bytes was only
possible beacuse extensive testing showed that those were the only
ASCII bytes that the tens of thousands of D7 and D700 radios would
decode now.  Fortunately, the D710 also parses tthese TYPE bytes,
but the D710 does have some display issues on these new bytes as
noted below:

D710 TYPE-BYTE Fix needed in next version.
--------------------------------------------

Everything works with all the models above except for a small
problem with the D710.  When the OTHER category '......Mv or
`......Mv is used, the D710 CORRECTLY performs the following
parsing:

1) Altitude (leading `AAA}...) is parsed and cut from display text
2) Type is correctly shown as "Mic-E"
3) Frequency (FFF.FFFMHz) is parsed and displayed
4) This Frequency can be TUNED with the TUNE button

BUG:  But on the D710, when the --> buttons are pushed to display 
LAT/LONG or COURSE/SPEED, then the radio displays a BLANK.  This 
is the only incompatibility to the future use of many more Mic-E 
versions and Types.  So we hope that Kenwood can fix this in the 
D710 in the next version.  Because it will be a problem to dislay 
OTHER models of Mic-E.

See examples in www.aprs.org/aprs12/mic-e-examples.txt

Bob Bruninga
WB4APR@amsat.org