|
Hello. I have two MT4BB units being used as low-current-draw digis on mountain tops. I am having an issue with them working for a few weeks/months/etc then falling off the the face of the earth. We know they have power as they're on the same power source as the VHF repeaters that are up there working fine. We have no reboot capability, at least not remotely, so I am wondering if anyone knows of an issue that would cause them to just lock up/halt without reason? It's infuriating as we picked them for their all-in-one design and simplicity. Now I am questioning if there is maybe something else we should be using. Anyone able to suggest why this might be happening or have any similar experiences?
|
I am in a group in Sydney that uses 4 of these. We experence the same issue. We ended up fitting a timer that turns the power on/off. We set the time to do this every Tue at 2AM. If they happen to go off air during the week then the timer will revive them on Tues at 2AM. Yes, its an annnnoying porblem but the timer does work as a good work around. We are suspicious of RF getting into them that causes the hang up to occur. Seems to occur in the 2-3 month time period but we can see no pattern to it.
Allen and Byron at Byonics are aware of the issue.
This is the timer we use:
--
Compton
VK2HRX
Sydney, Australia
|
Compton,
Why not reset the timer more often? (Every day?) Are you finding that once a week is enough to keep the units running reliably? Our problem is not being able to replicate the hanging complaint in a TT4 or an MTT4BT. I recently found that the MAX232 chip has a non-documented problem that occasionally causes the chip to lock up, overheat, and draw a bunch of excess power ( Google "MAX232 overheating" and you will see that the problem with the chip has been going on for years with no satisfactory explanation) I hoped I could find someone who has consistent lock-up to see if pulling the MAX232 chip solved the problem...of course, this would need to be in a digipeater or similar application where the serial ports are not in use during operation. When the MAX gets hot, it may start sending gibberish to the TT4 chip. I like your timer solution, but I wish it was not necessary! If you get to one of your remote units, can you see if pulling the MAX chip makes any difference??
73,
Allen
-----Original Message-----
From: Compton <comptonallen@...>
To: [email protected]
Sent: Sun, Oct 17, 2021 3:06 pm
Subject: Re: [TinyTrak] MT4BB Halting
[Edited Message Follows]
I am in a group in Sydney that uses 4 of these. We experence the same issue. We ended up fitting a timer that turns the power on/off. We set the time to do this every Tue at 2AM. If they happen to go off air during the week then the timer will revive them on Tues at 2AM. Yes, its an annnnoying porblem but the timer does work as a good work around. We are suspicious of RF getting into them that causes the hang up to occur. Seems to occur in the 2-3 month time period but we can see no pattern to it.
Allen and Byron at Byonics are aware of the issue.
This is the timer we use:
--
Compton
VK2HRX
Sydney, Australia
|
Hi Allen,
We selected once a week as the units have always lasted between 1-3 months before hanging. We could do it daily or even hourly but once a week works. There has only been a single episode when the hanging occurred between the weekly power on/off events and the power cycle restored the unit. It happens to all of our units and we know of at least 1 other where it also happens. One unit operates in an aircon controlled comms hut, the others are under cover but no air con and temps could certainly get to 40C in summer.
I can get to a few ouf our units fairly easily.
Not sure what you mean by pulling the Max chip.
--
Compton
VK2HRX
Sydney, Australia
|
On 10/17/21 7:26 PM, vhsproducts via groups.io wrote: Compton,
Why not reset the timer more often? (Every day?) Are you finding that once a week is enough to keep the units running reliably? Our problem is not being able to replicate the hanging complaint in a TT4 or an MTT4BT. I recently found that the MAX232 chip has a non-documented problem that occasionally causes the chip to lock up, overheat, and draw a bunch of excess power ( Google "MAX232 overheating" and you will see that the problem with the chip has been going on for years with no satisfactory explanation) An open input might be asking for trouble. On something where the serial port isn't being used, a connector wired to pull the input to a known state might help. Putting one of the problem systems in a location where it was easier to troubleshoot when it failed would probably help a lot. -- David Schultz
|
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
|
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
toggle quoted message
Show quoted text
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
|
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
|
Dave,
The MAX chip has built-in pull-ups, and a bunch of people have tried adding external pull ups or pull downs with out any clear resolution. The problem is so intermittent, that its very difficult to tell if you have solved the problem with any particular hardware fix. Of the many years of the problem that have gone by ( And the Mfg denying that the problem even exists) No one has a bulletproof fix. There are several known ways you can induce the converter chip to go berserk, and it only rarely kills the chip.?
FYI, for quite some time, any new MTT4BT-40 has an additional bimetallic thermostat that will switch off the power amplifier if the MTT4BT-40 locks-up in transmit mode. Fortunately, this only happens if their is a cataclysmic failure of the antenna. When any MTT4BT-40 comes back for service, check-out or programming, I automatically add the thermostat to the unit, switching off the power amp when it reaches 50C, and with a drop-out period for cool down of several minutes.?
73,
Allen AF6OF
-----Original Message-----
From: David Schultz, KC5WSV <david.schultz@...>
To: [email protected]
Sent: Sun, Oct 17, 2021 6:45 pm
Subject: Re: [TinyTrak] MT4BB Halting
On 10/17/21 7:26 PM, vhsproducts via groups.io wrote:
> Compton,
>
> Why not reset the timer more often? (Every day?) Are you finding that
> once a week is enough to keep the units running reliably? Our problem is
> not being able to replicate the hanging complaint in a TT4 or an MTT4BT.
> I recently found that the MAX232 chip has a non-documented problem that
> occasionally causes the chip to lock up, overheat, and draw a bunch of
> excess power ( Google "MAX232 overheating" and you will see that the
> problem with the chip has been going on for years with no satisfactory
> explanation)
An open input might be asking for trouble. On something where the serial
port isn't being used, a connector wired to pull the input to a known
state might help.
Putting one of the problem systems in a location where it was easier to
troubleshoot when it failed would probably help a lot.
--
David Schultz
|
I am not sure what the MT4BB is?
If it really "IS" the max232 chip, and the MAX232 chip is in a socket (MTT4B and kit TT4), I suggest removing the chip and interfacing with the unit through TTL connectors.? There are many FTDI or cheaper knock offs available for interfacing with the computer.
I don't know if the BT module requires the MAX232 chip (since most modules are TTL, I am guessing the answer is no).
Remove the MAX232 chip from the socket (if you used one).? If not, you could remove it and install a socket, but that may not be worth the effort. Use?24 gauge AWG solid wire to jumper across the socket. ?
These can be pushed in the socket without damage and removed to put the MAX232 chip back in - if needed.
?? 7 <--> 10 ?? 8 <-->? 9
?11 <--> 14 ?12 <--> 13
Of course that would require a (new) TTL serial GPS - but these are cheap too.? Since most have 5V on one of the pins, these are similar to the Byonics TT USB cable (but different logic levels) and convenient for changing settings.?
NOTE:? This is the same as the MTT4B-mini.
IMPORTANT!!!? Do not use the Byonics TT USB with jumpers.? The logic levels are very different.
Robert Giuliano KB8RCO
On Monday, October 18, 2021, 08:42:13 AM EDT, vhsproducts via groups.io <vhsproducts@...> wrote:
Dave,
The MAX chip has built-in pull-ups, and a bunch of people have tried adding external pull ups or pull downs with out any clear resolution. The problem is so intermittent, that its very difficult to tell if you have solved the problem with any particular hardware fix. Of the many years of the problem that have gone by ( And the Mfg denying that the problem even exists) No one has a bulletproof fix. There are several known ways you can induce the converter chip to go berserk, and it only rarely kills the chip.?
FYI, for quite some time, any new MTT4BT-40 has an additional bimetallic thermostat that will switch off the power amplifier if the MTT4BT-40 locks-up in transmit mode. Fortunately, this only happens if their is a cataclysmic failure of the antenna. When any MTT4BT-40 comes back for service, check-out or programming, I automatically add the thermostat to the unit, switching off the power amp when it reaches 50C, and with a drop-out period for cool down of several minutes.?
73,
Allen AF6OF
-----Original Message-----
From: David Schultz, KC5WSV <david.schultz@...>
To: [email protected]
Sent: Sun, Oct 17, 2021 6:45 pm
Subject: Re: [TinyTrak] MT4BB Halting
On 10/17/21 7:26 PM, vhsproducts via groups.io wrote:
> Compton,
>
> Why not reset the timer more often? (Every day?) Are you finding that
> once a week is enough to keep the units running reliably? Our problem is
> not being able to replicate the hanging complaint in a TT4 or an MTT4BT.
> I recently found that the MAX232 chip has a non-documented problem that
> occasionally causes the chip to lock up, overheat, and draw a bunch of
> excess power ( Google "MAX232 overheating" and you will see that the
> problem with the chip has been going on for years with no satisfactory
> explanation)
An open input might be asking for trouble. On something where the serial
port isn't being used, a connector wired to pull the input to a known
state might help.
Putting one of the problem systems in a location where it was easier to
troubleshoot when it failed would probably help a lot.
--
David Schultz
|
Rob,
The MTT4BT-40 is much the same as the original MTT4B, we just decided that all the MTT4BT's would have the Bluetooth Module instead of having to stock four different varieties of MTT4BT's ( Low and high power MTT4BT's, with and without BT modules)
?IF the cause of the TT4-hang is actually caused by the MAX232 chip in the MTT4BT-40,? and someone has an application where it does occasionally hang ( Like Compton's,? Australian installs), AND they are not using the serial ports ( Pretty common thing in a portable, battery powered digi I would think)? I am interested in having them pull the MAX232 chip solely to rule out the MAX chip overheating as the root cause of the hanging or locked up MTT4BT.
?I have seen the MAX232 chip lock and overheat, but I have not been able to replicate the lock up of the MTT4BT-40...Pulling the chip is just an experiment, the root cause is a mystery, but the other working theory is an issue related to high SWR building up RF voltage on the PCB. ( A problem we see with TT3's and compromised antennae quite a bit) Pulling the MAX232 out of the machine assembled, SMD TT4 would be a challenge!?
The BT unit is selected internally for connecting to the TT4 COMPORT A? via jumpers, or to the external serial (2.5mm jack) through the MAX 232. The BT module can only be connected to the the PORTA TTL (UART) or to the 2.5mm jack through the serial/TTL converter in the case of someone who may need to change their Bluetooth parameters. If the jumpers are set to connect the 2.5mm jack to the TT4 via the MAX232 converter, the BT module is still awake, its just not connected to anything.?
?If the issue is related to the converter, communicating via TTL is an alternative ( I did not set up the PCB for easy access to PORTA and PORTB through a TTL connection, but its doable with minor surgery) But its not a very convenient or clean way of dealing with the root problem as a permanent solution.?
73,
Allen AF6OF
-----Original Message-----
From: Rob Giuliano via groups.io <kb8rco@...>
To: [email protected] < [email protected]>
Sent: Mon, Oct 18, 2021 6:20 am
Subject: Re: [TinyTrak] MT4BB Halting
I am not sure what the MT4BB is?
If it really "IS" the max232 chip, and the MAX232 chip is in a socket (MTT4B and kit TT4), I suggest removing the chip and interfacing with the unit through TTL connectors.? There are many FTDI or cheaper knock offs available for interfacing with the computer.
I don't know if the BT module requires the MAX232 chip (since most modules are TTL, I am guessing the answer is no).
Remove the MAX232 chip from the socket (if you used one).? If not, you could remove it and install a socket, but that may not be worth the effort.
Use?24 gauge AWG solid wire to jumper across the socket. ?
These can be pushed in the socket without damage and removed to put the MAX232 chip back in - if needed.
?? 7 <--> 10
?? 8 <-->? 9
?11 <--> 14
?12 <--> 13
Of course that would require a (new) TTL serial GPS - but these are cheap too.? Since most have 5V on one of the pins, these are similar to the Byonics TT USB cable (but different logic levels) and convenient for changing settings.?
NOTE:? This is the same as the MTT4B-mini.
IMPORTANT!!!? Do not use the Byonics TT USB with jumpers.? The logic levels are very different.
Robert Giuliano
KB8RCO
On Monday, October 18, 2021, 08:42:13 AM EDT, vhsproducts via groups.io <vhsproducts@...> wrote:
Dave,
The MAX chip has built-in pull-ups, and a bunch of people have tried adding external pull ups or pull downs with out any clear resolution. The problem is so intermittent, that its very difficult to tell if you have solved the problem with any particular hardware fix. Of the many years of the problem that have gone by ( And the Mfg denying that the problem even exists) No one has a bulletproof fix. There are several known ways you can induce the converter chip to go berserk, and it only rarely kills the chip.?
FYI, for quite some time, any new MTT4BT-40 has an additional bimetallic thermostat that will switch off the power amplifier if the MTT4BT-40 locks-up in transmit mode. Fortunately, this only happens if their is a cataclysmic failure of the antenna. When any MTT4BT-40 comes back for service, check-out or programming, I automatically add the thermostat to the unit, switching off the power amp when it reaches 50C, and with a drop-out period for cool down of several minutes.?
73,
Allen AF6OF
-----Original Message-----
From: David Schultz, KC5WSV <david.schultz@...>
To: [email protected]
Sent: Sun, Oct 17, 2021 6:45 pm
Subject: Re: [TinyTrak] MT4BB Halting
On 10/17/21 7:26 PM, vhsproducts via groups.io wrote:
> Compton,
>
> Why not reset the timer more often? (Every day?) Are you finding that
> once a week is enough to keep the units running reliably? Our problem is
> not being able to replicate the hanging complaint in a TT4 or an MTT4BT.
> I recently found that the MAX232 chip has a non-documented problem that
> occasionally causes the chip to lock up, overheat, and draw a bunch of
> excess power ( Google "MAX232 overheating" and you will see that the
> problem with the chip has been going on for years with no satisfactory
> explanation)
An open input might be asking for trouble. On something where the serial
port isn't being used, a connector wired to pull the input to a known
state might help.
Putting one of the problem systems in a location where it was easier to
troubleshoot when it failed would probably help a lot.
--
David Schultz
|
Watchdog timers are awesome and easy to implement internally in most any micro.? Here is an external one in an old-fashioned dip:
As Barry pointed out, you can deadbug it by gluing it upside down with epoxy or such, and soldering to the pins in the air.? However, the watchdog needs a periodic reset within its timeout window, and the firmware needs to provide this on a pin, or some signal on the board needs to be tapped that is fast enough to keep the WD happy, yet stops toggling when the system hangs.? Not something that is generally added after the fact.
Also, there are system latchups that require a power cycle to clear.? The silicon structure can get an scr-like trigger from static zaps, rf, or whatever, and a reset will not clear it.? For a remote install, a timer cycling power at midnight is a pretty good plan, and easy to implement.
gil
----- Original message -----
Subject: Re: [TinyTrak] MT4BB Halting
Date: Monday, October 18, 2021 5:31 AM
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@...>
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
|
On 10/18/21 7:31 AM, vhsproducts via groups.io 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. The ATMEGA has a watchdog timer built in. Which should be just fine for detecting hung code. Not the greatest which reminds me of a web page I ran across years ago: -- David Schultz
|
The ATMEGA has a watchdog timer built in. Which should be just fine for
detecting hung code.
One would think so, wouldn't one? Byon could doubtless address that better, but the illusive hanging condition does not seem to fit into definition of hanging code as we seem to view it. This is kind of a Loch Ness monster kind of thing, a rare problem, and once we come running to see it, it ducks its little head back under the water! If we could see it happen, we would be a lot better off.
One other way we have dealt with this is to use one of our DTMF receiver/decoders to force a commanded reset:?http://byonics.com/dtmf? As my mentor taught me many years ago, "there is no problem that can't be solved with brute force and ignorance!" I have plenty of both.?
73,
Allen
-----Original Message-----
From: David Schultz, KC5WSV <david.schultz@...>
To: [email protected]
Sent: Mon, Oct 18, 2021 3:38 pm
Subject: Re: [TinyTrak] MT4BB Halting
On 10/18/21 7:31 AM, vhsproducts via groups.io 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.
The ATMEGA has a watchdog timer built in. Which should be just fine for
detecting hung code. Not the greatest which reminds me of a web page I
ran across years ago:
--
David Schultz
|
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
|
good thinking.? pretty much exactly what Jack Ganssel said in the
OP link
I hope everyone will read this and take a few lessons.? Jack is
absolutely the premiere of embedded system programming, he has a
lot of great stories.
(every bug I make, has been made before, somewhere...)
Clifff K6CLS CM87
On 2021-10-18 16:02, vhsproducts via
groups.io wrote:
toggle quoted message
Show quoted text
The ATMEGA has a watchdog
timer built in. Which should be just fine for
detecting hung code.
One would think so, wouldn't one? Byon could doubtless
address that better, but the illusive hanging condition
does not seem to fit into definition of hanging code as
we seem to view it. This is kind of a Loch Ness monster
kind of thing, a rare problem, and once we come running
to see it, it ducks its little head back under the
water! If we could see it happen, we would be a lot
better off.
One other way we have dealt with this is to use one
of our DTMF receiver/decoders to force a commanded
reset:?? As my mentor taught me
many years ago, "there is no problem that can't be
solved with brute force and ignorance!" I have plenty
of both.?
73,
Allen
-----Original Message-----
From: David Schultz, KC5WSV
<david.schultz@...>
To: [email protected]
Sent: Mon, Oct 18, 2021 3:38 pm
Subject: Re: [TinyTrak] MT4BB Halting
On 10/18/21 7:31 AM, vhsproducts
via groups.io 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.
The ATMEGA has a watchdog timer built in.
Which should be just fine for
detecting hung code. Not the greatest which
reminds me of a web page I
ran across years ago:
--
David Schultz
|
Thanks everyone!
I am eager to remove the MAX232 just for the few mA of quiescent current back into the power budget as these are both solar sites. I am planning to install a relay that I will trip via DTMF from our Arcom controller at the site. It has an active-low output option so a 3906, a decent snubber diode, and a 1k resistor should be enough to trigger a NC side of a relay to open long enough to reset the power to the unit.
Cheers,
Bob Holowenko
B.Tech & ASC (Computer Forensics), Dipl Technical Studies, CCNA CCNP ASC?
Quesnel Search and Rescue Society, Director?
Quesnel Emergency Radio Communications, DERC - VE7WNKcell: 250-255-6439email:?holowenko@...
On Tue, Oct 19, 2021 at 9:16 PM Cliff Sojourner < cls@...> wrote:
good thinking.? pretty much exactly what Jack Ganssel said in the
OP link
I hope everyone will read this and take a few lessons.? Jack is
absolutely the premiere of embedded system programming, he has a
lot of great stories.
(every bug I make, has been made before, somewhere...)
Clifff K6CLS CM87
On 2021-10-18 16:02, vhsproducts via
wrote:
The ATMEGA has a watchdog
timer built in. Which should be just fine for
detecting hung code.
One would think so, wouldn't one? Byon could doubtless
address that better, but the illusive hanging condition
does not seem to fit into definition of hanging code as
we seem to view it. This is kind of a Loch Ness monster
kind of thing, a rare problem, and once we come running
to see it, it ducks its little head back under the
water! If we could see it happen, we would be a lot
better off.
One other way we have dealt with this is to use one
of our DTMF receiver/decoders to force a commanded
reset:?? As my mentor taught me
many years ago, "there is no problem that can't be
solved with brute force and ignorance!" I have plenty
of both.?
73,
Allen
-----Original Message-----
From: David Schultz, KC5WSV
<david.schultz@...>
To: [email protected]
Sent: Mon, Oct 18, 2021 3:38 pm
Subject: Re: [TinyTrak] MT4BB Halting
On 10/18/21 7:31 AM, vhsproducts
via 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.
The ATMEGA has a watchdog timer built in.
Which should be just fine for
detecting hung code. Not the greatest which
reminds me of a web page I
ran across years ago:
--
David Schultz
|
On 10/18/2021 5:38 PM, David Schultz, KC5WSV wrote: On 10/18/21 7:31 AM, vhsproducts via groups.io 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. The ATMEGA has a watchdog timer built in. Which should be just fine for detecting hung code. Not the greatest which reminds me of a web page I ran across years ago:
Excellent article. Read it all and was informed AND entertained. I've bookmarked it. Unfortunately, the Niall Murphy article referenced at the end of the article pulls up a cryptic error. Hopefully I'll remember to look into that later. My earlier post dismissed the notion of using the TT4 based watchdog since the source code is unavailable, but a dead-bugged single-chip watchdog IC might still be possible if a suitable, already-existing WDT "kicker" signal can be located on the TT4. Maybe Byon will give us a clue. I would think just a simple, no-frills WDT should be sufficient for almost all remote TT4 applications. The failed product I took over was not a critical thing since the product I delivered was just a one-off prototype to demonstrate a concept. We built two demo units, one to develop the firmware on and the second to deliver a pristine copy to the customer. The undelivered unit MAY be in my messy garage. If the demo generated a follow-on contract to produce some quantity of products based on the prototype, then it would be a whole different ballgame, as the concept was developed to hopefully save lives in an industrial situation. My involvement in this product was temporary, just to fill in and clean up someone else's mess, so I never heard how the project continued (or even if it did continue). Barry
|
Try instead.? I think it is the same article.
toggle quoted message
Show quoted text
On 20/10/2021 14:42, Barry L. Lankford wrote: Unfortunately, the Niall Murphy article referenced at the end of the article pulls up a cryptic error.
--
Ian G3ZHX
|
On 10/20/21 8:42 AM, Barry L. Lankford wrote: Excellent article.? Read it all and was informed AND entertained.? I've bookmarked it.? Unfortunately, the Niall Murphy article referenced at the end of the article pulls up a cryptic error.? Hopefully I'll remember to look into that later.
One of the handier add ons to Firefox fires up the archive when this sort of thing happens. -- David Schultz
|
Compton
Barry L. Lankford
Cliff Sojourner K6CLS