| |
ZL3AI > APRDIG 13.06.04 09:07l 723 Lines 30202 Bytes #999 (0) @ WW
BID : 3450-ZL3AI
Read: GUEST
Subj: TAPR Digest, Jun 07, 6/7
Path: DB0FHN<DB0RGB<DB0MRW<DB0WUE<DK0WUE<DB0RES<ON0AR<IK1ZNW<I0TVL<HG8LXL<
VK4TTT<VK7AX<ZL2BAU<ZL3VML
Sent: 040613/0512Z @:ZL3VML.#80.NZL.OC #:25751 [Chch-NZ] FBB7.00i $:3450-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: '...I'll just take my ball and go home!"
From: Keith Allen <kallen2@bellsouth.net>
Date: Mon, 07 Jun 2004 16:31:23 -0500
X-Message-Number: 111
Here here :-)
Brian Riley (maillist) wrote:
>On 6/5/04 7:38 AM, <someone@somewhere.net> wrote:
>
>>2,999 of them signed off the sig a while back because of the BS. Which
>>is what I am going to do. 73.
>
>You know this is the third instance of this I have seen during this
>particular melee ... Usually each is followed by three more threats to leave
>in case anyone didn't notice the first few and beg them not to be hasty. My
>general reaction to these messages is "Good, don't let the door hit you in
>the butt, when it closes behind you!" It leaves more bandwidth for those of
>us who care. What's the matter didn't these people ever here of the Delete
>key or a 'killfile' ????
>
>I will say, once again, we all learn from these melees ... It gets stuff
>out in the open and discussed, no-holds-barred. Granted it would be tiresome
>if they went on for ever, but even the most cantankerous of the combatants
>has to take a 'nice'-break once in a while! ;-)
>
>Cheers ... 73 de n1bq
----------------------------------------------------------------------
Subject: Re: APRS Protocol - A Modest Proposal
From: "Scott Miller" <scott@opentrac.org>
Date: Mon, 7 Jun 2004 16:29:23 -0700
X-Message-Number: 112
>sticking point here. But, everyone involved in the opentrac side of this
>discussion doesn't seem to be telling everyone using APRS on 144.390mhz that
>tomorrow opentrac will take over. This particular event illustrates an issue
We're aiming for Thursday. I hadn't been planning on it, but according to
Bob I have the power to declare 20,000 APRS systems obsolete overnight, so I
figured I'd take advantage of that and make the official proclamation then. =]
>I think that an easy way to solve this would be to use a separate port for a
>new, slightly different structured stream of data that included the PID. I
>would think that the existing code could be easily used when the PID was F0,
>and when its not F0, you could do something specific to that protocol, archive
>it, or event drop it.
There might be some merit to carrying OpenTRAC data over the APRS-IS, but
that hasn't been the plan so far. The protocol already has a port number
reserved through IANA for its use on TCP and UDP. TCP mode should function
pretty much like the APRS-IS does now, but with a filtering syntax built in
from the start (though that's yet to be nailed down.) UDP mode should be
especially useful for LANs. What I DON'T want to do is start putting
random, special-purpose ports everywhere. You've got one well-know OpenTRAC
port (3855) to do everything. The APRS-IS seems well on its way to this
sort of configuration with the introduction of filtered ports, and I hope to
build on the concept.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: APRS Protocol - A Modest Proposal
From: "AE5PL Lists" <HamLists@ametx.com>
Date: Mon, 7 Jun 2004 18:30:31 -0500
X-Message-Number: 113
>-----Original Message-----
>From: Gregg G. Wonderly
>
>>Worse, the APRS IS could no longer be part of APRS. The APRS IS is
>>based upon the textual representation of packets used in converse mode,
>>and like converse mode, it has no way to tell a PID number. You would
>>have to completely trash the
>>APRS IS and start from scratch. Every client with internet connectivity
>>would have to be changed.
>
>I think that an easy way to solve this would be to use a
>separate port for a new, slightly different structured stream
>of data that included the PID. I would think that the
>existing code could be easily used when the PID was F0, and
>when its not F0, you could do something specific to that
>protocol, archive it, or event drop it.
Can't do that. You missed the statement "APRS-IS is based upon the
textual representation of packets". Inter-server and server-client
communications rely on lines to be terminated with a carriage return
and/or line feed. Since OpenTrak is a binary protocol, these characters
may occur anywhere in a packet. Beyond that, IGates and most APRS-IS
clients expect packets to have some semblance to APRS packets.
The current release of javAPRSSrvr prevents packets with unproto
starting with OPNTRK from passing. This is in keeping with Scott's
statement that "OpenTrak packets should not appear on APRS-IS". As in
the past, the server code has been modified to attempt to prevent lines
from misconfigured TNC's from passing through the server.
As Scott has stated, the OpenTrak protocol is NOT the APRS protocol.
The APRS-IS is designed to pass APRS packets. As such, it is not
designed to handle the binary packets of OpenTrak or any other protocol.
The ability to handle any packet type is a major design undertaking and
is non-trivial unless we want to do this every time someone comes up
with a new protocol to pass.
You can complain that "gee, that was short sighted", but your complaints
are meaningless. The APRS-IS was established to carry APRS packets.
Period. Otherwise, it would have been called AX25-IS or something like
that. It doesn't mean that an AX25-IS can't be designed. But if one
is, it should have a lot of consideration for all of the protocols AX25
can pass and should allow APRS-IS servers to connect to it
transparently. This is no small task but one that is being looked into
by a number of qualified individuals.
As I said before, it would be much more beneficial to the entire APRS
and OpenTrak communities if the pundits on this SIG stick to Bob's and
Scott's statements that APRS and OpenTrak are 2 different protocols.
They have some similar functions but also have dissimilar functions.
Quit trying to find ways to merge the two, either on RF (remember back
in the days of IP on RF, BBS's, and nodes were all run on different
frequencies for a reason) or on the Internet.
Personally, I am sick and tired of hearing the bickering about OpenTrak
vs. APRS on this SIG. If I am not mistaken, this is an APRS SIG, not an
OpenTrak SIG. Scott, start up your own SIG and take the discussions
about OpenTrak there. Let's get back to talking about APRS on this SIG.
73,
Pete Loveall AE5PL
mailto:pete@ae5pl.net
----------------------------------------------------------------------
Subject: NBAA Intl Ops, Region I: North America > Expect GPS Outages in Canada
June 2004
From: Gerry Creager N5JXS <gerry.creager@tamu.edu>
Date: Mon, 07 Jun 2004 18:38:41 -0500
X-Message-Number: 114
Just saw this while perusing the NBAA news. Canada will be performing
some jamming exercises and public access to GPS may be affected.
<http://web.nbaa.org/public/ops/intl/nam/gps200406.php>
--
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
Page: 979.228.0173
Office: 903A Eller Bldg, TAMU, College Station, TX 77843
----------------------------------------------------------------------
Subject: RE: How about making OpenTrak part of APRS SPEC?
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Mon, 07 Jun 2004 19:48:03 -0400
X-Message-Number: 115
>>>Henk de Groot <henk.de.groot@hetnet.nl> 6/7/04 5:45:16 PM >>>
>Good, so occasional nightly updates to update a
>digipeater using TCP/IP will not do any harm then and
>also the few packets from a hand full of programmers
>experimenting with OpenTrack can be sustained easily
>in the big ocean of APRS packets.
No, I didnt say that at all. You aren't listening. I say repeatedly that
BINARY on the APRS channel will cause problems. We all TELL YOU over and
over agian, and you all complain over and over again, that APRS is not
perfect. Thus IT WLL HAVE PROBLEMS when you transmit BINARY on the
existing nationally declared APRS channel.
Right or wrong, spec or no spec, IT WILL CAUSE PROBLEMS, and these problems
will NEVER be completely eliminated becaues APRS users RARELY upgrade and
NEVER 100%.
Thus we are:
1) Telling you again, that BINARY WILL CAUSE PROBLEMS.
2) We know (and you know) that all users will not upgrade even if we
provide our best attempts at a fix. and thus we can never be
in-vulnerable.
3) We are ASKING you to not send binary on a channel that is KNOWN to have
problems with it and where BINARY is not welcome and never hase been
welcome.
As gentlemen, your insistance that you are going to send it anyway, does
not seem to be in the amateur radio spirit of not causing willful
interference...
Bob
----------------------------------------------------------------------
Subject: RE: Introducing "OPENAPRS"
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Mon, 07 Jun 2004 19:53:32 -0400
X-Message-Number: 116
BS and propaganda, jeff.
Im not wasting my time any further on your
twists and distortions... Bob
----------------------------------------------------------------------
Subject: Re: Kenwood APRS radio...
From: "Gregg G. Wonderly" <gregg@skymaster.cytetech.com>
Date: Mon, 07 Jun 2004 18:56:55 -0500
X-Message-Number: 117
>If I were making such decisions at Kenwood, I doubt I would have
>stuck around this long.
>
>As a quite happy D700 owner, it is truly sad to see the hatred of
>us out there... I never knew I was in league with the evil empire.
I own a THD-7A and I used it heavily until the serial port receptors broke due
to pluging and unpluging my GPS and serial cable. I need to send it in for
repair. I had been repairing it myself, but the last go round, I did something
that has made the radio inoperable.
I think that some people are imagining that somehow OpenTrac will replace APRS
without their control. If APRS users become the minority because there is a
wealth of new opentrac equipment and software, then that is the market
speaking. If, on the other hand, opentrac is never available to enough
people, then it will just stay in a quiet corner as a way for embedded
telemetry systems to be created easily for simple, dedicated missions.
It's not going to happen overnight unless the hardware vendors get interested.
I'll still be able to use my THD7A to do everything I was doing. The APRS
won't stop working, and as long as people are interested in APRS, I'll have
infrastructure to support it. But, if there becomes equipment that allows
more people to use OpenTrac than are using APRS, then I'll have to switch.
I never had an AM radio, but I bet the use of SSB as a replacement for AM had
a bunch of birds singing similar tunes of doom and gloom. I did have an AM CB
radio when I was growing up. Yep, no sooner than I got a midland AM radio,
did there suddenly appear SSB radios. And, then there were 40 channels etc.
The market spoke, and SSB is the rule of the day.
I'm not planning on being an opentrac hardware or software vendor. But, I
will play with it, and hope that something new will revolutionize the
affordability of portable packet radio and telemetry systems. It's still a
dual band FM radio that I can fully utilize. If I need to go from APRS to
OpenTrac, we have demonstrated that the PID can be used on the air to
differentiate protocols. Thus, APRS could be converted to OpenTrac, or
OpenTrac could be converted to APRS by smart digis. Imagine a digi that knew
that an OpenTrac or APRS device was in its area, and did the conversion of
outbound traffic too.
Lots of ways to prolong the life of these kinds of devices until they really
are no longer useful.
-----
gregg@cytetech.com (Cyte Technologies Inc)
----------------------------------------------------------------------
Subject: Arizona's upcoming Disaster Drill
From: "Spider" <spider@rivcom.net>
Date: Mon, 7 Jun 2004 17:00:49 -0700
X-Message-Number: 118
This year, Arizona's Disaster Drill will be held in La Paz County, AZ and
will be in November.
Two people are in charge of communications for the event in La Paz County.
Jim Wooddell, spider@rivcom.net
Karl Hartmetz, khartmetz@co.la-paz.az.us
I am looking for volunteers in the nearby area (California, Nevada, AZ, UT,
etc.,) with portable and mobile APRS units to test APRS capabilities in such
a large scale disaster test within La Paz County for resource tracking. I
also would like an APRS unit at the AZ SEOC (with a good display screen or
wall projector) and at the NWS in Phoenix, Red Cross in Phoenix but that
coordination has not occurred at this time.
If I can drum up enough volunteers, this will be the first time APRS has
been used at this level in AZ for resource tracking.
I can not give out too much information at this time however, November is
sometimes a very nice time of year out here.
If you are close enough to participate and have the interest, please contact
me off sig at spider@rivcom.net.
I am also looking for volunteers with 2m, 440 and HF comm capabilities to be
out here as well. Portable and mobile preferred.
This email is very general and is basically a feeler and heads-up to see if
we can support APRS in an area such as La Paz County, AZ. Much of the State
will be activated, as well as parts of Nevada and California. Many hams may
need to serve there local area.
I am praying for a good APRS turnout.
Jim Wooddell
WA6OFT
----------------------------------------------------------------------
Subject: Re: APRS OBJECT Caching (Rev 1)
From: Danny <danny@messano.net>
Date: Mon, 7 Jun 2004 20:00:35 -0400
X-Message-Number: 119
Just the same as:
RB> Good idea. Ill add it to the APRS errata page.
RB> thanks.
RB> Bob
So that I am clear on this. APRS is locked into spec 1.0 + Bob's APRS
Errata page. These *SPEC* Updates (which I see there are now offically
dubbed "SPEC Updates".. Interesting...) are added based on the "Uh yeah,
that sounds cool" decision of ONE person.
This is fascinating.
Danny
KE4RAP
Monday, June 7, 2004, 7:04:33 PM, you wrote:
JK> Insight...
JK> Quoting Robert Bruninga <bruninga@usna.edu>:
>>Revised APRS OBJECT-Caching SPEC:
JK> ...
JK> Not to be a smart alec in the past, but quite a few people, including
myself,JK> have asked about the status of the APRS-WG and if the
charter/protocolJK> submission process is being followed. All of them have been
summarily ignored
JK> (my lawyer calls this stonewalling). Yet, you seem to be able to post new
JK> things here, and call it a "SPEC"....
JK> I'm soley pointing out this apparent double standard might explain for some
of
JK> the conflict and bad feelings here. Clearly too late to fix that now, but
might
JK> be some insight for those wondering what the big deal is about.
--
Danny
----------------------------------------------------------------------
Subject: RE: Introducing "OPENAPRS"
From: Danny <danny@messano.net>
Date: Mon, 7 Jun 2004 20:10:45 -0400
X-Message-Number: 120
I dont understand how CHANGES mean "overnight obsolescense"..
Additions to the protocol wouldn't obsolete everything or anything
necessarily.
Problem is, as with all your arguments, is that it's ALL or NOTHING. There
is no in between. Stop being so close minded and think about what is being
said here. You seem to take "changes", "opentrack", "obsolete", "kenwood",
and "aprs" and throw them all into the SAME arguments.
If the kenwoods are that volitale that additions to the protocol will
render them INSTANTLY obsolete, then boy they are pieces of junk.. either
that or the APRS Protocol is so poorly designed that any changes to it will
render all hardware and software obsolete.. Which is it?
Danny
KE4RAP
----------------------------------------------------------------------
Subject: Re: APRS Protocol - A Modest Proposal
From: "Gregg G. Wonderly" <gregg@skymaster.cytetech.com>
Date: Mon, 07 Jun 2004 19:21:19 -0500
X-Message-Number: 121
>>I think that an easy way to solve this would be to use a
>>separate port for a new, slightly different structured stream
>>of data that included the PID. I would think that the
>>existing code could be easily used when the PID was F0, and
>>when its not F0, you could do something specific to that
>>protocol, archive it, or event drop it.
>
>Can't do that. You missed the statement "APRS-IS is based upon the
>textual representation of packets". Inter-server and server-client
>communications rely on lines to be terminated with a carriage return
>and/or line feed. Since OpenTrak is a binary protocol, these characters
>may occur anywhere in a packet. Beyond that, IGates and most APRS-IS
>clients expect packets to have some semblance to APRS packets.
Okay, I'll be more specific. I said 'slightly different structured stream
of data that included the PID'. What this means is that the APRS-IS
servers could be expanded to handle new protocols. First, they would start
using KISS mode if not already using it. Next, they would add processing
to connect to the new port, and write the data down that port with the PID
included as the first byte. The next two bytes would be a payload length,
and then they would write the packet.
The result would be that embedded carriage control would not be a part of
the protocol. Thus, the receiving software would be able to do some
validation and say humm, this is PID 0xf0, there should be no carriage
control present. This would provide a backwards compatible upgrade of the
APRS-IS. At some point most systems would be upgraded, and the old ports
could be turned off to provide an impetus for the conversion of any
remaining systems.
Another interesting thing to include in the new protocol would be an
acknowledgement mechanism using a window so that the number of failed
packets going into APRS could be counted. A message capability would be
nice too so that an admin of a higher level machine could send a message to
the connected users to help them know of issues, such as upgrades that they
might need to take action on.
-----
gregg@cytetech.com (Cyte Technologies Inc)
----------------------------------------------------------------------
Subject: Re: APRS Protocol - A Modest Proposal
From: "AE5PL Lists" <HamLists@ametx.com>
Date: Mon, 7 Jun 2004 19:30:11 -0500
X-Message-Number: 122
Re-read my post, Gregg. I stated very clearly why APRS-IS can't do what
you want and that there is already work being done to look at designing an
interconnect protocol that can carry any AX25 protocols. Let it drop.
73,
Pete Loveall AE5PL
>-----Original Message-----
>From: Gregg G. Wonderly
>
>Okay, I'll be more specific. I said 'slightly different
>structured stream of data that included the PID'. What this
>means is that the APRS-IS servers could be expanded to handle
>new protocols. First, they would start using KISS mode if
>not already using it. Next, they would add processing to
>connect to the new port, and write the data down that port
>with the PID included as the first byte. The next two bytes
>would be a payload length, and then they would write the packet.
----------------------------------------------------------------------
Subject: RE: Introducing "OPENAPRS"
From: "Scott Miller" <scott@3xf.com>
Date: Mon, 7 Jun 2004 18:34:46 -0700
X-Message-Number: 123
Then show us the errors, Bob. ~400,000 square miles, ~60,000 packets, and
one user complaint.
Scott
N1VG
-----Original Message-----
BS and propaganda, jeff.
Im not wasting my time any further on your
twists and distortions... Bob
>>>Jeff King <jeff@aerodata.net> 6/7/04 6:21:45 PM >>>
-Serious- logic flaw correction here
Quoting Robert Bruninga <bruninga@usna.edu>:
>Remember, no one on APRS is seriously impacted except
>the Kenwoods, Mic-E's, Trackers, HAM Huds and
>other trackers.. so its only they who really care...
ONE SINGLE HAM HUD was effected by the direct over the air protocol, sent
over a ~400,000 sq mile area!! That is all we know of after hundereds of
messages on the SIG. ONE! No-one else!
----------------------------------------------------------------------
Subject: PID 77 in AX.25 spec?
From: Wes Johnston <wes@johnston.net>
Date: Mon, 07 Jun 2004 22:04:48 -0400
X-Message-Number: 124
Scott asked this a long time ago, but how do we get 0x77 registered as
Opentrac under ax.25? Some group got eax.25 added a number of years ago...
how was that change made?
Wes
----------------------------------------------------------------------
Subject: RE: APRS Touchtone Wow
From: "Ramon F. Kolb" <ramon@ieee.org>
Date: Mon, 7 Jun 2004 22:06:04 -0400
X-Message-Number: 125
Actually, I just posted a mail to another mailing list where I was looking
to develop something similar, and I think this can be easily tweaked into
something Bob is foreseeing. Let me repeat my email here, and see if someone
can help me further:
________________________________
From: Ramon F. Kolb [mailto:ramon@ieee.org]
Sent: Monday, June 07, 2004 2:52 PM
To: wara64@yahoogroups.com
Subject: [wara64] Voicexml/vxml experiments...
Hi,
I want to experiment with voicexml and vxml to make an interactive
application that can be used on 2 meters. (I'm not yet looking at any
practical applications, just a learning experience.)
What do I want to be able to do, is:
- listen via the soundcard for input. In the beginning this would be DTMF,
lateron I would want to add voice recognition
- this input would be presented to the vxml/voicexml app that I wrote and
gets processed
- Output, be it a pre-recorded WAV file or TTS (using for example FreeTTS),
would be played back via the soundcard
My question now is the following:
Is there a free voicexml browser that I can download that interprets the
voicexml/vxml script that I write, and takes input from the soundcard and
plays via the soundcard? Has anyone experimented with voicexml? It needs to
work in WinXP professional as I want to make the application portable and
quickly deployable using for example a laptop.
In the end, I want to have developed a system that can be easily deployed on
existing equipment such as laptops running Windows, using simple
soundcard-to-radio interfaces. The voice interface should be easily
changeable so I (or anyone else) could quickly develop and test an
application that can be deployed for the specific needs. That's where VXML
or VoiceXML (two different, but quite similar mark-up languages, based on
XML) appear in the picture.
I have some ideas about applications:
- in the "daily-leasure" category:
+ allow HAMs to leave messages for other HAMs that can be played
back/retrieved/etc. (Like voicemail)
+ allow HAMs to listen to the latest ARRL bulletin/DX information/weather
reports
- in the "alerts" category:
+ allow automatic postings of relevant SkyWarn or weather watch/warning
messages
+ allow operators or "specially thereto assigned HAMs" to record emergency
messages that get replayed at a regular basis
- in the "emergency operations" category:
+ provide a "disaster communications" capability for heath/wellness
traffic during large-scale outages of the PSTN/PMLN (in ADDITION to the
traffic system, not INSTEAD of course)
+ provide up-to-date information to HAM operators that are involved with
the emergency recovery operation
Anyone that can help me further with ideas of the software I need to deploy
and develop this, I'd like to hear from his/her!
73s,
--Ramon KX1T
-----Original Message-----
>>>Sean Jewett <sean@rimboy.com> 6/7/04 12:35:07 PM >>>
>>"In other- words the exact way to spell WB4APR is
>>922444427A77 but in most cases, just using one key press per letter or
>>hitting 0924277 will be a unique enough number [in the vicinity of
>>THAT aprstt local RF server so that] it only matches WB4APR in your
>>area without ambiguity."
>but I think it'd create too much of a problem in the long run. You're
>going to have to have some sort of registration process.
No, not at all. Just send the SHORT version of your call by Keypad or from
DTMF memory and if the APRStt server recognizes you it will say "WELCOME
WB4APR".
If the short version decodes to two calls in your area it will say, "Press 1
for WB4APR or 2 for WA4BRP"
At that point it sends out an APRS packet to the APRS system placing you on
the MAP within 10 miles of the location of that APRStt server using the 10
mile ambiguity symbol. Now worldwide everyone can see you... and you can
not do anyting else in APRS such as messages, queries etc. And all give
VOICE responses...
>it'll be an interesting day when WA4BPS tries to get on the air with
>the same code.
The APRStt server will notice if it has an ambiguity or not and will ask for
a clarification if needed as noted above..
>nevermind finding a good hands down application for it.
>The search continues...
Wow, I can think of DOZENS of immediate needs I have of this!
My kids would use it every day from their tiny HT's.
When they get out of school, or practice, or music, or scouts, or whenever
they need DAD's taxi, they just seleect DTMF #1 which is their call, and
then DTMF #2 which has encoded "GET ME". Or DTMF #3 which has encoded "CALL
ME" or whatever. ALl this from their $129 super tiny VX-2R HT in their
pocket.
Then on my D7 I get the instant APRS message alert and can READ the message
without having to listen to the local repeater all day long...
de WB4APR
----------------------------------------------------------------------
Subject: RE: APRS Touchtone Wow
From: "Andrew Rich" <vk4tec@hotmail.com>
Date: Tue, 08 Jun 2004 12:25:24 +1000
X-Message-Number: 126
I just made a talking aprs weather station. using perl and liniux
What I want to do is menu drive it with dtmf.
"Select one for ..."
----------------------------------------------------------------------
Subject: Thoughts on a proposed replacement for D700
From: Doug Bade <doug@clecom.com>
Date: Mon, 07 Jun 2004 22:32:13 -0400
X-Message-Number: 127
This is kinda long, so feel free to not read/delete it if you want, as it
is kinda Kenwood centric.
Being that I actually use APRS with radios, as well as mobile, and I guess
as the intent is to allow APRS, OpenTrac and maybe APRS 2.0 to exist on
the same RF channel, and all now being discussed from the standpoint that
it IS going to happen regardless ( which BTW I still really think is a bad
idea, and which I am also being told is irrelevant ...) , I am exploring
thoughts on how I can "see" and maybe even use these new packets in my car
in leu of my D700's, soon to be obsolete, display.
I guess the intended implementation is a processing device like a Laptop (
I hope not ) or a Palm or Pocket PC ??? I doubt law enforcement will be
real happy with a large deployment of laptops hanging from the ceiling or
in/on dashboards, or in the front seat of cars, so Pocket devices seem more
sensible???
Has the Pocket APRS author and the APRS CE author indicated they are
willing to migrate their sw to allow/use the old and new protocol(s) ? I
guess my Pocket PC is a cheaper/smaller display than my laptop, so it
would be a better option, and for now it seems this will be the quickest/
safest /best answer....but in Kiss mode the display will need to do it all,
so the SW must be more capable... back and forward compatibility and all...
I guess it should be easy for them to add parsers for these new protocols
and all too...they are supposed to be much simpler to figure out...from a
programmers standpoint anyhow...
Actually not that I want to make work for them, and absolutely no
disrespect to those who have worked so hard producing these as well as
other clients, but the implementations I have looked at for palm and pocket
pc do not really lend themselves really well to a vehicular mobile
environment... more a "portable" or "home" albeit compact one... maps and
all... Not that the devices and cradles are exactly designed for mobile
either, but some mobile centric SW options may be needed to be built in,
like bigger text for displaying packet text etc....bulletins, finger size
selection buttons, and such, all that day to day stuff...read-able from say
two to three feet away.....
I have seen cellfone cradles, which could work, to hold my $500.00 Pocket
PC, but that pesky serial/power cable would be a hindrance.. Maybe a
bluetooth serial link to connect to the D700 !!!!!!!! That would be cool
!!!!! Someone should be able to design one !!!
Maybe we need to have some new Pocket SW written to serve the particular
needs of the mobile user though, maybe use the D700 as a model??? It has
served fairly well to date, just needs replacing with a computer display
for the next generation capabilities... like APRS 2.0 and all...
Do we have pocket device authors who want to work on this, or new ones
signing up? Seems their input up front might be sorta important....
Anyone have experience running APRS CE mobile, day to day, with a D700??
Opinions REALLY are welcome, private if you would rather, as I really DO
want to hear of experiences, positive and negative using these applications
in this manner....
I downloaded the SW to install, and now I need to build some
mounting/serial/power hardware stuff and try to secure it all against
theft....and I need to figure out where to mount it so I can see it in
daylight too, I guess the daylight thing was not real important to HP when
they made it and all....hot car interior and such, not being a design
criteria...And I have to keep access to the old D700 display for those
pesky radio related things like volume, and freq control and all...
There are several thousand of us who will need to learn how to make this
work best, and avoid pitfalls...even a mini howto may be in order....any
relevant suggestions would be helpful, and maybe we should start another
SIG to support this mode....assuming this is really the plan anyhow...
We do seem to have a bunch of experts telling us how easy it will be and
all...It MUST be pretty simple... I am willing to give it a try !!!!
I apologize in advance if I offend anyone in particular with this, as there
is absolutely no intent to do that, just to enlighten/question....
Doug KB8GVQ
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
