OpenBCM V1.07b12 (Linux)

Packet Radio Mailbox

DB0FHN

[JN59NK Nuernberg]

 Login: GUEST





  
ZL3AI  > APRDIG   13.07.04 21:24l 746 Lines 29196 Bytes #999 (0) @ WW
BID : 3576-ZL3AI
Read: GUEST
Subj: TAPR Digest, Jul 09, 1/2
Path: DB0FHN<DB0FOR<DB0SIF<DB0EA<DB0RES<ON0BEL<CT4DK<ZL2TZE<ZL2TZE<ZL3VML
Sent: 040713/1943Z @:ZL3VML.#80.NZL.OC #:27811 [Chch-NZ] FBB7.00i $:3576-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To  : APRDIG@WW

TAPR APRS Special Interest Group Digest for Friday, July 09, 2004.

1. Re: Power, Path & Digis
2. TNC's
3. RE: TNC's
4. Re: Lat / Lon text file to map track
5. Re: Power, Path & Digis
6. Re: Lat / Lon text file to map track now .POS
7. Re: [ui-view] Repeater Overlays
8. Re: Repeater Overlays
9. Re: Repeater Overlays
10. Re:  Repeater Overlays
11. Re: Repeater Overlays
12. Re: Power, Path & Digis
13. Re: Repeater Overlays
14. Re: Power, Path & Digis
15. migration to 9600/70cm
16. Re: migration to 9600/70cm
17. Re: migration to 9600/70cm
18. Has anyone tried 9600 for APRS ?
19. Re: How fast can you transmit APRS ?
20. Re: How fast can you transmit APRS ?
21. Re: How fast can you transmit APRS ?
22. Re: migration to 9600/70cm
23. Super Tiny DIgipeater
24. Re: TNC's
25. Is any one using an ALINCO DR 620 on APRS ?? Mine won't work .
26. Symbols
27. RE: Symbols

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

Subject: Re: Power, Path & Digis
From: "Peter Maxfield" <pete@petemaxfield.com>
Date: Thu, 8 Jul 2004 22:45:28
X-Message-Number: 1

Well, I'm back!

Coverage was better than expected, even in the desolate areas of I-80 in PA

http://geo.aprsworld.net/map/track.phtml?call=W1LBR-9&skipTable=0&skipBogusChec0
k=&start_year
04&start_month=7&start_day=4&start_hour=3&start_minute=27&end_year
04&end_month=7&end_day=9&end_hour=0&end_minute=0&start_weeks=0&start_days=0&sta_
rthours=&start_minutes=0&end_weeks=0&end_days=0&end_hours=&end_minutes=0

My daughter was able to see where we were via aprsworld.  We couldn't even 
suprise her that we were coming home a little early!

I only received 1 message during my trip, and that was to remind me that 
stationary vehicles should transmit every 30 minutes. I think it was an 
autoamtic message.

I do have ct enabled on the aprs freq. and keep the volume up a little to 
hear any nearby packets, but only heard 3 or 4 the whole trip.

146.52 was desolate. I heard a qrz around 3 AM, but couldn't call back in 
fear of waking the wife and dogs (bulldogs)

I had two little problems and don't know how to address them:
1. As you travelacross the United States, you receive a lot of packets.  i 
mean a lot!  I had to clear out the waypoints in my Garmin GPS III+ twice.  
This is tedious when you are traveling at 70+ MPH

Does anyone know a way to just overwrite these waypoints?

2. I also received an error message on the Garmin stating that "Invalid 
waypoint received".  You have to press enter to get past this message and 
restore the display.  Has anyone else had this problem and a way to filter 
out the culprit packet.  I wouldn't even know where to begin to try and 
"catch" the packet to review it

BTW, it is much easier to leave the aprs menu up on the bottom of the 
screen, thanx Bob!

So overall, IMO, the idea of tracking my location on a long trip was 
interesting, but not as valuable as using it in a local tactical program 
for measuring and coordinating response.
 Are their APRS coordinators for areas of the US? How would I contact 
then?

I have been unsuccesful in hooking up my notebook to the D700 to look at 
the data.  I just received a new cable db9f/db9f.  I'll keep trying with 
hyperterminal to get a connection.

Again, thanx to all who read my post and many thanx who took the time to 
reply!

73, 
de, W1LBR 
Peter

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

