Order Tray | Contact Us | Home | SIG Lists

[aprssig] One last question on digipeater code for TNC-X

Ron Stordahl ron.stordahl at digikey.com
Wed Aug 17 16:34:46 UTC 2005


"HARD" limits?  I would suggest the sysop could set suitable for his 
region.  What could be wrong with that?

Ron, N5IN

Robert Bruninga wrote:
> Personally, I think we need to be very careful
> about adding too many HARD limits.  Ham radio
> by its very nature does a huge variety of functions
> for very many different uses.
>
> There is no one-size fits all.  What we have done
> recently to get everyone's attention to their own
> ALOHA limited network and only use a path that
> fits that network.   And we are making great progress
> on that front.  We have gone from wall-to-wall
> packets in the highest density APRS system in the
> world (Baltimore) down to sometimes 10 seconds
> with NO packets heard locally... and yet we now
> see all the same activity as before but BETTER...
>
> It is amazing to see how a good idea in one area
> which makes no sense in another area, then gets
> applied and enforced where it doesnt apply.
>
> So be careful about giving draconian tools...
>
> Bob
>
>   
>>>> Ron Stordahl <ron.stordahl at digikey.com> 08/17/05 10:44 AM >>>
>>>>         
> If one is implementing new digipeater code, wouldn't this be the time to 
> actually enforce a hop limit in the code?  Right now all we have been 
> able to to for the KPC3(+) and UIDIGI-ROM is to shoehorn in some limits 
> which are easily circumvented.  John, I assume you have read 
> http://web.usna.navy.mil/~bruninga/aprs/fix14439.html 
>
> Ron, N5IN
>
> Robert Bruninga wrote:
>   
>> John
>>
>> Good question.  But there are some important facts.
>> 1) Digi ID/posit beacons should always be IDENTICAL, 
>> else they consume LOG files by constant changes
>> on every transmission.
>>
>> 2) But more than one can be used if it has nothing
>> to do with this digi.  Such as an OBJECT for something
>> else local that APRS users need to see.
>>
>> 3) The only reason we needed 4 was to implemnet
>> the variable PATH and variable TIMING for 
>> the digi's ID/Posit beacons.  No other reason.
>>
>> 4) It would be far better to avoid all these pitfalls,
>> in a new TNC by allowing for just ONE DIGI POSIT
>> text and then haveing the TNC smart enough to
>> use the variable timings and paths so that locally
>> a beacon is seen every 10 minutes.  A one hop
>> copy is sent out once every 30 minutes and a
>> 2 hop one is sent out every 2 hours.
>>
>> That Item #4 is the MAIN objective of a digi's
>> beacon system...   Bob, Wb4APR
>>
>>   
>>     
>>>>> John Hansen <hansen at fredonia.edu> 08/16/05 10:35 PM >>>
>>>>>         
>>>>>           
>> Hi:
>>
>> A while back I was working on the code for a digipeater daughter board 
>> for TNC-X and I asked a few questions here about features.  I appreciate 
>> the input.  I'm now finishing up this code (I expect to have it ready 
>> for beta testing by the end of this week) and I have one last question.
>>
>> As you may recall, I was modelling this project on the widely used 
>> UIDigi feature set.  I was advised by someone that one problem with this 
>> code was there were only 3 beacons and really 4 were needed.  So I put 
>> four in the code for XDigi.  I've set this up so that a separate beacon 
>> text and beacon interval can be specified for each.  My remaining 
>> question is whether it is important to have a separate destination 
>> callsign and path for each of the four beacons.
>>
>> Any advice?
>>
>> Thanks in advance for your input.
>>
>> John W2FS
>>
>>
>> _______________________________________________
>> aprssig mailing list
>> aprssig at lists.tapr.org 
>> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig 
>>
>>
>> _______________________________________________
>> aprssig mailing list
>> aprssig at lists.tapr.org 
>> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig 
>>   
>>     
>
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org 
> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
>
>   




More information about the aprssig mailing list