| |
ZL3AI > APRDIG 22.08.03 19:02l 125 Lines 4260 Bytes #999 (0) @ WW
BID : 1807-ZL3AI
Read: GUEST
Subj: TAPR Digest, Aug 19, 5/5
Path: DB0FHN<DB0RGB<DB0MRW<OK0PKL<OK0PHL<OK0PBB<OK0PHK<OK0NAG<OK0PPL<DB0RES<
ON0AR<WB0TAX<N1UAN<ZL2BAU<ZL3VML
Sent: 030821/1200Z @:ZL3VML.#80.NZL.OC #:6908 [Chch-NZ] FBB7.00i $:1807-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: APRSfl.net - fourth.aprs.net - status update...
From: "Jon Anhold" <jon@snoopy.net>
Date: Tue, 19 Aug 2003 21:32:55 -0400
X-Message-Number: 22
Hearing Steve mention that third is no longer useful as it's connect limit
is too low twice now, I have shut it off.
Enjoy.
-j
----------------------------------------------------------------------
Subject: Interface Idea for old KPC-3's
From: "Jacob Tennant" <k8jwt@adelphia.net>
Date: Tue, 19 Aug 2003 21:48:05 -0400
X-Message-Number: 23
I was thinking about a simple PIC based interface to help out those of us
with the old KPC-3's to get the same functionality as a KPC-3+. If I am not
mistaken the two TNC's function the same except for the second data port for
GPS data.
My idea was basically a PIC based HSP type system whereas at a set interval
the PIC would switch the data in line to the TNC from the
computer/Palm/etc... to the GPS just long enough for the TNC's data buffer
to get a good $GPRMC sentencs then return the line back to normal use.
For what little I know about PIC's this should be very easy for it to do.
Comments, suggestions, ideas ????
Jacob Tennant K8JWT
PS: Yes I am cheap and don't want to/ can't, spend the money on a new TNC
right now...
----------------------------------------------------------------------
Subject: Re: Interface Idea for old KPC-3's
From: David VanHorn <dvanhorn@cedar.net>
Date: Tue, 19 Aug 2003 22:12:33 -0500
X-Message-Number: 24
At 09:48 PM 8/19/2003 -0400, Jacob Tennant wrote:
>I was thinking about a simple PIC based interface to help out those of us
>with the old KPC-3's to get the same functionality as a KPC-3+. If I am not
>mistaken the two TNC's function the same except for the second data port for
>GPS data.
>
>My idea was basically a PIC based HSP type system whereas at a set interval
>the PIC would switch the data in line to the TNC from the
>computer/Palm/etc... to the GPS just long enough for the TNC's data buffer
>to get a good $GPRMC sentencs then return the line back to normal use.
>
>For what little I know about PIC's this should be very easy for it to do.
If you must use a pic.. :)
I'd start with a mega-8 AVR.
Picture the uart ports as TxA, RxA, TxB, and RxB.
Take an I/O pin and put it on the GPS.
Put RxB on the TNC
Also TxB
TxA goes to the PC
As RxA
Normally, RxB data just passes through, in a pair of circular buffers, to
TxA Same for RxA and TxB.
The bit-banged port runs with a uart and a timer, since it's receive only.
You buffer up an NMEA sentence, keep replacing that with new data as it's
available. Make one buffer per sentence. When you see the ^E in the stream
to the TNC, you "eat" it. It never reaches the TNC. Now you start scanning
the buffer transfer outbound to the PC, and when you've just sent a <CR>
(or <CR><LF>) then you insert the data in the GPS buffers, and resume
normal flow as soon as you can.
You'd have to rely on hardware handshake back to the TNC, and you'd want
the PC port to run fast. The AVR uarts love high speed, I'm using them at
115200 with no problems at all, and very little CPU overhead since the AVR
has vectored interrupts.
The ring buffers are easy. The store routine stores data at the head
pointer, increments the stored byte count, and increments the head pointer.
The retreive routine gets data, increments the tail pointer and decrements
the stored byte count. The handshaking works off the stored byte count
compared to the buffer size. For buffers < 256 bytes, the implementation is
easy.
If you like I can send you AVR routines for the ring buffers.
You'd need four.
The M8 has fairly large internal ram, and it's all "flat" address space, so
no "page" problems to deal with.
----------------------------------------------------------------------
Subject: Black Box retrieval tool (Was: Big Brother)
From: "Mark Fellhauer" <sparkfel@qwest.net>
Date: Tue, 19 Aug 2003 22:12:33 -0500
X-Message-Number: 25
According to the South Dakota State Highway Patrol, this is the device they
use to extract data from automobile black boxes.
http://www.vetronix.com/diagnostics/cdr/
Some of the other products on their web site look pretty cool.
73,
Mark
KC7BXS
---
END OF DIGEST
Read previous mail | Read next mail
| |
