<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>Note that there is no reason why non-APRS packets couldn't be digipeated (they did it in the old days, just not with the flood-fill aliases we use for APRS). Why such packets would be on the same channel as APRS traffic and using APRS flood-fill digipeat aliases is a different story. If such packets were on the APRS channel but not using APRS digipeat aliases like WIDEn-N, they would just die quietly because no APRS-specific digipeater would relay them (wouldn't match the digipeater's alias).<br><br>But there is no reason why other broadcast non-connected protocols, such as OpenTRAC, couldn't use APRS-style flood-fill aliases for digipeating. They just should stay off the APRS channels and use separate digipeater instances.<br><br>Andrew Pavlin, KA2DDO<br>author of YAAC (which supports other protocols along with APRS)<br><br><div>> Date: Wed, 21 May 2014 21:42:38 +0000<br>> From: wb2osz@comcast.net<br>> To: aprssig@tapr.org<br>> Subject: Re: [aprssig] Digi Deduplication Behavior<br>> <br>> Two packets are considered a match if the source, destination, and information parts match. The digipeater fields are ignored for the comparison. <br>> <br>> There is no point in comparing the control and protocol id fields because they are always the same for all APRS frames. Non-APRS frames would presumably be dropped before considering whether they were eligible for digipeating. <br>> <br>> A brute force implementation would need to store and compare up to around 270 characters for each packet. This could be a resource drain on a little 8 bit microprocessor. <br>> <br>> A common implementation trick is to store a CRC value instead to greatly reduce storage requirements and expense of comparisons. Not the original CRC of the frame, rather a new CRC computed from the source, destination, and information parts. <br>> <br>> It is very unlikely that two different packets will have the same CRC value especially so close together in time. Occasionally there could be a false match and a packet gets dropped when it shouldn't. Good enough for our purposes. <br><br></div> </div></body>
</html>