All my satellites and other APRS projects (and TT4 modules) use an external
watchdog timer made from a simple 555 timer chip. I just set the RC to
time out in 90 seconds. And then the restart RC to about 3 seconds. The
555 timer output powers the TT4.
Then I put an NPN transistor across the timing capacitor who's base is
driven from the PTT line. THen I assure that the programming of the telemetry
is once every minute. As long as the telemetry (or any other packet) keys
the PTT, then the 555 never times out. But if the CPU locks up, then there
will be no tgransmissions and no PTT and the 555 will time out and remove
power for 3 seconds. The 555 timer has enough load drive cpapability that
I actually power the TT4 from the 555 output (for the small satellites).
Of course there are CPU hangups that could transmit at too high a rate, but
on the small satellites, I assume that too high a rate would run down the
satellite battery in a few orbits and get a power cycle that way...
Of course, for terrestrial use, a 1 minute telemetry is too much for the APRS
channel, but maybe 10 minus will do. BUT THEN we are talking about a
very-very long RC time constgant, and I would not trust a 1000 uF
electrolytic and
1 meghom or greater RC timer to be reliable?
PCSAT now going on 20 years and never locked up (though it coiuld be being
reset every hour or so, who knows. It dies in the dark and wakes up
35 minutes later.
Bob
On Mon, Oct 18, 2021 at 8:31 AM vhsproducts via groups.io
<vhsproducts@...> wrote:
The problem with having a TT4-based watchdog timer is that the ATMEGA chip seems to be the thing that hangs, so depending on the code to run in the chip that is locked up is a no-go. I have considered an extra timer based on a PIC to periodically restart the TT4 chip ( It does not take long to reboot) so that it will still automatically essentially push the reset switch on pin 9 of the TT4 chip, and not be dependent on the TT4 itself. Compton's use of an external timer seems to validate the approach. I don't know if having a timer to intermittently reset the TT4 actually prevents the mysterious hanging condition, or if it just allows recovery in the rare instance of a hangup.
73,
Allen AF6OF
-----Original Message-----
From: Barry L. Lankford <BarryL@...>
To: [email protected]
Sent: Sun, Oct 17, 2021 11:08 pm
Subject: Re: [TinyTrak] MT4BB Halting
If you are OK with the fixed periodic reboot solution, the following
might still be useful in the future. Google "Watchdog Timer," the
time-honored, last-ditch method of dealing with many impossible-to-find
(and yet-to-be-experienced) bugs.
I once took over a bad project where the original designer (and also its
programmer) had included a watchdog function but put the code to
periodically clear the watchdog counter inside an interrupt routine
instead of in-line with the main program path. So, when the main
program somehow got out in the weeds, the timer service interrupt would
push the "out in the weeds" program counter onto the stack, jam in the
address of the interrupt service routine, which would then reset the
timer preventing it from ever timing out. The interrupt service code
would then reach the end of the routine and the return from the routine
would pop the old "out in the weeds" program counter location off the
stack and the program would jump right back out into the weeds, solving
NOTHING. Don't do it that way!
Unfortunately, AFAIK, we still don't have access to the source so it'd
be difficult to add some elements of a watchdog timer function to the
TT4 code. I think there are some one-chip hardware watchdog timer
solutions now. Might be worth a look, but I've been out of that level
of design for several years, so I'm not familiar with a lot of the newer
ICs. Maybe you could dead-bug the chip, connect it to suitable circuit
nodes with wire-wrap wire and be done with it. If "dead-bug" and
"wire-wrap" are unfamiliar to the younger folks, Wikipedia them
(wire-wrap is actually referenced in the wiki article about dead-bug).
I think the techniques are still useful and the dead-bug method is very
durable.
Barry
N4MSJ
On 10/17/2021 9:10 PM, Compton wrote:
On Mon, Oct 18, 2021 at 12:45 PM, David Schultz, KC5WSV wrote:
Putting one of the problem systems in a location where it was easier
to troubleshoot when it failed would probably help a lot.
Done that. Found nothing. The timer work around works. Not worth
spending any more time on the issue.
--
Compton
VK2HRX
Sydney, Australia
