[OZAPRS] MICE usage

[owen]

Hello Dom, All,

An interesting possible explanation, and it may partly account for the
observations.

However, here is one of TKK's posits:

2014-09-23 12:02:47 EST: *VK3TKK-9
<http://aprs.fi/?c=raw&limit=&call=VK3TKK-9>*>ST43ZL,VK2AMW-1*
<http://aprs.fi/?c=raw&limit=&call=VK2AMW-1>,WIDE2-1,qAR,VK2NR-5
<http://aprs.fi/?c=raw&limit=&call=VK2NR-5>:`MV<0x1c>qzZ>/`";3}Just cruising ^:-}_"
2014-09-23 12:02:48 EST: *VK3TKK-9
<http://aprs.fi/?c=raw&limit=&call=VK3TKK-9>*>ST43ZL,VK2AMW-1
<http://aprs.fi/?c=raw&limit=&call=VK2AMW-1>,VK2RTZ-1
<http://aprs.fi/?c=raw&limit=&call=VK2RTZ-1>,WIDE2*,qAR,VK2ZEN-5
<http://aprs.fi/?c=raw&limit=&call=VK2ZEN-5>:`MV qzZ>/`";3}Just cruising ^:-}_" 

Look at the  <0x1c> in NR's submission, and see that in ZEN's for the
same posit, there is a blank.

Some software developers think that AX.25 packets contain printable
characters, and substitute non-printables (eg with a space as here) and
so corrupt the packets. It seems aprsd developers may have thought that way.

MICE packets are not purely printable characters, and it is presumptuous
for any server handling traffic to edit the contents of a another
parties packet 'info' section.

I think this problem in aprsd has been known for more than a decade.

Best way to avoid position reports if that is a concern is to turn the
thing off, and it saves bandwidth otherwise utilised by garbage!

73
Owen


On 23/09/2014 15:26, Dom Dahl wrote:
> Hi Owen
>
> I thought the same thing to start with but his whole track was from
> goulburn was all over the place. (I didn't look back any futher)
>
> I was reading this the othe day and i think this would explain what
> VK3TKK-9 setup is. Its more a security thing. Who knows why you would
> use it but some people just really don't want you to know there exact
> location.
>
> Cheers
>
> Dom
>
>
>     Ambiguous positions
>
> Many APRS transmitters using MIC-E or uncompressed packets can be
> configured to intentionally transmit less precise positions. This may
> seem a bit backward at first, but there are perfectly good reasons to
> do so. Some people might want to transmit a rough location of their
> car without revealing the exact parking spot where their expensive
> radio gear spend their night in. Some might like some aspects of APRS
> but wish to adjust the level of privacy by hiding their precise location.
>
> Ambiguity is configured by setting the number of digits which will be
> truncated from the end of the position. Plaintext APRS positions are
> transmitted in degrees and decimal minutes (DD° MM.mm'), with two
> decimals of minutes. When ambiguity is set to 1, it'll be truncated to
> DD° MM.m', 2 will transmit DD° mm', 4 will transmit DD° only,
> resulting in a resolution of 1 degree.
>
> The station in the following image has chosen to send positions with 1
> digit of precision reduced. It can be seen that the car is driving the
> ring road, but the positions are slightly off.
>
>
>
> On Tue, Sep 23, 2014 at 3:00 PM, owen <owen at owenduffy.net
> <mailto:owen at owenduffy.net>> wrote:
>
>     Hello All,
>
>     In the past, I have been a devotee of MIC encoding as it reduced
>     packet
>     size, reducing channel utilisation and increasing probability of
>     successful transmission.
>
>     But... I have review that position seeing the existence and continued
>     operation of nodes that corrupt MICE packets.
>
>     An example of the effect is VK3TKK-9's track up the Hume today, see
>     http://owenduffy.net/files/Screenshot%20-%2023_09_2014%20,%2013_20_03.png
>     .
>
>     No, he is not drunk... his MICE packets are corrupted by VK2ZEN-5 and
>     hence the gross track errors.
>
>     My suggestion is to NOT use MIC encoding as there would seem little
>     chance of fixing network infrastructure.
>
>     73
>     Owen
>     _______________________________________________
>     OZAPRS mailing list
>     OZAPRS at aprs.net.au <mailto:OZAPRS at aprs.net.au>
>     http://lists.aprs.net.au/mailman/listinfo/ozaprs
>
>
>
>
> _______________________________________________
> OZAPRS mailing list
> OZAPRS at aprs.net.au
> http://lists.aprs.net.au/mailman/listinfo/ozaprs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.aprs.net.au/pipermail/ozaprs/attachments/20140923/2d3edbe5/attachment.html>