| |
ZL3AI > APRDIG 16.06.04 11:26l 799 Lines 30430 Bytes #999 (0) @ WW
BID : 3472-ZL3AI
Read: GUEST
Subj: TAPR Digest, Jun 10, 2/8
Path: DB0FHN<DB0THA<DB0ERF<DB0FBB<DB0GOS<DB0ACC<DB0EA<DB0RES<ON0AR<ZL2BAU<
ZL2BAU<ZL3VML
Sent: 040616/0732Z @:ZL3VML.#80.NZL.OC #:25935 [Chch-NZ] FBB7.00i $:3472-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: RE: Thoughts on a proposed replacement for D700
From: "DG2JW" <dg2jw@privateasylum.com>
Date: Thu, 10 Jun 2004 14:50:02 +0300
X-Message-Number: 19
Very good well made point Juergen.
I have every intention of testing in Europe on 144.800. Locally at first,
and if there is no problem, continuing on. There are several of us here
that are in Europe and have a slightly different perspective on things.
Anyway, with good testing in small increments, there is no reason things
would not work along side each other as long as we don't ignore the data
from each test.
73s
Julian
----- Original Message -----
From: "db2fm" <db2fm@jfsattv.de>
>>Sorry guys, I do not think I like the idea of mixing APRS and OPENtrack in the
>>same frequency.
>Don't agree! As Henk stated, no problem here in Europe experienced. So
>why not try ist here, away friom the holy APRS-frequency 144.39, on 144.8?
>>
>73 de Juergen DB2FM
>--
>DB2FM
>Juergen Frank
----------------------------------------------------------------------
Subject: Re: How to Run ZTerm on Mac OS X?
From: Jason Winningham <jdw@eng.uah.edu>
Date: Thu, 10 Jun 2004 06:54:52 -0500
X-Message-Number: 20
On Jun 9, 2004, at 7:03 PM, Matthew Stennett wrote:
>Not familiar with what Panther will do, so don't know how to run
>simple terminal program to MFJ-1270C on OS X?
I download and use kermit. The old unix standby tip is already on the
system, too.
>I have a serial ><USB adaptor but don't know how to configure it.
>Serial adaptor is a Belkin F5U103-MAC.
>No OS X driver on DISC from when I bought it.
>Don't know if it will even run.
I don't know about this particular belkin device, but several months back
when I tried to use some other belkin USB hardware I found the drivers were
OS 9 and prior; no support for OS X.
-Jason
kg4wsv
----------------------------------------------------------------------
Subject: Re: Kenwood APRS radio...
From: "Bill Diaz" <william.diaz@comcast.net>
Date: Thu, 10 Jun 2004 07:12:29 -0500
X-Message-Number: 21
What would happen if someone in the future decides to create an "improved"
OpenTrak protocol that corrects its shortcomings and obvious design
deficiencies.
There is nothing stopping a protocol developer from using the same PID as
OpenTrak. He could also use a similar structure but expand or change some
of the "obsolete" fields. These changes could cause "Obsolete" OpenTrak
implementations to fail when used on the same frequency as the "improved"
protocol.
How could this happen? The "improved" protocol developer is not required
to test his implementation in the real world. He may have little knowledge
of ( or care )how the "obsolete" version actually works on the air. It is
not his fault that the "obsolete" versions cannot tolerate his "improved"
protocol.
"Obsolete" OpenTrak implementations could obtain new code to fix the
shortcoming, but if experience is any guide, it will take months or years
for all users to upgrade.
The "improved" protocol developer could spend a year or more hyping his
product and introducing new features or tweaking the protocol. Several of
these changes could again cause newer "obsolete" OpenTrak implementations
to fail. And so on.
I wonder how the "obsolete" OpenTrak users would react to this?
Bill
----------------------------------------------------------------------
Subject: Re: Kenwood APRS radio...
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Thu, 10 Jun 2004 08:25:13 -0400
X-Message-Number: 22
>>>Drew Baxter <droobie@maine.rr.com> 6/9/04 8:26:13 PM >>>
>No, because it isn't in the SPEC or SPEC errata, it's
>non-aprs-channel-interference. Bob has a habit of using
>Kenwood as a reference because it [fully] supports the
>1.0 APRS Spec.
I must also appologize for using the term Kenwood when I should have been
using the term D7/D700. I have no brand loyalty. I have Icoms, and
Yeasus, and Alincos. I was just using the brand name as an easy substitute
for the only APRS radios on the market. Sorry if that confused some
people... Bob
----------------------------------------------------------------------
Subject: Re: Kenwood APRS radio...
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Thu, 10 Jun 2004 08:30:50 -0400
X-Message-Number: 23
>>>"Eric H. Christensen" 6/9/04 8:46:55 PM >>>
>The Kenwood can't decode the Peet Brothers packets,
>either...
But No amount of software can keep up with the plethoria of WX stations
interfaces. That is why APRS1.0 has only ONE WX format (2 variants). So
that software could be written ONCE and it would always receive all
weather. I know thta make it boring for programmers, but it is that kind of
forsight by the APRS-WG that makes APRS work.
----------------------------------------------------------------------
Subject: Re: Kenwood APRS radio...
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Thu, 10 Jun 2004 08:33:15 -0400
X-Message-Number: 24
>>>Drew Baxter <droobie@maine.rr.com> 6/9/04 9:38:35 PM >>>
>Doesn't the WXTrak support Peet Brothers?
>Supposedly there's only one weather format actually
>in the APRS SPEC... That'd mean the other hacks
>for other weather stations are just that.. hacks.
Yes, that was the whole idea. Instaed of upgrading the SPEC and all 20,000
users everytime a new WX instrument came out, the idea was to hve one
standard, and then let PIC processors (about $10) convert anything and
everything to the one APRS WX format.
Bob
----------------------------------------------------------------------
Subject: Re: APRS TT
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Thu, 10 Jun 2004 08:39:52 -0400
X-Message-Number: 25
>>>N5TIM <n5tim@comcast.net> 6/9/04 9:53:49 PM >>>
>Thanks to all that had some information regarding APRStt.
>What I have learned so far it that since I do not have
>a Kenwood I'm up the creek.
That is why APRStt is so powerful. It will let any HT and any MOBILE user
send and receive APRS data with ANY radio of any brand. We just gotta get
a programmer to do it in Windows with a sound card, and it will explode
into amateur radio...
>Secondly the only software that enables it is APRSdos
>and I do not use that either. Well maybe someday...
you dont have to "use" it. Only one person in your entire city has to run
only 1 copy of APRStt at a repeater, on aa PC that will never be seen or
touched by any user.
To the end user, he never sees it. Just put APRStt on a laptop in the
closet hooked to a radio and and antenna and then everyone within radio
range can use it with their DTMF radios...
Bob
----------------------------------------------------------------------
Subject: APRS capable Satellite Ready for launch
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Thu, 10 Jun 2004 09:01:35 -0400
X-Message-Number: 26
ECHO Satellite has 2 transponders, one will be mostly for voice and the
other for packet at 9600 baud. VHF uplink and UHF downlink. This has the
potential to provide Global APRS connectivity to mobiles and travelers. The
D7(g) model HT and the D700 mobile are fully ready for 9600 baud APRS using
split cross band mode for this satellite. Bob
>>>"Lee" <lee-fl@cfl.rr.com> 6/9/04 10:25:58 PM >>>
ECHO satellite enroute to launch site
AMSAT News Service Bulletin 161.01 From AMSAT HQ
SILVER SPRING, MD. June 9, 2004
To All RADIO AMATEURS
Chuck Green, N0ADI, reporting in from SpaceQuest's facility says, "ECHO is
in it's shipping container and on its way to the launch sight."
As a final check ECHO was placed in the vacuum chamber for an hour and
pushed hard with both 70 cm transmitters running full power. Everything
that could be tested in this configuration worked well.
Chuck said, "We also checked the sensitivity of all the 2M receivers and
the SQRX (wideband tunable receiver) and they were all very good."
Continuing, he added, "We also characterized the received signal strength
indicator (RSSI) and measured the power out of the 70 cm transmitters at
various power settings"
Robin Haighton, VE3FRH, added, "Congratulations on a job well done! A lot
of hard work has gone into getting ECHO to this point and we're looking
forward to following ECHO's progress through launch".
More news and information about the final integration activities will be in
this week's regular AMSAT News Service bulletin.
[ANS thanks Robin and Chuck for the above information]
----
Sent via amsat-bb@amsat.org. Opinions expressed are those of the author.
Not an AMSAT member? Join now to support the amateur satellite program!
To unsubscribe, send "unsubscribe amsat-bb" to Majordomo@amsat.org
----------------------------------------------------------------------
Subject: Re: Kenwood APRS radio...
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Thu, 10 Jun 2004 09:05:53 -0400
X-Message-Number: 27
>>>Drew Baxter <droobie@maine.rr.com> 6/9/04 10:14:56 PM >>>
>Bob's going to have to explain that one. In a post
>earlier in the week he said that the Kenwoods support
>the 'one APRS Weather format' if memory serves.
>This lead me to believe there is a defined weather
>format and the other things are just hacks.
Yes, I was wrong. I was opposed to putting in specific Manufacturers
formats because it would forever lead to incompatilibites as new WX
products came out. I guess I forgot that we put them in at the time to get
consensus...
But I feel confident that we are not going to add any more and change the
APRS spec everytime a new WX station comes out. In fact, I would propose,
for the purpose of SIMPLIFYING the APRS spec, that in version 1.1 we remove
all WX formats except for the one APRS standard for future applications.
Then let the programemrs develop little $10 PIC converters to put the
stand-alone WX stations into the correct standard on-the-air format.
Bob
----------------------------------------------------------------------
Subject: Re: Not all of us use Kenwoods in the field -was- Re: Tetroon
collateral damage report, revision1
From: "Jason Rausch" <ke4nyv@hamhud.net>
Date: Thu, 10 Jun 2004 8:7:27
X-Message-Number: 28
I have to agree to this...
Kenwoods are nice, don't get wrong. But when it comes to mobile use, my
HamHUD II is far superior in my eyes, I could'nt imagine trading it in on a
overpriced, non-upgradable, non-customizeable unit. These are the reasons
the HamHUD group formed. We basically all have a common interest in that
regard. Features like the simple, but effective LCD, the ability to do
easy hooks and message entry, The DigiMeter - Which counts your digipeats
heard back and calculates how you're getting into the network. At a glance
when I receive a packet I can see the stations call, path and their last
digipeat. It also displays their distance from me and heading. If they
are moving gives me their spead and heading all on a single line. Very
handy. Sure, we have to use an external TNC for now, but thats soon to
change I hope. But again, I can't justify the cost of a D700. A MAJOR
drawback to me is the lack of user-upgradable capability. With the HamHUD,
if someone does a firmware revsion, you hook it to a serial port and load
the new code, no programmer, nothing special other than a cable you make up
to match the interface you chose when you built it.
On the other hand, for portable use. There is NO better way than a D7. I
dumped my old HT/Pico/Palm setup a long time ago. Now its just a Palm and
my D7, one cable, slick! I use my D7 for regular palmtop packet and APRS
and of course you can throw all of that away and still have about 80% of
APRS function with just the D7 itself. Again, the upgradable point is a
sore subject with me, but I kind of compensated by waiting right at 6 years
or so to buy one. I heard the horror stories of bugs and sending it in at
YOUR cost to fix it. It seems to me now that Kenwood has really tweaked
this little guy now. Except for that POS antenna they give you!
I'm not 100% biased, but I can see the good and bad in each.
I'v got my flame suit on!
Jason KE4NYV
www.ke4nyv.com
RPC Electronics
www.ke4nyv.com/rpc
----------------------------------------------------------------------
Subject: Repeaters in N. Georgia Mountains
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Thu, 10 Jun 2004 09:18:08 -0400
X-Message-Number: 29
In North Georgia, what VOICE repeaters are dead solid coverage to a 1W
hiker on the Appalachian Trail near SPringer Mountain and Neels gap.
An APRS user wants voice backup.
Bob
----------------------------------------------------------------------
Subject: RE: Thoughts on a proposed replacement for D700
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Thu, 10 Jun 2004 09:26:33 -0400
X-Message-Number: 30
>>>John Hall <n5jrh@houstonhams.org> 6/10/04 12:57:12 AM >>>
>Aren't you a programmer Bob, as in APRSDos?
Depends on the word. I USE ham radio and I dabble around in BASIC to try
to get PC's and radios to do the kinds of HAM radio stuff that I think
needs doing. Back then, EVERY PC had basic on it and so I could share my
hacks with others..
I got left in the dust by Bill Gates, and am too busy and now have wife and
kids and am too old to have time to dig as deeply as would be required.
Thus, I too am now totally dependent on the programmers of today to give us
what we need in HAM radio. SO I try to just keep focused on that. What do
we really need in our Mobiles to serve the end user in the field.
Bob
>But I am NOT going to waste time on coulda/shoulda/
>woulda whinning from programmers.... that will DENY
>EXISTING USERS continuity of operations on APRS!
----------------------------------------------------------------------
Subject: Compressed Positions -was- Re: Tetrooncollateral damage report,
revision1
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Thu, 10 Jun 2004 09:33:34 -0400
X-Message-Number: 31
>>>Bill Herrmann 6/10/04 2:25:22 AM >>>
>At 02:42 PM 6/9/2004 -0400, Robert Bruninga wrote:
>>4) In addition, I now propose that the APRS-WG REMOVE
>> the problematic compressed protocol form the APRS
>> spec to help simplify the protocol for future programmers.
>
>...that is a really, really bad idea ... If you remove it, future
>programmers won't have the documentation to decode it.
>
>Instead of removing it you would want to mark it as obsolete,
>not to be transmitted etc. but leave the information in the
>specification so that it can be decoded.
Yes, that is exactly what I meant. Thanks. We want to "obsolete" some
underutilized, or broken things in the current spec so that future
programmers are not saddled implementing things that are just not used
much. They can sitll implement them on receive, but if they transmit them,
they should not EXPECT others to necessarily decode them.
So APRS1.1 will be published as an ADDENDUM. It will not go back an
re-write the original document...
Bob
----------------------------------------------------------------------
Subject: RE: Compressed Positions -was- Re: Tetrooncollateral damage report,
revision1
From: "Eric H. Christensen" <kf4otn@earthlink.net>
Date: Thu, 10 Jun 2004 09:56:21 -0400
X-Message-Number: 32
Are we seriously talking about removing the one format in APRS that actually
gives us precision to 1 foot??? A packet that reduces bandwidth??? Why?
My software decodes them fine! My friend's software decodes them fine! If
your software doesn't decode them, I suggest you go with a software option
that actually keeps up with the times...
73s,
Eric KF4OTN
kf4otn@amsat.org
----------------------------------------------------------------------
Subject: RE: Compressed Positions -was- Re: Tetrooncollateral damage report,
revision1
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Thu, 10 Jun 2004 10:32:52 -0400
X-Message-Number: 33
>>>"Eric H. Christensen" <kf4otn@earthlink.net> 6/10/04 9:56:21 AM >>>
>Are we seriously talking about removing the one format
>in APRS that actually gives us precision to 1 foot???
Yes, that is the proposal.
1) Because it has been replaced with the !DAO! constuct
a) Which gives resolution to 7"
b) INCLUDES Datum (so it is meaningful)
c) can be human readable to 6 feet
d) is 100% backwards compatible to all HW and software
2) Use of that kind of precision without control of DATUM at the receiving
end is a recipe for disaster
3) And since the #1 complaint of all programmers is at the complexity and
duplicity within the protocol and since the compressed protocol is broken
in many applications, it seemed like it was a good one to phase out.
4) AND since the compressed is LONGER than the Mic-E format, it just has no
advantages. Only disadvantages...
Bob
----------------------------------------------------------------------
Subject: Re: Repeaters in N. Georgia Mountains
From: "Tim Makins, EI8IC" <contesting@eircom.net>
Date: Thu, 10 Jun 2004 15:36:28 +0100
X-Message-Number: 34
http://rptr.amateur-radio.net/arn/rptr/index.html
Bob - this page might help.
73s Tim EI8IC
----------------------------------------------------------------------
Subject: Re: Kenwood APRS radio...
From: db2fm <db2fm@jfsattv.de>
Date: Thu, 10 Jun 2004 16:37:02 +0200
X-Message-Number: 35
Am Mittwoch, 09.06.04 um 21:46 Uhr schrieb Steve Dimse:
>On 6/9/04 at 3:09 PM Robert Bruninga <bruninga@usna.edu> sent:
>
>>Throw out when Kenwood users are ASLEEP
>>with their radios off, and the 16% becomes 25%.
>>Throw out the HALF of all those packets that
>>are from Europe (not part of my claim) and BINGO
>>the 25% becomes 50%.
Very bad math...
(like if A wins against B and B against C, A must win against C!
Terrible!)
>Well Bob, sorry to disappoint you, it has been nice to be on the same
>side of an
>argument for once, but it doesn't go that high. Take the following
>three lines
>and add them to the program I just posted (right before the cnt++):
>
> next unless (m/^[KNWA]/);
> next if (m/TCPIP/);
> next if (m/TCPXX/);
>
>These discard any packet that does not start with KNWA or that
>originates on the
>internet, which leaves US stations on RF, you get 2165 of 6975, 31.0%.
So, that means that roughly 2000 are from outside US, where APRS-users are
NOT MOBILE as Bob stated :)) ... and where so less Kenwoods were sold...
HI HI HI <G>
>Still, nearly a third of the stations sending posits on RF in the US
>are using
>Kenwoods, enough to make the point that this is not a trivial minority.
>
>A little more work would be to find what percentage of root callsigns
>used a
>Kenwood...in other words, group K4HG, K4HG-5, and K4HG-8 together, and
>count yes
>if any of them use Kenwoods. This would give the percentage of US APRS
>hams that
>would be affected. Left as an exercise for the readers...
>
>Steve K4HG
Juergen (Kenwood TM-D700E user in Germany, only used in the car :)
----------------------------------------------------------------------
Subject: Re: Kenwood APRS radio...
From: db2fm <db2fm@jfsattv.de>
Date: Thu, 10 Jun 2004 16:29:47 +0200
X-Message-Number: 36
Am Donnerstag, 10.06.04 um 06:55 Uhr schrieb Scott Miller:
>>I'd like to see something go a little faster like 9600.. But if memory
>>serves, the Tasco 9600 portion is very buggy.. Like it holds the
>>channel
>>open as long as it would take to do a 1200 baud packet.
>
>I'd love to see 9600 in links between digis, and maybe a separate
>channel
>that'd pipe a larger APRS stream to more capable clients.
That's how the packet radio network is designed in Europe, at least in
Germany. We have 1200 and 9600 Bd user frequencies (most 9k6) and even
faster links between the digis. There are all sorts of protocols (YES, the
can co-exist, even on the same frequency!) and on the links there are also
TCP/IP-packets flying around. That's one reason, that there are discussions
on changing the APRS network to have a backbone network and the
user-network. Easiest is to just use the PR-network as the APRS-IS and
connecting to the IS-servers just via PR with TCP/IP. Pure ham-radio,
without Internet at all! That way we could also get rid of the excessive
path problem on the user frequency (everyday I see those uneducatable
WIDE7-7 users in my area).
That's also, why I proposd to test a new protocol in Europe as it will not
harm there. Europe is the example for the thesis, that different protocols
can co-exist on the same channel. (By the way: didn't a German guy develop
a new protocol for packet, named FlexNet? (D)K7WJ as he holds a US-licence,
too. He still in PR, but not developing FlexNet much at the moment, it's
just working very reliable. Also Baycom and Nord><Link are from Germany. At
the beginning there have been problems with path-finding between Nord><Link
at FlexNet as FlexNet does that automatically (you just have to know the
call of the digi at the far end and the one near you to get a connection
established), but everything could be sorted out.)
That's why I don't understand, when I hear US-hams say, that a new protocol
once killed packet there. Why? (I re-state it must be because some people
do only accept ideas, they did not have themselfs. In Germany we call them
'concrete-heads' ;)
>For tracker use though, I think the concern is that it requires a greater
>s/n ratio, and that the modulation formats I've seen take longer to sync up.
>Oh, and many radios out there won't do it at all without modification.
>Thankfully that's changing, but I still own a lot of handhelds with no 9600
>input.
>
>You can make up for the increased bit error rate using forward error
>correction, and you can probably pick a modulation format that syncs up
>quick, but you're also still stuck with the transmit delay imposed by the
>radio.
>
>Plus, 1200 baud is just really simple to generate. I do it in software with
>an 8-bit microcontroller, using a single output pin in PWM mode. That's
>hard to do at 9600.
>
>(My PSK31 code, on the other hand, is really close to working.)
>
>Scott
>N1VG
Juergen DB2FM
----------------------------------------------------------------------
Subject: Re: Kenwood APRS radio...
From: db2fm <db2fm@jfsattv.de>
Date: Thu, 10 Jun 2004 16:54:01 +0200
X-Message-Number: 37
Did you ever read the OpenTRAC 'specs'?
They are far from completion, but if you had, you would have seen
immediately, that your below statement is proven wrong.
The most important guideline, as I read it, of OpenTRAC is, that new things
can be added easily and if time shows that something is obsolete, it can be
left out without any harm to the network (only this parameter isn't shown
any more, nothing else).
Please, take the (short, less than an hour) time to read, what Scott offers
as his first attempt to begin the specs and try to understand!
Juergen DB2FM (having read both specs, APRS 1.0.1 and OpenTRAC)
Am Donnerstag, 10.06.04 um 14:12 Uhr schrieb Bill Diaz:
>What would happen if someone in the future decides to create an "improved"
>OpenTrak protocol that corrects its shortcomings and obvious design
>deficiencies.
----------------------------------------------------------------------
Subject: Re: [ Robert Bruninga ] Re: [ Robert Bruninga ] Re: D700 - Yes mine
has FLASH and In-Circuit Programming.
From: "Herb Gerhardt" <hgerhardt@wavecable.com>
Date: Thu, 10 Jun 2004 08:24:26 -0700
X-Message-Number: 38
Don't hold your breath on ICOM making an APRS radio. I suggested that to
them long before Kenwood released the D7 and ICOM's Marketing folks said,
thanks but no thanks, we do not foresee a large enough market to make it
worth while.
Now that Kenwood has the niche in APRS radios, I think they might have been
right. I don't think there are enough APRS players out there who are
willing to part with their $$$ to make two companies issue such products and
make it profitable. Remember, us Hams always want something for next to
nothing!
BTW I recently asked Garmin to evaluate whether they would consider making a
Ham Radio similar to their Rino but on Ham Frequencies. I would not hold my
breath on that one either but you never know. Just to think, a Ham Radio,
TNC and mapping GPS all in one unit!
Herb, KB7UVC
NW APRS Group, West Sound Coordinator
Our WEB Site: http://www.nwaprs.org
My NEW Email Address: hgerhardt@wavecable.com
----------------------------------------------------------------------
Subject: Re: APRS capable Satellite Ready for launch
From: "Scott Miller" <scott@opentrac.org>
Date: Thu, 10 Jun 2004 08:59:21 -0700
X-Message-Number: 39
>ECHO Satellite has 2 transponders, one will be mostly
>for voice and the other for packet at 9600 baud.
>VHF uplink and UHF downlink. This has the potential
>to provide Global APRS connectivity to mobiles and
>travelers. The D7(g) model HT and the D700 mobile
>are fully ready for 9600 baud APRS using split cross
>band mode for this satellite. Bob
This is kind of off-topic, but who chose that name? Might cause a little
confusion, or at least make it hard to Google for relevant info.
http://samadhi.jpl.nasa.gov/msl/QuickLooks/echoQL.html
Scott
N1VG
----------------------------------------------------------------------
Subject: RE: Compressed Positions -was- Re: Tetrooncollateral damage report,
revision1
From: "Scott Miller" <scott@opentrac.org>
Date: Thu, 10 Jun 2004 09:09:40 -0700
X-Message-Number: 40
>1) Because it has been replaced with the !DAO! constuct
> a) Which gives resolution to 7"
> b) INCLUDES Datum (so it is meaningful)
> c) can be human readable to 6 feet
> d) is 100% backwards compatible to all HW and software
I'll go along with removal of the compressed format as long as the Mic-E
format goes with it.
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: [ Robert Bruninga ] Re: [ Robert Bruninga ] Re: D700 - Yes mine
has FLASH and In-Circ
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Thu, 10 Jun 2004 12:19:02 -0400
X-Message-Number: 41
>>>"Herb Gerhardt" <hgerhardt@wavecable.com> 6/10/04 11:24:26 AM >>>
>BTW I recently asked Garmin [about] making a Ham
>Radio similar to their Rino but on Ham Frequencies.
Same here. And I had been put in contact with a real mole (high in the
ogrganization) who was also a HAM and he said something to this effect:
1) We are selling RINO's and GPS's by the millions.
2) Why would we want to invest a million $ to re-tool and make a unique
radio that only 0.005 of the population could use?
Show us the business model that makes sense. We dont see it. HAMS can use
the RINO with no restrictions. WHy make a unique product etc...
Face it guys, we are small potatoes.
Bob
----------------------------------------------------------------------
Subject: RE: Compressed Positions -was- Re: Tetrooncollateral damage report,
revision1
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Thu, 10 Jun 2004 12:21:59 -0400
X-Message-Number: 42
There he is again, determined to Force ALL D7 and D700 users off the
air.... 38% of all users...
>>>"Scott Miller" <scott@opentrac.org> 6/10/04 12:09:40 PM >>>
>I'll go along with removal of the compressed format
>as long as the Mic-E format goes with it.
>
>Scott
>N1VG
----------------------------------------------------------------------
Subject: Re: APRS capable Satellite Ready for launch
From: Doug Bade <dbade@clecom.com>
Date: Thu, 10 Jun 2004 12:28:14 -0400
X-Message-Number: 43
You might try AMSAT ECHO for a google search, as it is their
satellite. ECHO is for E as in Phase 3E series....
Doug
KB8GVQ
>This is kind of off-topic, but who chose that name? Might cause a little
>confusion, or at least make it hard to Google for relevant info.
>
>Scott
>N1VG
----------------------------------------------------------------------
Subject: RE: Compressed Positions
From: Doug Bade <dbade@clecom.com>
Date: Thu, 10 Jun 2004 12:27:41 -0400
X-Message-Number: 44
I think the stats were 7% of the packets sent are Mic-E packets, I think
that is unfair, and an unjust request....I for one use 8 public service
event radio/trackers which are pic-e/mic-e transmitters, and as they
actually do monitor for channel activity unlike some other encoders, I
think they can stay.. thank you very much !!!!!
Doug
KB8GVQ
>>1) Because it has been replaced with the !DAO! constuct
>> a) Which gives resolution to 7"
>> b) INCLUDES Datum (so it is meaningful)
>> c) can be human readable to 6 feet
>> d) is 100% backwards compatible to all HW and software
>
>I'll go along with removal of the compressed format as long as the Mic-E
>format goes with it.
>
>Scott
>N1VG
----------------------------------------------------------------------
Subject: RE: Compressed Positions -was- Re: Tetrooncollateral damage report,
revision1
From: "Matt Werner" <kb0kqa@arrl.net>
Date: Thu, 10 Jun 2004 11:25:47 -0500
X-Message-Number: 45
>>1) Because it has been replaced with the !DAO! constuct
>> a) Which gives resolution to 7"
>> b) INCLUDES Datum (so it is meaningful)
>> c) can be human readable to 6 feet
>> d) is 100% backwards compatible to all HW and software
>
>I'll go along with removal of the compressed format as long as the Mic-E
>format goes with it.
It was already pointed out by someone that if you do away with the
compressed format, you'll need to keep it in the spec for those that
transmit in it now and aren't going to upgrade their software or practices.
It was in the spec, it should stay there (at least in a receive
capability). To eliminate it cold will leave your users out there hanging
- thinking that they are transmitting valid data (it WAS in the spec) when
they are actually transmitting garbage (it ISN'T in the spec now, as you
propose).
If it is in there for receive only, then that doesn't stop anyone from
transmitting it (since others have to receive it).
Thus, what have you accomplished? Bob, you've already stated that you wish
people would stop using it. I don't see how you can go further than that
without messing up what people already do.
I'm not saying that you should or shouldn't get people to stop using it,
only that deleting it from the spec all-together would not be a wise choice
(in my eyes anyway).
Also, Bob (or anyone), if you're going to personally attack me as you have
others then please don't bother responding. I don't need a personal attack
for offering my opinion (thanks anyway).
73 - Matt
KB0KQA
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