Subject: TNC's
From: "Peter Maxfield" <pete@petemaxfield.com>
Date: Thu, 8 Jul 2004 23:1:59
X-Message-Number: 2

Hello again!

With all the TNC's out there for sale, how does one new to aprs, such as 
myself, find out which tnc's can be used successfully for aprs?

I know next to nothing anyway, and even less still about packet. I read 
about different revision levels, Pactor, Kiss, Amtor.... AAAGGHH! I'm 
starting to hyperventilate!

My goal is to evaluate cost/functionlity of a standalons home station to 
monitor local activity instead of using aprsworld and findu.

I'm only interested in vhf APRS and maybe the local EOC packet frequency we 
use for skywrarn (145.760 tel-pac/pac-link)

Ebay always has a few tnc's avaialble, but without knowing which will work, 
I probably will purchase something that will not work for me.  Has anyone 
compiled a list of "compatible" tnc's?

thanx in advance for your time, effort and patience with me, especially 
patience!

73, 
Peter W1LBR

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

Subject: RE: TNC's
From: "Larry Cerney" <lcerney@viawest.net>
Date: Thu, 8 Jul 2004 23:17:16 -0600
X-Message-Number: 3

Peter,

I use a couple of Kantronics KPC3+'s that have worked great for me on VHF.
I also have Paccomm PicoPacket which works, but has never held its
configuration.  A real pain when you're doing GPS and APRS and the whole
configuration needs to be reinput every day.  I would not recommend them.
There are other TNC's out there and I'm sure others folks will fill you in
on them.

73....
Larry
K0ANI

"There is a theory which states that if ever anyone discovers exactly what
the Universe is for and why it is here, it will instantly disappear and be
replaced by something even more bizarre and inexplicable. 
 
There is another theory which states that this has already happened."
 
unknown....

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

Subject: Re: Lat / Lon text file to map track
From: "Bill Vodall" <wa7nwp@jnos.org>
Date: Thu, 8 Jul 2004 22:22:45 -0700
X-Message-Number: 4

>I need to find a way to display a latitude / longitude
>text file as a track on a map.  I have Street Atlas
>and PM.  Anybody know a way to import Lat / Lon text
>file into a map program?  Or Using WinAPRS or SA+? Or
>Waypoint+ & convert to GPL file?

Street Atlas+  (version 7 at least) has it built in.   See the command
FILE - IMPORT LAT/LONG FILE.

I've been using it just today to map some low power "microwave" stations
in my neighborhood...   :-)      Only took a few minor changes to the script
that created ".POS" files to create the lat/long file for SA+...

73
Bill - WA7NWP

---  some low power microwave stations in SA+ format ---

46.6485667,-122.9564833,CSD_1_ESS,47,1,1
46.6603167,-122.9621167,linksys_6_ESS_Pollable,47,1,1
46.6617000,-122.9668667,'X-Box Net.'_6_ESS_WEP_Short,47,1,3
46.6620500,-122.9688167,USR8054_11_ESS_Short_PBCC,47,1,1
46.6619333,-123.0126667,NETGEAR_11_ESS_Short,47,1,1
46.7063833,-122.987,linksys_11_ESS,47,1,1
46.7090333,-122.9869167,network_6_ESS_WEP_Short,47,1,3
46.7084500,-122.9869333,NETGEAR_11_ESS_Short,47,1,1
46.7118333,-122.9869667,SST-PR-1_6_IBSS_WEP,47,1,3
46.7138333,-122.9960333,linksys_6_ESS,47,1,1
46.7138000,-122.9989333,WLAN_11_ESS,47,1,1
46.7128667,-123.00105,Wireless_11_ESS,47,1,1
46.7137333,-123.0064667,default_6_ESS,47,1,1
46.7169167,-123.0190833,home_10_ESS_PBCC,47,1,1
46.7355667,-122.99975,linksys_6_ESS,47,1,1
46.7356000,-123.0045333,BRIDGE_11_ESS,47,1,1
46.7321667,-123.0217,hpsetup_10_IBSS,47,1,1
46.7357667,-123.01955,MLINK_1_ESS_WEP,47,1,3
46.7327333,-122.9996333,wireless_6_ESS,47,1,1
46.7321833,-122.9996667,basin_2_ESS,47,1,1
46.7299833,-122.9997,megyesi_11_ESS_Short,47,1,1
46.7283667,-122.9997167,linksys_6_ESS,47,1,1
46.7271167,-122.9962167,VianHome_10_ESS_WEP,47,1,3

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

