OpenBCM V1.13 (Linux)

Packet Radio Mailbox

DB0FHN

[JN59NK Nuernberg]

 Login: GUEST





  
ZL3AI  > APRDIG   01.10.03 11:19l 126 Lines 5116 Bytes #999 (0) @ WW
BID : 2041-ZL3AI
Read: GUEST
Subj: TAPR Digest, Sep 28, 2/2
Path: DB0FHN<DB0RGB<DB0MRW<DB0FOR<DB0SIF<DB0EA<DB0RES<ON0AR<7M3TJZ<IK1ZNW<
      ZL2TZE<ZL3VML
Sent: 030930/1332Z @:ZL3VML.#80.NZL.OC #:9372 [Chch-NZ] FBB7.00i $:2041-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To  : APRDIG@WW

Subject: Re: APRS Grass growing...
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Sun, 28 Sep 2003 16:19:03 +0200
X-Message-Number: 5

Hello Bob,

At 13:30 27-9-03 -0400, Bob Bruninga wrote:
>Yes, I thnk DIGI_NED is an ideal engine at a digi...  I assumed it has
>remote sysop features.  Are you saying it doesnt?

Yes it does, but not in the program itself! There is a special command to 
remotely shut it the digi down with a specific exitcode (if it was 
enabled). Only specific calls can perform this action and you need to have 
a direct radio link to the digi. The .bat file that started the DIGI will 
continue after the DIGI is stopped and can examine the exitcode and take 
action.

In our digi PI1APK we use several exit codes to restart the digi with 
different configuration files. Currently we have "normal" (default 
behaviour), "highload" (with 29 minute dupe check, and WIDEn-N limitiation) 
and "silent" (digi is silent but can still be commanded "blind" to enable 
it again).

Another specific exitcode will start NetCHL. We don't use it on PI1APK 
since that one cannot change from QRG (you don't want to upload on the busy 
APRS QRG!) but we used it on PI1APA which has a second QRG on 70 cm that 
can take the upload. In the .bat file you have all the control you want so 
you could command the TRX to another QRG before starting NetCHL. When 
NetCHL is started you can just FTP new versions and new configurations to 
the digi. We used NetCHL since one of the Sysops knew that program very 
well, you can just as well use JNOS or a packet program like TSTHOST that 
allows YAPP uploads (or even start a FBB BBS, why not?).

For Linux systems its even much simpler, you can just FTP and remote login. 
Of course the option to remotely shut down also works for Linux, but you 
can also simply login with telnet an kill the program.

In DIGI_NED you can also send "!out" commands to the digi to put data on 
the LPT port, that can be used to command a TRX to a secondary QRG for 
uploading.

Anyway, plenty of options here to do whatever you want. We uploaded 
completly new releases several times to PI1APA without the need for a 
single site visit.

Kind regards,

Henk.

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

Subject: Re: APRS Grass growing...
From: Bob Bruninga <bruninga@usna.edu>
Date: Sun, 28 Sep 2003 14:42:47 -0400 (EDT)
X-Message-Number: 6

On Sun, 28 Sep 2003, Henk de Groot wrote about the Decaying algorithm of
old data relative to the initial high rate for new data:

>That makes sense! I think clients need to be adjusted and change to this
>behaviour....  It is frustrating that this, like many other finer
>details, is not described in the APRS spec.
>
>If this is so fundamental then something seriously went wrong when the APRS
>Spec was written. How could such a fundamental point be missed?

Remember, the SPEC was written 6 years after APRS was invented and fully
implemented in APRSdos.  By then there were other authors who had new
versions of APRS out there, but that had not yet fully implemented all the
underlying communications networking details.  Therefore the only way to
get aggreement on the final spec was to water it down to the lowest common
denominator so that no author's existing program appeared to be
deficient.

>I like to know: how do we fix it and what else is missing?

I think it is time to encourage authors to update to these conecepts.

>The decay algorithm was described for messaging and as a result of that
>it is used in DIGI_NED for messaging (it-------------------------------

Subject: Re: Another thought on reducing congestion in busy metro areas...
From: "Komljanec" <ve3pep@rac.ca>
Date: Sun, 28 Sep 2003 16:11:54 -0400
X-Message-Number: 11

- idle/busy marker on a 2nd frenquency to reduce collisions
- transmitter steering.

Adding a 147 MHz frequency to transmit an idle/busy marker would certainly
improve digi throughput due to collision control.   Are there any existing
APRS implementations of this sort of thing?  It would seem easy to implement
for any mobile.  The digi would have to duplicate outgoing messages to the
147 MHz frequency as well .

ARDIS network is N=1 (one frequency reuse in Canada).  It is now obsolete,
but the concept has some things in it that could be borrowed for IGATE based
APRS in urban areas. Perhaps in a downward compatible way?  A method of
TRANSMITTER STEERING for APRS would require figuring out which DIGI has the
best signal for the mobile. Igates would have to have local coordination
between themselves.

http://www.comsoc.org/livepubs/surveys/public/3q99issue/salkintzis.html
http://www.motorola.com/MIMS/WDG/pdf_docs/5-.pdf

Idle / (busy?) thoughts.  Perhaps Naive... but... 2 cents.

Tony K  VE3TK
----------
>RE:
>APRS is simple.  If you are on the air, you periodically send a single
>packet to keep the net aware of your status.  APRS was founded on the
>principle of KISS.

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

[commercial content deleted]

---

END OF DIGEST


Read previous mail | Read next mail


 29.10.2026 23:47:41lGo back Go up