| |
ZL3AI > APRDIG 04.10.03 11:18l 252 Lines 9877 Bytes #999 (0) @ WW
BID : 2077-ZL3AI
Read: GUEST
Subj: TAPR Digest, Oct 01, 2/11
Path: DB0FHN<DB0RGB<OK0PPL<DB0RES<ON0AR<7M3TJZ<F6CDD<EA5RQ<VK4TUB<ZL2BAU<
ZL3VML
Sent: 031003/1340Z @:ZL3VML.#80.NZL.OC #:9637 [Chch-NZ] FBB7.00i $:2077-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: DigiNed in dedicated flash devices ??
From: tvsjr <tvsjr@sprynet.com>
Date: Wed, 01 Oct 2003 00:58:38 -0500
X-Message-Number: 8
There are several PDAs available (such as the Sharp Zaurus, iPaq, etc.)
that can run Linux natively. Rather than trying to run a DOS emulator on
top of an inherently unstable OS, it might be worth looking at running
something natively in Linux...
73,
Terry/N5RSE
----------------------------------------------------------------------
Subject: Re: Take Control of your DIGI part 4
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Wed, 01 Oct 2003 00:12:54 +0200
X-Message-Number: 9
Hello Scott,
At 13:51 30-9-03 -0700, Scott Miller wrote:
>Henk, what are DIGI_NED's requirements for RAM and program space? Is there
>any chance that it could be squeezed into an embedded platform, like maybe a
>KPC-3? How much OS-dependent stuff has it got?
This is what Borland C++ 3.1 reports for the DOS compile:
File Lines Code Data
-------------------------------------
MAIN.C 648 1275 1026
CALL.C 479 1239 517
DIGIPEAT.C 1655 6973 2712
GENLIB.C 751 2318 686
KEEP.C 300 814 674
MAC_IF.C 1240 3567 622
MESSAGE.C 3194 13833 4244
OUTPUT.C 757 3552 2039
READ_INI.C 710 3510 1444
SEND.C 780 2979 641
TIMER.C 154 285 0
MHEARD.C 401 1343 43
DISTANCE.C 1275 4874 257
DX.C 1145 4680 2688
PREEMPT.C 628 2569 744
TELEMETR.C 1233 5398 1466
COMMAND.C 488 1615 1106
DIGI_DOS.C 403 794 77
SAT.C 349 1211 128
PREDICT.C 1563 12894 4927
SERIAL.C 690 2887 860
IBMCOM.C 558 1221 4172
WX.C 1036 4932 1340
-------+ -------+ -------+
Total: 20437 84763 32413
(This is the latest version I had on my DOS computer on which I build for
DOS with only some very small changes compared to the last distributed
source).
The amount of dynamic storage depends on your configuration. It needs to
store the rules in expanded form. Furthermore it depends on how long
packets must be remebered and how many calls to keep in the heard list. I
know that keeping 400 stations in the heard list does not fill up all 640
kB DOS memory, never checked where the limit is. When DIGI_NED runs out of
memory it just skips the action that needed the memory so it keeps on going
without crashing.
When loaded with the default rule-file the program "mem /c" (shelled out of
DIGI_NED with ALT-D) reports that DIGI_NED uses 200 kB. Additional the
mac-layer driver uses 52 kB, but when making a TNC version that needs to be
rewritten and can be a lot smaller.
DIGI_NED uses very little OS specific stuff. It uses normal C standard I/O
and time(). For the DOS version software interrupts are used to communicate
with the mac-lay TSR, but you do not need that. The telemetry and remote
control stuff uses direct I/O to the serial and parallel port. The
satellite tracker stuff uses math functions.
You can strip the code however. You don't need telemetry, the sat tracker,
the WX stuff and maybe you also want to get rid of the message functions
and only keep the core digipeater. You can see in the list above roughly
what savings that will give. Most of these features are compiled in with a
compile-flag. When I compile without SATTRACKER, TELEMETRY, OUTPORT
(=remote control of the bits on the LPT port), SERIAL (raw GPS/ULTIMETER
serial in) and WX and then load DIGI_NED and let it read the default
rulefile, "mem /c" reports 151 kB. When instead of the default rulefile the
rulefile for simple RELAY use is loaded the used space is 124 kB, so
storage of the default digipeating rules takes roughly 27 kB.
Furthermore reading and interpreting the rulefile could be done off-line by
a separate program so it can be loaded into the digi in a ready to use
binary format. This way it should be able to make it small enough for an
embedded platform (but most likely too much for a Z80). You have to figure
out a way to load configuration data and what to do about remote control
since the trick used for DOS to load NetCHL or something similar to do the
upload doesn't work for an embedded system... What should be feasible is to
make a Palm version out of this...
There are also oportunities to optimize the code for space. I didn't worry
too much since 640 kB provides more than enough space for any application
:-).
I hope this answers your question. Maybe further discussions about this
should be off SIG, I think this is too detailed and too specific for most
SIG readers...
Kind regards,
Henk.
----------------------------------------------------------------------
Subject: Automated User Education
From: "Ev Tupis (W2EV)" <w2ev@arrl.net>
Date: Wed, 01 Oct 2003 07:02:51 -0400
X-Message-Number: 10
OK developers...here's one for you...
APRSniffer (maybe a UI-View plug-in?)
o Monitors traffic
o Analyzes it for "path abuse" (definition of "abuse" can vary by geography!)
o Sends an APRS screen-message to stations, suggesting a change if appropriate
Education is a very strong tool. Automating it can help.
RELAY,TRACE2-2 means more fun for everyone.
Ev, W2EV
----------------------------------------------------------------------
Subject: RE: Random backoff
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Wed, 01 Oct 2003 11:52:47 +0200
X-Message-Number: 11
Hello Bob,
At 18:00 30-9-03 -0400, Bob Bruninga wrote:
>Hold on. SLOT TIME and PERSIST only work in a connnected envrionment with
>retries. (IE, regular packet) APRS is a UI system that has no retries,
>thus no PERSIST. Yes we can assign SLOTS based on GPS timing, but NONE of
No, thats RESP and FRACK. SLOTTIME and PERSIST are used to find an empty
channel. It works this way:
A) The TNC listens to the RF channel
B) If the channel is busy the TNC waits SLOTTIME, then goto A in this sequence
C) If the channel is empty get a random number between 0 and 255
If the number is bigger than PERSIST then wait SLOTTIME and goto A in
this sequence
D) If the random number is lower or equal to PERSIST access is granted,
start transmision
So the channel needs to be empty, if not then wait SLOTTIME (usually 100
ms) and retry. This avoids that the station jumps in immediatly after the
carrier vanishes and causes collisions with other TNCs that do the same.
Since TNCs are not time synchronized, they attempt to jump in at slightly
different moments avoiding collisions due polling of the channel at
SLOTTIME interval.
If the channel is empty then there is a gamble which of the TNCs is allowed
to transmit. With PERSIST set to 64 there is a chance of 1 out of 4 (in
fact 64 out of 256) that your station is granted access to the channel. The
other TNCs will have an equal chance and this lowers the probability of two
TNC be granted access at the same time (1 out of 16 with 2 TNCs). When the
TNC is not granted access it has to wait SLOTTIME and then if the channel
is still empty take another random number and match it again with PERSIST,
until access is granted.
As you see this has purely to do with channel access and is independent of
connected or unconnected packet mode. This collision avoidance system only
works well if you can hear if the channel is busy. Also important is that
if the TNC is granted access that the channel is claimed immediately, in
our radio environment TXDelay of the transmitter gets in the way here.
For ethernet for example this mechanism works very well (but they also have
collision detect, the mechanism here is CSMA, ethernet is CSMACD). In APRS
a station often cannot see if the channel is busy, so the effect of this
mechanism is far from optimal. APRS is not like CSMA but more like Aloha
where you transmit at will without listening.
To get a TNC to respond immediately the SLOTTIME must be set to 0 (if that
means infinite set it to 1) and PERSIST set to 255 (so the random number
will never be higher and you are always granted access at the first try).
Note! Kenwood has PERSIST the wrong way arround, there you have to set it
to zero, with 255 a Kenwood will never transmit (may also apply to other
TASCO TNC implementations, e.g. Alinco).
I hope this clears this part up. Kind regards,
Henk.
----------------------------------------------------------------------
Subject: PERL APRS Stream SPLIT
From: "Andrew Rich" <vk4tec@hotmail.com>
Date: Wed, 01 Oct 2003 21:31:27 +1000
X-Message-Number: 12
For those interested in learning more about APRS, here is my latest code in
PERL.
Splits the APRS stream up into relevant bits, callsign, dest, digis,
payload, email, webpage.
#!/usr/bin/perl
use Net::Telnet;
my $host = "aprs.net.au";
my (@data, $line);
my $t = new Net::Telnet(Timeout=> '5', port => '10153');
$t->errmode('return');
$t->Net::Telnet::open($host);
sleep 5;
print $t "user VK4TEC pass <pass> vers XASTIR \n";
while (<$t>)
{
chop;
$email="";
$webpg="";
if (m/.*\s+([a-zA-Z0-9\+_.-]+)\@([a-zA-Z0-9.-]+)\s+/)
{
$email = $1."@".$2;
}
if (m/http:\/\/([a-zA-Z0-9.-]+)\s+/)
{
$webpg = $1;
}
($callsign, $rest) = split(/>/,$_,2);
($dest, $rest) = split(/,/,$rest,2);
($digis, $payload) = split(/:/,$rest,2);
$payload =~ s/'/\\'/g,$payload;
print
"-------------------------------------------------------------------------------
-------------------------\n";
print "data : $_";
print "calls: $callsign\n";
print "dest : $dest\n";
print "digis: $digis\n";
print "payld: $payload\n";
print "email: $email\n";
print "webpg: $webpg\n";
}
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
