| |
ZL3AI > APRDIG 18.06.04 18:36l 815 Lines 30791 Bytes #999 (0) @ WW
BID : 3485-ZL3AI
Read: GUEST
Subj: TAPR Digest, Jun 12, 1/2
Path: DB0FHN<DB0FOR<DB0SIF<DB0EA<DB0RES<ON0AR<VK6HGR<GB7ESX<ZL2BAU<ZL3VML
Sent: 040618/0809Z @:ZL3VML.#80.NZL.OC #:26057 [Chch-NZ] FBB7.00i $:3485-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
TAPR APRS Special Interest Group Digest for Saturday, June 12, 2004.
1. why kenwood d7
2. Re: ping
3. Re: question about possession of an object.
4. Re: question about possession of an object.
5. APRS IS stats and access
6. Re: question about possession of an object.
7. RE: Thoughts on a proposed replacement for D700
8. Re: Traffic and Weather Together on the Eights
9. Re: why kenwood d7
10. Re: question about possession of an object.
11. Re: XASTIR - Mac OSX - Serial Ports ?????
12. Where can I get Midland & Big Spring Texas maps
13. RE: APRS IS stats and access
14. Re: question about possession of an object.
15. New APRS resources
16. Re: question about possession of an object.
17. Re: question about possession of an object.
18. Re: ping...APRS Traffic ?
19. Re: why kenwood d7
20. Re: Traffic and Weather Together on the Eights
21. Alinco beacons
22. APRS Focus
23. Re: question about possession of an object.
24. NWS
25. Re: question about possession of an object.
26. APRSCE Maps
27. RE: NWS
28. TX / GPS / TinyTrak
29. Re: TX / GPS / TinyTrak
30. Atmel Butterfly - New personal HamHud?
31. RE: B2V path
32. PocketAPRS
33. APRS Messages to Instant Message bridge ?
34. Re: APRS Messages to Instant Message bridge ?
35. Re: question about possession of an object.
36. Re: APRS Messages to Instant Message bridge ?
37. Re: APRS Messages to Instant Message bridge ?
38. Rino stuff
----------------------------------------------------------------------
Subject: why kenwood d7
From: Kevin Deckert <kdeckert@telus.net>
Date: Sun, 06 Jun 2004 00:54:22 -0700
X-Message-Number: 1
It struggled for a long time over the decision to purchase a kenwood
handheld the D7 seemed like a lot o money. I have had the priveldge of
using it under some demanding conditions. As well as many other forms of
APRS equipment. I am senior Search manger as well as a "bonifide"
Tracker
Yes I track people by following their tracks and the operations team
can follow mine by watching my D7 broadcast my location back to base.
It is great for me to be able in the field to see all the other "dumb"
Electronic trackers as well...But the best feature for me is the ability
of the D7 to log stations into the disply of my Garmin 12xl...is a
simple, dependable set up.......
Messaging back to operations from the D7 is great for getting urgent
comms through without the inevitable "news" media knowing what is
happening.......
de ve7whk
----------------------------------------------------------------------
Subject: Re: ping
From: "DG2JW" <dg2jw@privateasylum.com>
Date: Sat, 12 Jun 2004 12:38:53 +0300
X-Message-Number: 2
Well all the toys were divided and everyone went home to play alone for
a while.
Sometimes its the best way. :)
I could argue about something with you Wes if you'd feel better :)
Julian
----- Original Message -----
From: "Wes Johnston" <wes@johnston.net>
>kinda dead here! perhaps the storm has stopped.
>Wes
----------------------------------------------------------------------
Subject: Re: question about possession of an object.
From: db2fm <db2fm@jfsattv.de>
Date: Sat, 12 Jun 2004 11:45:15 +0200
X-Message-Number: 3
Am Samstag, 12.06.04 um 00:21 Uhr schrieb Spider:
>----- Original Message -----
>From: "Wes Johnston" <wes@johnston.net>
>
>>What is the difference between an object and an item?
>
>Chapter 11, page 57 and 58 of the spec.
>
>Jim
Only difference, as I read the named part of the protocol reference, is,
that Objects can have timestamps, items don't. Both must have position, can
have course/speed and other extended data, only objects are allowed to have
time-stamps. "Objects are inteded primarily for plotting moving objects."
The indication character of objects is '*', of items '!', both are killed,
when placing an underscore '_' instead of the '*' or '!'.
There is a mistake in the reference: On page 57 there's written: "..., can
have optional timestamp, ..." on page 58: "An object always has a
timestamp."
That should be cleared ASAP!
Juergen
----------------------------------------------------------------------
Subject: Re: question about possession of an object.
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Sat, 12 Jun 2004 13:39:09 +0200
X-Message-Number: 4
At 11:45 12-6-2004 +0200, db2fm wrote:
>Only difference, as I read the named part of the protocol reference, is, that
>Objects can have timestamps, items don't. Both must have position, can have
Another difference is that the Kenwoods understand Objects but do not
display any Items. Since it looks like everything the Kenwoods do not
understand is not desired I guess Items will become depricated in the
future just like the current proposal for compressed posits.
In when you have a DIGI_NED digipeater in the area, you can send queries to
it to request the position of certain Items like police-stations, hospital,
ham-shops etc. These Items are however send as Objects because of the
Kenwoods. The time on these Objects is set to 010000 to indicate that there
is no time.
I think Bob's QDOS tiny-web-pages use the same for the same reason.
Kind regards,
Henk.
----------------------------------------------------------------------
Subject: APRS IS stats and access
From: Steve Dimse <k4hg@tapr.org>
Date: Sat, 12 Jun 2004 08:46:11 -0400
X-Message-Number: 5
Now that the debate has died down, I have gotten a chance to get my stream
statistics page back up. This page grabs five minutes of data from the four
core hubs, one second tier hub, and findU's local javAPRSSrvr, and then
looks for the middle 4 minutes of data (to allow for latency in the APRS
IS) in the other streams, counting and logging missing packets.
http://www.findu.com/stream
You may remember this was taken down because of changes in the APRS IS,
some of the servers switched on a feature that does not send data until the
logon string appears. The data was grabbed from the servers using telnet,
which does not have a command line way to send a string to effect the
login. Telnet is the same way I've been doing many of the short perl
programs I've posted on the sig, e.g.:
telnet 1.aprs.net | ./mycode.pl
Below is the code to connect to the APRS IS and print out the stream. If
you save this code as, for example aprsis and place it somewhere in your
codepath (like /usr/bin/local/ on most linux systems), the stream will only
be a few keystrokes away, the above example becomes
aprsis | ./mycode.pl
This defaults to rotate.aprs.net (which randomly picks one of the four core
servers) but you can specify any server and port you want:
aprsis 1.aprs.net 10151 | ./mycode.pl
Steve K4HG
----------cut here---------
#!/usr/bin/perl
use IO::Socket;
($host,$port) = @ARGV;
$host = "rotate.aprs.net" unless $host;
$port = 23 unless $port;
$| = 1;
$con = IO::Socket::INET->new(
PeerAddr => $host,
PeerPort => $port,
Proto => "tcp",
Type => SOCK_STREAM,
Timeout => 10) or die ("Can't connect to $host");
sleep(1);
$con->send("user perl pass -1 vers 1.0\n");
while (<$con>)
{
print;
}
----------------------------------------------------------------------
Subject: Re: question about possession of an object.
From: "Spider" <spider@rivcom.net>
Date: Sat, 12 Jun 2004 06:20:12 -0700
X-Message-Number: 6
----- Original Message -----
From: "Henk de Groot" <henk.de.groot@hetnet.nl>
>At 11:45 12-6-2004 +0200, db2fm wrote:
>>Only difference, as I read the named part of the protocol reference, is, that
>>Objects can have timestamps, items don't. Both must have position, can have
>
>Another difference is that the Kenwoods understand Objects but do not
>display any Items. Since it looks like everything the Kenwoods do not
>understand is not desired I guess Items will become depricated in the
>future just like the current proposal for compressed posits.
Hi Henk,
From what I can gather, talking to 'some' of the software authors that
remain active, compressed posits are not going to go away, nor do they feel
the APRS-WG, if it actually exists, will act on the rash decisions being
made. This IS the concensus I've gathered. For some of them, this has
motivated them more into supporting them. On FireNet, we have 20,000+
objects an hour spewing out. We were just asked the question where we send
our objects out compressed! I am waiting to hear the answers on that
one...but I think most of the folks over there really enjoy experimenting
with new things and trying things that may or may not work! Thats part of
the fun of Ham Radio. If someone is learning and experimenting, the way I
look at it is if he crashes my system, SHAME ON ME, but it will get
resolved by working together. Pretty tough group of folks over there but
it's all in fun even though we are serious about what we do!
>In when you have a DIGI_NED digipeater in the area, you can send queries to
>it to request the position of certain Items like police-stations, hospital,
>ham-shops etc. These Items are however send as Objects because of the
>Kenwoods. The time on these Objects is set to 010000 to indicate that there
>is no time.
Interesting. UI-View does not allow the creation of Items. So, for me at
least, I can not play with them or use them.
It does decode them AOK. Sometimes I think the reason such low numbers are
shown in some of these stats is because out of the 20,000 + people that use
APRS, they are not given the choices in software to use the 90% of
the capabilities of APRS...for the most part.
73
WA6OFT
----------------------------------------------------------------------
Subject: RE: Thoughts on a proposed replacement for D700
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Sat, 12 Jun 2004 16:07:56 +0200
X-Message-Number: 7
At 08:25 9-6-2004 -0500, hasan schiers wrote:
>The DR-135TP does not work "reliably" in KISS mode. It may work for an hour
>or less, but then it's non-functional. I have one, and have tried every
>trick in the book to get it to work reliably in kiss mode. I finally gave up
>and use a Tiny2 TNC externally and the radio works fine.
PREFACE
-------
If you have control over the driver sending and receivind the KISS data
from the DR-135TP then a few modifications may help; at least the helped
with the TH-D7 TASCO TNC.
DIAGNOSTICS
-----------
To verify if you have the same problems as the TH-D7 TASCO TNC switch it to
KISS and cut the TXD line towards the DR-135TP. If KISS stays up and keeps
receiving and doesn't give up then you most likely have the same problem;
the TNC doesn't handle simultaneous reception and transmission very well.
CURE
----
The cure for the problem it to be very carefull with sending data to the TNC.
1) Only throw one frame at the modem and wait 2 seconds before sending the
next
2) Interrupt transmission immediately when you get incomming data from the
TNC, resume if you have not received any data from the TNC in the last 500 ms.
So basically the communication to the TNC should be half-duplex. I can run
the TNC in the TH-D7 all day without locking up.
ADDING RECOVERY
---------------
With the above cure I could keep my TH-D7 running as digipeater for more
than 24 hours without a single lock-up. Without the precaution the TH-D7
would lock up in minutes if not seconds... The problem is however not 100%
contained so a lockup of the TNC is still possible. Ass added safty you can
add a watchdog if the DR-135TP switches on after a power-break. When the
KISS driver hasn't got any packets for 2 minutes then power-cycle the radio
and reinitialize KISS. With the TH-D7 I have the advantage to be able to
send Kenwood Control commands to accomplish this, but I do more or less the
same thing (only I wait only 30 seconds). Aditional advantage of this is
that the system will also recover from a power-failure.
VERIFICATION
------------
The solution above depends on the ability to produce a KISS connection that
has this added functionality to backoff transmission during reception. The
AX25_MAC driver on the DIGI_NED floppy can do this if you select the THD7
TNC from the list of TNC's. That gives you a way to at least test if such a
mechanism would work also for the DR-135TP.
SOLUTION
--------
If RX&TX collision is indeed the problem, I see two obvious solutions. The
first one is to modify the KISS driver, this is however only possible with
OpenSource solutions like Xastir and Linux. A second solution it to add a
small PIC processor that handles the flow-control towards the TNC or
listens to the data from the TNC and manages the CTS flow-control signal
towards the PC to hold the transmission until it is safe. This PIC could
also listen to the transmitted data and make sure 2 seconds spacing is used
between packets by watching for the FEND flags. I think the PIC solution
could be small enough to fit inside the TRX.
Kind regards,
Henk.
----------------------------------------------------------------------
Subject: Re: Traffic and Weather Together on the Eights
From: isobar@bcpl.net
Date: Sat, 12 Jun 2004 11:01:09 -0400
X-Message-Number: 8
At 05:58 AM 6/11/04 -0700, Spider wrote:
>[...]
>And why is that, Bob? FireNet has over 20,000 weather objects being sent out
>around the hour along with fire warnings/watches and weather
>warnings/watches, etc. I am curious why you think they should not be there
>on an amateur network????
>Jim, WA6OFT
Jim... Can't respond since I don't know what firenet is, so it may, indeed,
have value. I claim expertise in weather forecasting but nothing about fire
warning. Is it rebroadcasting a continuous stream of warnings or such onto
APRS? (20,000 obj per hour)? Can you point me to a paper or ref?
Bob Kirk
N3OZB
----------------------------------------------------------------------
Subject: Re: why kenwood d7
From: "sv1uy" <sv1uy@ham.depa.gr>
Date: Sat, 12 Jun 2004 18:02:21 +0300
X-Message-Number: 9
On Sun, 06 Jun 2004 00:54:22 -0700, Kevin Deckert wrote
>It struggled for a long time over the decision to purchase a kenwood
>handheld the D7 seemed like a lot o money. I have had the
>priveldge of using it under some demanding conditions. As well as
>many other forms of APRS equipment. I am senior Search manger as
>well as a "bonifide" Tracker Yes I track people by following their
>tracks and the operations team can follow mine by watching my D7
>broadcast my location back to base. It is great for me to be able in
>the field to see all the other "dumb" Electronic trackers as
>well...But the best feature for me is the ability of the D7 to log
>stations into the disply of my Garmin 12xl...is a simple, dependable
>set up....... Messaging back to operations from the D7 is great for
>getting urgent comms through without the inevitable "news" media
>knowing what is happening....... de ve7whk
Hi Kevin and group,
I use my D7 exactly the same way you do, although not for SAR but for joy
when I walk on the mountains, when I cycle on the mountains, when I go to
the beach, when I go on holiday, when I leave my car and of course I cannot
take my D700 with me, when I can have a break from work, when I visit
friends... and I find it extremely satisfactory. I think this feature of
the D7 (i.e. the built in TNC) overshadows any deficiencies it might have
compared with other radios and of course compared to what you expect from
the HOBBY. If professional SAR operators are happy with it, what can I say?
I only use it for the HOBBY, but on a daily basis so if I ever need to
offer my services to any SAR operation I am ready for it.
I don't think anything can beat a setup consisting of a small GPS with a
map and a D7 connected to it with a short homemade RS232 cable without any
special interface between not even D9 adaptors which are bulky if you care
to build your own RS232 cable.
This morning I went to the beach and after a swim in the nice and clean
eastern beaches of Athens I left the XYL and YL sunbathing and I sat at a
nearby cafe for a nice iced coffee and some shade.
I had my D7 and PALM V with me but no GPS since I knew were I was. I just
connected my PALM V to the D7 with only one homemade RS232 cable to the
serial port of the D7, without any D9 adaptors, and usign the "I am here"
function of PocketAPRS to st my position on the map I enjoyed operating
APRS from the cafe table. Minimal setup again and I could see everyone's
beacons plotted on the PALM V map.
Many times I use my D7 with my HP200LX also (a palmtop DOS5 computer) and
then again I only need one RS232 cable to connect the D7 with the HP200LX.
No other interface nor any D9 plug adaptors since I have made my own RS232
cable to go to the D7 directly. I use it with APRSdos for APRS and I can
also run JNOS (runs OK with a tcpwindow of one or two frames) or even a
plain DOS terminal program to connect to the local BBS or do some DIGI
DXing, hi hi hi!!!
Just 2 pieces of small hardware hooked together with a simple homemade
RS232 wire.
Both things (the D7 and GPS or the D7 and PDA/palmtop) fit in my pocket and
not many things to clutter all over the place. Very little to go wrong when
you are away from home and on the move. Operating times are at least 6
hours with the small battery.
Many times I use the D7, in a standalone setup, as a perfect APRS
monitoring device and APRS SMS exchanger, e-mail sender etc, when I don't
want to see anyone on the map but it can still show me on it's display how
far everyone is away from me etc. Plus that I can also monitor and have a
QSO using the local UHF voice repeater or Echolink repeater.
I can't expect more than one radio. I think I love this radio since it can
do so many things guys. It is the best portable ham radio device I have
ever used.
DISCLAIMER
No ties with Kenwood of course, just a happy D7 user who wants to share his
experiencies with you.
---
73 de Demetre SV1UY
e-mail sv1uy@ham.depa.gr
http://sv1uy.webhop.org
http://www.athnet.ampr.org/~sv1uy
http://www.qsl.net/sv1uy
----------------------------------------------------------------------
Subject: Re: question about possession of an object.
From: "KC2MMi" <kc2mmi@verizon.net>
Date: Sat, 12 Jun 2004 11:02:30 -0400
X-Message-Number: 10
<NWS folks is that they don't want people moving
"their" funnel clouds. How can we lock an object so that only one station
can own it?>
Wes-
Technically, probably extremely difficult unless you do an end run around
the issue of identifying the sender. Simply require all objects to be
accompanied by the call sign of their owner. Now, if someone else moves
it--without changing the ID, which would also change the object--they've
committed identity theft and impersonation. People might refrain from doing
that, since everyone knows hams would never be so discourteous.
Change the spec, encourage compliant behavior, and at least come of the
people will follow it.
But trying to authenticate owners? On a system that accepts input from all
comers? I don't think that could be done without major changes.
----------------------------------------------------------------------
Subject: Re: XASTIR - Mac OSX - Serial Ports ?????
From: Greg Noneman <greg@clubnet.net>
Date: Sat, 12 Jun 2004 08:38:12 -0700
X-Message-Number: 11
Brian,
I don't know about the USA19QW, but I have successfully used both the
original Keyspan dual adapter (USA-28) and the updated dual adapter
(USA-28X) with XASTIR.
Good Luck.
Greg
WB6ZSU
On Jun 11, 2004, at 6:22 AM, Brian Riley (maillist) wrote:
>That is what I did. I have the single adapter the USA19QW designation
>...
>But I will try it again ... I definitely want to get APRS of some kind
>running to a TNC on my 12" PB without going to VirtualPC!!!!!
>(aaarrrgghhh!!!!)
----------------------------------------------------------------------
Subject: Where can I get Midland & Big Spring Texas maps
From: APRS SIG <aprssig@w9if.net>
Date: Sat, 12 Jun 2004 09:08:12 -0700
X-Message-Number: 12
I am looking for a repository of maps around Midland and Big Spring Texas.
Anyone have suggestions where I can find any.
thanks,
Rich, W9IF
----------------------------------------------------------------------
Subject: RE: APRS IS stats and access
From: "Dave Anderson" <dandersn@citicom.com>
Date: Sat, 12 Jun 2004 12:33:42 -0400
X-Message-Number: 13
>http://www.findu.com/stream
Thanks, Steve. Glad to see it back online.
Seeya,
Dave
KG4YZY
www.aprsfl.net
----------------------------------------------------------------------
Subject: Re: question about possession of an object.
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Sat, 12 Jun 2004 18:44:03 +0200
X-Message-Number: 14
Hi Spider,
At 06:20 12-6-2004 -0700, Spider wrote:
>the rash decisions being made. This IS the concensus I've gathered. For
>some of them, this has motivated them more into supporting them.
Yes, I know... If a format is depricated, applications still need to decode
it but should not send it anymore in new appliction. At some later date
when nobody is sending the format anymore it can be deleted. This is
normally a process of years. Don't get me wrong, my vote is to keep it.
>On FireNet, we have 20,000+ objects an hour spewing out. We were just asked
>the question where we send our
>objects out compressed! I am waiting to hear the answers on that one...but
You know the Kenwood will only display those on screen but not enter them
in the station list, do you?
But... you can twist the APRS spec's arm to get it done anyway, let me show:
According to the APRS specification, this is the kind of objects you want:
;CompObj1 *010000z/4)TLP"!!x{.CCompressed object
But on reception the TH-D7 does show the object on screen but does not
store it in the station list. It is known however that the TH-D7 does
decode stations with compressed positions. A few weeks ago Bob told that
Object/Items and stations are more or less the same thing. The object van
however not be send as station packet since "CompObj1" is not a valid AX.25
call and you have to know who is responsible for the object. Well, here we
can twist the specification's arm by sending the object as third party
formatted station like this:
}CompObj1>AP:/010000z/4)TLP"!!x{.CCompressed object
This is at least Kenwood-APRS, it preserves the case and the AX.25 packet
still shows which station is responsible. In fact this could easily replace
the Object format in the spec. You can even define objects that can accept
APRS messages this way...
Likewise for Items. You want:
)CompItem1*/4)TLP"!!x{.CCompressed item
But you can send it as:
}CompItem1>AP:!/4TLP"!!x{.CCompressed item
This is also Kenwood-APRS complient.
I also checked Findu. The CompObj1 object shows up as COMPOBJ1 (looknet>
Date: Sat, 12 Jun 2004 18:15:37 +0100
X-Message-Number: 15
A new way of displaying live APRS positions with a variety of background
data -
see my Dublin APRS map
New Maps for UI-View
New FindU Maps and Access Forms
New APRS logos for your website - 5 sizes
Visit my APRS section....
(Refresh your browser if you don't see 'APRS Maps' in the menu)
73s Tim Makins EI8IC
www.mapability.com/ei8ic
www.qsl.net/ei8ic
----------------------------------------------------------------------
Subject: Re: question about possession of an object.
From: "AE5PL Lists" <HamLists@ametx.com>
Date: Sat, 12 Jun 2004 12:59:19 -0500
X-Message-Number: 16
>-----Original Message-----
>From: Henk de Groot
>
>For this to work we need the following changes to the APRS
>specification:
>-Allow non AX.25 calls in the third party format
Nothing in the spec precludes non-AX.25 calls in the 3rd-party format.
>-Reserve TO-call "AP" in a third party format for objects and items
I will address the hole in the 3rd-party packet idea below.
>-Depricate use of compressed Object positions
Why deprecate compressed Object positions? Again, you are recommending
doing something in the spec because one or more software authors (Kenwood
included) decided not to implement that thing. Decisions to deprecate
should be based on something being replaced because it provided inaccurate
or incomplete results. Compressed objects do neither of those.
>-Depricate the use of Items completely
Why? You don't think there is a need for the ability to show a static
object with no time stamp? Using current statistics doesn't take into
account that many software packages don't let you create items so people
use objects instead.
>By this we gained:
>-Higher precision objects
Not when compared with standard compressed objects and items.
>-These objects and items do not need to be padded up to 9
> characters, for small names the packet will be smaller
> than the original object format!
Items are not padded to 9 characters. And we are probably talking an
average of 2 bytes saved in objects at the cost of adding a complete
3rd-party header. Net loss, not gain, in efficiency.
>-Ability to use items and same advantage for small names
You said above to deprecate items. And there would only be an increase
in packet size for items, not a decrease.
>-Compatible with Kenwood and minor change to most software
> to get this working everywhere
The problem begins with how this really works. We start getting into
stacked 3rd-party headers, which is allowed by the spec but not necessarily
a good idea due to the size of the packet. Let's look at your
case-in-point:
}CompObj1>AP:/010000z/4)TLP"!!x{.CCompressed object
This would really be on APRS-IS (where the packet is being inserted by
automated servers):
SOMECALL>APXXX,TCPIP*:}CompObj1>AP:/010000z/4)TLP"!!x{.CCompressed object
and gated to RF as:
IGATE>APRS,PATH:}SOMECALL>APXXX,TCPIP,IGATE*:}CompObj1>AP:/010000z/4)TLP
"!!x{.CCompressed object
This is as opposed to:
IGATE>APRS,PATH:}SOMECALL>APXXX,TCPIP,IGATE*:;CompObj1
*010000z/4)TLP"!!x{.CCompressed object
An item would be even simpler:
IGATE>APRS,PATH:}SOMECALL>APXXX,TCPIP,IGATE*:)CompObj1!/4)TLP"!!x{.CComp
ressed item
Now, add to this that some IGates and servers, because of the significant
looping that has been occurring over the past years, completely exclude
passing third-party packets. So, you end up with a similar problem and you
have tried to use a construct for something that it was not intended while
deprecating a perfectly usable construct.
Your 3rd-party format also precludes killing an object or item. This is an
important feature of those constructs.
I would think APRS would be better served to put pressure on those software
authors to expand their software to include compressed objects and items.
For that matter, have them add item support which, it is my understanding,
the Kenwoods may not have.
73,
Pete Loveall AE5PL
mailto:pete@ae5pl.net
----------------------------------------------------------------------
Subject: Re: question about possession of an object.
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Sat, 12 Jun 2004 21:38:52 +0200
X-Message-Number: 17
Hello Pete,
At 12:59 12-6-2004 -0500, AE5PL Lists wrote:
>Nothing in the spec precludes non-AX.25 calls in the 3rd-party format.
No, but when taking it to the letter the header used to be an AX.25 header
before it was changed to a third-party header, which means that up to the
point were the I-Gate picked up the packet is must consist of AX.25 calls.
This knowledge can be used by a client to detect garbled packets.
>>-Depricate use of compressed Object positions
>
>Why deprecate compressed Object positions? Again, you are recommending
>doing something in the spec because one or more software authors
>(Kenwood included) decided not to implement that thing. Decisions to
Yes. If I understood the discussion of the last two weeks correctly, APRS
extenstions should be compatible with existing hardware in order not to
obsolete 38% of the APRS stations running today. Okay, when that is the
context in which enhancements shall take place then you get these kind of
proposals. Starting to use APRSSPEC complient compressed objects will not
be visible by 38% of the stations, so in the APRS philosply, as pictured
here the last few weeks, this should be discouraged.
It makes no sense to change APRS practice in such way that people still
have to upgrade their software since that was just the thing the APRS
community complained about regarding OpenTrack.
So my proposal just had 2 key elements:
1) Be able to run on existing systems, including Kenwoods
2) The ability to use some form of compressed objects and items to enable
the higher accuracy and smaller packets compared to the ASCII position objects.
>deprecate should be based on something being replaced because it
>provided inaccurate or incomplete results. Compressed objects do
>neither of those.
Compressed objects do no work on 1/3 of the users equipment, this is better
because this works.
>>-Depricate the use of Items completely
>
>Why? You don't think there is a need for the ability to show a static
>object with no time stamp? Using current statistics doesn't take into
Items do no work on 1/3 of the users equipment, this is better because this
works.
I'm open for other suggestions, provided that they also work.
>>By this we gained:
>>-Higher precision objects
>
>Not when compared with standard compressed objects and items.
They do, it has a higher precision than the ASCII version that works for
Objects and fake Objects acting as Items today. Standard compressed objects
and items do not show up on at least 1/3 of todays enduser equipment. So it
is a big improvement from no position at all to an high precision object
and item.
>>-These objects and items do not need to be padded up to 9
>> characters, for small names the packet will be smaller
>> than the original object format!
>
>Items are not padded to 9 characters. And we are probably talking an
Oops, you're right. But anyway, the items today do not work on Kenwoods so
its pointless to compare the propsal to the original - non working - format.
>You said above to deprecate items. And there would only be an increase
>in packet size for items, not a decrease.
It will convert a slightly smaller unusable item packet into a little
bigger one that works.
>>-Compatible with Kenwood and minor change to most software
>> to get this working everywhere
>
>The problem begins with how this really works. We start getting into
>stacked 3rd-party headers, which is allowed by the spec but not
>necessarily a good idea due to the size of the packet. Let's look at
>your case-in-point:
It is at most 4 bytes bigger in all cases, stacked or not and it is smaller
than the Object with a dummy date which is currently the common way to
transmit items.
>and gated to RF as:
>
>IGATE>rds,
Henk.
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
