| |
ZL3AI > APRDIG 15.06.04 10:13l 537 Lines 22994 Bytes #999 (0) @ WW
BID : 3458-ZL3AI
Read: GUEST
Subj: TAPR Digest, Jun 08, 4/5
Path: DB0FHN<DB0RGB<OE5XBL<OE3XSR<OK0PBX<OK0PHK<OK0NAG<OK0PPL<DB0RES<ON0AR<
VE3FJB<ZL2TZE<ZL3VML
Sent: 040615/0712Z @:ZL3VML.#80.NZL.OC #:25878 [Chch-NZ] FBB7.00i $:3458-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: D700 - Yes mine has FLASH and In-Circuit Programming.
From: "Scott Miller" <scott@opentrac.org>
Date: Tue, 8 Jun 2004 13:32:11 -0700
X-Message-Number: 62
>Perhaps you erroneously infered that meant something more than the wires from
>the programmer. The wires from the programmer must indeed be soldered to the
>board. The pads are VERY small, this is not a minor task. I watched them doing
I'm looking at a picture Drew sent me of the board this morning, and I see
what appears to be a small 10-pin flex cable connector on the board, located
by the lower left corner of a crystal labelled '11.059'. Looks like a good
candidate for a programming connector to me. Perhaps Kenwood started
shipping the radios with the connector installed at some point? It'd
certainly be cheaper to have it done during assembly than to do it by hand
later.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: D700 - Yes mine has FLASH and In-Circuit Programming.
From: Jon Anhold <jon@snoopy.net>
Date: Tue, 08 Jun 2004 16:35:42 -0400
X-Message-Number: 63
Steve Dimse wrote:
>I clearly indicated I was talking abou the D7, that most definitely required
>soldering the three wires to the board. I've seen it done. REALLY!
And Drew clearly indicated he was talking about the D700.
Jon N8USK
----------------------------------------------------------------------
Subject: Re: D700 - Yes mine has FLASH and In-Circuit Programming.
From: Drew Baxter <droobie@maine.rr.com>
Date: Tue, 08 Jun 2004 16:48:50 -0400
X-Message-Number: 64
Just in case this didn't get posted to the SIG, check out the link.
Thanks Jon
--Droo, K1XVM
At 04:45 PM 6/8/2004, jon@snoopy.net wrote:
>http://n8usk.com/k1xvm/
>
>73
>
>-j
----------------------------------------------------------------------
Subject: Re: D700 - Yes mine has FLASH and In-Circuit Programming.
From: Steve Dimse <k4hg@tapr.org>
Date: Tue, 8 Jun 2004 16:51:17 -0400
X-Message-Number: 65
On 6/8/04 at 4:35 PM Jon Anhold <jon@snoopy.net> sent:
>>I clearly indicated I was talking abou the D7, that most definitely required
>>soldering the three wires to the board. I've seen it done. REALLY!
>
>And Drew clearly indicated he was talking about the
>D700.
Which was why in my response I was careful to mention the D7. I never said
he was wrong about the D700, I have not looked inside. He, however, did
flat out say I was wrong, and I was not wrong, I clearly stated I was
talking about the D7.
Can we just have one discussion that doesn't degenerate into accusations?
Steve
----------------------------------------------------------------------
Subject: Re: Tetroon collateral damage report, revision1
From: Doug Bade <dbade@clecom.com>
Date: Tue, 08 Jun 2004 17:02:55 -0400
X-Message-Number: 66
Hey Jeff;
I think you missed the entire point as you commented on everything
except what the post was really about. Just because no one got hit by the
tree falling in the woods does not mean it did not fall.. Damage was done.
Others who were entitled rightfully to transmit, unmolested, in the local
terrestrial networks were "harmed", however somehow the damage done to them
is ignored in the promotion and defense of a protocol for the sake of
inovvation. It appears that NOT ONE of the offending packets was received
by anyone capable of using it, so the fact that they were sent at all, by
itself is in fact evidence of collateral damage, which we are so quick to
sweep under the rug.. Collateral damage includes ALL parties , not just
those who can PROVE specific damage. I am sorry my satirical references, to
a shotgun trial, do not meet your approval, but I think there are likely
others who agree that it was just that...
I am done on the subject. It is clear that perspectives of what
constitutes collateral damage differ.. I felt it had to be said...
regardless of whether you agree with it.
Done...
End.
Doug KB8GVQ
At 01:56 PM 6/8/2004, Jeff King wrote:
>Hey Doug:
>
>On Tue, 08 Jun 2004 02:51:01 -0400, Doug Bade wrote:
>
>
>> I would like to forward a thought... which seems to have been
>>overlooked by the prosecutors involved.
>
>You see, this is the problem. "prosecutors". What a way to start a technical
>presentation Doug! In my Kenwood emphircal data thread, I didn't try to make
----------------------------------------------------------------------
Subject: Re: APRS Protocol - A Modest Proposal
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Tue, 08 Jun 2004 21:39:03 +0200
X-Message-Number: 67
At 14:47 7-6-2004 -0700, Scott Miller wrote:
>>The problem is that there is no way to tell what the PID is if the program
>uses
>>converse mode. AFAIK, all APRS programs support converse, not all support
>KISS
>
>In that case, it's just a matter of setting the PID filter option on the
>TNC. I don't think we've identified any TNCs in use that don't have that
>feature.
The Kenwood TNC to not seem to have no option to set the filter, at least
nothing the DISP command showed looked like it. The good news is that it
seems to be hard-coded to ALWAYS FILTER.. Anyway, if you do nothing special
the Kenwood TNC only displays the packets with PID F0 in converse mode.
Kind regards,
Henk.
----------------------------------------------------------------------
Subject: Re: PID 77 in AX.25 spec?
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Tue, 08 Jun 2004 22:27:32 +0200
X-Message-Number: 68
Hello Wes,
At 22:04 7-6-2004 -0400, Wes Johnston wrote:
>Scott asked this a long time ago, but how do we get 0x77 registered as
>Opentrac under ax.25? Some group got eax.25 added a number of years
>ago... how was that change made?
Which EAX.25 do you mean? PE1CHL designed an extended AX.25 protocol 10
years or so ago using modulo 128 numbering. This was used for fast links
where the modulo 8 numbering of AX.25 V2.0 would not be sufficient. This
EAX.25 is used all over the world (and is also implemented in Linux) but as
far as I know it uses the same PID as AX.25 V2.0. EAX.25 used by PE1CHL
took advantage of some reserved bits in the source and/or destination SSID
to indicate the extended protocol (mainly because the RR and RNR primitives
do not have a PID but you still want to be able to monitor the dataflow).
Note that the reseverd bits are also used by DAMA. None of this you will
find in the official TAPR specs.
When TAPR released AX.25 V2.2 they also included EAX.25. This is a
different one is in line with the widely used protocol on the signalling
channels of digital trunks. Nobody uses it however on air, this protocol
only exists on paper. I guess the PID you talk about was assigned for this
protocol since TAPR holds the spec and also hands out these PID's (although
I'm ammazed to find out FlexNet somehow managed to get a PID assigned).
The tactic seems to be is just to assign one with good luck and when the
protocol catches on hope and pray that some day it will make it to the
offcicial spec. If not, no harm done, people will use it anyway.
Kind regards,
Henk.
----------------------------------------------------------------------
Subject: Re: Kenwood APRS radio...
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Tue, 08 Jun 2004 23:21:32 +0200
X-Message-Number: 69
At 12:02 8-6-2004 -0400, Robert Bruninga wrote:
>are earlier on the growth curve.. APRS has been in the
>USA since 1992. It only becaame popular in Europe after
>2000. And don't exclude rush hour either, when its much higher...
This is mainly because APRSdos could only driver TAPR TNC's in convers
mode. I looked at it in 1998 and downloaded APRSdos. It was a big
disapointment since it could not run on common European hardware, only on
American hardware that was hard to get and very expensive (almost
exclusively TimeWave AEA TNC's). I threw it in a corner anyway, not usable
for Europe.
In Europe there are only a very few TNC's with TAPR type commands. When
APRS opened ualtime modes like DX clusers and APRS are a different cup of tea,
so the same controversy doesn't exist for these modes as far as I know,
only for store and forward systems like the BBS system on Packet.
Where I'm getting at is this; these interlinks just use telnet connections
and exchange KISS packets. The technology is there and its working. Any
kind of AX.25 data can be carried on it and using the same protocol for
APRS and OpenTrack would be simple. I think a experienced Perl writer
writes module to write and read data from such a stream in a day.
Kind regards,
Henk.
----------------------------------------------------------------------
Subject: Re: Tetroon collateral damage report, revision1
From: "Gregg G. Wonderly" <gregg@skymaster.cytetech.com>
Date: Tue, 08 Jun 2004 16:43:24 -0500
X-Message-Number: 72
>Others who were entitled rightfully to transmit, unmolested, in the local
>terrestrial networks were "harmed", however somehow the damage done to them
>is ignored in the promotion and defense of a protocol for the sake of
>inovvation. It appears that NOT ONE of the offending packets was received
>by anyone capable of using it, so the fact that they were sent at all, by
>itself is in fact evidence of collateral damage, which we are so quick to
>sweep under the rug..
Hi Doug, sorry, in advance for rambling here...
I think there are some separate issues here. Did too much AX.25 traffic get
sent? Yes, we all agree to that. The PATH was not optimal. That's been
settled. Were there OpenTrac packets being transmitted? Yes, we agree on
that too. Were they the complete cause of all problems? No. By numbers,
they increased the channel use from the balloon. By content, they may not
have all been digi'd by all digipeaters, because we found that UIDIGI only
digis 0xf0 packets. I don't think counting the total number of packets is
possible. We do know that there were too many packets.
Now, the ultimate point of this dicussion was OpenTrac being on the air on
144.390mhz. As an AX.25 protocol user, it works within the confines of the
system without introducing any on air anomolies in and of itself (we already
agree there were too many packets). This is where everyone is huddled in
discussion. Bob believes that it is impossible for OpenTrac to not cause
problems with APRS stations on the same frequency. It is clear from the
event, that some types of stations had problems with the presence of the
OpenTrac packets. What Jeff King has been putting forth repeatedly is that a
HamHud user had problems because their TNC was not configured to reject
PID=0x70 packets. We've gone round and round about whether the APRS spec says
that you must configure your TNC to only receive 0xf0 packets. Bob has
modified the APRS errata page to state that this is a good choice to make for
APRS users.
So, now the discussion is really about should there even be an OpenTrac, or
should we figure out how to make APRS have extensions via the user defined
packet types.
If you a just transmitting packets, APRS is fairly easy to use when you just
send the simple format of position, or if you just pass GPS data to the TNC to
be transmitted while in converse mode.
When you are receiving APRS, then you have 5 different ways that clients might
send you a position. This is where things get ugly. Bob, seems to agree that
this is an area where a new format, that was more accurate would be a great
candidate for a new user defined packet that could be adopted over time. This
would then add a 6th choice to the mix without eliminating the other 5.
OpenTrac removes all these choices and uses just one.
But, that doesn't remove the fact that it does not have anything in common
with APRS at the basic level. But, that does not mean that it can't interwork
through transcoding or otherwise along an evolutionary path into future.
The challenge is that Bob and others have control of parts of the APRS system
that others don't. So, we will have a marketing and emotional exchange here,
probably forever. It will just be a fact of life. Scott, and others will
continue their investigations, and knowing that there are people interested in
packet radio technologies, they will post announcements and questions here.
Those who can't stand the thought of OpenTrac will rant and rave about this,
and make ugly comments about the content and the author.
It will seem like a bunch of children fighting, because the emotions won't be
put aside.
I'm here because I'm interested in packet radio, have been since I created my
first such application (a message board) in Z80 assembler using the cassette
port on a TRS-80 model 1 at 300 baud on two meters back in 1983 or so. Was I
licensed then? No, I wrote it for my good friend, WB5RWS (now N0LID).
As long as I see progressive applications and new hardware, I'll be excited
and think about ways I can use the technologies to serve my community.
Bob is very pro community service. I think that's a good thing too. He has a
lot of opportunities to use APRS in some large applications. I don't have
enough mobile APRS users in my area, that participate in community service
events to use APRS.
But, there is a balloon group here (KC5TRB) that has great fun with APRS on
144.340mhz. It's been a great way for them to track their balloons so that
they can find them and keep enjoying those experiments.
-----
gregg@cytetech.com (Cyte Technologies Inc)
----------------------------------------------------------------------
Subject: Re: Venus transit?
From: Roger Grady <k9opo@comteck.com>
Date: Tue, 08 Jun 2004 16:50:49 -0500
X-Message-Number: 73
At 08:57 AM 6/8/04, Richard Amirault wy hard data
offered was one single hamhud in Virginia. And don't mistake "trees falling"
on the APRS-SIG to have any semblance of reality. They don't. The internet is
not the same thing as ham radio.
And speaking of the internet, I assure you, from what I have seen on the
OpenTrak list, private e-mails and other AVL lists I am on, no-one is taking
this lightly. No-one is out to get anyone. These guys are gentlemen.
Really.
>Damage was done. Others who were entitled rightfully to
>transmit, unmolested, in the local terrestrial networks were
>"harmed", however somehow the damage done to them is ignored in the
>promotion
But again, you could say that about any balloon flight, be it APRS or
OpenTrak. For that matter, you could even say that about PocketTracker which
doesn't use CSMA. It is all about mitigating the damage, which PocketTracker
does by a limited RF footprint and balloons can do by limiting path lengths,
power levels and/or going to another frequency.
NOTHING to do with the OpenTrak or APRS protocols, strictly a LAYER 1 RF
ISSUE.
>Collateral damage includes ALL
>parties , not just those who can PROVE specific damage. I am sorry
>my satirical references, to a shotgun trial, do not meet your approaval.
I'm sorry, I am not an attorney, but "collateral damage" sounds like lawyer
talk to me. Are you satirically suggesting some sort of class action lawsuits
of APRS users against the OpenTrak developers? Maybe a lawsuite from Kenwood
against Scott because they have to update their software to display OpenTrak?
Again, I'm not an attorney, but for a class action, don't you need more then
one party damaged? I do know you really don't need any real grounds to bring
a lawsuit, but most parties don't do this because it would be a waste of time
(such as Kenwood suing Scott).
But to be crystal clear, for the record, only one party has reported an
on-air problem with the protocol, despite 1000's e-mails on this SIG, since
Thursday. Plus, and I think this is a legal term, Scott has made a sincere
effort to "mitigate' the damage by looking at the code base of HamHUD.
Doug, this is about ham radio and working together. Even though you say your
legal analogies where satirical, they framed your technical discussion and
set the tone. Suggest solutions.
To be clear, the problem you cite is strictly a layer one issue, NOT a
protocol issue, and as I said above, is by no means OpenTrak-centric. And
there ARE solutions for this, for any kind of balloon flight, be it APRS,
OpenTrak or the ApplePie AX.25 packet protocol. Here are some suggestions:
1. NO wides above a certain height (this was THE mistake made IMHO)
2. Just enough power to maintain communications. As Tetroon proved, 500mw is
more then enough. This allows less chance of balloon "stepping on" strong
local mobiles due to 'near/far' effect and lack of effective CSMA. Remember,
there is such a thing as the FM capture effect, and because balloons have
RLOS, one wants to use this to their maximum advantage.
3. Maybe special antennas to null the signal directly down (since it is
closest). Tetroon used a 1/2 wave wire dipole I am told, so it seems to have
maybe helped here? (signal off end of dipole is weakest, and that would have
been directly down, to the nearest stations..)
4. Frequency agile radios. Use 144.39 down low for initial assent/descent and
recovery, but QSY to another frequency, like 144.34, when at altitude. This
is not "blue sky" thought from me, but really is quite doable with
PocketTracker if you want to dig into the code (SOTT) and read the data sheet
on the PLL.
Doug, I really think this is case of making Mount Everest out of a molehill.
Big non-issue for 99.995% of those ~20,000 we are told that operate APRS on
the air. The world didn't stop rotating on Thursday, even though big mistakes
where made in digi path selection. Lets focus on the problem, not the
anti-OpenTrak rhetoric, and we might accomplish something, OK?
Thanks
-Jeff wb8wka
----------------------------------------------------------------------
Subject: tapr email server is being blacklisted
From: "Tyler Allison" <tyler@allisonhouse.com>
Date: Tue, 8 Jun 2004 18:27:28 -0400 (EDT)
X-Message-Number: 75
FYI...
http://www.spamcop.net/w3m?action=checkblock&ip 4.17.217.24
Someone who knows the admins at tapr.org may want to get in contact with
them and fix whatever needs to be fixed.
Im not trying to start a flame war over RBL systems, just giving a notice
since I found all my aprssig email getting thrown in my 'spam' folder and
others may be seeing the same.
-Tyler
----------------------------------------------------------------------
Subject: Re: Tetroon collateral damage report, revision1
From: "Jason Rausch" <ke4nyv@hamhud.net>
Date: Tue, 8 Jun 2004 17:33:27
X-Message-Number: 76
>...is that a HamHud user had problems because their TNC was not configured
>to reject PID=0x70 packets.
Sorry Greg or whoever (I lost track a long damn time ago), but that is
INCORRECT. I AM the HamHUD user being spoke of in many of these posts.
There has been extensive discussion about this on the HumHUD SIG and one of
the first requests made to me was to check MY TNC for the PID check. I
confirmed that was NOT the problem. So it was NOT a matter of MY TNC being
configured properly.
I just wanted to set the record straight that I was not making a complaint
based on MY neglagence. The packets were indeed somthing irregular. There
was somthing in them that did not want to play nice with the HH2 parser.
That...is being worked on.
Jason KE4NYV
www.ke4nyv.com
RPC Elecronics
www.ke4nyv.com/rpc
----------------------------------------------------------------------
Subject: Re: APRS Protocol - A Modest Proposal
From: "AE5PL Lists" <HamLists@ametx.com>
Date: Tue, 8 Jun 2004 17:47:34 -0500
X-Message-Number: 77
I am fully aware of how TCP/IP works and what can be transported across it.
My statement st to handle. But, this is
not a quick process nor one to be designed by the "seat-of-the-pants"
method. As more concrete ideas are formulated, this type of protocol will
be proposed to TAPR, maybe in draft form by DCC but that may be very
aggressive timing.
By designing such a protocol, APRS-IS would remain intact, servers could be
configured to interconnect with said protocol, but those servers, IGates,
and clients that don't won't be obsolete. If someone wants to write server
code for an OpenTrac-IS, great. They too could use the same interconnect
protocol. But don't look for an APRS-IS server to implement OpenTrac-IS on
a merged data stream (they could use the same pipe, but would be separate
protocols) because for an APRS-IS server to operate properly, it must
assume that the data is some form of APRS packet. Dupe checking, mangled
packet filtering, etc. depend on it. Of course, someone could just pipe a
binary protocol in but that would threaten the stability of APRS-IS and I
don't think we want to go back to where we were 2 years ago with servers
and connections crashing, looping, etc.
73,
Pete Loveall AE5PL
mailto:pete@ae5pl.net
>-----Original Message-----
>From: Henk de Groot
>Posted At: Tuesday, June 08, 2004 4:38 PM
>Subject: [aprssig] Re: APRS Protocol - A Modest Proposal
>
>At 18:30 7-6-2004 -0500, AE5PL Lists wrote:
>>Can't do that. You missed the statement "APRS-IS is based upon the
>>textual representation of packets". Inter-server and server-client
>>communications rely on lines to be terminated with a carriage return
>>and/or line feed. Since OpenTrak is a binary protocol, these
>>characters may occur anywhere in a packet. Beyond that, IGates and
>>most APRS-IS clients expect packets to have some semblance
>to APRS packets.
>
>The TCP/IP pipe itself is binary. The easiest to make a
>universal data-stream is just to put KISS data on it (packets
>delimited by FEND characters where FEND caracters appearing
>in the data stream are escaped, very simple and not only used
>by KISS but also used by SLIP for example to get IP packets
>over a modem connection). You can transport both APRS and
>OpenTrack just as easily.
----------------------------------------------------------------------
Subject: Re: Tetroon collateral damage report, revision1
From: "Scott Miller" <scott@opentrac.org>
Date: Tue, 8 Jun 2004 16:15:00 -0700
X-Message-Number: 78
>4. Frequency agile radios. Use 144.39 down low for initial assent/descent and
>recovery, but QSY to another frequency, like 144.34, when at altitude. This
>is not "blue sky" thought from me, but really is quite doable with
>PocketTracker if you want to dig into the code (SOTT) and read the data sheet
>on the PLL.
Speaking of which, I've been thinking about doing this with the
OpenTracker - add frequency as an option in the config profiles, and use an
output pin to control the Pocket Tracker. Of course, integrating a Pocket
Tracker with an OpenTracker requires a band saw and some soldering. =]
Hopefully Byon will find code space and an I/O pin to implement this in the
stock TinyTrak code.
Scott
N1VG
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