Subject: Re: Power, Path & Digis
From: "Rich Mazzeo" <forummail@richmazz.com>
Date: Fri, 9 Jul 2004 01:35:27 -0400
X-Message-Number: 5

Most db9f to db9f cables I have seen are crossover cables meant for
networking 2 PCs via their serial ports. This will not work with the D700.
Test to make sure pin 2 leads to pin 2 on the other end, as well as pin 3 to
pin 3.  If the cable connects pin 2 to 3 and 3 to 2, you have a crossover
cable.

>I have been unsuccesful in hooking up my notebook to the D700 to look at
>the data.  I just received a new cable db9f/db9f.  I'll keep trying with
>hyperterminal to get a connection.

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

Subject: Re: Lat / Lon text file to map track now .POS
From: "Bill Vodall" <wa7nwp@jnos.org>
Date: Thu, 8 Jul 2004 22:48:31 -0700
X-Message-Number: 6

>I've been using it just today to map some low power "microwave" stations
>in my neighborhood...   :-)      Only took a few minor changes to the script
>that created ".POS" files to create the lat/long file for SA+...

I found the old file for an example.   Here's what a .POS (position) file
looks like with "low power microwave" stations...   

----

linksy007!4743.28N/12207.75W/  linksys 000625532d52 BBS signal=81 noise=50
defaul002!4743.28N/12207.69W/  default 00904b083444 BBS signal=84 noise=51
defaul003!4743.26N/12207.79W/  default 00055dd9e093 BBS signal=56 noise=50
DESTRYHOM!4743.26N/12207.78W/  DESTRYHOME 00062554a372 BBS signal=57 noise=50
WLAN001!4743.19N/12207.81W/  WLAN 0090d100bd6a BBS signal=83 noise=51
JWGHome!4743.22N/12207.80W/  JWGHome 005018065ce2 BBS signal=71 noise=51
wireless!4743.25N/12207.33W/  wireless 000124f0a02f BBS signal=76 noise=51
linksy008!4743.22N/12207.12W/  linksys 00045af61c86 BBS signal=76 noise=50
HOMELAN!4743.17N/12207.17W/  HOMELAN 00022d1c7c5b BBS signal=75 noise=51
defaul004!4743.09N/12207.21W/  default 00055da76f7a BBS signal=58 noise=53
SpeedS001!4742.73N/12207.28W/  SpeedStream 000124f0c734 BBS signal=67 noise=50
linksy009!4742.24N/12207.78W/  linksys 00062553d4cb BBS signal=60 noise=50
wirele001!4742.11N/12207.40W/  wireless@home 00501804cfa4 BBS signal=68 noise=48
defaul005!4742.02N/12207.40W/  default 004005b28de9 BBS signal=68 noise=50
SSID!4741.88N/12207.42W/  SSID 00022d2f1740 BBS signal=74 noise=50
wetnet!4741.89N/12207.50W/  wetnet 00501809bb88 BBS signal=98 noise=50
WLAN002!4741.89N/12207.46W/  WLAN 000124f070f6 BBS signal=82 noise=50

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

Subject: Re: [ui-view] Repeater Overlays
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Fri, 09 Jul 2004 08:27:24 -0400
X-Message-Number: 7

>>>Fritz Anderson <fritza@manoverboard.org> 7/8/04 2:46:07 PM >>>
>Reviewing the symbol table in the spec, I don't 
>see a "radio" symbol.  Would that be /r, "Antenna"?

My fault.  Yes, originally I tried to make all the symbols have a
reasonable association with their character, so I always remember that one
as radio antenna "r"

>I see a lot of stations posting ... voice repeaters as 
>/m, which the protocol spec lists as "Mic Repeater." 
>... I wasn't aware there was such a thing as a Mic-E 
>repeater 

I agree completely that the Mic-Repeater is not a common occurrence as it
was intended back in 1994 when we came up with it.  My original Mic-E was a
little match box sixed PIC that would add your APRS data in a 0.3 sec tone
burst on the end of an occassional voice trnamissimion.  The repeater would
filter it out so that no-one heard it and yet, then everyone with only one
radio in the car would be on APRS too even while normally QSO'ing on voice.

