craigerl
commented
5 years ago following up after going through the code. According to beacon.c, if the system clock shifts forward, direwolf will emit all the pbeacons it missed during that interval all at once, until it's caught up. For example, if the internet is unavailable during boot, ntp cannot update the system time. Direwolf then starts, the internet becomes available, and ntp shifts the clock foward three hours. If direwolf is configured to send a pbeacon every 20 minutes, it will quickly send nine consecutive pbeacons.
In beacon.c below, just below the comment Don't take relative to 'now' in case there was some delay, is where the bug exists. It should, in fact, be relative to "now" in case the system clock shifted forward. At a minimum an exception check should be made at that point to see if the next scheduled beacon is in the past, then set it relative to the new now. That would prevent all the catchup beacons after a system time change.
/*
* Send if the time has arrived.
*/
for (j=0; j<g_misc_config_p->num_beacons; j++) {
struct beacon_s *bp = & (g_misc_config_p->beacon[j]);
if (bp->btype == BEACON_IGNORE)
continue;
if (bp->next <= now) {
/* Send the beacon. */
beacon_send (j, &gpsinfo);
.
.
.
.
.
.
else {
/* Non-tracker beacon, fixed spacing. */
/* Increment by 'every' so slotted times come out right. */
/* i.e. Don't take relative to now in case there was some delay. */
bp->next += bp->every;
}
} /* if time to send it */
} /* for each configured beacon */
} /* do forever */
juchong
sardylan
wb2osz
sq2mo
dranch
Direwolf 1.5 was issuing a beacon every second, for a minute or so (I killed the power to the Tx after a dozen). It was running for a few days w/o problems. During this test, the only difference was a disconnected internet. Any reason it would send out PBEACONS as fast as possible? Raspbian, pi-zero, thus compiled from a git clone last week. This is a "personal" digi only interested in traffic to/from my callsign -- conf file below.
conf file.......................................