Re: T2-135 Message ACK
- In addition, the issue of the APRS message ID automatically
incrementing (evident in the case of an "Outbox hangup") needs to be
corrected. I'm having a hard time figuring out any rhyme or reason to
the incrementing message ID logic during a "hangup". Many digis and
-IS backend daemons have good duplicate filtering methods; however,
these are almost all based on message ID, and are thus trumped if the
message ID increments, since the digi/daemon/etc. sees the message as
a new message. This really gums things up--dupe messages getting
routed, dupe responses getting returned...lots of bandwidth badness.
At some point Scott's going to bump up against firmware sizes that
will exceed chip capacity if we keep adding fixes to the current
firmware. It might be time to consider forking the current firmware
into a "dedicated digipeater" version, a "weather station" version, a
"mobile version", etc. This would allow more dedicated capacity for a
given application depending on the desired usage, and function could
be changed out with a simple firmware swap.
Also might be good to move these types of issues onto their own
"Bugfix" and "Requested Features" threads here on the group. Might
make it easier to compile inputs for future firmware upgrades.
> > IMO, the OT2 should probably send a Garmin ACK to the NUVI in eitherperforming
> > one of the following cases:
> > #1 if it gets an APRS MSG ACK (that works already, cool!!!)
> > #2 after the RETRIES count reached its limit
> > #3 right away if the Nuvi keeps sending the message to the OT2 at a
> > faster pace than the OT2's RETRYTIME value.
> I also suggest:
> #4 when the OT2 is powered on. That way you clear the outbox by
> a power cycle on the OT2.
> At some point Scott's going to bump up against firmware sizes thatThe problem there is that (aside from complicating maintenance) there's
> will exceed chip capacity if we keep adding fixes to the current
> firmware. It might be time to consider forking the current firmware
> into a "dedicated digipeater" version, a "weather station" version, a
> "mobile version", etc. This would allow more dedicated capacity for a
> given application depending on the desired usage, and function could
> be changed out with a simple firmware swap.
no way to satisfy everyone with a finite number of combinations of
features - they'll always want some combination that's not available.
I'm trying to hold off on splitting the code as long as possible.
Some of the rewrites I'm doing now *might* free up some space. Or make
it worse, but at least make things easier to work with and add some new
options. I went poking around and figured out that I can recompile the
ANSI C libraries with some (poorly documented) options to help trim the
size of the functions, at the expense of features and standards
compliance. That might free up enough space to clean up some ugly kludges.