[aprssig] New n-N and 28 versus 30

[Wes Johnston]

Ummm.....  the checksum in the UIFlood is a checksum of the data portion of a
packet.  So if the data portion changes, so does the checksum.

If I have a tracker that is transmitting a posit every 10 seconds as I travel,
then every packet's data portion is unique.  Each posit will slip thru the
checksum filter, right?

If I have a fixed station (or stationary tracker), then the checksum filtering
will catch it.  So in the case of a parked car, you'd limit the parked car's
psitions to one every 30 seconds... or in the case of UIFLOOD 32, it would
round over to the next integer minute.

So on the one hand, if we make the number of seconds something high like 255
seconds, then we slow the redundant packets from parked cars... but we also
limit retries on messages from stations...

I'd say the number could be 61 seconds.
Wes
--



Quoting Robert Bruninga <bruninga at usna.edu>:

> I also wonder if it is also time to change  the common
> 28 second filter parameter in most digis' UIFLOOD, and UITRACE
> parameters from 28 to 32?
>
> It was set to 28 so that people running 30 second trackers
> would not get filtered out.
>
> These days, No one should be running 30 seconds *routinely*
> so why not change the filter to 32 so they CANT (routinely).
> Of course the SYSOP can change it to 19 seconds if he
> wants for any special event or for doing mobile coverage
> studies at a 20 second rate if he wants,...
>
> But in general, I dont see why we leave this floodgate
> open for such rare occassions.  Better to keep it closed
> most of the time and only open it up when needed..
>
> I'm changing all my docs to show this.  or at least 30 secs.
>
> Bob
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
>