OpenBCM V1.13 (Linux)

Packet Radio Mailbox

DB0FHN

[JN59NK Nuernberg]

 Login: GUEST





  
ZL3AI  > APRDIG   28.10.03 15:19l 245 Lines 9910 Bytes #999 (0) @ WW
BID : 2223-ZL3AI
Read: GUEST
Subj: TAPR Digest, Oct 26, 2/5
Path: DB0FHN<DB0RGB<DB0MRW<OK0PKL<OK0PCC<OK0PAD<OK0PPL<DB0RES<ON0AR<7M3TJZ<
      IK1ZNW<ZL2TZE<ZL3VML
Sent: 031028/1240Z @:ZL3VML.#80.NZL.OC #:11457 [Chch-NZ] FBB7.00i $:2223-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To  : APRDIG@WW

Subject: Re: Whoa, wait a minute [was: A Low-Tech APRSteward	Proposal]
From: Steve Jones <s.jones@rogers.com>
Date: Sun, 26 Oct 2003 09:11:08 -0500
X-Message-Number: 6

on 10/26/03 8:43 AM, Bob Bruninga at bruninga@usna.edu wrote:

>Transmit it only once during the day, and my radio captures it and that
>is one less message I can get from anyone else.  Once my memory is full,
>then I cannot receive any other messages from anyone.

IIRC, this only affects the people running Kenwood equipment?

-- 
Steve <s.jones@rogers.com>

----------------------------------------------------------------------

Subject: Re: Coiled Coax Loss
From: Rich Osman <Rich@osman.com>
Date: Sun, 26 Oct 2003 08:22:18 -0600
X-Message-Number: 7

Allan,

You've omitted most of the pertinent details.

1) what type of coax?  (of this is RG-8 1 foot is probably below the 
minimum specified bend radius of the cable, there are also a bunch of 
other part number specific things to be considered.)

2) have you measured the match (VSWR) on the antenna? (best do this on 
the **antenna** end, coax loss makes it look better than it really is)

3) Have you tried stringing the coax out, but operating with the antenna 
close to the radio? (are you interfereing with the digi when the antenna 
is close?)

----------------------------------------------------------------------

Subject: Re: Whoa, wait a minute [was: A Low-Tech APRSteward  Proposal]
From: "Ev Tupis (W2EV)" <w2ev@arrl.net>
Date: Sun, 26 Oct 2003 09:27:07 -0500
X-Message-Number: 8

>>This is not a one-size-fit's-all
>>proposal.  It allows for LAN's to setup their APRSteward to TX only as
>>often as it makes sense in the LAN.  Geez, this is much too simple.
> 
>Transmit it only once during the day, and my radio captures it and that
>is one less message I can get from anyone else.  Once my memory is full,
>then I cannot receive any other messages from anyone.

No kidding?  You have 10 slots for BLN's and when you've received 10, you
can get no more?  Maybe someone should be keeping a list of the stuff that
Kenwood needs to change in their next ROM so that it doesn't keep the state
of the APRS art from advancing. :)

I understand your predicament now.

Maybe the BLN: mode is the wrong one.  Maybe a simple MSG, then?  The
concept of user education is a good one...maybe the mode is all that needs
to be changed?

>My suggestions put the power to improve in thehands of the SYSOPS in a
>consistent way.

Maybe it's time for you to define the next generation of digipeater ROM
characteristics.  We seem to have reached that point.  Once an "openly
developed" and "flash upgradable" stand-alone network control appliance
exists, such advancements can come along more readily.

>We have been trying for 5 years to solve the problems by user education
>and it has not worked AT ALL.  AND we also have SOLID EVIDENCE that
>attempting to send users "corrective info" over the air has not worked
>either.  So I am not "opposed" to your idea, its just that we have every
>indication that it will do nothing to solve the problems an dwill only add
>more problems than it is worth.
> 
>Nothing personal, that's just the facts...

Things must be quite different in Washington DC than they are in the
Toronto-Buffalo-Rochester crescent.  I've never seen any attempt at user
education using RF APRS...and I lurk 24/7 on 144.39 -- and have been for
over 11 years now.  I see WX stations TXing every couple of minutes,
mobiles with very annoying TX intervals and digipeaters with UNPROTO's that
make me scratch my head at times.

Oh well...nothing taken personally (and hope the same in return).  I simply
see a huge potential for the APRS service beyond what it already is today
and am trying to offer constructive input for consideration.

Best regards,
Ev

----------------------------------------------------------------------

Subject: BASIC program for TNC use
From: "Ev Tupis (W2EV)" <w2ev@arrl.net>
Date: Sun, 26 Oct 2003 09:36:26 -0500
X-Message-Number: 9

I'm interested in performing some mental gymnastics and hoping that someone
on-SIG can help me.

Is there anyone willing to share any BASIC (GW- or Q) sourcecode that
interacts with a KISS-TNC and parses for APRS-compliant stuff?  It's sort
of a general request, but I'd like to play a little, and thought I could
build on something that already exists.

What have you, please? ;)
Ev, W2EV

----------------------------------------------------------------------

Subject: Test Message
From: Tim Schall <grover@fortgirlfriend.com>
Date: Sun, 26 Oct 2003 07:42:58 -0800
X-Message-Number: 10

