| |
ZL3AI > APRDIG 23.10.03 04:32l 316 Lines 12497 Bytes #999 (0) @ WW
BID : 2178-ZL3AI
Read: GUEST
Subj: TAPR Digest, Oct 20, 1/4
Path: DB0FHN<DB0RGB<DB0MRW<DB0ERF<DB0FBB<DB0GOS<ON0AR<ON0AR<IK1ZNW<ZL2TZE<
ZL3VML
Sent: 031022/1233Z @:ZL3VML.#80.NZL.OC #:10965 [Chch-NZ] FBB7.00i $:2178-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
TAPR APRS Special Interest Group Digest for Monday, October 20, 2003.
1. RE: OpenTracker
2. Re: OpenTracker
3. RE: APRS Linux digi, was: Re: DigiNed, was: Re: Take Control of your DIGI
part 4
4. Accuracy of Garmin GPS devices?
5. Re: Accuracy of Garmin GPS devices?
6. RE: Accuracy of Garmin GPS devices?
7. RE: Accuracy of Garmin GPS devices?
8. run time a car battery....
9. Re: Smart DIgis and the new Paradigm
10. RE: Accuracy of Garmin GPS devices?
11. RE: run time a car battery....
12. D700 / WinAPRS / tracker compatibility?
13. New APRSCA Website
14. Mic-E hardware
15. RE: TH-D7 Question
16. Re: Smart DIgis and the new Paradigm
17. Re: D700 / WinAPRS / tracker compatibility?
18. Re: Accuracy of Garmin GPS devices?
19. IGate Support on Filtered and Regional Server Ports
20. NO INFO
21. Re: D700 / WinAPRS / tracker compatibility?
22. Re: Smart DIgis and the new Paradigm
23. RE: OpenTracker
24. Re: Smart DIgis and the new Paradigm
25. Isabelle objects???
----------------------------------------------------------------------
Subject: RE: OpenTracker
From: "Scott Miller" <scott@3xf.com>
Date: Sun, 19 Oct 2003 23:03:15 -0700
X-Message-Number: 1
Current PCB prototype next to a TinyTrak3 for comparison:
http://www.opentrac.org/tracker3.jpg
Missing a couple of parts until my next Digi-Key order comes in... this is
the first version to use a crystal rather than a canned oscillator. If I
can find a suitable ceramic resonator I might use that instead.
The next revision will have a pin header for access to the extra I/O lines.
Building small double-sided boards by hand is a pain, though. As a
concession to hand solderability this version has no vias, but it's still
hard to get all of the top side connections without through plating.
I'll make a few available for beta testing once I've got a basic
configuration program written, and more importantly a serial bootloader
that'll allow end user firmware upgrades.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: OpenTracker
From: "Scott Miller" <scott@3xf.com>
Date: Sun, 19 Oct 2003 23:24:15 -0700
X-Message-Number: 2
>You could measure deviation.... A full signal which saturates the a/d
>would be considered white noise, and anything less than saturation would be
>a valid signal. Using this method , you don't have to decode a
The A/D reference voltage is fixed at +5v... so I don't think it's going to
saturate it. But yeah, it should still make for a more reliable energy
detect. You still need the pot (or a couple of resistors) to provide the DC
bias for the signal... or at least a diode to protect it from negative
voltages, I guess.
>Force POSIT/ID is great idea... maybe double duty the pin to a "hold off"
For APRS use it might stick an object at the current location. OpenTrac
provides an 'ident' flag that's intended to work like the ident button on a
transponder, causing your icon to 'bloom' on the screen or otherwise call
attention to itself.
>Power to radio pin (before PTT is great power management)
A separate signal to power up the radio with a pre-PTT delay, is that what
you're asking for? I wish my uWeather station did that... it'd save me some
solar panels. Maybe it could be set to a pulse, to be wired into a radio
with a soft power button like the DJ-S11?
>I vibration sensor input would be slick.... unit is in low power mode until
>it senses vibration, then it powers up the GPS and radio.
Yeah, and everyone in California's going to key up at the same time whenever
there's an earthquake. =] I had a couple of miniature accelerometers around
here... unfortunately they're a bit TOO miniature and I haven't been able to
find them for awhile.
>The mini-6 would be a problem... unless it was a PCB mount MALE plug... I
>don't know of any male to male mini6 cables... and they're really hard to
Cables for KVM switches should do it, I think. The RJ-12 is probably easier
to deal with, though.
Scott
N1VG
----------------------------------------------------------------------
Subject: RE: APRS Linux digi, was: Re: DigiNed, was: Re: Take Control of your
DIGI part 4
From: "Scott Miller" <scott@3xf.com>
Date: Sun, 19 Oct 2003 23:26:01 -0700
X-Message-Number: 3
>Haven't tried it yet however heard Mosquito is verrry small.
I decided to avoid the micro-distribution thing entirely... I just put a 128
meg card in the box and loaded a stripped-down install of Debian. Working
great so far, but I haven't hooked a packet modem up to it yet.
Scott
N1VG
----------------------------------------------------------------------
Subject: Accuracy of Garmin GPS devices?
From: "Darryl Smith" <Darryl@radio-active.net.au>
Date: Mon, 20 Oct 2003 16:41:07 +1000
X-Message-Number: 4
People
Does anyone apart from me have suspicions on the accuracy of Garmin GPS
devices, when they say that they have valid data? I am referring here to a
Garmin GPS-16
I have just done a field test, and it appears that the GARMIN waits for
about 15 seconds or so after losing lock before it indicates to the user
that the data might be suspect. During this time, the NMEA data continues to
come out the port with an 'A' indicating valid data, and static positions.
I am attempting to convince a client to go with an embedded Motorolla, and
have found that the Motorolla tends to be quick with indicating lack of
lock, whilst the Garmin is slow.
Darryl
---------
Darryl Smith, VK2TDS POBox 169 Ingleburn NSW 2565 Australia
Mobile Number 0412 929 634 [+61 4 12 929 634 International]
www.radio-active.net.au - www.radio-active.net.au\tracking
----------------------------------------------------------------------
Subject: Re: Accuracy of Garmin GPS devices?
From: "Andrew Rich" <vk4tec@hotmail.com>
Date: Mon, 20 Oct 2003 18:48:55 +1000
X-Message-Number: 5
yes Darryl, I too have seen this behaviour, they seem to have a weird
hysteresous loop when it comes
to going in and out of lock.
Is that a big problem ?
----------------------------------------------------------------------
Subject: RE: Accuracy of Garmin GPS devices?
From: "Darryl Smith" <Darryl@radio-active.net.au>
Date: Mon, 20 Oct 2003 19:35:48 +1000
X-Message-Number: 6
It is only a big problem if you are attempting to get a client to allow you
to supply a Garmin GPS rather than a Motorola M12, and he points out to you
that the Garmin unit lost lock three times only during a trip, and the
Motorola lost lock 25 times...
Darryl
---------
Darryl Smith, VK2TDS POBox 169 Ingleburn NSW 2565 Australia
Mobile Number 0412 929 634 [+61 4 12 929 634 International]
www.radio-active.net.au - www.radio-active.net.au\tracking
----------------------------------------------------------------------
Subject: RE: Accuracy of Garmin GPS devices?
From: "Bill Diaz" <william.diaz@comcast.net>
Date: Mon, 20 Oct 2003 07:34:04 -0500
X-Message-Number: 7
Darryl,
I noticed some inconsistancies after losing a WAAS satellite with a Garmin
Etrex.
>I am attempting to convince a client to go with an embedded
>Motorolla, and
>have found that the Motorolla tends to be quick with indicating lack of
>lock, whilst the Garmin is slow.
I have 2 fixed Motorola OnCores that are regularly losing lock due to
interference I believe. I can confirm that they immediately indicate loss
of signal/sync while the Garmin continues to show a 3D fix for a short
time.
Bill
----------------------------------------------------------------------
Subject: run time a car battery....
From: Wes Johnston <wes@johnston.net>
Date: Mon, 20 Oct 2003 10:08:51 -0400
X-Message-Number: 8
For those who may be interested, a kenwood d700 and garmin 162 gps will run
for 31 hours beaconing every 30 minutes before exhausting a car
battery. Always fun to learn such things on a monday morning.
Wes
----------------------------------------------------------------------
Subject: Re: Smart DIgis and the new Paradigm
From: Bob Bruninga <bruninga@usna.edu>
Date: Mon, 20 Oct 2003 10:34:49 -0400 (EDT)
X-Message-Number: 9
On Sun, 19 Oct 2003, Wes Johnston wrote:
>In order for our network hierarchy to work, all digipeaters must repond to
>RELAY and some to WIDE. If you alter the expected behavior of RELAY, then
>you are effectively cutting off one of my legs. Let me explain... I want a
>packet to bounce out three hops in the local RF network. At the first hop
>(direct to a WIDE digi), it is possible that my packet could be IGATED and
>never digipeated.
No, even if the IGate was in range of the same smart digi that heard the
packet, that digi must still digipeat it at least once. So you still get
the guarante of at least one full digipeat by at least one FULL function
digi.
1) If a home RELAY picked it up, then it would digi it to the next full
function digi.
2) If a full function smart digi heard it first, then it would DIGIpeat it
at least once or whatever it took to get to the IGate.
In both cases, your packet is guaranteed to get to the APRS Infrastructure
as defined to be the nearest full function DIGI and from there to the
nearest IGate.
>guess what.... a path of RELAY is what I had to use just incase I was out
>of range of a digi and happened to be in range of a home user.
No, you are not understanding the concept. Only full function smart digis
will make the change. A home station should NEVER change people's paths.
>This becomes a catch 22... a damned it I do, and damned if I don't.... If I
>don't use RELAY as my first hop, I may not get into the network, If I do
>use RELAY as my first hop, I have a better chance of getting into the
>network, but now my packet may be "stolen" away from RF or have it's path
>altered so that it does not reach my intended audience. This is a bad
>implementation of a good idea.
No, I think you are missunderstanding the concept. As I proposed it, the
mobile path startgin with RELAY will always guarantee you to be
digipeated by the first full function digi at least, and from there to the
first active IGate..
>Since smart digi's such as DIGINED can do preemptive digipeating, why not
>use a normal path of RELAY WIDE, and those who want to ensure their packets
>get dynamically routed to an IGATE just add IGATE to the end of their
>path.... so if I were to intend my packet to go out 3 hops
>omnidirectionally, I could use RELAY, WIDE,WIDE , but if I wanted it to get
>to an IGATE, I could use RELAY, WIDE,WIDE,IGATE and I would expect that
>along the way some smart digi would alter my path. Of course the first
>smart digi which saw IGATE in the path could preemptively alter the
>path. Meanwhile, I can use the existing "dumb" network infrastructure to
>get near a smart digi. And people wishing to NOT have their paths altered
>would still be using RELAY in the first hop. People who specifically
>include the word IGATE in their path are in effect saying that they desire
>their path be changed dynamically.
Yes, that is a viable approach. But could you also live with the way I
proposed that still guarantees deliver through the first real digi? The
advantage is that the additional hops (not needed most of the time) then
do not add QRM that is also not needed.?
>Also, if you are going to say that it's "legal" or "permissiable" to alter
>someone's path if they use RELAY in it (as everyone SHOULD do), then you go
>against the philosophy that we can't weed out stupid paths b/c the user
>_might_ just know what they are doing. All along you have objected to the
>network fixing things and pushed for user education... and now it appears
>that you are advocating forcing people to have their paths altered by the
>network... taking control away from the users.
No, this is the only exception. But maybe the advantage of cutting off
the unnecessary long path wheen an IGate is nearby is not worth adding
this additional "rule"... the alias of "IGATE" only has the minor
disadvantage of having an extra 7 bytes in every such packet, but you are
correct, that it does carry the user's intent, and so is proablay worth
it.
The difference is that the RELAY idea would enforce the filtering out of
unnecesary long paths and not depend on the users. Whereas the IGATE idea
is just the status quo and 90% of those that could use it would probably
never do it... Adding 7 bytes to every packet actually makes your
probabliity of success go down...
Bob, WB4APR
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
