[aprssig] APRS Digipeter Design Questions

[John Hansen]

Hi Folks:

For a few weeks now I've been working on and off on a design for an 
elementary APRS digipeter daughterboard for TNC-X.  This is not the full 
blown product that you might have heard about at last year's DCC... I'm 
still hoping that item will become available at some point.  However, so 
many people have been interested in getting something going that I 
thought I would do a less ambitious digi that might be available 
sooner.  This digi will be physically similar to XTrack, if fact, I'm 
hoping to use the same PC board for it as is use for XTrack.  Anyway, 
I've run into a number of issues that I would like to have comments on 
by potential users before I finish the beta version of the code.

For this project, I first started with the capabilities of UI-Digi, but 
then disposed of some of the items that don't seem to be used all that 
much (such as the directional digipeting).   Currently I have a 
prototype that is digi-ing properly doing callsign substitution (with up 
to 8 UIDigiCalls... like UIDigi) and handles UIFlood in the same way 
that UIDigi does. I've implemented 4 beacons, though as you will see 
below I still have some questions there.  The last items on my to-do 
list are to build in duplicate suppression and to provide a terminal 
interface so that users can set it up using a terminal program (remote 
configuration will not be offered on this version).  Here are my questions:

1.  Currently I've not implemented TRACE.   TRACE can be included as a 
UIDigiCall... in which case it would be treated just like RELAY (or 
anything else that was entered as a UIDigiCall), but it would not add to 
the path like a traditional TRACE does.  I did this because TRACE seems 
to have fallen out of favor, from what I've been able to determine.  Is 
there any reason for me to include support for TRACE?

2. I've allowed for 4 different Beacon texts.  I have a number of 
questions here. 

2A.  UIDigi allows for Beacons of up to 70 characters.  Is that a 
reasonable number?
2B.  UIDigi allows for a different path for each Beacon.  How important 
is this?
2C.  How many digipeters should be allowed in a Beacon path (surely 8 is 
not the correct answer!).

3. I also have a number of questions with regard to duplicate supression. 

3A.  UIDigi does this by time interval.  While this is desirable, it is 
much more complicated to keep track of time than to keep track of the 
number of transmissions.  Unless someone sees a huge problem, I would 
like to implement this as a CRC value (like is used for packets) and 
compare the current received packet with the last X received packets 
where X is user settable.  This way I could simply maintain a history 
list of the last X received packets and check it as each new packet is 
received.  If I do it this way, of course, the time window during which 
duplicates will be rejected will be variable depending on the traffic on 
the channel.  Does anyone see a serious problem with this?

3B.  If I do implement this as described above, what would be a 
reasonable maximum value for X?

3C.  What parts of a packet should I include in the CRC calculation?  
Obviously, the text should be included and (it seems to me) the path 
should be excluded (since it may change every time it goes through a 
digi).  Any other thoughts?  Also, with regard to this I'm concerned 
about what happens when a D700 sends a message and it isn't acked.  The 
D700 then sends it again.  Would the dup checker catch this and not digi 
it?  Is that desirable?  If not, how can the CRC be calculated so that 
it can be avoided?

4.  UIDigi ignores packets that are not UI frames.   Some of the public 
service communications that are being done around here on packet are 
using connected mode.  I wanted to make this device useful as an 
"emergency" portable digipeter for these types of communications as 
well.  Is there any problem with me causing it to digi properly 
addressed connected frames as well?

Thanks in advance for your comments.  I expect a number of people may 
comment on this and so I can spend my time finishing this project rather 
than writing email, it may not be possible to respond right away to 
everyone personally who comments.   However, your comments are very 
important to me... I'd like to get these issues resolved before 
beta-testing starts rather than afterwards!

Thanks,

John W2FS