Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #26081

Re: Watchdog for an embedded Linux-based system

Show all headers | View raw

On 3/14/2017 10:28 AM, Dimiter_Popoff wrote:
> On 14.3.2017 г. 18:09, Don Y wrote:
>> Hi Dimiter,
>>
>> On 3/14/2017 3:01 AM, Dimiter_Popoff wrote:
>>
>>>> Don't use a watchdog to fix a DESIGN PROBLEM.  Find a new vendor.
>>>> (How can you have confidence in your product if one of the main
>>>> components
>>>> can't even meet its minimal performance requirements?)
>>>
>>> this is how they do things nowadays, not much we can do about it.
>>
>> Well, *I* can certainly not contribute to the practice!  If you've
>> got a "slow leak" in a tire, do you drive around with a *pump* in
>> the trunk (forever!) or do you fix the leak?
>
> What they seem to do in that situation is to put a larger tire over
> the leaky one, pump a few kilograms of glue between the two and
> move on....

But, that would *solve* the problem -- assuming they similarly
increased the size of the remaining tires.

The "tire pump" remedy I mentioned just *perpetuates* the problem.
Akin to treating symptoms instead of the underlying problem.

It is particularly annoying to see how willingly folks will "dismiss"
problems THAT THEY, THEMSELVES, WITNESSED if they are intermittent (not
EASY to track down).

I designed a LORAN-C-based autopilot early in my career.  In our first
sea trial of the prototype (a piece of perf board bolted to a chunk of
lumber!), we defined a course to circumnavigate Cape Cod (Massachusetts)
<https://en.wikipedia.org/wiki/Cape_Cod> via a set of "waypoints"
designed to allow us to hug the coastline.

[The autopilot worked by letting you enter the latitude and longitude of
these waypoints, in sequence, and it would steer the boat *to* each,
in turn (at the time, most autopilots simply tried to keep a vessel
pointed in a particular direction and couldn't compensate for drift)]

We monitored the boat's course with a position plotter (took positional
information from a LORAN-C receiver and plotted those on a chart/map).
As expected, the vessel's track was true to the series of waypoints we'd
entered (you use the nominal coordinates of buoys in the ocean/bay
as markers cuz its hard to tell one wave from another!  :> ).

But, there was a very noticeable 'S' in the track at one particular point.
As if the algorithm had "overflowed" and then overcompensated before
eventually returning to its ideal track.  I spent weeks (off-hours)
digging through my source code, the floating point library implementation,
etc. in an attempt to understand why this anomaly was present.

Unfortunately, I had no way to log the raw data from the LORAN receiver;
that was the purpose of the plotter's record!  Nor any way to log the
actions INTENDED by my device (had it COMMANDED the vessel to take such
a course?).

My boss dismissed the "problem" -- citing the fact that we had stopped
the vessel in that general area to do some deep sea fishing.  As such,
its movements were largely at the whim of the ocean current and the
MANUAL compensation that the skipper would occasionally bring to bear
(to keep the waves from turning the vessel sideways which would leave it
vulnerable to being toppled by larger waves).

I still have that code (I have *everything* I've ever designed/written)
and periodically drag it out hoping to stumble on some OTHER explanation.
I'd much prefer a genuine bug to explain the behavior than HOPE it was
as my boss had suggested!

A colleague had implemented a video game that suffered from an annoying
"problem" -- almost invariably when the player was having a REALLY GOOD
game!  Yet, it proved difficult to track down as the game is, by its
very nature, based on "random" events (pseudo-random number generators
governing its actions; non-repeatable interactions with the player, etc.).

The game was released with the "problem" unresolved (that market is very
aggressively competitive and narrow windows of "opportunity").

Some *years* later, the problem was found to be a genuine bug (duh!).
Unfortunate that EVERY unit shipped had that bug.  *But*, a strong sense
of closure finally KNOWING the cause!

> Like I said before, past the point of no return. Way past really.

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Watchdog for an embedded Linux-based system pozz <pozzugno@gmail.com> - 2017-03-13 08:55 +0100
  Re: Watchdog for an embedded Linux-based system Mikko OH2HVJ <mikko.syrjalahti@nospam.fi> - 2017-03-13 10:09 +0200
    Re: Watchdog for an embedded Linux-based system pozz <pozzugno@gmail.com> - 2017-03-13 10:06 +0100
      Re: Watchdog for an embedded Linux-based system Joe Chisolm <jchisolm6@earthlink.net> - 2017-03-13 12:11 -0500
  Re: Watchdog for an embedded Linux-based system Tim Wescott <tim@seemywebsite.really> - 2017-03-13 11:24 -0500
    Re: Watchdog for an embedded Linux-based system Paul <paul@pcserviceselectronics.co.uk> - 2017-03-14 20:16 +0000
  Re: Watchdog for an embedded Linux-based system Don Y <blockedofcourse@foo.invalid> - 2017-03-13 17:02 -0700
    Re: Watchdog for an embedded Linux-based system Dimiter_Popoff <dp@tgi-sci.com> - 2017-03-14 12:01 +0200
      Re: Watchdog for an embedded Linux-based system Don Y <blockedofcourse@foo.invalid> - 2017-03-14 09:09 -0700
        Re: Watchdog for an embedded Linux-based system Dimiter_Popoff <dp@tgi-sci.com> - 2017-03-14 19:28 +0200
          Re: Watchdog for an embedded Linux-based system Don Y <blockedofcourse@foo.invalid> - 2017-03-14 11:07 -0700
            Re: Watchdog for an embedded Linux-based system Dimiter_Popoff <dp@tgi-sci.com> - 2017-03-14 20:37 +0200

csiph-web