From stanzepa@mail2.nai.net Fri Oct 02 19:45:25 1998 Received: from mail2.javanet.com (mail2.javanet.com [205.219.162.11]) by tapr.org (8.8.5/8.8.5) with ESMTP id TAA22735 for ; Fri, 2 Oct 1998 19:45:25 -0500 (CDT) Received: from [209.150.33.52] (ct-hartford-us637.javanet.com [209.150.33.52]) by mail2.javanet.com (8.8.8/8.7) with SMTP id UAA04619 for ; Fri, 2 Oct 1998 20:45:22 -0400 (EDT) Message-Id: <199810030045.UAA04619@mail2.javanet.com> X-Mailer: Microsoft Outlook Express for Macintosh - 4.0c (197) Date: Fri, 02 Oct 1998 20:25:58 -0400 Subject: [APRSNEWS:148] APRS Coding and HF Opportunity! From: "Stan Horzepa" To: aprsnews Mime-version: 1.0 X-Priority: 3 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: Bob Bruninga Subject: APRS Coding and HF Opportunity! If you like neat projects, this one is fun and needed. If you can write software of any kind, please read: There is an opportunity for someone to improve our HF performance by a factor of TEN OR MORE with no change in the protocol! Since we have the APRServe system to distribute packets, all we need is ONE OR TWO good HF receive sites to run some special software to use intelligence to pull the weak sigs out of the noise and then digi them for all the rest of us! Here is how: APRS uses 300 baud on HF packet. Packets are typically 100 bytes long or about 800 bits and take 3 seconds to transmit. Lets use W7LUS our 18 wheel vagabond as an example: W7LUS-14>APRS,ECHO,GATE,WIDE,WIDE:@021234z/LAT/LONG$CSE/SPD... This packet is ONLY received if there is not a single bit error in all 800 bits! Thus we need about 10-3 bit error rate or better or we get NOTHING. Most of the time HF is worse than this... There are several things we can do to improve this: 1) Make packets shorter... 2) Allow some errors and fix em or ignore em... STEP1. GATE-ALL. Each digi field actually takes 7 bytes even for short calls. AND we want all HF packets widely distributed anyway, so why not drop ALL the digi fields. THis saves 4*7 or 28 bytes for a 28% improvement! The special software then just always GATES to VHF and the internet using his local path. Done. Easy. STEP2. Error DETECTION: Of the 72 bytes remaining, MANY are not really important. Just keep the last 3 copies of all POSITS for all HF stations and compare each new one to the old one! Lets look at the separate fields: FROM CALL: Easy to compare slight garbled call to known mobiles TOCALL: Errors ok. Doesnt matter in APRS DIGIS: Errors ok. If it aint GATE or WIDE, than make it so DATE/TIME: Ignore it. Use local time LAT/LONG. Compare to last known position and time since. if posit is within dead reckoned estimate, accept it. If way off, fix obvious errors. Of DDDMM.HHN then you can do the following: Ignore HH errors if any DDd should probably be same as before DMM is critical. Use DR and best guess N,S,E,W are easy to guess if in error ICON SYMBOL Just assume same as last packet if different CSE CSE should be within +/- 90 degrees or so of last one or just ignore it SPD SPD should be less than 70 MPH or ignore it... COMMENTS just acccept as is. But put [FIXED] on end so we all know that it is a "fixed" posit. Now, summing all this up, it looks to me that we could easly make sense out of packets with 1 error (doubled our success rate) or 2 errors (quadrupled our success rate) or even 4 errors (8 times success rate) or even 8 errors (16 times better than we currently do!) Or another way, is that out of 100 bytes, we only need the 6 bytes of ..DMM...DMM for LAT/LONG to be more or less error free. or only 6 % of the bytes. THus, a 16 fold improvement in "procesing gain". Anyone can accept error packets by just turning PASSALL ON in your TNC. CAUTION!!! DO not do this unless you write the special code outlined above, or you will be destroying the integrity of "error-free" packet which is assumed to exist throughout the entire APRS network. One digi or gate with PASSALL ON can destroy APRS.. Dont do it. Unless you llike this idea and ar willing to write some neat code... You can write this in Basic or anything. All you are doing is messing around with the bytes out of the TNC. Then turning around and transmitting them via another TNC on to VHF for the rest of the world to see! [DO NOT USE the VHF port of an HF TNC with PASSALL ON because the VHF port will gate ERROR FILLED PACKETS TO VHF and cause a mess. You must use two separate TNC's] Any one wanna play with this? I would love to do it, but already got too many other APRS projects to work on.. I wouild prefer that this be written stand alone to run on an old DOS machine so it can sit in the closet and just do the job... bob, WB4APR From stanzepa@mail2.nai.net Mon Oct 05 18:33:11 1998 Received: from mail2.javanet.com (mail2.javanet.com [205.219.162.11]) by tapr.org (8.8.5/8.8.5) with ESMTP id SAA08571 for ; Mon, 5 Oct 1998 18:33:10 -0500 (CDT) Received: from [209.150.33.182] (ct-hartford-us923.javanet.com [209.150.33.182]) by mail2.javanet.com (8.8.8/8.7) with SMTP id TAA22504 for ; Mon, 5 Oct 1998 19:33:07 -0400 (EDT) Message-Id: <199810052333.TAA22504@mail2.javanet.com> X-Mailer: Microsoft Outlook Express for Macintosh - 4.0c (197) Date: Mon, 05 Oct 1998 18:58:39 -0400 Subject: [APRSNEWS:151] APRS824 posted From: "Stan Horzepa" To: aprsnews Mime-version: 1.0 X-Priority: 3 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: Bob Bruninga Subject: APRS824 posted APRS824.zip is now posted on tapr.org in the following directory: tapr/SIG/aprssig/files/dosstuff/APRSdos Nothing new, just minor cleanup items. * fixes bug with deadreckoning of some WX stations * New MAPFIX38 has EDIT-TRIM to bring all edge points inside yellow box * Fixes Mic-E dupes on the ALL page * FIxed remote U-2K wind and rain anomoly on some U-wk's Does not fix the undertermined problem that W7LUS was having with 2 comm ports. Is he OK now? I see him on the air.. but donno what he did to fix it. bob From stanzepa@mail2.nai.net Thu Oct 15 19:15:46 1998 Received: from mail2.javanet.com (mail2.javanet.com [205.219.162.11]) by tapr.org (8.8.5/8.8.5) with ESMTP id TAA21174 for ; Thu, 15 Oct 1998 19:15:45 -0500 (CDT) Received: from [209.150.34.223] (ct-hartford-us1516.javanet.com [209.150.34.223]) by mail2.javanet.com (8.8.8/8.7) with SMTP id UAA09633 for ; Thu, 15 Oct 1998 20:15:41 -0400 (EDT) Message-Id: <199810160015.UAA09633@mail2.javanet.com> X-Mailer: Microsoft Outlook Express for Macintosh - 4.0c (197) Date: Wed, 14 Oct 1998 19:21:31 -0400 Subject: FW: [APRSNEWS:155] Re: [APRSSIG:29046] Re: HF congestion From: "Stan Horzepa" To: aprsnews Mime-version: 1.0 X-Priority: 3 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: Bob Bruninga Subject: Re: [APRSSIG:29046] Re: HF congestion **** The APRS HF Network is for HF mobiles and stations **** **** It is GATED to VHF nets as a courtesy because the VERY SLOW **** **** HF traffic can easily be accomodated in the 1200 baud VHF nets **** **** The reverse, VHF => to HF must be avoided... **** Its time for the periodic warning to all APRS users that the HF net can be killed if VHF users try to go backwards from VHF to HF. HF at 300 baud can only handle about 100 users at one packet every 30 minutes. That is it. ANy more and the throughput goes to zero with constant collisions. There are over 5000 people on VHF all over the country. If only ONE PERSON IN 100 or only 1% of APRS users decide to use a VHF to HF gateway, then the HF net becomes CLOGGED AND USELESS TO EVERYONE. Please remember these guidelines: 1) Unless your station is actively involved in something of NATIONAL interest, do NOT use a path on VHF that includes GATE ever. 2) Do NOT use any VHF=>GATE path for WX stations or digipeaters! 3) Do NOT use any VHF=>GATE path for local mobils 4) If you are on a big trip, traveling cross country, and need to communicate and do not have HF, then you might consider adding your QRM to the very fragile and narrowband HF network. 5) Listen before you transmit if possible. Listen to 10151 LSB and do NOT use a VHF-HF path if the channel is more than 50% full... (statistically, an APRS frequency must be clear 67% of the time to avoid a reduction of throughput due to collisions.) 6) Read my HF.TXT in the APRSdos README directory... De WB4APR, Bob