Blah

----------------------------------------------------------------------

Subject: Re: Using a BS2 to gerate packet tones ?
From: "Douglas Quagliana" <dquagliana@hotmail.com>
Date: Sun, 26 Oct 2003 18:31:18 +0000
X-Message-Number: 11

Andrew Rich asks:
>There are lots of Basic Stamps that do FREQOUT Could you use this for 
>packet tones ?

If you want to just generate the 1200 Hertz and 2200 Hertz packet tones,
just to test something (not actually send packets) then yes.  You can
generate those "packet tones" with FREQOUT.

Can you actually send 1200 baud AX25 packets by using FREQOUT?  Probably
not.  I don't remember the minimum duration for a tone generated by FREQOUT
on a BS2, but I think it was longer than the time for one bit at 1200 baud.
(I think it was longer than 1/1200 of a second).

While I haven't tried it on a Basic Stamp, I'd think a resistive bridge
connected to four of output pins might be a better option.  I think this is
what the TinyTrak uses, and I think this is what the NJQRP's PSK31 beacon
uses (it does PSK31 on a PIC).  Of course, you will need to toggle the pins
quite quickly, and I'm not sure you can do that fast enough through BASIC
on the Basic Stamp.

Douglas KA2UPW

----------------------------------------------------------------------

Subject: Re: Using a BS2 to gerate packet tones ?
From: David VanHorn <dvanhorn@cedar.net>
Date: Sun, 26 Oct 2003 13:52:12 -0500
X-Message-Number: 12

>While I haven't tried it on a Basic Stamp, I'd think a resistive
>bridge connected to four of output pins might be a better
>option.  I think this is what the TinyTrak uses, and I think
>this is what the NJQRP's PSK31 beacon uses (it does
>PSK31 on a PIC).  Of course, you will need to toggle the pins
>quite quickly, and I'm not sure you can do that fast enough
>through BASIC on the Basic Stamp.

Realtime tasks with sub-millisecond resolution, are not well suited to
interpreted languages. 

Even in a PIC, this would not be a problem in assembler.

----------------------------------------------------------------------

Subject: The real problem.
From: Tim Schall <grover@fortgirlfriend.com>
Date: Sun, 26 Oct 2003 11:05:43 -0800
X-Message-Number: 13

OK, I'm quite sure I'm gonna honk somebody off here but quite frankly, I
don't care.  Get over it.

I sit here and I watch all of us debate the problems and the things that
are wrong with aprs in general and 144.39 in particular.  User education is
a problem, yes, but it's not gonna solve the physics problem of trying to
get ten pounds of crap in a five pound bucket.  'Bad' paths, to densly
packed digis, multiple digis at the same site, 'blow torch' mountain tops,
people that seem to think the only reason this thing exists is to get to
findu so Aunt Martha can watch your whereabouts, stupid - brain damaged
hardware, etc....  All of these things contribute to the mess.

The real problem here is that the 144.39 network is a poorly coordinated, 
unmanaged, mish-mash of crap.  It's a wonder it works at all.  I don't 
believe I'm about to say this, but what's needed is a coordinating body to 
maintain and, for want of a better word, sanctify, digi operations and 
generally over see the operation of 'the network.'  Until somebody has a 
better view of the 'big picture' I doubt that this thing will get any
better.

For what it's worth, I think the idea of having the smart digipeaters
(Sorry guys the Kantronics TNC's are one of the biggest contributers to the
overall mess and they have to go.) manage the paths is the best one yet.
You just spew a packet addressed to region, local, igate, etc.... and let
the digi's swap out the best path for your purpose.  That way, here in the
metro areas of Seattle for instance, we could take 'region' and swap it out
for wide2-2 and get on down the road.  In the middle of the Kansas wheat
fields where the traffic is lighter, 'region' could result in wide5-5 on
even bigger if the smart digi's determined the traffic load to be light
enough.

Oh yeah, this is an RF network guys, things like igates and findu, while 
awesome efforts, are not what it's all about.  We heap lots of work on
findu and things like it but there's no substitute for putting a lot of
this sort of stuff at the local levels and basing it on monitored RF
traffic.

----------------------------------------------------------------------

Subject: Re: Whoa, wait a minute [was: A Low-Tech APRSteward Proposal]
From: Bob Bruninga <bruninga@usna.edu>
Date: Sun, 26 Oct 2003 14:35:10 -0500 (EST)
X-Message-Number: 14

On Sun, 26 Oct 2003, Steve Jones wrote:

>on 10/26/03 8:43 AM, Bob Bruninga at bruninga@usna.edu wrote:
>
>>Transmit it only once during the day, and my radio captures it and that
>>is one less message I can get from anyone else.  Once my memory is full,
>>then I cannot receive any other messages from anyone.
>
>IIRC, this only affects the people running Kenwood equipment?

Yes, all X,000 of them...  And since it is the only fully integrated APRS
radio and it represents 80% of everyone mobile, and APRS is supposed to
serve the mobile community...  It makes sense to me to make sure we dont
do anything stupid to mess up a good thing...

de WB4APR, Bob

----------------------------------------------------------------------



Read previous mail | Read next mail


 23.10.2026 22:14:46lGo back Go up