| |
ZL3AI > APRDIG 23.06.03 09:21l 264 Lines 9205 Bytes #999 (0) @ WW
BID : 1518-ZL3AI
Read: GUEST
Subj: TAPR Digest, Jun 20, 1/2
Path: DB0FHN<DB0RGB<OK0PPL<RZ6HXA<SP7MGD<7M3TJZ<ZL2TZE<N1UAN<ZL2BAU<ZL3VML
Sent: 030622/1330Z @:ZL3VML.#80.NZL.OC #:2889 [Chch-NZ] FBB7.00i $:1518-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
TAPR APRS Special Interest Group Digest for Friday, June 20, 2003.
1. APRS Short Standard
2. Re: WinAprs and PMapping 5.0
3. Re: Pmap 5.0 and WinAPRS
4. WinAPRS Support for Server Filters?
5. Re: WinAPRS Support for Server Filters?
6. aprsd memory usage
7. PCsat Test
8. APRS Traffic Speed indicators
9. Wx problem
10. Re: Wx problem
11. Re: WinAPRS Support for Server Filters?
12. Re: WinAPRS Support for Server Filters?
13. Re: WinAPRS Support for Server Filters?
14. Re: WinAPRS Support for Server Filters?
----------------------------------------------------------------------
Subject: APRS Short Standard
From: "Andrew Rich" <andrew.rich@bigpond.com>
Date: Fri, 20 Jun 2003 21:50:00 -0700
X-Message-Number: 1
Just experimenting with a few ideas for storing location info into a memory
stick and short APRS pos TX
1. example 2734.45S15306.22E
2. Strip off dec point - you know the last two in are where the dec point
goes
3. 273445S1530622E
4. each number is going to be 0-9 that requires 4 bits
5. you can stuff two digits into one 8 bit number and split at rx end
6. 2 = 0010 7=0111 3=0011 4=0100 4=0100 5=0101 1=0001 5=0101 3=0011 0=0000
6=0110 2=0010 2=0010
7. That makes 13 x nibbles, you need 14xnibble to make up 7 bytes.
8. Use the last nibble to store S/N E/W eg 0100 = NW 0000=SE 1100=NW 1000=
NE
At the receiver
00100111 00110100 01000101 00010101 00110000 01100010 0010 0000
2 7 3 4 4 5 1 5 3 0 6
2 2 SE
Go in 4, add a dec point, go in 2. add the N/S bit, go in 3, add dec, go in
2, add E/W
2734.45S15306.20E
Ideas ?
This seems to fit.
----------------------------------------------------------------------
Subject: Re: WinAprs and PMapping 5.0
From: Mark Sproul <msproul@jove.rutgers.edu>
Date: Fri, 20 Jun 2003 09:46:54 -0400
X-Message-Number: 2
This is an on-going issue, I had to do this in order to get the maps
to register properly. I have been talking to Prec-Mapping about how
to fix it but have not been able to make it work properly yet.
Mark Sproul
At 6:34 PM -0400 6/19/03, John Thurston wrote:
>I am able to pull PMap up within the WinAprs program but I cannot get a
>full screen but only half of the PMap. Is there a fix for this so that I
>can obtain a full screen? I had no problems when I was utilizing the PMap
>3.0 version...
>
>Thank You
>John/N0MEQ
------------------------------------------------------------------
Mark Sproul |
http://ecs.rutgers.edu |
msproul@jove.rutgers.edu |
Manager - Engineering Computing Services | 732-445-3121
Rutgers University School of Engineering |
Eng D111 |
------------------------------------------------------------------
----------------------------------------------------------------------
Subject: Re: Pmap 5.0 and WinAPRS
From: Mark Sproul <msproul@jove.rutgers.edu>
Date: Fri, 20 Jun 2003 11:36:56 -0400
X-Message-Number: 3
I received this question directly but thought the question was worth
sharing to the sig.
Robbie
PMap is implemented using an OCX under the Windows environment. If you use
a Microsoft envirionment such as Visual basic or Visual C++ utilizing MFC,
then OCX support is built in and the programmer has to do very little to
make it work.
I do not use Microsoft compilers, as everyone is surely aware, we have
versions for Windows, Mac and Unix. It is all the same source code using
generic C/C++ compilers (CodeWarrior on Mac and Windows, GCC on unix). This
environment does directly support OCX modules and therefore the ability to
access them is much more difficult. I have worked with developers from PMap
to try to resolve this but the version 5 OCX does not behave the same as
the previous OCX when returning screen lat lon info.
I am still working on trying to resolve this issue.
Mark Sproul
>I appreciate what you have done for us Mark, and I hope you take no
>offense to this question, ok? :-)
>
>How is Roger Barker doing it differently in his UI-View32.
>Obviously, I don't have any of the programming experience any of you
>have. I for would rather use WinAPRS over any of the other client
>programs but for this one issue..
>
>Tiger maps for me isn't the answer..
>
>Thanks again and hope this can be straightened out..
>
>Robbie, wa9inf
------------------------------------------------------------------
Mark Sproul |
http://ecs.rutgers.edu |
msproul@jove.rutgers.edu |
Manager - Engineering Computing Services | 732-445-3121
Rutgers University School of Engineering |
Eng D111 |
------------------------------------------------------------------
----------------------------------------------------------------------
Subject: WinAPRS Support for Server Filters?
From: "Phil Pacier, AD6NH" <ad6nh@arrl.net>
Date: Fri, 20 Jun 2003 11:22:27
X-Message-Number: 4
Mark/Keith, will WinAPRS ever support logon messages to a server for filter
definitions? There are other Windows platform APRS clients that support
automatic server logon messages. Currently, WinAPRS users must manually
enter in the filter paramaters and send a message to the server. I have
several WinARPS users connected to my server who would like to make use of
port 14580 but would like to have the automatic filter messaging supported
in the software. Any plans to put this into WinAPRS? Thanks! 73
Phillip Pacier - AD6NH
http://www.aprsca.net
----------------------------------------------------------------------
Subject: Re: WinAPRS Support for Server Filters?
From: Dennis Hudson <n2lbt@n2lbt.com>
Date: Fri, 20 Jun 2003 13:37:30 -0400
X-Message-Number: 5
If it gets added it would be good to have it be port agile. Port 14580
is the default raw TNC port on aprsd. aprsd's omniport portfilter
default is 14600.
Dennis, N2LBT
--
Dennis, N2LBT
Sysop aprsdALY IGate
http://www.n2lbt.com
n2lbt@n2lbt.com
----------------------------------------------------------------------
Subject: aprsd memory usage
From: "Scott Miller" <scott@opentrac.org>
Date: Fri, 20 Jun 2003 10:55:13 -0700
X-Message-Number: 6
I was just looking over the memory usage on my primary Linux box, and I see
that aprsd is still the biggest memory hog, using about 80 megs of RAM for
seven processes. I'm not really sure why it needs seven processes, since
I've got all of the server ports disabled. It should only be gating between
AX.25 and a single remote hub. Apache, on the other hand, only uses about
3.3 megs for four processes, and it's far more sophisticated than aprsd.
It's not a huge problem - the server's got 384 megs of RAM - but it's
annoying. Does anyone know why it takes so much memory?
Scott
N1VG
----------------------------------------------------------------------
Subject: PCsat Test
From: Bob Bruninga <bruninga@usna.edu>
Date: Fri, 20 Jun 2003 15:57:41 -0400 (EDT)
X-Message-Number: 7
Today's PCsat test.
For fun I digipeated 2 messages via PCsat while it was over the middle of
the USA on 144.39. If your mobile was on at 1530 EDT, it probably made it
to your MSG list (anywhwere in the USA). Remember, we have this
capability to hit every APRS radio in the USA at once. This is a
powerful feature...
The uses to date have been for a few special HAM travelers in remote areas
(Alaska, etc) to be able to digipeat back into the terrestrial system
directly on 144.39 without having to rely on IGates on 145.825. Anyone in
unique situations can request authorization.
Maybe during Field Day, we could use it to send some one-way messages to
everyone? We cannot send the ARRL message (because isn't it normally a
full paragraph?) APRS is best suitable for one liners...
de WB4APR@amsat.org, Bob
PCsat WEB page http://www.ew.usna.edu/~bruninga/pcsat.html
----------------------------------------------------------------------
Subject: APRS Traffic Speed indicators
From: Bob Bruninga <bruninga@usna.edu>
Date: Fri, 20 Jun 2003 16:22:44 -0400 (EDT)
X-Message-Number: 8
APRS has always had an ICON in the protocol for indicating traffic speed
past a point on the Highway so that commuters could look ahead and see what
was coming..
But we have never developed the sensors. Now, 8 years later, most cities
already have radars on critical bridges and overpasses and collect this
info live and make it available live.
All we need is someone to write the code to automatically interrogate these
local state sites and then output the speed ICONs locally on APRS.
Todd, WB4HAI has found the WEB site in MD. There are two approaches:
1) Use the URL and try to "mine" the data from the site as is (and have to
update it with any changes to the WEB page)
2) Ask the state if there is a machine readable standard that they would
put out...
ANyway, a FUN project!
Here is the info on Maryland's site:
---------- Forwarded message ----------
From: "Bruner, Todd" <tbruner@dsrnet.com>
Maryland Traffic Site: http://www.chart.state.md.us/travinfo/speedData.asp
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
