[aprssig] Future Concept for APRS
Chris Moulding
chrism at crosscountrywireless.net
Mon Sep 21 12:28:55 EDT 2009
Matti,
I've recently written a program for APRS messaging using serial TNC's
called APRS Messenger.
It's not fixed to the US-ASCII character set and to check I've just
re-set a laptop to the Finnish language and keyboard settings and sent
APRS messages with the correct Finnish characters over my test rig that
consists of two APRS TNC Digi Tracker's mounted back to back. It will
probably work with the Russian character set as well.
You can download the program at
http://www.crosscountrywireless.net/aprs_messenger.htm
The program is now at version 1.8.2.
Let me know if it solves your messaging problem.
73s,
Chris, G4HYG
Chris Moulding
Cross Country Wireless (2009) Ltd
7 Thirlmere Grove, Bolton, Lancs, BL4 0QB, UK
Tel/fax: +44(0)1204 410626
Mobile: +44(0)7752 391908
Website: http://www.crosscountrywireless.net
Company number 6780346 registered in England and Wales
Matti Aarnio wrote:
> 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
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3306 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20090921/eb8d1f62/attachment.p7s>
More information about the aprssig
mailing list