| |
ZL3AI > APRDIG 26.09.03 12:18l 248 Lines 9523 Bytes #999 (0) @ WW
BID : 1986-ZL3AI
Read: GUEST
Subj: TAPR Digest, Sep 23, 6/7
Path: DB0FHN<DB0RGB<DB0FSG<DB0PV<DB0MRW<OK0PKL<OK0PPL<DB0RES<ON0BEL<VK7AX<
ZL2BAU<ZL3VML
Sent: 030925/1614Z @:ZL3VML.#80.NZL.OC #:9014 [Chch-NZ] FBB7.00i $:1986-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: Path limiting by digis
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Tue, 23 Sep 2003 11:43:04 +0200
X-Message-Number: 27
Hello All,
At 10:20 21-9-03 -0700, Tim Schall wrote:
>Yes, the other digi's will still recognize it as one they've already sent.
>That decision is one that is based on the contents of the packet and not the
>source and destination headers.
In DIGI_NED dupe-checking is done based on the source address and a 16 bit
CRC of the contents (payload) of the packet (to save memory not the whole
packet is stored, only the 16 bit CRC). The source address is taken into
account to prevent false detection of dupes when somebody else happens to
send a packet which gives the same 16 bit CRC result (~ 1/65536 chance).
You can argue if the the destination address should be taken into account.
When looking at MIC-E type packet it should be done, since the destination
address is part of the position report and 2 subsequent position packets
could differ only in the destination address. Dupe checking without looking
at the destination address will regard the second position packet as
duplicate if the data part contains the same data. There is however a
problem when the destination address is considdered, digipeating on
destination-SSID also changes the destinaton address; when a change in
destination address is considdered a different packet this can create
loops. DIGI_NED does not check the destination address, the risk that a
MIC-E packet only differs in its destination address is very low.
The digipeater addresses in the "VIA" list are never taken into account for
dupe checking, they will almost always change with every hop the packet makes.
I don't know how Kantronics solved their dupe checking mechanism, I can
only say how I did it in DIGI_NED and it works very well this way.
Kind regards,
Henk.
----------------------------------------------------------------------
Subject: Re: WIDEn-N to-UHF path splitters
From: "Georgette Sampson" <georgette.sampson@cox.net>
Date: Tue, 23 Sep 2003 14:19:03 -0500
X-Message-Number: 28
>On Tue, 23 Sep 2003, Daron J. Wilson wrote:
>>
>>Let us just remember though that we don't already have:
>>2nd TNC at each location
>>UHF transmitter/cavity/antenna at each location
>>Dual band radios for each user in the area
>
>Ah, but those are only needed if one insists on continuing to see WIDE7-7
>traffic from everyone in their surrounding states.
So the IS feeds should probably all move to the UHF side, unless they are
also a WIDE?
If you don't have UHF, then you could just use Findu on your
cell phone/PDA/WiFi :-)
Jo
----------------------------------------------------------------------
Subject: Re: WIDEn-N to-UHF path splitters
From: Henk de Groot <henk.de.groot@hetnet.nl>
Date: Tue, 23 Sep 2003 21:24:45 +0200
X-Message-Number: 29
Hello all,
At 19:54 22-9-03 -0400, Bob Bruninga wrote:
>Better idea. If DIGI-NED or UIDIGI authors could simply add an OUTPUT BIT
>to their TNC code, that used the NORMAL PTT for all RELAY/WIDE digipeated
>packets, but then keyed this SECOND PTT for only WIDEn-N traffic, then the
>one TNC could do both jobs. That is playing traffic cop to route packets
>as needed.
This doesn't realy work since the moment of transmission is determined by
the TNC, DIGI_NED or any other PC based software cannot key the PTT at the
right time when the audio leaves the TNC. So you need 2 TNC's. For the rest
it is DONE and available TODAY! In fact is was already done 3 years ago
with the very first version of DIGI_NED...
Here is how it is done:
DIGI_NED can have up to 8 ports. Its driven by "rules" programmed in a
ASCII file. The rules in the ASCII file determine which packet from which
port is send to what output port and what modifications have to be done to
the packet along the way.
So you just have to modify the rule file. Make a 2 port configuration, port
1 is connected to the busy APRS QRG and port 2 to the backup UHF QRG.
Now modify all WIDEn-N rules so these will only to send packets to port 2
instead of "all" active ports. From now on everything is copied to both
bands except for WIDEn-N type paths which are only copied to port 2.
You see, its perfectly possible to make a WIDEn-N splitter with the
available DIGI_NED software without the need for any new programming; its
just a configuration issue.
Kind regards,
Henk.
P.S.
Building the same kind of configuration with one TNC will be hard, but
maybe it can be done the following way:
1) Configure 2 ports, the first port is connected to a KISS TNC, the second
port is configured as BayCom modem connected to the LPT port. The PTT
signal for the BayCom modem will be on the LPT port at pin 9, High (5V) if
active, see AX25_MAC.TXT section 2.1. You can also use a serial port if you
want.
2) Give the second port a big TX-Tail delay so that the PTT signal you get
on the LPT port will overlap with the KISS TNC's audio transmission.
3) The PTT for the UHF transmitter shall be an AND function of the PTT
signal on the LPT port and the PTT signal from the TNC (otherwise the UHF
transmitter is keyed too long).
4) The VHF transmitter shall be keyed if the PTT signal of the TNC is
present but no PTT signal is present on the LPT port.
5) AX25_MAC shall not have the -L flag so it will start tranmission
simultaneous on both ports.
6) Modify the rule file, for all rules packet shall only be send to port 1
except for WIDEn-N types, they shall be send to both port 1 and 2.
The result is that normal packets are send on VHF and WIDEn-N packets are
send to UHF. Note that this way non-WIDEn-N packets are not send to UHF...
This one TNC solution is a big hack, with 2 TNCs this setup would work very
well and more reliable, but it can be done if you want it...
Disclaimer: not tested!
----------------------------------------------------------------------
Subject: Re: Tactical RF Networking !!!
From: Bob Bruninga <bruninga@usna.edu>
Date: Tue, 23 Sep 2003 16:40:33 -0400 (EDT)
X-Message-Number: 30
On Tue, 23 Sep 2003, Sadowski, Allan wrote:
>http://www.faqs.org/rfcs/rfc1677.html
>
>Having heard repeatedly about the "tactical" nature of APRS... the one
>thing that APRS really fails to deliver is ASSURED DELIVERY of position
>info. In REAL tactical situations... you really need to get the message
>through in time to be useful - or at least know that it failed to get
>through...
If APRS was used as designed, that is, was not flooded by out-of area
traffic, and the local channel was operating at below the ALOHA rate, then
I think you could depend on relatively assured delivery. As originally
designed not only did it have repetative position reports, but it was
intended that the WIDE,WIDE path would have enough dupes (average about 1
dupe) so that the probability of receipt was very high...
Bob
----------------------------------------------------------------------
Subject: Re: WIDEn-N to-UHF path splitters
From: Bob Bruninga <bruninga@usna.edu>
Date: Tue, 23 Sep 2003 16:55:04 -0400 (EDT)
X-Message-Number: 31
On Tue, 23 Sep 2003, Georgette Sampson wrote:
>>Ah, but UHF is only needed if one insists on continuing to see WIDE7-7
>>traffic from everyone in their surrounding states.
>
>So the IS feeds should probably all move to the UHF side, unless they
>are also a WIDE?
No, one IGate listens to all the local WIDE traffic. All you need is a
single other IGate to listen to the UHF termination of a discontinued
WIDEn-N chain if there is no other IGate anywhere along that WIDEn-N
chain. My suspicion is that there is an IGate already hearing the WIDEn-N
traffic.
Bob
----------------------------------------------------------------------
Subject: RE: Tactical RF Networking !!!
From: "Sadowski, Allan" <allan.sadowski@ncshp.org>
Date: Tue, 23 Sep 2003 16:54:41 -0400
X-Message-Number: 32
Agreed... "IF"... but the reality is obviously different...
I'd think that a "slotted ALOHA" mechanism would be worthwhile at this
point.... and probably just as good, a full duplex channel - like voice
repeaters... especially given time signal info is available from
GPS's...
Begs the question... can the vaunted D7 and D700's work half duplex
instead of simplex?
But then that's another "IF"...
More intelligence at the Digi's and higher level routing are the only
way it looks likely to be cleared up...
Another IF
Better minds than mine are working the issue... the DCC meeting on
Networking was looking real interesting Saturday... but I had to leave
before the meeting was more than half over... hopefully somebody
(STAN??) took good notes and will be posting them here... cause I didn't
see any recorders going to make the discussion available at TAPR...
And for those who were not there at DCC... the FUTURE IS SDR's... and PC
soundcards connected directly to your VHF rig to to APRS... ... no TNC
needed... everything from soundcard...
DesMoines (sp?) Iowa... next year DCC ought to be really interesting
based on presentations this year...
ALOHA
AH6LS
>-----Original Message-----
>From: Bob Bruninga [SMTP:bruninga@usna.edu]
>
>Subject: Re: [aprssig] Tactical RF Networking !!!
>
>If APRS was used as designed, that is, was not flooded by out-of area
>traffic, and the local channel was operating at below the ALOHA rate, then
>I think you could depend on relatively assured delivery.
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
