[Xastir] Mic-E problem.

[Curt Mills, WE7U]

On Tue, 13 Aug 2002, Curt Mills, WE7U wrote:

> On Tue, 13 Aug 2002, Rolf Dahl wrote:
>
> > Getting this info from FindU :
> > Raw packet: LA7MHA-9>UWTWLL,SK5MR,SK0MM-5,SK0CC,SK5MK,SK5AD*,TRACE5-1,qAR,SM5NRK:`*)*l!];/>"5:}I Joenkjoeping.
> >
> > Then i do a "fetch findu trail" for LA7MHA-9 and the pos. fix are locatet:
> >  08/13  00:14   57 47.500N  114 13.499W   126m    0km/h 165°  DO27VT
> >
> > The position Xastir decode is not corect.
>
> The problem is definitely in the Xastir Mic-E decoding.

Found the problem:

We were testing for the bit patterns found in the TAPR Mic-E
document (not the APRS spec) and we didn't handle this special case:
Position ambiguity letter of 'L'.  Masking off and testing bit 0x40
doesn't work for this case.  I added specific tests for 'L' in order
to solve this problem.  Now if we see 'L' specifically we set the
North, West, or Longitude_Offset bits to zero.

Also, in the Mic-E document the Table showing the "Message/N/W/L
Bit" has the state of the bit wrong at the heading for columns 2 and
3.

It should read like this:

Latitude Digit  Message/N/W/L Bit  Message Bit/N/W/L  Custom Msg. Bit =
                     = 1                 = 0                 1

It currently has 0 1 1 for the state of the bits instead of 1 0 1.

You'll notice reading down the columns that in column 3 it goes from
0 to 9, and then L.  That goes from 0x30 to 0x39, and then 0x4c.
Unfortunately they chose a letter for ambiguity that has bit 0x40
set.  That caused our problem.  It is one special case that doesn't
fit the bit pattern given just before it in the document.  Oh well.

Fixed in CVS.

Curt Mills, WE7U                         hacker.NO_*SPAM at tc.fluke.com
Senior Methods Engineer/SysAdmin
"Lotto:    A tax on people who are bad at math." -- unknown
"Windows:  Microsoft's tax on computer illiterates." -- WE7U