| |
ZL3AI > APRDIG 06.06.03 15:01l 271 Lines 10835 Bytes #999 (0) @ WW
BID : 1430-ZL3AI
Read: GUEST
Subj: TAPR Digest, May 31, 4/8
Path: DB0FHN<DB0RGB<OK0PPL<RZ6HXA<SP7MGD<ZL2TZE<ZL3VML
Sent: 030605/1345Z @:ZL3VML.#80.NZL.OC #:1726 [Chch-NZ] FBB7.00i $:1430-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: raw frames
From: Steve Dimse <k4hg@tapr.org>
Date: Sat, 31 May 2003 09:49:23 -0400
X-Message-Number: 13
On 5/26/03 at 12:40 AM kr1st@amsat.org (Alex) sent:
>Is there a way to find raw frames on findu or any other site? I've
>checked some sites that offer queries, but they already assume it's
>either weather or position reports. In other words, they are already
>interpreted in some fashion. I'd just like to look at some frames
>regardless of what they may be.
raw.cgi is what I think you want, assuming you meant you wanted the packet
text, rather than the AX-25 data itself (the customary meaning of a frame).
This has been on findU for a long time, but the documentation was pulled
because the database was not designed to handle the queries, but I have
since updated the table structure to make this efficient enough to allow
it. Also, there is an undocumented parameter "&time=1" which adds a
timestamp for each packet (but makes it incompatible with client program
file reading routines.
Steve K4HG
----------------------------------------------------------------------
Subject: RE: APRS Internet System Design Philosophy
From: "AE5PL Lists" <HamLists@ametx.com>
Date: Sat, 31 May 2003 09:10:07 -0500
X-Message-Number: 14
Steve,
Unfortunately, you have taken statements out of context and tried to use
them to support your apparent view that there should be no tier 2
servers. That is not what I said nor did you make a plausible argument
for removing tier 2 servers.
>-----Original Message-----
>From: Steve Dimse [mailto:k4hg@tapr.org]
>Posted At: Saturday, May 31, 2003 8:48 AM
>Subject: [aprssig] RE: APRS Internet System Design Philosophy
>
>Ahub network is also in place. The fact is, neither of these
>designs are implemented as well as they should be, and
>neither architecture should be judged by its present
>implementation. I thought you and I had agreed to that in a
>prior discussion just a week or two ago.
And I did not say anything contrary to that.
>Huh? You are then not advocating a tiered plan, but anarchy?
Not true. But giving people the ability to implement their own servers
does not automatically equate to anarchy. You do have a dim view of
your fellow hams, don't you.
>Idon't think so. Do you really mean that every hub in the
>lower tier is free to do whatever they want? Connect to every
Yes, because there is nothing you can do to stop them.
>other core and tier two hub, and all the aprsd IGates? Of
As I stated in my original post, that should be highly discouraged, but
you can't prevent it without getting the server authors to quit
distributing their software. Even then, there are 100's of servers out
there already implemented.
>This argument is not in any way one of filtered vs.
>non-filtered. No filtering being done in a tier 2 server
>could not be done at tier 1. There is nothing that says a
>central server cannot provide additional ports for those
>people that like them, just as fourth does now.
But the specialized ports are actually being offered as non-core
functionality. The reason: you are not going to get all of the core
servers to continuously update their configurations for each hams
different wants. If you do, you threaten the reliability of the overall
network with the number of changes that would need to be implemented.
>>packets being lost between RF networks.
>>
>No packets were lost. findU got all of them, they existed,
My statement was that packets were lost between RF networks, not Findu.
If you have segmentation like we did the day fourth was added, then
certain segments can't talk to other segments and therefore packets that
normally would transcend the segments were "lost" as far as individual
users of each segment were concerned.
>this very simple change. This is exactly why the two tier
>approach is more dangerous. Imagine if a change needed to be
>made to every tier two server...how long would that take???
>How would you be able to monitor if all had done it? How
>would you convey changes to the users? And how long would it
>take all of them to implement the changes in their config files.
Again, your assumption is that every tier 2 server must be a mirror.
That is not the case and should not be the case. Only the core servers
are required to be mirrors with regards to their base functionality.
>complex the network needs to be to provide the services. As
>you point out, the core server approach is capable of giving
>every user whatever they want or need, and is in fact quite
>close to actually implementing this.
That is not what I pointed out. I pointed out that with port 14580,
they give a powerful subset of ports that can be used in many ways.
However, they do not meet all needs as I pointed out later.
>>nothing. As long as hams come up with special needs, there will be a
>>place for non-core servers.
>>
>Ihave no great objection to this....but I think this is
>different from the tier 2 concept. Correct me if I'm wrong,
>but as I've understood it, the plan is to try to get all
>users to connect to tier 2, reserving the central hubs for
>IGates and hub interconnects. This is the plan I've been
>arguing against. If someone wants to create a substream and
As I said in my original post, whether clients should be able to connect
to the core is not the basis for determining whether a tiered approach
or a totally centralized approach should be used. I reiterate that we
have a tiered system now with an almost fully functional core. There
are needs for both, but I highly discourage trying to make the core the
"does all for everybody". As I pointed out before, the level of
reliability and usability goes down as you try to increase the mirrored
core functionality of the core servers.
73,
Pete Loveall AE5PL
pete@ae5pl.net
----------------------------------------------------------------------
Subject: findu.com & TinyTrak3
From: "James Bell Jr. [K7FTP]" <k7ftp@commtechreview.net>
Date: Sat, 31 May 2003 08:23:37 -0600
X-Message-Number: 15
There has been a discussion about this issue in the TinkTray group on Yahoo,
but I wanted to run it by those here to see if anyone knows why this is
happening.
It appears that no matter what Status Beacon text a TinkTrak III user
enters, findu.com always shows "Status: TinyTrak3 v1.00".
My info for example is at http://www.findu.com/cgi-bin/find.cgi?call=k7ftp
From what we can tell, when the TinyTrak is started, it sends a packet with
a CQ in it, and the TinyTrak3 v1.00 status text.
It appears that findu.com is locking onto this and ignoring any other status
text which comes through - although there is a question as to the formatting
being correct on the TinyTrak3.
It seems that UI-view and WinAPRS see the status text users enter, so is
findu.com not looking at something it should be?
Thanks for any insight the group can provide.
73 to all,
K7FTP
----------------------------------------------------------------------
Subject: Re: raw frames
From: Alex <kr1st@amsat.org>
Date: Mon, 26 May 2003 01:53:05 -0400
X-Message-Number: 16
Steve Dimse wrote:
>raw.cgi is what I think you want, assuming you meant you wanted the
>packet text,
>rather than the AX-25 data itself (the customary meaning of a frame).
I was indeed thinking of the AX.25 data. I should've been more clear on
that. Right now I don't have a second setup for packet to analyze
packets, so I was hoping I could peek at them after they made it through
APRS-IS into Findu. Usually, I use a Linux box for these purposes, but
I've been swapping drives and now Linux doesn't boot on the machine it's
in now. Imagine that! :)
However, the packet text that raw.cgi produces works just fine for now.
Very nice feature.
Thanks a bunch, Steve!
73,
--Alex KR1ST
----------------------------------------------------------------------
Subject: Re: findu.com & TinyTrak3
From: Alex <kr1st@amsat.org>
Date: Sat, 31 May 2003 12:08:36 -0400
X-Message-Number: 17
"James Bell Jr. [K7FTP]" wrote:
>From what we can tell, when the TinyTrak is started, it sends a packet with
>a CQ in it, and the TinyTrak3 v1.00 status text.
My question would be, why is it issuing a CQ at all? I assume that is
for advertising purposes? (we already have TOCALLs to identify sofware
and version numbers, APT310 in this case)
What did the developer/merchant answer when you asked?
>It appears that findu.com is locking onto this and ignoring any other status
>text which comes through - although there is a question as to the formatting
>being correct on the TinyTrak3.
Findu will show the latest _valid_ one. So if the CQ contains a valid
status text, and any subsequent status packets are invalid, then Findu will
only show the latest. However, that is not what is going on here.
>It seems that UI-view and WinAPRS see the status text users enter, so is
>findu.com not looking at something it should be?
Raw (text) packet from your station:
K7FTP>APT310,WIDE2-1,qAo,K7UHP:!4021.54N/11146.76W>142/000/>www.commtechre
view.net or k7ftp@arrl.net
The "status" in the packet above is actually just a beacon comment and
not a status report. See Chapter 8, page 33 of the APRS spec for the
position format. For the status report, see page 80, Chapter 16 of the
APRS spec. I don't recall ever seeing anything in the spec that says
that the status text could be embedded in a position report, only
comments.
I'm not sure if the packet is incorrectly formatted as I do not know
what you typed for the beacon comment, but the "/" after the
course/speed field should not be there, unless you intended that to be
part of your comment of course. I seem to remember though that the extra
"/" was added sometimes for D7 and/or D700 radios so that the comment
would show up correctly on the display. I may be way off here. However,
slash or no slash, it's still a beacon comment and not a status text.
I also did a query on raw (text) packets from your TT3 station and only
see position reports and no status report packets at all. So I assume
your TT3 is not actually transmitting a status report it seems. I
remember that for my TT1 I had to specify something about how often I
wanted to have my status transmitted. If that's not required anymore,
then you can safely bet that your TT3 is not transmitting status packets
at all.
I loaded your packet in WinAPRS (2.4.6) and it shows your "status text"
correctly as a beacon comment and not as status text.
Seems to me to be a (perhaps unintended) clever advertising trick. That
way the TinyTrack name will always show up on Findu if anyone looks you,
or anyone else with a TT3, up on Findu.
Thanks for reporting this. I was just checking out the TT3 for another
project.
73,
--Alex KR1ST
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
