[aprssig] Future Concept for APRS

[Matti Aarnio]

On Mon, Sep 21, 2009 at 12:50:55AM -0400, Bob Bruninga  wrote:
> Matti Aarnio, OH2MQK, wrote:
> > So, if here somebody wants to use messaging with somebody, they are
> > within the service area of same digipeater.  No non-local traffic.
> 
> This is too bad that Finland has hacked up the APRS network and does
> not  allow two-way messaging.  This is a shock to me and to all APRS
> travelers!  And it shows why messaging does not work well via Igates
> beacuse of such local draconian hacks... that destroy the integrity of
> the APRS network and Global APRS-IS connectivity!

Please do give us motivation to develop the two-way messaging.
Currently APRS-1.0.1 protocol says:  US-ASCII, 7-BIT CHARACTERS.
For us that is completely inadequate.

I am now writing in an approximation of English, but when talking with
other local people, I use my native language, which requires a bunch of
characters outside the US-ASCII.

To make the APRS MESSAGING usable here, you must amend the fundamental
APRS "protocol" specification to require binary transparent (versus
present US-ASCII transparent) interface to TNC.  You must also amend
the character set definition from US-ASCII to something really useful.

Practically that is UNICODE, and byte stream representation options you
have are:  UTF-16  (commonly sends char(0) at every second byte when
sending ASCII or west european characters, and it has problems with
big-endian vs. little-endian),  and then you have the UTF-8, which does
not send char(0), and is endianity free.

I would be a lot more motivated to on anything on messaging, if the
specification says:

    Messaging is done using UNICODE characters in UTF-8 encoding.

When using only characters present in US-ASCII, the messages are identical.

Now the fact that dead softwares, like UIview, are unable to be updated to
do UTF-8 is no big deal.  Just one more motivator to trash them, and to
write better ones.


Also do realize that while FCC may have very relaxed rules regarding
automatic transmitters (digi and tx-igate both), other administrations
are not quite so free minded.


> Again... these appear to be more examples of why I worry about
> individual sysops making draconian local hacks to the network:
> 
> > Network viability preservation says that 
> > if you do send more than N messages
> > per minute, we must not digipeat your packets.
> 
> What!  The person who gets involved in a situation, event, or
> emergency may need to send lots of messages right now!  Having
> such a draconian rule that limits an individuals need to communicate
> destroys the flexibility of APRS to be responsive to the need of
> the moment.  We need to be careful in making narrow definitions
> of what one individual wants to see on his screen.
> 
> If some people are overusing the network on a regular basis for
> idle chit-chat that is objectionable, then raise the issue with
> those individuals.  Dont cripple the network!

We can do elastic algorithms to permit occasional high traffic peaks,
but prolonged channel flooding is to be automatically protected by
not retransmitting all packets when channel occupancy reaches high
enough value. (When around 60-70% of time there is carrier on channel.)

If that is dragonian, so be it.  (Multiple-Access channels throughput
degrades very rapidly when channel occupancy exceeds about 60%)

...
> > Digipeating packets with indicated position 
> > far from local system is also very questionable.
> 
> It happens very often for the travler with his HT.  When I travel and
> pass through airports with my APRS HT, I frequently use it to send
> messages and I do NOT usually bother with the GPS (doesnt work indoors
> anyway).  Therefore the radio is probalby sending my HOME location,
> even though I am 500 miles away.  If you implemented this rule, no one
> could message unless they had a GPS!  And that is a severe restriction
> to the messaging function of APRS...

Strange..  Most times I do get a fix - Sirf-III is quite sensitive, and
you do not need a geodetic accuracy fix anyway.   If you insist on using
something 10+ years old that is 10-20 dB less sensitive, well, tough.


> > When a chap in south Sweden sends a beacon of WIDE7-7, and I hear it
> > repeated  5 to 10 times in Helsinki, it means that  a) there is 2m
> > tropo in baltic! b) bloody flools really should know better and not
> > do that kind of thing
> 
> Yes, and the New-N  Paradigm should limit hops to 2 or 3 and is a perfect
> solution.  No need to criple the network when the network already has the
> tools to solve the problem to limit large hop counts.  Also you should
> educate the user that 7-7 is abusive.

Yet 3 weeks ago you said that "lets beacon WIDE7-7 for now" regarding
6m band APRS experiments.

When this is the way how you define new uses for the protocol, it really
makes it difficult to educate people...

Unfortunately most digis in this continent are UIDIGI, which does New-N,
but is utterly unable to limit the number of executed hops to something
lower than the requested N.  Furthermore the UIDIGI is dead software with
unpublished source code.


> > If you transmit positionless packets, 
> > in our thinking they will not be
> > digipeated unless you have recently 
> > enough sent a position that is within
> > our local service coverage.
> 
> So APRS in your area is only for vehicle tracking.  That is unfortunate.
> Vehicle tracking is not of much interest to most hams.  Most hams want
> to do 2-way communications, not watch some tracker drive around with no
> way to talk to him...

Voice radio works -- locally, of course.  Also when driving, I can not go
poking at some keyboard and reading undersize text in undersize display.
(Not to mention wanting to use our native characters...)


> >>> Remember, it is our network, not yours. 
> 
> No, the network is supposed to serve ALL ham travelers, not just some
> locally defined only-do-it-our-way kingdoms.

So when WB4APR appears in Helsinki, we must provide bi-directional messaging
for him?  Sure we can, if you can be bothered to fix the specification so
that also we could use the messaging among ourselves.

 
> > Here locally we have been hashing some 
> > Requirement Specifications for an APRS 
> > DIGI/IGATE as we see it.
> 
> I hope I can find the time to look at them.  So far, some of the ideas
> you have proposed are very worrysome to the consistent operation of
> the network for the traveler...

Now is your change to affect on requirements, before I start coding.


> >  http://repo.ham.fi/svn/aprx/trunk/doc/
> 
> Please give the New-N paradigm and the ability to trap large N a good
> impementation.  I think it will solve many of your problems...
> if done correctly...
> 
> Bob, Wb4APR

Please do read the pdf.

  73 de Matti, OH2MQK