| |
ZL3AI > APRDIG 27.01.07 06:33l 205 Lines 8640 Bytes #999 (0) @ WW
BID : 9628-ZL3AI
Read: GUEST
Subj: [APRSSIG] Vol 31 #29, 3/3
Path: DB0FHN<DB0MRW<DK0WUE<I0TVL<TU5EX<IW2OAZ<ZL2BAU
Sent: 070127/0455Z @:ZL2BAU.#79.NZL.OC #:29417 [Waimate] $:9628-ZL3AI
From: ZL3AI@ZL2BAU.#79.NZL.OC
To : APRDIG@WW
Message: 16
Date: Thu, 25 Jan 2007 10:52:15 -0000
From: "Dave Baxter" <dave_at_emv.co.uk>
Subject: RE: [aprssig] HOW A CLEAN TNC LOOK
"Packet Virus" ????
Please explain, have I missed something? Is something nasty propagating
from TNC to TNC on Kenwoods then?
Dave G0WBX.
>From: julien mervyn dedier
>Sent: Wednesday, January 24, 2007 9:35 AM
>To: TAPR APRS Mailing List
>Subject: [aprssig] HOW A CLEAN TNC LOOK
>
>When you have a clean free tnc from packet virus you see no question
>mark or bird marking in the tnc data,tnc data show you clean raw data
>of the station as what is shown below,i have seen hams in the island and
>else where,hams selling their radios because the tnc not functioning.
------------------------------
Message: 17
Date: Thu, 25 Jan 2007 06:59:27 -0500
From: Amir Findling <sarlabs_at_twcny.rr.com>
Subject: Re: [aprssig] HOW A CLEAN TNC LOOK
The way I understood it, Julien really meant TNC bug, as in an
unintentional glitch in the software that makes the TNC malfunction
and not a virus, as in malicious malware introduced intentionally in
order to cause harm and/or reproduce itself from unit to unit.
73' de Amir K9CHP Member ARRL, AMSAT #36083
Cayuga County Highland SAR http://www.cayuganet.org/highlandsar/index.html
1st Special Response Group www.1srg.org <http://www.1srg.org>
Apprentice Tracker Joel Hardin Professional Tracking Services
http://www.jhardin-inc.com
------------------------------
Message: 18
Date: Thu, 25 Jan 2007 10:06:27 -0400
From: "julien mervyn dedier" <julien9z4fz_at_gmail.com>
Subject: Fwd: [aprssig] HOW A CLEAN TNC LOOK
Thanks Amir well said you fully understand me and this is great,that others
will follow on thanks
>The way I understood it, Julien really meant TNC bug, as in an unintentional
>glitch in the software that makes the TNC malfunction and not a virus, as
>in malicious malware introduced intentionally in order to cause harm and/or
>reproduce itself from unit to unit.
--
THANKS
JULIEN
9Z4FZ//TRINIDSA & TOBAGO.
M0JDD//UNITED KINGDOM.
M0JDD/J3//GRENADA.
------------------------------
Message: 19
Date: Thu, 25 Jan 2007 09:53:58 -0500
From: "Robert Bruninga" <bruninga_at_usna.edu>
Subject: RE: [aprssig] Local Repeater Displays on Mobiles
>... To program for the least common denominator, IMO,
>leaves a lot to be desired. You get all the info by
>looking up on the D7/D700 where it is easy to see the -R
I have no problem at all with an object 146.940-R. Though I wouldn't use
it, since if it is 146.940, I can already tell that it is a voice repeater.
And by leaving off the "R", then for those GPS displays that show only 6
characters on their maps, then at least they show 6.940- instead of.940-R.
I just don't see that the -R gives anything.
>(Bob, if you are doing lookups while you are in motion
>behind the wheel, you are spending way too much
>time with your eyes off of the road).
If the object name is the freq, as I propose, then one does not have to do
any "lookup".
I have the control head mounted on the dashboard above the steering wheel
where it is even easier to glance at than the car's instrument cluster.
And since the frequency 146.940 of the OBJect repeater shows up on the
display without me having to push any buttons, then it is hands free too.
Your proposed method of having voice repeaters send out just anther
callsign with an -R on the end and requiring the driver to push a button to
see what the frequency is, I would say is more distracting to the driver
and lacks any ergonomics considering the mobile traveler's needs.
>I find it interesting that Bob has been a big proponent
>of IRLP, EchoLink, and Winlink objects to use the SSID
>or the first two letters of the object name as a visual
>identifier that it is that type of object, yet he doesn't
>like that idea for voice repeaters.
Yes, what I am proposing now is completely consistent with those
receommendations. That is, that the *info* needed by the travler (in this
case the node number) shows up in the OBJECT name, so that it shows on the
front panel of the radio hands-free. We recommended putting the ER or IP
in front of the object name so that when it was truncated on a 6 character
GPS map, then the more important node number would still show on the map.
Thus we get ER-123456 for ECHOlink and IRLP-8080 for IRLP and these show on
the worst-case-6-byte GPS map as 123456 and P-8080.
These are easy to distinguish at a glance from an object "146.940-"
But for this voice repeater application, I don't see that much value in
focusing so hard on trying to get the digits to show on the GPS map. What
we are after here is not that, but the hands-free, heads-up-display on the
front panel of the radio without pushing any buttons to show the traveler
the receommended voice repeater for where he is right now.
>Bob's refusal to say "OK" to adding,TCPIP* to the third-
>party path is odd too: it takes care of APRS-IS being a
>factor in this discussion with minimal effort.
But your email made two recommendations:
1) put in TCPIP* so the APRS-IS would ignore these packets
2) you wanted to be able to see recommended repeaters in an area remotely
via the APRS-IS.
You cannot have it both ways. So I took your suggestions and modified my
propossal for voice repeaters so that 1) yes we could see them on the
APRS-IS if desired and by 2) using the 9th character to make them all
unique, so that they could be individualy viewed from anywhere. This then
necessitated not blocking them from the APRS-IS by adding TCPIP*, since you
cannot have it both ways.
>APRS-IS is not going to start handling certain objects
>based on their names or symbols in certain ways out of
>the millions of packets sent each day.
Why not? They already do. The APRS-IS and all clients are already
required to parse out the object name and the SENDERS call for every
object, since attribution of an object is required in the spec. Only a few
lines of code change can logically combine these fields to make all such
objects unique.
>Yes, propagation in the DFW area where these objects can
>collide is almost a daily issue. It must be nice for Bob
>to live in an isolated area where he can pass down his
>pronouncements with a "I don't care if it doesn't work
>for you 'cuz we don't have that problem here" attitude.
Don't make a quote out of your own opinion and imply that I said it. I
would never say that. And besides it is unfounded anyway... for several
reasons.
1) I live in probably the highest density of APRS and voice repeaters on
the planet, over 100 voice repeaters and I just checked 50 digipeaters
heard on RF. So I think it is representative of the worst case scenario..
SO my area on the eastern deaboard is probably a pretty good test bed.
2) With our population density, we have multiple 146.94 repeaters every 50
to 100 miles or so and yet we don't think that a 146.94 object transmitted
DIRECT from 100 miles away is going to cause a problem to our locals.
3) Yes we have tropo sometimes and we sometimes hear multiple 146.94
repeaters in our area, but then it is doubtful that an adjacent 146.94
repeater is also the #1 APRS recommended repeater in the next eastern
seeaboard city. Thus, there will not be that many 146.94 objects competing
during tropo with ours.
4) OK, say there is a string of 146.94 recommended traverlrs repeters and
during band openings these objects do come in. So what. What shows on the
radio's display is still just 146.94- which is all that the traveler needs
to see anyway.
5) In an area such as you claim as DFW, then if multiple 146.94 repeaters
are all the receommended travelr repeaters and you want to distinguish
them, then surely the APRS digipeater sysops who are putting these objects
in the digipeaeters can agree on a unique -X byte to make them unique.
Say, 146.94-D for the Dallas one, 146.94-F for the FortWorth one, and so
forth...
In any case, these recommended voice repeater frequencies showing up on the
front panel hands-free, are far more valuable to the driver than seeing
W5XYZ-R and W5APC-R, both of which the operator has to push a button just
to see what frequency they are on.
So it still seems to me that the best object name should be 146.940- and
even the "-" is optional and also any of the 36 additional "-X" options can
be used to make the repeaters unique in areas where tropo may be a problem.
Bob, WB4APR
------------------------------
aprssig mailing list
aprssig_at_lists.tapr.org
https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
End of aprssig Digest, Vol 31, Issue 29
Read previous mail | Read next mail
| |