What basically killed this evolution was the Kenwood APRS dual band radios.
Since the D7 and D700 have DUAL band there is no need to put the data on
the end of a voice transmission since the radio can do dual channels all
the time and therefore operate on the APRS channel directly.

Thust there was no incentive for people to build Mic-E's nor to develop
Mic-E-Repeaters to receive the combined voice and data...  The kenwood does
have the PTT mode built in, but I dont know of anyone that uses it.

But people could!.   Then they would be able to use the radio for DUAL
voice channels all the time.  Just as long as one of the channels is used
on a Mic-E repeater channel...

de WB4APR, Bob

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

Subject: Re: Repeater Overlays
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Fri, 09 Jul 2004 08:30:23 -0400
X-Message-Number: 8

I'm confused.  All OVERLAY files are supposed to have the .POS extension
and are all kept in the \POS sub directory...  Bob

>>>Fritz Anderson <fritza@manoverboard.org> 7/8/04 2:57:49 PM >>>
This probably won't come up as a practical matter, but can I put a word in
for distinct file name extensions for distinct file types? .shp files are
shapefiles, .geo files are geofiles, .map files are Mac/WinAPRS maps
(unless the parser chokes, in which case I try again as APRSdos...), but
for every other file in the world, I have to open it and see if lines 3
through 7 contain at least one item string (so it's a POS file). And this
is just to validate a drag-and-drop.

Grumble.

	73 de WT9T=
	-- F

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

Subject: Re: Repeater Overlays
From: Fritz Anderson <fritza@manoverboard.org>
Date: Fri, 9 Jul 2004 07:46:46 -0500
X-Message-Number: 9

Then it is no doubt I who am confused... I took the zipped compendium of
POS files, with names like NWR.MID, RSHACKS.EAS, etc., as authoritative.
I'm glad to know people are supposed to rename them before use. This was
probably even documented, and I was too clueless at the time to notice.

I'm learning a lot by putting out my assumptions like this. I think this is
a good thing (for me), and I'm really grateful to everyone who is putting
up with it!

	73 de WT9T
	-- F

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

Subject: Re:  Repeater Overlays
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Fri, 09 Jul 2004 08:51:38 -0400
X-Message-Number: 10

And the advantage of the Mic-E PTT mode is that it allows full APRS
tracking with only one radio in the car AND it is as portable from one car
to the next as simply moving a microphone...

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

Subject: Re: Repeater Overlays
From: "Spider" <spider@rivcom.net>
Date: Fri, 9 Jul 2004 05:57:08 -0700
X-Message-Number: 11

----- Original Message ----- 
From: "Robert Bruninga" <bruninga@usna.edu>

>I'm confused.  All OVERLAY files are supposed to have
>the .POS extension and are all kept in the \POS sub
>directory...  Bob

If they are APRS Overlays.  Remember, some software, like UIView running
with Pmapserver can use *.OVR overlay files built by a non APRS application.

Jim, WA6OFT

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

Subject: Re: Power, Path & Digis
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Fri, 09 Jul 2004 09:08:24 -0400
X-Message-Number: 12

>>>"Peter Maxfield" <pete@petemaxfield.com> 7/8/04 10:45:28 PM >>>
>Coverage was better than expected, even in the 
>desolate areas of I-80 in  PA
>My daughter was able to see where we were via aprsworld....
>
>I do have ct enabled on the aprs freq. and keep the 
>volume up a little to hear any nearby packets, but only 
>heard 3 or 4 the whole trip.

Yes, APRS voice alert is a rare occurrence, so keep the volume up ALL THE
WAY, so you dont miss an opportunity when you get one...

>2. I also received an error message on the Garmin...
>"Invalid waypoint received".  You have to press enter 
>to get past this message and restore the display.

Yes, these are OBJECTs that people are placing on APRS with names such as
"146.76" or whatever that have punctuation marks in the object name. This
is not good practice.  We have recmmended to OMIT the decimal point and use
frequencies in KHz such as 146520 or to use a DASH as 146-52

>BTW, it is much easier to leave the aprs menu up on 
>the bottom of the  screen, thanx Bob!

Yes, it is AMAZING how many D700 users don know of setting the display mode
to MODE-3!  It makes APRS trivial to oeprate while mobile instead of a"nice
burried feature"...

>I have been unsuccesful in hooking up my notebook
>to the D700 to look at the data.  I just received a new 
>cable db9f/db9f.  I'll keep trying with 
>hyperterminal to get a connection.

Should work.  Just hit the TNC button twice to get it into PACKET mode and
you have to use the RADIO MENU-TNC to set the right band, etc...

Bob

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

Subject: Re: Repeater Overlays
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Fri, 09 Jul 2004 09:19:48 -0400
X-Message-Number: 13

>>>Fritz Anderson 7/9/04 8:46:46 AM >>>
>Then it is no doubt I who am confused... I took the zipped 
>compendium of POS files, with names like NWR.MID, 
>RSHACKS.EAS, etc., as authoritative. I'm glad to know 
>people are supposed to rename them before use.

OOPS, my fault again.  I forgot about that in ARPSdos. Yes, since they are
all in the /POS directory. I assumed there would be no confusion, so I
added the .XXX extension to match the 5 different major distributions of
APRSdos maps so that the correct .POS file would be used for each area...
This allowed me to keep the file sizes down for each distribution.

But in APRSdos, you dont have to rename, them.  Those come up automatically
when you select WRECKS, RShacks, etc from the menu.  But any other named
file will need to have the .POS externsion probably to be used with other
versions of APRS that are not APRSdos?

Bob

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

Subject: Re: Power, Path & Digis
From: Jason Winningham <jdw@eng.uah.edu>
Date: Fri, 9 Jul 2004 08:27:44 -0500
X-Message-Number: 14

On Jul 9, 2004, at 8:08 AM, Robert Bruninga wrote:
>...MODE-3!  It makes APRS
>trivial to oeprate while mobile instead of a"nice burried
>feature"...

It sure is nice, but it would be even nicer if I could pick and choose. 
  For example, I'd gladly trade "PMON" for the transmit power button.  
Is there a way to pick and choose specifically which function is tied 
to which button combination?

-Jason
kg4wsv

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

Subject: migration to 9600/70cm
From: wes@johnston.net
Date: Fri, 09 Jul 2004 13:21:36 -0400 (EDT)
X-Message-Number: 15

Given that APRS has hidden transmitter problems making it difficult for the
local users to hit nodes due to competition with distant stations
propagating in, and that APRS needs to transition to higher baud rates,
here is one possible solution.

Super node idea.
The node has three receivers and two transmitters.  The frequencies in this
example are just examples... nothing set in stone yet. 

Main RX is on 446.100/9k6, main tx on 446.100/9k6. 
User input port is RX only on 441.100/9k6
Legacy access port is 144.39/1k2

There are several points to address.
1) users need a migration path from 1200 to 9600 without loosing contact
with other locals.

