[Xastir] Multiple Object Beacon Successive Transmit Delay

[Tom Russo]

On Sat, Sep 24, 2011 at 12:48:11PM -0700, we recorded a bogon-computron collision of the <jason at ke4nyv.com> flavor, containing:
> Right now, I am hosting about 20 object through my XASTIR station.  However, I am testing a new KISS TNC design and I noticed that when XASTIR transmits objects, it seems to shotgun all 20 at the same time.  The KISS TNC cannot buffer that much at once and it usually only catches the first one or two.  Is there a way to delay the rate at which the beacons are sent to the TNC?  Maybe a 5 second delay between each?

What version of Xastir?  The current version (and going quite a few versions
back for several years) use the decaying algorithm for objects, and they 
shouldn't all be bunched together unless they're all created at exactly
the same time.  

Looking in objects.c, there is also an attempt to randomize the timing of
object beacons by adding a random offset of up to 20% of the current interval
to prevent exactly that sort of thing.  This code is in the function 
"check_and_transmit_objects_items".

Almost all of the debugging lines of that function are commented out.  If you
wanted to check how well it's working (or why it's not), you'd have to edit 
code and uncomment them.

Are all your 20 objects created at once (e.g. by loading in the persistent
object list from a previous run)?  It could be that is the reason for this,
and perhaps there *should* be an offset applied to the objects when they're
created so they don't all get their initial beacon done so close together.
But there is not, as yet, any such early offset applied to objects created
at start-up, as far as I know.

-- 
Tom Russo    KM5VY   SAR502   DM64ux          http://www.swcp.com/~russo/
Tijeras, NM  QRPL#1592 K2#398  SOC#236        http://kevan.org/brain.cgi?DDTNM
 "One man alone can be pretty dumb sometimes, but for real bona fide
 stupidity, there ain't nothin' can beat teamwork." - Edward Abbey