| |
ZL3AI > APRDIG 18.06.04 10:36l 563 Lines 22697 Bytes #999 (0) @ WW
BID : 3487-ZL3AI
Read: GUEST
Subj: TAPR Digest, Jun 13, 1/1
Path: DB0FHN<DB0RGB<DB0MRW<DB0WUE<DK0WUE<HA3PG<7M3TJZ<ZL2TZE<ZL3VML
Sent: 040618/0809Z @:ZL3VML.#80.NZL.OC #:26059 [Chch-NZ] FBB7.00i $:3487-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
TAPR APRS Special Interest Group Digest for Sunday, June 13, 2004.
1. Re: APRS Messages to Instant Message bridge ?
2. ui-radar vs uinws
3. waterproof/underwater APRS
4. Re: waterproof/underwater APRS
5. Re: waterproof/underwater APRS
6. Re: waterproof/underwater APRS
7. Re: waterproof/underwater APRS
8. Re: question about possession of an object.
9. Re: waterproof/underwater APRS
10. Re: question about possession of an object.
11. Re: question about possession of an object.
12. Re: waterproof/underwater APRS
13. Re: question about possession of an object.
14. Re: question about possession of an object.
15. Re: question about possession of an object.
16. waterproof/underwater APRS
17. Re: waterproof/underwater APRS
----------------------------------------------------------------------
Subject: Re: APRS Messages to Instant Message bridge ?
From: "William McKeehan" <mckeehan@mckeehan.homeip.net>
Date: Sun, 13 Jun 2004 09:37:21 -0400 (EDT)
X-Message-Number: 1
I was thinking this some more last night and I can see how it would become a
less used feature.
My guess is that sending lots of messages (other than just position type
information) from an in-field APRS unit is not so trivial and if you are
sitting at a computer, you already have any IM clients that you need loaded
there, so there would be little need for it.
>One of the reasons I stopped messing around with the IRC to APRS stuff. Other
>than the "Hey, I made it work" factor, it really wasn't practical, already
>having a client connected to APRS-IS anyway.
>
>Danny
>KE4RAP
----------------------------------------------------------------------
Subject: ui-radar vs uinws
From: "deni" <deni@dwatt.com>
Date: Sun, 13 Jun 2004 11:00:59 -0500
X-Message-Number: 2
Gentlemen,
Just what is the major difference between ui-radar and ui-nws. Currently,
ui-radar gets my local radar and displays it properly. Am I lucky in the
fact that our local radar has outlines for all of the surrounding states and
counties/parrishes? The only problem is the inability to zoom either in or
out, but other than that it is just great.
Thanks
Deni
wb0tax
----------------------------------------------------------------------
Subject: waterproof/underwater APRS
From: "James Lux" <aprssig@luxfamily.com>
Date: Sun, 13 Jun 2004 12:21:25
X-Message-Number: 3
I'm looking for APRS solutions that can tolerate being on a sea kayak.
Sure, you could put the GPS and HT in a drybag and lash it to the deck, but
I'm curious if anyone has done this, or come up with other clever
implementations. I've seen APRS done in connection with sailboats. What
sort of antenna would be good on a kayak (given that you're sitting all of
a foot off the ocean's surface).. maybe a tall whip with the radiating
element on top?
What about integration with Marine VHF equipment? Are any of the Marine
VHF radios able to do 2m ham band as well. I would assume that a number of
multiband radios could probably be modified to transmit (illegally because
the ham radios aren't type accepted, etc.) on Marine VHF channels, but what
about the inverse (which would be legal). Presumably you'd do something
like GPS, KPC3, marine radio, or maybe GPS, PalmTop, Radio.
Jim, W6RMK
----------------------------------------------------------------------
Subject: Re: waterproof/underwater APRS
From: Gerry Creager n5jxs <gerry.creager@tamu.edu>
Date: Sun, 13 Jun 2004 12:46:03 -0500
X-Message-Number: 4
Cows In Space had to contend with cattle suitably instrumented going
into ponds to cool off. We used a hermetically sealed die-cast box (Dow
Corning 3140 to seal inside and outside), pressure-bearing bulkhead
connectors (BNC) and a sealed M/A-Com patch antenna fed with an SMA.
The antenna connector was sealed with Scotch 130 tape and over-coated
with ScotchKote.
I'd be thinking about something like a NEMA-4 enclosure with
pressure/water-tight connection for the coax and a patch similar to what
I used. I'd recommend one of the older OnCore receivers that doesn't
require a preamplified antenna, having the amp at the receiver; the coax
run will be short. You can keep batteries inside, and if you're going
to try solar panels they can be fed-through with a BNC or a water-tight
connector.
I've *NOT* tried these. They're related to putting trackers on cows and
graduate students. The latter are notibly harder on equipment!
73, gerry
--
Gerry Creager -- gerry.creager@tamu.edu
Network Engineering -- AATLT, Texas A&M University
Cell: 979.229.5301 Office: 979.458.4020
FAX: 979.847.8578 Pager: 979.228.0173
Office: 903A Eller Bldg, TAMU, College Station, TX 77843
----------------------------------------------------------------------
Subject: Re: waterproof/underwater APRS
From: Steve Dimse <k4hg@tapr.org>
Date: Sun, 13 Jun 2004 13:54:40 -0400
X-Message-Number: 5
On 6/13/04 at 12:21 PM James Lux <aprssig@luxfamily.com> sent:
>I'm looking for APRS solutions that can tolerate being on a sea kayak.
>Sure, you could put the GPS and HT in a drybag and lash it to the deck, but
>I'm curious if anyone has done this, or come up with other clever
>implementations. I've seen APRS done in connection with sailboats. What
>sort of antenna would be good on a kayak (given that you're sitting all of
>a foot off the ocean's surface).. maybe a tall whip with the radiating
>element on top?
Here is the guy with the answers, Steve Roberts, N4RVE.
http://www.microship.com
He was the guy that covered over 17,000 miles pedalling a recumbant bike
with computerized hamshack trailer, since finishing that adventure he's
been working on doing the same with small boats, and has an inflatable
kayak equipped with more electronics than many of us own!
Steve K4HG
----------------------------------------------------------------------
Subject: Re: waterproof/underwater APRS
From: Jeff King <jeff@aerodata.net>
Date: Sun, 13 Jun 2004 14:29:53 -0400
X-Message-Number: 6
Hi Jim:
Here is a project I did, and the audio from the DCC talk, that would
tolerate brief submersion:
http://www.aerodata.net/images/educopen.jpg
http://www.tapr.org/tapr/html/dcc2001audio.html (embedded LINUX tracker
under APRS symposium)
The spec that I designed it to only required "water spray" but I tested it
by dropping it in the bathtub. Totally dry inside. Of course, the case was
closed and latched!
The specifics are as follows:
Case: SERPAC http://www.serpac.com/products__r-home.htm
GPS and power connectors: AMP circular plastic:
http://dkc3.digikey.com/PDF/T042/0225.pdf
also the rubber gasket for the connectors (next page I think)
The above, plus plenty of RTV. I filled the external plugs with it, outline
the edge of the socket with it before mount, and on the back of the socket,
injected RTV into each wire hole.
DigiKey carries both Serpac and the AMP connectors above.
The CDPD antenna already was designed for outdoor use, and had rubber
gaskets on it. However, do be careful of where the coax joins with the
connector, as that is also a place water can get in.
For APRS, you'd do the same thing with the GPS and power connector, but of
course you'd need to figure out the antenna connector. I imagine worse
case, you could use the coax tar/tape they sell, if you can't find a water
proof PL-239.
Also talk to Mike Musick, he has done some APRS trackers in Pelican Boxes,
very similar to the Serpac boxes (and I think he discusses it above my talk
in the 2001 DCC).
Good luck
Jeff wb8wka
----------------------------------------------------------------------
Subject: Re: waterproof/underwater APRS
From: Jeff King <jeff@aerodata.net>
Date: Sun, 13 Jun 2004 14:34:24 -0400
X-Message-Number: 7
Oh, I forgot to mention the GPS'es. I used the Garmin GPS-35 and later the
GPS-16, as both units are totally sealed. Not sure on the GPS-18, but I
suspect the case with that one as well.
http://www.garmin.com/products/gps35/
http://www.garmin.com/products/gps16/
http://www.garmin.com/products/gps18oem/ (not sure if this one is
waterproof)
----------------------------------------------------------------------
Subject: Re: question about possession of an object.
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Sun, 13 Jun 2004 21:38:48 +0200
X-Message-Number: 8
Hello Pete,
At 17:10 12-6-2004 -0500, AE5PL Lists wrote:
>No, you missed the point about OpenTrac. It is a separate protocol,
>100% not compatible with APRS parsers. Before everyone starts throwing
Yes, but adding a base 91 decoder to the existing APRS parser is about the
same amount of work (if not more) than writing the complete OpenTrack
parser for that part. OpenTrack is optimized for programmers.
>say "Because some people have not implemented a feature in APRS, it
>should not be used." I say that pressure should be brought to bear on
No. I say: "because of the existence of equipment that can not be upgraded
but is used by a large number of the APRS users (38%), APRS packets that
are not compatible should not be used". The the only thing we can do is to
see to it that packets stay compatible with the Kenwood-APRS defacto standard.
By introducing Kenwood-APRS incompatible packets you obsolete 38% of the
used APRS equipment over night. Bob has been telling this over the last two
weeks. I don't see how it makes a difference if its OpenTrack - which the
Kenwood silently ignores - or additions that are incompatitble with the
Kenwood-APRS defacto standard for which the unit will display ??. Both are
unusable for 38% of the END USERS. We have to keep the END USERS in mind!
>does not function as designed. Compressed packets function as designed.
>Items function as designed. Some authors decided not to implement them.
One of the authors happens to be Kenwood. Therefore the use of the function
should be discouraged since 38% of the users are unaware of these packets
because they cannot see them. What is the prupose of sending packets that
1/3 of the people can not see, is this progress?
>Also, you are assuming that the Kenwoods can handle multi-tiered
>3rd-party headers. Much software out there doesn't. And, by doing it
The TH-D7 doesn't handle nested third-party headers. But when serving in a
local area these packets will hardly become nested. Anyway, still a lot
better than the APRS 1.0 Items that do not show up at all.
By the way, yet anohter bug in the Kenwood. It shows the range to the
object in miles dispite my setting that I want kilometer values...
>this way, you may be excluding over 50% of the area served by APRS-IS
>servers and IGates that don't support 3rd-party packets. This last part
Yes, but unlike the Kenwoods, that software can be and should be upgraded.
If you look at the objects near my station you see all my experimatal
packets made it to the APRS-IS:
http://www.findu.com/cgi-bin/near.cgi?call=pe1dnn-2
>is changing, but like everything else is a slow process which is
>unlikely to go to complete adherence. Most servers do not currently
I don't think the situation with the Kenwoods will change...
>I understand your desire to make a work-around, but I am saying that
>nothing is gained by this method and, in fact, the repercussions of this
>are that many more people than that 38% of the mobiles may not see those
>packets. For that matter, I question whether those 38% will see the
>packets because of the stacked 3rd-party headers.
There will are not much stacked 3rd party headers on air. But if this is a
problem then the only safe way is to continue to use uncompressed Objects,
they work for everyone and do not require anybody to upgrade. So then we
should go with Bob's proposal to drop compressed packets for Objects at all.
My real desire however is to hold a mirror to APRS's face. If we allow
packets that are incompatible with the defacto APRS standard (= APRS as
used today) and will therefore require software upgrades then we might just
as well invest in APRS2, code named OpenTrack. If we take all the critisism
about APRS2 seriously then we should also apply the same rules to APRS
enhancements that are incomparible with the Kenwood-APRS defacto standard
and the APRS equipment in the field.
Only two options:
Either
* You stay compatible with the installed base - in which case you can not
use compressed items and objects as specified in the APRS Spec. Tricks like
the solution I presented have to be applied to get it done anyway.
Or
* You allow the software upgrades where people without the upgrade do not
see some of the packets. For the end-user it doesn't make the slightest
difference if the latter is an APRS addition that is incompatible with
their equipement or that some packets are send via an enhanced but
incompatible protocol.
Kind regards,
Henk.
----------------------------------------------------------------------
Subject: Re: waterproof/underwater APRS
From: "J. Moen \(K0ZXU/6\)" <jmm@jwmoen.com>
Date: Sun, 13 Jun 2004 13:56:28 -0700
X-Message-Number: 9
N4RVE also authored an article "Extreme Harsh-Environment Packet/APRS" in
the Spring 2004 issue of CQ VHF. He shows how he mounted the entire rig in
a kayak.
----------------------------------------------------------------------
Subject: Re: question about possession of an object.
From: "AE5PL Lists" <HamLists@ametx.com>
Date: Sun, 13 Jun 2004 16:05:14 -0500
X-Message-Number: 10
Hi Henk,
I am only responding to your last statement since you missed my point
about nested 3rd-party packets. The objects in question are generated
on APRS-IS (or on Firenet) and therefore are nested by default when they
hit RF. The Kenwoods do not support that so your work around does not
accomplish what you claim.
----------------------------------------------------------------------
Subject: Re: question about possession of an object.
From: Jeff King <jeff@aerodata.net>
Date: Sun, 13 Jun 2004 17:09:19 -0400
X-Message-Number: 11
On Sun, 13 Jun 2004 21:38:48 +0200, Henk de Groot wrote:
>At 17:10 12-6-2004 -0500, AE5PL Lists wrote:
>>No, you missed the point about OpenTrac. It is a separate
>>protocol, 100% not compatible with APRS parsers. Before everyone
>>starts throwing
>
>Yes, but adding a base 91 decoder to the existing APRS parser is
>about the same amount of work (if not more) than writing the
>complete OpenTrack parser for that part. OpenTrack is optimized for
>programmers.
OpenTrak is also optimized for small embedded MicroController trackers as
well. I find it quite ironic, that the only tracker that supports APRS
Compressed posits, AFAIK, is the OpenTracker with one of its APRS compatible
modes.
----------------------------------------------------------------------
Subject: Re: waterproof/underwater APRS
From: "Germino" <mgermino@sbcglobal.net>
Date: Sun, 13 Jun 2004 14:25:56 -0700
X-Message-Number: 12
Jim: On a canoe trip with the Boy Scouts, I used a 5 gallon bucket with a
lid that had a o-ring. Only had a KPC-3 and a mobile radio at the time, so
I put the TNC, GPS, battery and radio in the bucket. I had a hole in the
lid for the coax that went to a roll-up J-Pole, that was supported by a 6'
PVC pipe. Silicone was sealed around the coax at the hole in the lid. It
was ugly but safe and the bucket had room for other misc. radio stuff. Just
"to be prepared".
The PVC was clamped to the side of the Canoe using a modified C-clamp. I
welded a pipe to the clamp that the 3/4" PVC would slide into. In the river
there were places where we were well below ground level, so I wanted a
taller antenna.
The equipment you would use would depend on what you want to do with the
APRS. If all you want to do is be tracked, then a TinyTrak would work fine
and you can seal and forget it.
Mike
73, AD6AA
----------------------------------------------------------------------
Subject: Re: question about possession of an object.
From: "Scott Miller" <scott@3xf.com>
Date: Sun, 13 Jun 2004 14:32:56 -0700
X-Message-Number: 13
We've been discussing this off and on in the OpenTRAC list. Seems like what
you need for a 'strong' implementation is a public key signature algorithm.
Something like ECDSA should work, but without a separate distribution
mechanism you'd need to publish the whole public key with the packet, which
adds quite a bit to the packet size. Once you've got that, the clients just
make sure that the subsequent packets are signed with the same private key.
This way, you can still pass on ownership of the object if you send the
private key to someone else.
It's not easy for embedded processors to handle, but for things like weather
objects that's probably not a big deal. I'm pretty sure there's a more
lightweight solution, but I'm not sure exactly what it would be. We've got
the advantage of not needing verification of the sender's identity - we just
want to be able to verify that two packets were signed with the same private
key. That doesn't seem to be a very common situation, though, and I have
yet to find an appropriate signing algorithm.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: question about possession of an object.
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Sun, 13 Jun 2004 23:38:59 +0200
X-Message-Number: 14
At 16:05 13-6-2004 -0500, AE5PL Lists wrote:
>Hi Henk,
>
>I am only responding to your last statement since you missed my point
>about nested 3rd-party packets. The objects in question are generated
>on APRS-IS (or on Firenet) and therefore are nested by default when they
>hit RF. The Kenwoods do not support that so your work around does not
>accomplish what you claim.
Okay, I see. This is of course different for Items and Objects created by
SAR on RF. But I see for Items created on Firenet or APRS-IS I see that
they will not show up on the Kenwoods.
The point is however to find a way compatible with the Kenwood APRS defacto
standard. Using the APRS 1.0 compressed position Objects and Items are not
a solution for this either.
There is still a solution for this. The reason a 3rd party header must be
used on RF is because different case objects/items cannot be send directly
as source address; AX.25 will take it. But when the packet is constructed
by Firenet or by APRS-IS there is nothing against just putting the Object
or Item name in the source adres. So just send the Object or Item like this:
CompItem1>APXXX:!/4TLP"!!x{.CCompressed item
This kind of packet is not a problem on Firenet or APRS-IS. Better yet, it
is compact!
After transmission by he IGATE it looks like this on RF:
IGATE>APRS,PATH:}CompItem1>APXXX,TCPIP,IGATE*:!/4)TLP"!!x{.CCompressed item
In short:
- When generating the object on RF use the 3rd party header trick
- When generating the object outside RF just use the source call
Maybe the destination call could be special to see that it is an item or
object. Bob already told that there is no real differenc between stations
and objects, so this would be in line with that.
Agreed that none of these solutions are very nice, it is a hack, but it is
compatilble with the Kenwood APRS defacto standard.
Kind regards,
Henk.
----------------------------------------------------------------------
Subject: Re: question about possession of an object.
From: "Spider" <spider@rivcom.net>
Date: Sun, 13 Jun 2004 14:48:50 -0700
X-Message-Number: 15
----- Original Message -----
From: "Jeff King" <jeff@aerodata.net>
>..that the only tracker that supports APRS
>Compressed posits, AFAIK, is the OpenTracker with one of its APRS
compatible
>modes.
I might add they work pretty good in that mode too! The added Temp and
voltage readings are very cool too!!!
Jim, WA6OFT
----------------------------------------------------------------------
Subject: waterproof/underwater APRS
From: WB4GQK@aol.com
Date: Sun, 13 Jun 2004 21:13:14 EDT
X-Message-Number: 16
Hi Jim,
Well I can talk with you regards marine VHF radios being able to transmit
in the ham bands. None exist! On the other hand it is possible to link any
DSC equipped Marine VHF radio to a APRS application and transmit at least
position reports. You will certainly be restricted to a MMSI ( Maritime
Mobile System Identification) as far as station identification is concerned
rather than a ham callsign.
In some respects DSC (Digital Selective Calling) is similar to APRS in as
much as you can direct your transmission to whomever it may concern, or to
a specific MMSI and guess what? If you do direct a transmission to a MMSI
and that station receives the data, it will send you an ACK! As is the case
with APRS the DSC system can also send and receive short terse messages.
Now let me be very specific about one point. Even if you have a ham VHF
receiver that can listen on the Marine DSC channel you will not be able to
decode the transmission with standard APRS software simply because the
format of the transmitted signal is quite different than the APRS format.
Conversely if one transmitted an APRS data string on a Marine VHF not one
other vessel equipped with a Marine VHF DSC radio would be able to decode
the information.
In the marine field this ability to transfer precisely the same type of
data as APRS is called, Automatic Identification System, AIS. ALL
commercial vessels over 400 tons are required by International Law to carry
a VHF transponder that operates on the Marine frequencies 161.975 and
162.025 MHZ. For over a year I have been attempting to work with the ITU
specifications; ITU-RM.1371-1 and IEC61993-2 to extract from their ten bit
code only the position, course and speed and plot an icon on my APRS
screen. I am close but still a way to go.
Why bother? Well you have to think about the VHF range these large ships
can cover. Easily 35-40 miles THAT'S TWICE THE RANGE OF A SMALL BOAT'S
RADAR! You don't have to be a rocket scientist to see the advantages of
knowing where these vessels are before you can see them.
73 Jim
----------------------------------------------------------------------
Subject: Re: waterproof/underwater APRS
From: "Rich Garcia" <k4gps@bellsouth.net>
Date: Sun, 13 Jun 2004 22:44:17 -0400
X-Message-Number: 17
I have never seen a waterproof PL-259 unless you pack the thing with 5200
(3M Brand RTV) and tape, a few pounds of it! I actually think I have heard
that there is not such a beast on the market. The best thing to use are real
waterproof RF connectors as in BNC, Type N, or DIN. DIN is a bit huge for
such an application so I would think BNC and N would be better. Personally I
like N connectors over BNC, they are easier to install.
Rich
---
END OF DIGEST
Read previous mail | Read next mail
| |
