[aprssig] APRS Cron Object Injector

[Steve Dimse]

On Mar 23, 2015, at 8:06 PM, Kenneth Finnegan <kennethfinnegan2007 at gmail.com> wrote:

> My paragraph on interval dithering isn't supported in anything I
> actually wrote in my thesis, but I still believe it's a more correct
> behavior.  Let's not confuse my gut feeling in that one paragraph with
> calling my entire thesis theoretical. I put a tremendous amount of
> effort into producing an applied thesis with useful, actionable
> conclusions.  I do not appreciate how many armchair reviewers have
> questioned the overall value of my work. The next grad student that
> asks me for help on what to do for their thesis gets at least five
> different choices on what parts of APRS they can work on; there is
> plenty of science left to examine here.
> 
You misunderstood my point. In the thesis there I do not see any evidence of actual analysis of the RF situation. Is that a true statement or did I miss it? I do not say there is not value in theory in general or your work in particular, or that theory is less effort; in fact I think it is more effort. My point was simply that from what I see on the APRS IS, which is a clustering of weather, position, objects, and ID/status (frequency in roughly that order) at the top of the hour (and to a lesser extent other times) is not likely to cause real-world problems. The vast majority of these packets are of internet origin, and will be IGated on few if any RF networks. As always, I believe issues of RF congestion are something to be addressed locally rather than with pronouncements from on high. The world has too much variety - APRS is used in too many different ways - for any one set of rules to be promulgated. 

> Just because you have a bad attitude about the future of APRS doesn't
> mean you need to discount my work on it. I'm not trying to fix all of
> APRS here; just enable everyone to make new parts of it slightly
> better.
> 
I have a very optimistic attitude about the future of APRS. I just don't think that future comes from a different power structure than in past. I believe in local users identifying and solving local RF problems if and when they occur. 

> Minimalistic isn't the same thing as simple; accomplishing something
> in fewer lines of code isn't necessarily better than exposing fewer
> parameters for the user to get wrong. I've hidden the concept of
> interval offset, because it's not something users should have to worry
> about or understand. Most of those 100 lines of code are defensive
> programming to try and keep bad packets off the APRS network.

Can you define bad packets you are trying to keep off the network? Minimalist according to dictionary.com is "being or offering no more than what is required or essential". In my opinion, defensive programming trying to keep bad packets of the network is not a minimalist solution to the problem of packets bunching up at certain times. The minimalist solution is a simple delay, and is only necessary for that small proportion of packets which end up on RF. 

Steve K4HG