2) during the migration, everyone LOCAL needs to be able to talk to LOCAL
users of the other baud rate.

3) mobile 9k6 is going to have a limited range, mobile 440 even worse, so
let's allow the mobiles to stay on 144.39

4) Hidden transmitter problems give mobile's hell.

5) Hidden transmitter problems give home stations hell.

6) We have to use 70cm because it allows the kenwood users to access 9600
when they are stationary.

7) By using 2m/70cm, if the digi fails it will be entirely possible that the
users could QSY to 144.39 or the 70cm simplex.

8) all IGATES will pickup traffic off of the 70cm frequency.

9) mobiles and old stations will still use 144.39.  They won't see much
there, so home stations on 144.39 are encouraged to migrate to 440/9k6.

10) 9600 is available cheaply with a sound card for $20.

11) Digi's must be smart enough to gate messages and IGATE traffic to the
mobiles still on 144.39.

My proposed solution is to basically cripple 144.39 by making it a "local
only" thing.  It will be there for the mobiles, but it will no longer
propagate packets along multiple hops.  By not allowing packets to
propagate outward more than just a single bounce off a digi on 144.39, we
stop congestion at the next tier outward.  For example, my mobile in Town A
no longer has to compete with packets streaming in from Town D or Town E.
It's like a firewall which allows  LAN users to be isolated from the WAN
area.  (It should be noted that the LANn-n idea effectively does the same
thing).  By continuing to support 144.39 however, we still provide a
service for the transient mobile users.  They will see the digipeat of
their packets on 144.39, but the path will be stripped away, so that no
other digipeater on 144.39 will repeat their packets.  Their packets will
end up propagating on 70cm as you will read later.

