| |
ZL3AI > APRDIG 11.06.04 10:11l 774 Lines 29572 Bytes #999 (0) @ WW
BID : 3426-ZL3AI
Read: GUEST
Subj: TAPR Digest, Jun 05, 2/8
Path: DB0FHN<DB0THA<DB0ERF<DB0FBB<DB0GOS<ON0AR<ON0AR<ZL3VML
Sent: 040611/0700Z @:ZL3VML.#80.NZL.OC #:25627 [Chch-NZ] FBB7.00i $:3426-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: RE: OPENtrack verus APRS format example
From: Bill Herrmann <bherrman@spro.net>
Date: Sat, 05 Jun 2004 00:21:23 -0600
X-Message-Number: 21
Note: If you don't want to read the technical stuff skip to the next to the
last paragraph.
At 06:13 PM 6/4/2004 -0700, Scott Miller wrote:
>In hex:
>
>0C 10 18 DC 17 7B AA 5D 7A D6 0F 89 BC 05 11 3E 38 3E 6E 05
>34 D8 19 0D 15 07 16 E6 96 87 E5 AD 97 04 13 9C 04 57 83 05
>00 0C 84 05 03 00 F0 04 12 41 42 43 03 14 00 0D
Ok, so why not tunnel that through APRS by adding the "user-defined data
format" header from page 87 of the APRS Specification? (page 97 of 128 in
the PDF)
Basically you would prefix it with three characters and make it a valid
APRS packet. Pure OpenTrac networks would not need to tunnel it and mixed
networks could happily coexist.
The identifier character is a "{" followed by a user id character and a 1
character user defined type character. "{" is an experimental user id
character. The spec. says that the APRS working group will issue user
characters - Can we get that done or does Scott need to specifically
request it
The specification says "Although there is no restriction on the nature of
user-defined data, it is highly recommended that it is represented in
printable 7-bit ASCII character form." so OpenTrac binary formats are
allowable as long as they are encapsulated in the APRS user-defined format.
The specification goes on to say:
This is envisioned as a way for authors to experiment and build in features
specific to their programs, without the danger of a non-standard packet
crashing other authors' programs.
....and...
Generally, all formats using this method will be considered optional. No
program is required to decode any of these packets, and must ignore any it
does not decode.
Which, in a nutshell means: If your client program crashes because of data
included in an APRS user-defined data format packet your client is broken
not the sender.
The APRS specification never says anything about the PID except what it is
set to. However, there is a statement on page 89 (99 of the PDF) that says:
Packets that do not meet any of the formats described in this document are
assumed to be non-APRS beacons. Programs can decide to handle these, or
ignore them, but they must be able to process them without ill effects.
APRS programs may treat such packets as APRS Status Reports.
(there's more, but that's the important part)
So, if OpenTrac never sends a packet that begins with the same characters
as a valid APRS packet the client programs must be able to process them
without ill effects. Of course, that also implies that OpenTrac cannot send
a packet (on an APRS network) that begins like a valid APRS packet.
Bottom line - FindU was operating according to the specification by
attempting to put that data in the status field. HamHUD's appear to have
been failing to ignore invalid packets. OpenTrac needs to insure that it
doesn't send things that look like valid APRS packets or use the
user-defined format. Anybody know what the Kenwoods did? (If they ignored
the packets and kept functioning they were working according to the
specification.) PID is not currently working as a way to differentiate and
the APRS specification doesn't say it's a supported way. (and if I recall
properly the OpenTrac one isn't actually part of the AX.25 spec. because
there doesn't seem to be anybody maintaining that spec.)
Now, can we remove some of the emotion from this and start acting like
we're on the same team? There is a pretty small list of valid identifiers
in APRS. It shouldn't be that hard for OpenTrac to avoid them.
Bill
----------------------------------------------------------------------
Subject: Wanted: PIC code to gen tones
From: "Andrew Rich" <vk4tec@hotmail.com>
Date: Sat, 5 Jun 2004 16:59:06 +1000
X-Message-Number: 22
Hi,
I am experimenting and wonder if someone is willing to give up the code to
gen sine waves in PIC's
I understand there is a lookup table to shape the wave involved.
Andrew Rich (VK4TEC)
----------------------------------------------------------------------
Subject: Empirical data on the Kenwood/APRS <> OpenTrak non-issue
From: Jeff King <jeff@aerodata.net>
Date: Sat, 5 Jun 2004 03:20:56 -0400
X-Message-Number: 23
Sean:
See below.
>>>Or scan for all kenwoods, That should give you about 3 thousand
>>>on any given day... is that enough?
>>Funny that none of those 3,000 that 'had a problem' didn't mention
>>it on the SIG.
>Could it be that most of the 3,000 are not on this list because of
>threads like these? This email list is far from representative of
>the the APRS userbase.
Good point. I went and looked for some "uncontaminated" empirical data on
other mailing list (sources at end).
Found 1500+ members subscribed to Kenwood D700 lists. Not a single reported
problem with OpenTrak.
Found 499+ hams subscribed to Kenwood TH-D7 lists. Not a single reported
problem with OpenTrak.
Kenwood total: 2000+ with no reported problems.
Found another 2000+ hams subscribed to general purpose/tracker APRS lists.
Not a single reported problem with OpenTrak.
CONCLUSION:
If Scott/Robert had kept a lower profile (not announce balloon test for
example and/or not use long path), no-one would have noticed.
A BIG NON-ISSUE.
73
Jeff
Data Sources below
-----------------------------------
TAPR APRS "Hot Technology" SIG, seems to cater to Kenwood HT's
no idea of membership number, not a single mention of a OpenTrak problem
>From Yahoo groups:
D700 lists
http://groups.yahoo.com/group/TMD700A/
954 members, very active, not a single mention of a OpenTrak problem
http://groups.yahoo.com/group/TM-D700/
483 members, very active, not a single mention of a OpenTrak problem
http://groups.yahoo.com/group/APRS_Radio_Built-in_TNC/
49 members, not very active, not a single mention of a OpenTrak problem
http://groups.yahoo.com/group/FL-D700/
19 members, not active, not a single mention of a OpenTrak problem
----
TH-D7 lists
http://groups.yahoo.com/group/TH-D7/
499 members, very active, not a single mention of a OpenTrak problem
http://groups.yahoo.com/group/Kenwood_TH-D7/
332 members, very active, must be approved to read posts (no data)
-----
A few of the larger APRS lists on Yahoo:
http://groups.yahoo.com/group/APRS/
766 members, very active, not a single mention of a OpenTrak problem
http://groups.yahoo.com/group/TinyTrak/
1866 members, very active, not a single mention of a OpenTrak problem
----------------------------------------------------------------------
Subject: Re: Empirical data on the Kenwood/APRS <> OpenTrak non-issue
From: Jeff King <jeff@aerodata.net>
Date: Sat, 5 Jun 2004 03:54:21 -0400
X-Message-Number: 24
Oh, I forgot to add there where no "ragging debates" in progress about
balloons, kenwoods or OpenTrak oon any of the lists I cited. That is what I
meant by "uncontaminated". Also, I was not a member of any of the Kenwood
lists. Not a scientific test by any means, but the best empirical data you
are likely to see in this matter.
On Sat, 5 Jun 2004 03:20:56 -0400, Jeff King wrote:
>Good point. I went and looked for some "uncontaminated" empirical
>data on other mailing list (sources at end).
----------------------------------------------------------------------
Subject: Proposed NWS policy change
From: n2iph@comcast.net
Date: Sat, 05 Jun 2004 09:59:02 +0000
X-Message-Number: 25
I was on the NWS site this AM and found this, thought others may be
interested as it relates to access and dissemination of information by
NOAA/NWS which could affect (good or bad is yet to be seen) Skywarn and
APRS WX.
http://weather.gov/fairweather/policy.php
----------------------------------------------------------------------
Subject: Re: OPENtrack incompatibilities
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Sat, 05 Jun 2004 06:25:46 -0400
X-Message-Number: 26
>>>Jeff King <jeff@aerodata.net> 06/05/04 12:41 AM >>>
>>>OpenTrak still uses CSMA. Basic layer one stuff Bob, just like>
>>APRS. TAB put out a really good book on packet radio...
>>
>>Ah, so just like on a voice net that is set up for passing NTS
>>traffic for example, as soon as you hear the channel go silent for a
>>second, you think it is your RIGHT to just bust in and send your DX
>>spots [on their designated NTS channel]?
>OpenTrak sends positional reports Bob, in a manner very
>similar to APRS. Smells like a duck to me.
But APRS is a distributed NETwork designed for everyone to share the data
for the mutual benefit of all. APRS is a one-to-all NET. Everyone
participates, everyone expects to see the data.
Adding incompatible OPENtrack packets to that network at the expense of
collisions designed so that no one else can see them seems to me to be
taking unfair advantage of the resources of others and at their expense.
----------------------------------------------------------------------
Subject: RE: OPENtrack verus APRS format example
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Sat, 05 Jun 2004 06:42:13 -0400
X-Message-Number: 27
Also, I notice that the OPENtrack 56 character version left out the word
"comment" which you clearly stated was one of the things you wanted to see
in the APRS example. That makes yours 66 bytes compared to the APRS
version.
From: "Scott Miller" <scott@3xf.com>
>APRS version:
> 'h9"l!8v/]"4%}comment/12v 75F/DOP5/6 sats
>
>OPENtrack version.
>0C 10 18 DC 17 7B AA 5D 7A D6 0F 89 BC 05 11 3E 38 3E 6E 05
>34 D8 19 0D 15 07 16 E6 96 87 E5 AD 97 04 13 9C 04 57 83 05
>00 0C 84 05 03 00 F0 04 12 41 42 43 03 14 00 0D
>
>As decoded by listen:
>
>fm N1VG to OPNTRK via WIDE ctl UI^ pid=77(OPENTRAC) len 56
>OpenTRAC decode (56 bytes):.
>EID 0x10 len 11: Position: Lat 34.959000 Lon -120.424000 Alt 183.000000
>EID 0x11 len 4: Time: Wed Jan 29 12:49:50 2003
>EID 0x34 len 4: GPS: 3D Fix Valid SPS, 8 sats HDOP=2.5 PDOP=1.3
VDOP=2.1.
>EID 0x16 len 6: Display Name: ??
>EID 0x13 len 3: Course: 312 Speed: 79.991997 kph.
>EID 0x500 len 1: 12 Volts.
>EID 0x503 len 2: 240 Kelvins.
>EID 0x12 len 3: Text: ABC.
>EID 0x14 len 2: Position +/- 13 meters.
>
>It's entirely machine-readable, and the client is free to display the
>information in whatever way it wants to.... that's 56 characters...
>Yeah, it sacrifices some bandwidth for element tagging, but you've got
>position to the centimeter and time to the second, including year, plus
all
>the extra GPS data. And a Kanji display name.
>
>Scott
>N1VG
----------------------------------------------------------------------
Subject: Re: OPENtrack incompatibilities
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Sat, 05 Jun 2004 07:00:25 -0400
X-Message-Number: 28
>>>"Scott Miller" <scott@3xf.com> 06/04/04 11:29 PM >>>
>>You claim that OpenTrac can do store and forward, backbone
>>routing, and digipeater maintained objects yet I can find no
>>documentation for these features on your site. Do they actually
>>exist? l
>
>I did not claim that OpenTRAC does that yet. Those are all stated
>design goals of the project, relevant to this discussion because
>they're goals that Bob doesn't share and opposes in APRS.
Lets tell the truth, not just continuing OPENtrack propaganda:
1) I oppose store-and-forward because APRS is a real-time system.
2) I never opposed backbone routing, in fact I INVITE IT!
3) I pointed out all the disadvantages of digipeater objects and
also pointed out how APRS fully supports them already.
MORE DETAILS:
The 1200 baud channel is quite busy as it is with REAL-TIME data
of immediate value to ALL on the net. It makes no sense to add
to that your propsed store-and-forward data that:
1) Is not of immediate interest
2) Can easily go via alternate means, or another channel
3) Should go point-to-point and not be distributed to EVERYONE
4) Should go via backbones, not the real-time user input channel
Gosh BACKBONE routing is a stated goal of APRS too! In fact, I have been
begging for people to do it for years. In fact, the request for level 4
network backbone routing for APRS has been in the APRS docs since 1994. I
would WELCOME same. But everyone knows that you CANNOT DO BACKBONE routing
on the existing 1200 baud APRS NATIONAL CHANNEL!
DIGIPEATER OBJECTS:
I fully addressed this in a prior email and showed how it is fully
supported already in APRS protocols. But that having DIGIS repeat all
OBJECTS heard has all kinds of negative impacts on the net and is not a
wise idea.
Bob
----------------------------------------------------------------------
Subject: OPENtrack DIGIpeater Objects
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Sat, 05 Jun 2004 07:12:05 -0400
X-Message-Number: 29
>>>"Scott Miller" <scott@3xf.com> 06/04/04 11:09 PM >>>
>>And there is nothing in the existing protocol that prohibits
>>this. In fact, it is fundamental to the protocl that anyone
>>or thing can take over reporting of an object.
>
>See the proposal I sent a minute ago. There's no added traffic,
>not even to kill the object. <snip>
Scott, you aren't getting my point.
My point was that APRS protocols fully support your idea already. There is
nothing whatsoever preventing you or anyone else from writing digi code to
doexactly what you want. If you think it is a good idea, just DO it, but
dont then wreck the system by doing it with new protocols that are not
compatible with everyone already.
>in APRS, so getting
rid of them is not a realistic option. As for the decaying rate, why would
the position of a hospital or EOC be any less important or relevant
tomorrow than today? Static objects should have static rates. And the
digi's not fighting so hard to make its traffic heard. Assuming you don't
increase the rate, you're cutting channel load for static objects in half.
>Why? Because you havent taken the time to see how
>to do these simple things in APRS?
Getting something by you that you don't approve is far from simple, Bob.
Someone counted about 50 messages from me in the past day and a half, and
probably at least as many from you, and we aren't any closer to agreement
on anything.
> you can do it anway. The existing APRS object format
> already INCLUDES these capabilities...
It's not just a format change, it's a digipeater behavior change. If it
was solely a matter of formatting at issue, I never would have started the
OpenTRAC project.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: OPENtrack incompatibilities
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Sat, 05 Jun 2004 07:39:42 -0400
X-Message-Number: 30
>>>"Scott Miller" <scott@3xf.com> 06/04/04 10:58 PM >>>
>But only those things that YOU approve of. I stand by my
>statement that digipeater-cached objects would be beneficial
>to the network. You have absolutely refused to allow work
>on this, even within the established APRS specification.
Outright untruths:
1) Anyone can do it now within the existing APRS protocol
2) In fact it is FUNDAMENTAL to APRS to allow that
3) I dont have to "approve" you to work on anything you want
4) I dont have to "allow" anyone to do it. Its easy and anyone can
5) These are the kinds of ideas that are excellent for experimentation
It is so trivial, and so fully supported in APRS, I dont see why you just
dont do it instead of just talking about it! If it is good for the
network, then people will use it. If it is not good for the network, they
wont. That is how APRS works. The protocols can support all kinds of
experimentation and none of it involves me.
In fact, APRSdos does EXACTLY what you propose and always has. That is, it
can take over all objects at an event by one master station for channel
efficiency. The command is NET-CON-ON. It is very usefful for special
events where good planning is involved. Nothing wrong with putting it at
the digi under the right controls either...
Any objections that you may have detected on my part is that of your plans
to make it apply to ALL stations! Stationa transmit their APRS postions to
indicate they are on the air and a LIVE participant of the net. If you
have digipeaters putting everyone on the map based on data from yesterday,
then the network as a real-time network becomes a sham... inconsistent, and
loses all integrity for a real time system.
>If that's not the case, prove me wrong. Let's start work
>on the concept now.
Like I said above. The concept has been in APRS since about 1994. Every
APRSdos station can already do it. The protocol fully supports it. If you
want to put it in the digipeaters for OBJECTS, then go right ahead. There
is absolutely nothing preventing it.
Write your digipeater code, make it available to others, and if they want
to use it, then they will. That is exactly the kind of experimentation
that APRS supports...
>We need:
>
>- A way for the originating station to indicate a cache request, with
> expiration and interval
>- An acknowledgement indication from the digi, also showing the time till
> expiration
>- A 'cancel' mechanism to purge the object from the cache
All of those exist in the present protocol:
1) EXP=HHMM in the comment field indicates an exiparation time
2) Any station that takes over an object AUTOMATICALLY
acknowledges it by simply transmitting it. That is the confirmation
3) The OBJECT CANCEL format is allready in APRS. Simply replace
the ";" as the TYPE character with a "-" and that is the CANCEL
format.
So there is nothing to do other than simply write the digi code. There are
no changes to the protocol required, absolutely nothing preventing you from
doing this... and within the existing protocol!
de Wb4APR, Bob
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond - signal loss????
From: Ernie Howard <w8eh-Ernie@cinci.rr.com>
Date: Sat, 05 Jun 2004 07:38:15 -0400
X-Message-Number: 31
2,999 of them signed off the sig a while back because of the BS. Which is
what I am going to do. 73.
Scott Miller wrote:
>>>Can you name 3 people that had a problem?
>
>>Or scan for all kenwoods, That should give you
>>about 3 thousand on any given day... is that enough?
>
>Funny that none of those 3,000 that 'had a problem' didn't mention it on the
>SIG.
>
>Scott
>N1VG
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond - signal loss????
From: "hasan schiers" <schiers@netins.net>
Date: Sat, 5 Jun 2004 06:42:31 -0500
X-Message-Number: 32
Not the point Jeff. It isn't aprs, it doesn't belong on 144.39. It is, from
an aprs point of view, a minor parasitic infection (at this point). Go
somewhere else.
w/r to voice alert, I won't debate its merits, I don't use it, but two
wrongs don't make a right.
What is without doubt is that OT is NOT aprs. Keep it off the national
network freq.
I don't care whether OT causes any problems or not. It could be perfectly
benign and it would not matter. If it isn't aprs, it doesn't belong on
144.390. Scott has admitted, and you have asserted that OT is NOT aprs. I
take you at your word. Go somewhere else.
I'm not interested in further debate. The authors and their minions can keep
it off, or we will do it for them. (or they can become
compliant/interoperable, and they will be welcomed with enthusiasm)
....hasan, N0AN
----- Original Message -----
From: "Jeff King" <jeff@aerodata.net>
>On Fri, 4 Jun 2004 18:36:31 -0500, hasan schiers wrote:
>
>>At worst this is an attempted hijacking, at best it is a parasitic
>>infection. It contributes nothing to the aprs network, it merely
>>steals the resources of the infrastructure, for its own self-serving
>>ends.
>
>You mean like position location? If it quacks like a duck, looks like a
duck,
>it might even taste like a duck.
>
>Hasan, clearly and specifically, tell us what problems OpenTrak caused you?
----------------------------------------------------------------------
Subject: DIGIpeater OBJECTS
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Sat, 05 Jun 2004 08:22:25 -0400
X-Message-Number: 33
>>>"Scott Miller" <scott@3xf.com> 06/04/04 11:09 PM >>>
>>And there is nothing in the existing APRS protocol that
>>prohibits this. In fact, it is fundamental to the protocl that
>>anyone or thing can take over reporting of an object.
>
>It's not just a format change, it's a digipeater behavior change.
>If it was solely a matter of formatting at issue, I never would
>have started the OpenTRAC project.
Let me summarize the idea of having DIGI's take over objects:
1) we both now agree is "not an APRS protocol change".
2) is noted that it has been built into all copies of APRSdos since 94
3) And it does not need OPENtrack to do it.
4) it's something to be implemented at the digis
5) It can be done at any time by anyone by a simple additon to
digipeater code without any impact on APRS, the APRS
protocol, or me.
So, please just go do it.
But I do strongly object to your original stated purpose of letting the
digis take over reporting responsibilties for all home stations for the
same original reasons I said before:
1) APRS is real time. When I get a packet from a home station, it tells me
his is LIVE and avaialble now, and an active participant of the real-time
net.
2) Having DIGIS' report ad nausium for home stations that may have QSY'ed,
are not on the air, have lost power, or who are no longer an active
ON-THE-AIR live station and can no longer receive messages is BAD.
3) In order for it to work would require a modification to EVERY ONE's home
station code, so it probably wont happen.
Now, can we move on...
thanks
Bob, Wb4APR
----------------------------------------------------------------------
Subject: Re: Solar tetroon Sky Diamond - signal loss????
From: blairhogg@comcast.net
Date: Sat, 05 Jun 2004 12:23:26 +0000
X-Message-Number: 34
I second that. That will make 3,001.
Here's my take on this situation:
Bob and his buddies have put up a 2m repeater system.
Scott and his buddies hacked the CTCSS codes and have started using it for
their own purposes, against Bob's wishes and refusing to change their
operating practices to comply with the repeater system guidelines.
Now we have a miniature war brewing, making everyone unpleasant.
OK, so this is not exactly the situation, but it is a good analogy.
I joined this sig about a month ago hoping to find some information and
advice on APRS. I didn't expect to find two groups of people behaving no
better than 6 year olds on the playground.
See y'all later... I'm outta here....
Blair WB3AWI
----------------------------------------------------------------------
Subject: Re: 30 Meter Policing needed.
From: WB4GQK@aol.com
Date: Sat, 5 Jun 2004 08:50:13 EDT
X-Message-Number: 35
Scott and James have some very good points regards getting everyone on the
30M frequency. On the other hand there may be others besides myself that
cannot set precisely on 10.151.51 LSB. I have been using a SGC 2000 marine
version for the last 6 years here in the shack. Unfortunately it tunes in
100Hz steps so I have to set my station dial on 10.1510 LSB. It doesn't
seem to affect the quantity of stations I receive. Generally I will record
90 to 100 stations every week. Now whether or not they hear me is another
story.
But to add more fuel to this line I also have a ICOM M800 marine SSB on my
boat, and yes it also tunes in 100Hz steps. On the other hand when I raced
my boat to Isla Mujeres (near Cancun) last year I transmitted position
reports every hour. A distance of 519 miles with 134 reports being sent and
received. Obviously they talk to each other very well. But this is actually
a side issue, the main point is to get more stations on the exact
frequency. Of course it is possible that maybe some dial frequencies don't
precisely indicate the center of their transmissions.
>From what I can see on the LEDs of my Kam98, there are several strong
stations that illuminate only the right or left LED and obviously I don't
record their transmission.
But over and above setting the frequency dead nuts is the problem of
collisions. I copy 3 WX stations in the Caribbean plus one in the Bahamas.
I strongly suspect some stations in the USA, specially mobiles, don't hear
them and transmit right on top of the ongoing packet.
I certainly agree with Scott and James. It would be nice to get every one
on the same frequency. I hope that my 10 Hz offset doesn't bother anyone.
73 Jim
----------------------------------------------------------------------
Subject: WinAPRS/TNC-X Questions
From: "Rick Stoneking" <w2rds@arrl.net>
Date: Sat, 5 Jun 2004 08:56:46 -0400
X-Message-Number: 36
All,
I am trying to get a portable APRS station running using a Libretto 30 PC
(Win95), TNC-X, and an HT. I am trying to use WinAPRS 2.7.5. On the
receive side all is well - stations are showing up on the map just fine. On
the transmit side the packets are not being 'received' by my home station
TNC. I am using Hyperterm to simply monitor the output from my MFJ-1270C
TNC and I see all of the other APRS traffic. I downloaded the TNC-X TX Test
program and it works fine. The test packets show up on my Hyperterm screen
no problem. So I must have something messed up in my WinAPRS setup but I
can not figure out what. Does anyone who has used WinAPRS in KISS mode have
any suggestions?
Thanks,
Rick
W2RDS
----------------------------------------------------------------------
Subject: Re: OPENtrack incompatibilities
From: Wes Johnston <wes@johnston.net>
Date: Sat, 05 Jun 2004 08:59:03 -0400
X-Message-Number: 37
Here's answer I got...
Wes
From: FCCInfo <FCCInfo@fcc.gov>
Reply-To: FCCInfo <FCCInfo@fcc.gov>
To: wes@johnston.net
Subject: FCC Consumer Center response from representative TLEAD3
Organization: FCC
You are receiving this email in response to your inquiry to the FCC on
4/7/2004 8:29:39 AM.
Thanks for contacting the FCC Consumer Center in Gettysburg PA.
store-and-forward (S-F): Pertaining to communications systems in which
messages are received at intermediate routing points and recorded i.e.,
stored, and then transmitted, i.e., forwarded, to the next routing point or
to the ultimate recipient.
From the Federal Standard Glossary at:
http://ntia.its.bldrdoc.gov/fs-1037/
----------------------------------------------------------------------
Subject: Re: OPENtrack incompatibilities
From: "Bill Diaz" <william.diaz@comcast.net>
Date: Sat, 5 Jun 2004 07:59:51 -0500
X-Message-Number: 38
Scott,
Please indicate in your OpenTrac posts what is a design goal and what
actually exists and works. Anything less is misleading and detracts from
what you have accomplished.
Bill
----------------------------------------------------------------------
Subject: The OpenTrac Debate and BS!
From: Greg Higgins <greghiggins@earthlink.net>
Date: Sat, 05 Jun 2004 08:07:15 -0500
X-Message-Number: 39
The count is now 3002 and climbing rapidly. It is disgusting the way that
this sig has degenerated to an open war by supposedly adults unwilling to
play in the sandbox together! Ya'll are NOT the only one's.
It has always amazed me that the rest of us "little guys" are always
ignored when we either ask a question (which usually results in a: no
comments or constructive answers; or b: being ridiculed for daring to even
asking the question in the first place!) or put in our two cents on a topic.
Despite the advances and contributions made by ALL of the APRS authors, all
I (and numerous others) see is: Scott - grow up, learn to open your mind
and contribute as an adult! Jeff - quit stirring the pot! Robert - this
isn't the military! Learn to work with the rest by learning people skills
and using them!
Amazing that the majority of the posts over the last several days has come
from these 3 people! Grow up and listen to those left on the sig. Remember
that of all of the minions in the APRS world, only a small fraction
subscribe to this sig, so don't even think about talking about MINE and
OTHER's opinion with out our explicit input.
Grow up, get a life. I, like many others are, am out of here! D700 and D7
being switched back to dual banders again.
Greg Higgins KB5GLV
----------------------------------------------------------------------
Subject: RE: commercial
From: "Bill Diaz" <william.diaz@comcast.net>
Date: Sat, 5 Jun 2004 08:16:48 -0500
X-Message-Number: 40
Kevin,
The vast majority of commercial AVL (Automatic Vehicle Location) systems
use proprietary protocols rather than an open protocol such as APRS. The
commercial users do not want to share the location of their assets with
other users or competitors.
APRS includes a bewildering variety of packet types and capabilities. The
commerical market has little need for many of them.
It is very important that location information be reliably transferred from
the mobile asset to the dispatch center or server. APRS does not provide
the means to acknowledge receipt of location messages or for mobiles to
retry when the location packet has not reached its intended destination.
AVL systems use a wide variety of RF networks, including cellular and
satellite. TNC's are slow and inefficient compared to some of the transfer
methods available on some of these systems. No need for AX25's vias etc.
HTH,
Bill KC9XG
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
