| |
ZL3AI > APRDIG 12.05.04 10:27l 217 Lines 8044 Bytes #999 (0) @ WW
BID : 3223-ZL3AI
Read: GUEST
Subj: TAPR Digest, Apr 23, 6/10
Path: DB0FHN<DB0RGB<DB0MRW<DB0SON<DB0SIF<DB0EA<DB0RES<ON0AR<ZL2BAU<ZL2BAU<
ZL3VML
Sent: 040512/0740Z @:ZL3VML.#80.NZL.OC #:23802 [Chch-NZ] FBB7.00i $:3223-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Compromise proposal (was: Re: The APRS-WG and spec improvements.)
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Fri, 23 Apr 2004 21:40:33 +0200
X-Message-Number: 34
At 09:58 22-4-2004 -0700, Curt, WE7U wrote:
>I have no problem with the datum thing, although I'd rather see
>WGS84 used across the air in all cases. I'll go with the
Maybe we can have a nice compromise here: Allow ASCII APRS posits and MIC-E
to be in the predominat datum that is current for some country. Make WGS84
mandatory for the high precision base-91 format. That way you only make the
datum mandatory in conjuction with a format with a high precision and leave
is open for the "recreational" formats where a high precision is less
important.
So if you want high precision in a defined datum use base-91, in all other
cases use one of the other less accurate formats and live with the
inacuracy of not knowing the datum.
Does that sound like something we can live with and still keep the
compatiblity?
Kind regards,
Henk.
----------------------------------------------------------------------
Subject: SW controled TH-D7 display (Was: Re: Everlasting discussions, Smart
Move/Transition?)
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Fri, 23 Apr 2004 22:52:36 +0200
X-Message-Number: 35
At 10:27 23-4-2004 -0400, wes@johnston.net wrote:
>Has anyone been able to make the display change from the serial port at all?
I think my message a few days ago was either lost or discarded because of
its length. Although a hack there is a way to show feedback my manipulating
the memory name. I even provided the commands.
I used this trick in a program called "TH-D7E Tool" which can be found at
http://www.homepages.hetnet.nl/~pe1dnn/#TH-D7E. This DOS program to save
and restore almost all settings of the TH-D7, uses this to display "PLEASE
WAIT" during the restore phase.
You can make it work transparently from software, just reserve memory
channels 198 and 199 for this. Procedure in software goes like:
1) Memorize the band settings (VFO or memory, and if the latter also the
location)
2) Copy the band A state to memory 198
3) Copy the band B state to memory 199
4) Switch to 198 for band A and 199 for band B, your QRG (including split,
CTCSS or whatever) should remain unchanged now
5) Switch to show Names for the memory channels if not already switched on
6) Output what you have to say to the 198 and 199 memory names (2 lines of
data)
7) Allow time for the user to read
8) Restore the original band A and band B settings and clean the memory
names on 198 and 199 for next time.
It's a bit of coding, but it should be able to use the TH-D7's display to
provide feedback without the need for the user to touch anything.
If you look in the file saved by the TH-D7E Tool you see all the commands
the TH-D7 knows, these can also be found on the web.
For supporting other protocols: the TH-D7 can receive in KISS mode, only
for transmission you have to temporarly switch back to TAPR mode. Although
limited, there is still a lot that can be done in software left. Finding
out robust sequences is a bit of a puzzle, but it is feasible.
Kind regards,
Henk.
----------------------------------------------------------------------
Subject: Re: Gaps in gated weather data
From: "Scott Miller" <scott@opentrac.org>
Date: Fri, 23 Apr 2004 14:02:41 -0700
X-Message-Number: 36
>Not true, you can get it with
I figured there had to be a way. What's the difference between raw.cgi and
rawwx.cgi?
>the periods, but this is direct internet data. Is there any other station using
>your your IGate which can be looked at to verify that the IGate is functioning
>during these periods?
KE6DKY-9, KD6LAY, KF6EWT, WA6YLB, K6YDW
>The episodes yesterday and today seem to be within a few hours, perhaps there
is>a solar heating problem. Another possibility is that something is wrong in
the
I've got all the raw packets logged locally though. They're making it at
least as far as my IGate. I don't think I intended to set it up that way,
but I've got 246 megs of data comprising every packet heard locally for
about 6 months.
>The position packet is indeed incorrect, Byon or one of his users would need to
>answer, but I suspect it is just as the TNC stand-alone weather stations or
>digis must enter the packet manually.
That's my guess as well. Unfortunately it's a bit of a drive to this
particular mountaintop and the owner probably won't have a chance to fix it
for a bit.
I'll keep an eye on things at this end and see if I can identify any other
problems.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: Everlasting discussions, Smart Move/Transition?
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Fri, 23 Apr 2004 22:57:43 +0200
X-Message-Number: 37
At 13:19 23-4-2004 -0400, Robert Bruninga wrote:
>Why not just have the PIC check the list every 30 seconds.
>There is not much in APRS that should be that time
>critical that a few seconds would make a difference if
>it added new fundtionality... Bob
With the "AI 1" command the TH-D7 spits out newly received data from the
list all by itself, no need to poll any list at all! The only problem is
that the data which the TH-D7 does not recognize will never enter the list
in the first place....
Kind regards,
Henk.
----------------------------------------------------------------------
Subject: Kenwood D700 remote mounting?
From: John Ackermann N8UR <jra@febo.com>
Date: Fri, 23 Apr 2004 17:19:21 -0400
X-Message-Number: 38
This may be a few degrees off topic, but I need some info about remote
mounting the Kenwood D700A. I'm considering swapping out a TM-V7A that I
have installed with the remote mounting kit. Can the D700A use the same
cable and control head mounting bracket, so that I can just swap out the
control head and radio, or is the remote cabling and mounting different?
Thanks,
John
----------------------------------------------------------------------
Subject: RE: Everlastit pete@ae5pl.net and I will work with you to
track down where and how these packets are disappearing.
Thanks.
73,
Pete Loveall AE5PL
pete@ae5pl.net
----------------------------------------------------------------------
Subject: Re: Everlasting discussions, Smart Move/Transition?
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Fri, 23 Apr 2004 17:27:56 -0400
X-Message-Number: 41
>>>"Scott Miller" <scott@opentrac.org> 4/23/04 3:24:11 PM >>>
>Bob said about an external PIC upgrade for the KWD:
>>Why not just have the PIC check the list every 30 seconds.
>>There is not much in APRS that should be that time
>>critical that a few seconds would make a difference if
>>it added new functionality... Bob
>
>Can I quote you on that, Bob? I've gotten blasted before
>for suggesting things that would introduce any kind of delay
>into the system.
Sure. BUT, I would have hoped that you would have understood the
difference between introducing drastic delays in the *on-air-network* (that
you proposed) that would have been disasterous, compared to the individual
delay I mentioned above that might only delay a few specialized new
upgrade packets to a single user's display and-I-quote "if it added new
functionality" unquote.
>How much delay IS acceptable in the system?
>What should the design goal be?
Well, first you have to understand the difference between an end user
display delay to add functionality compared to adding delays that would
muck up the on-air protocol and distribution network.
But its a good question. For the display case, we are onnly talking about
how often the external PIC would query the radio for something new to
process and look for any new protocol items that we might want to display
differently.. That is a tradeoff betweeen keeping the radio CPU too busy
so that it starts to degrade response...
Bob
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