Now for the Main 446.100 digipeater.  This digi will function just as the
WIDEn-n digipeaters do today.  It can support LANn-n, or widen-n, doesn't
matter.  It will function just like the existing APRS network we know
today, but on 70cm at 9k6.  It will hear packets from other digipeaters and
repeat the ones that are eligible to be digipeated.  It is important to
note that this is a SIMPLEX digipeater.  It hears and TX's on 446.100 for
example.  While it will be permissible for a user to send a packet on
446.100, he would have to compete with packets from other digipeaters on
446.100 (keep reading for that solution). Also, most user gear has really
long txdelays (on the order of 300ms) which wastes tremendous amounts of
time on 9600.  As a rule, if you TX on 446.100, you must have a decent
radio with <50mS TXD.

There will be an alternate USER INPUT PORT on 70cm... say it's on 441.100.
Users wishing to get into the node will TX on 441.100 at 9k6.  They will
only have to compete with other local users.  If two super nodes are nearby
each other, it will be permissible to stagger one of their user port input
frequencies, so long as they stay approximately 5mhz apart (for example,
this input frequency of the nodes would be 441.995, 441.100, 441.105, and
those frequencies would be reused as geography permitted).  It will be
important for each node to ID it's 70cm frequencies for users new to the
area.  Now, since there are relatively few packets which will be
transmitted by other stationary 9600 baud users, the competition for this
input frequency is greatly reduced.  Consider that the average mobile is
TX'ing a packet once a minute, and it bounces three times. That is
effectively 3 packets / min.  Now you consider that there are only 4 mobile
users in our area.  A home station trying to TX once every 10 or 30 minutes
has to slip in the digipeater between 12 packets / minute from the local
mobiles.  Now if that home user had his own input frequency into the
digipeater that he only had to compete with 4 or 5 other home stations
transmitting every 10 minutes, the likely hood of a collision is VERY low.
I suppose it could be permissible to have simple RELAY only digipeaters on
441.100 if the 446.100 antenna was very low (if you didn't have a duplexer
to allow the same antenna for 446.100/441.100)

THE FLOWCHART..

Packets heard on 144.39.....

1) they are presented to the 446.100 TNC unaltered to propagate on the 70cm
9600 digi network using the paths we're all familiar with today like WIDE
and TRACE.

2) their paths are stripped and they are presented to the 144.39 TNC where
they only appear ONE TIME on 144.39 and do no digipeat again if heard by
another 144.39 digi.  Digi-NED can do this for us.

Packets heard on 441.100 (or the other nearby frequencies)....

1) are passed forward and presented to the 446.100 TNC unaltered to
propagate on the 70cm 9600 digi network.

2) have their paths stripped off and are passed to the 144.39 tnc.  This
allows local 70cm users to talk to local 144.39 users.

Packets heard on 446.100

1) are digipeated just as in the APRS network today.  WIDEn-n, LANn-n, you
name it.....  Since this is the output frequency of the local 70cm
digipeater all users on 70cm see this traffic.

**********************************************************
Take this packet for example as heard on 144.39:
W1GRE>APW275,RELAY,WIDE3-3:=3259.46N/08013.96W-PHG7130/<630>

It gets digipeated back onto 144.39 with the path stripped and callsign sub'ed.
W1GRE>APW275,KC4PL-1*:=3259.46N/08013.96W-PHG7130/<630>

It also gets digipeated onto 446.100 just as on a regular APRS digi....
W1GRE>APW275,KC4PL-1*,WIDE3-3:=3259.46N/08013.96W-PHG7130/<630>

Note that this packet generated TWO copies.... one on 144.39 which will go
nowhere, and one on 70cm 9k6.

**********************************************************

Now, take the same packet heard on 441.100
W1GRE>APW275,RELAY,WIDE3-3:=3259.46N/08013.96W-PHG7130/<630>

It ends up on 446.100 just like a normal APRS packet gets digipeated today.
W1GRE>APW275,KC4PL-1*,WIDE3-3:=3259.46N/08013.96W-PHG7130/<630>

It also gets digipeated back onto 144.39 with the path stripped and callsign
sub'ed.
W1GRE>APW275,KC4PL-1*:=3259.46N/08013.96W-PHG7130/<630>

**********************************************************
Now, consider that the same packet is heard on 446.100 by the next super
NODE in the line...
W1GRE>APW275,KC4PL-1*,WIDE3-3:=3259.46N/08013.96W-PHG7130/<630>

This would be digipeated onto 446.100 just like a normal APRS packet gets
digipeated today.
W1GRE>APW275,KD4HTW-1*,WIDE3-2:=3259.46N/08013.96W-PHG7130/<630>

**********************************************************

Things to work on would include getting DX messages which do not originate
on the "local alternate input frequency" on 70cm down to the mobiles (or
legacy users) as needed on 144.39.  IGATES already do this from the
internet to RF, so it's not really a major hurdle.

Wes

ham callsign: kd4rdb
find me: http://wesvan.zapto.org

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

Subject: Re: migration to 9600/70cm
From: wes@johnston.net
Date: Fri, 09 Jul 2004 13:54:02 -0400 (EDT)
X-Message-Number: 16

Well, the mobiles would see the LOCAL infrastructure using my proposal.
They would not see the DX stuff.  Heck, I run around with my position limit
on the kenwood set to 100 miles just so my GPS screen doesn't redraw all
the time.  

The idea of a digipeater caching objects and transmitting them at later
times was discussed recently here in the whole opentrac debacle.  If
implemented it needs to be coordinated between the station being cached and
the digipeater so that stations can eventually expire... but you probably
intended that anyway.

Wes

On Fri, 09 Jul 2004 12:34:01 -0500, Jim Duncan wrote:
>I say leave 1200 baud to purely mobile stations. Those would still get
>to the network and to home stations using 9600 on 70cm.... Only problem
>I see is that the mobile user can no longer see the infrastructure
>around him, therefore I propose the following addition to Wes's
>proposal:
> 
>Once every xx minutes the local node broadcasts a "burst" which includes
>every station heard within the past xx minutes within xx miles of
>itself. This will update all of the mobiles who are using laptops,
>PDA's, etc.

ham callsign: kd4rdb
find me: http://wesvan.zapto.org

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

Subject: Re: migration to 9600/70cm
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Fri, 09 Jul 2004 13:47:55 -0400
X-Message-Number: 17

>Super node idea.
>The node has three receivers and two transmitters.  
>Main RX is on 446.100/9k6, main tx on 446.100/9k6. 
>User input port is RX only on 441.100/9k6
>Legacy access port is 144.39/1k2

Biggest problem I see with this idea is that by having the big digi simply
move to 70 cm and operate at 9600 baud

1) Still has the hidden transmitter problem

2) still has TXD delays on every packet

3) SUch a sdesign will definately need a bundeling process so that up to 7
packets are bundled into one TXD burst so the channel can still work as
true CSMA among all the digis that can hear eachother...

That would result in still a 1 second packet so that it does not add more
than a second or so latency to the network...

The way to use 9600 baud is like the APRS-IS.  It is constant key-down on
one TX channel and it carries everything (the backbone).  In this case, you
DO get an 8 fold increase in capacity (but of little use to a mobile)....
Users who want to tune in all that junk from all over the state, are
welcome to tune it in.  But the mobiles still send/rx on 144.39

See some of the UHF concepts at the bottom of

http://www.ew.usna.edu/~bruninga/aprs/fix14439.html

But I agree completely, that we need multiple channels separate inputs and
9600 baud backbones...

Bob

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

Subject: Has anyone tried 9600 for APRS ?
From: "Andrew Rich" <vk4tec@hotmail.com>
Date: Sat, 10 Jul 2004 05:18:41 +1000
X-Message-Number: 18

What is the performance like mobile ?

I know I see 1200 baud hit by mobile flutter some times.

Does the shorter packets help ?

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

Subject: Re: How fast can you transmit APRS ?
From: "Andrew Rich" <vk4tec@hotmail.com>
Date: Sat, 10 Jul 2004 05:27:13 +1000
X-Message-Number: 19

Has anyone tried on simplex tests to see how fast you can transmit packet ?

Has anyone wound the tinytrak up as fast as it will go ?

My GPS will update every 2 seconds.

Imagine a rac car, or a a jet.

How fast is the fastest 1200 baud transmission ?

Cheers 

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




Read previous mail | Read next mail


 29.11.2020 05:37:59lGo back Go up