http://feanor.sssup.it/~giorgio/mars/jones.html Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
OT An embedded-system lesson
Started by ●January 8, 2007
Reply by ●January 8, 20072007-01-08
"Jerry Avins" <jya@ieee.org> wrote in message news:MLSdnSBVqt708T_YnZ2dnUVZ_vWtnZ2d@rcn.net...> http://feanor.sssup.it/~giorgio/mars/jones.htmlThat's a nice story. I remember debugging someone else's RF subsystem during final integration of a satellite at ESA about 18 months ago. The satellite had operated flawlessly in all those rigorous tests you hear about (temperature, vibration, vacuum) until the last moment just prior to shipment to the launch site in Plesetsk. In the integration clean room we finally connected the flight antennas with flight cables (note: we were only allowed one cycle of the SMA connectors!) and suddenly the primary transmitter PA started went into self-oscillation, modulating wildly. Up until this moment ~40dB pads had been placed on the transmitters for two reasons - firstly because there was an unfounded concern several months earlier that we'd allegedly blown some digital driver chips up due to too much environmental RF in the integration clean room, and secondly to save the flight transmitters if no antenna was connected. But of course these pads also presented a beautiful load to the PA. Because the satellite was hours away from delivery for launch, and the RF guy whose department it was was on vacation and not answering his phone I got called and took the next flight over one Friday night to the integration facility. In the end it turned out to be an RF PA that was rather over picky to slight impedance mismatches. I was told later it could have been rectified by adjusting the bias (funny, I never saw that in the documentation!), but even if I'd known that everything had been conformally coated. So I dumped the flight cable and empirically measured various lengths of RF feeder between PA and antenna to tune out the mismatch until it worked. We took a cable that worked, plus the dozen or so bullet connectors that made it the right length, and popped it on a network analyzer to check the electrical length. We then got the 'cable guy' to make us a new space qualified flight cable just the right length, and it worked. The satellite was packed away and shipped to Russia. Next time I heard it was six months later in London standing on top of a building at Imperial College about two hours after it had been launched. Believe me that downlink telemetry never sounded so sweet! It's still in orbit but sadly there was a problem later on with the power unit. But that's a whole other story. Cheers, Howard
Reply by ●January 8, 20072007-01-08
Jerry Avins <jya@ieee.org> writes:> http://feanor.sssup.it/~giorgio/mars/jones.html > > Jerry > -- > Engineering is the art of making what you want from things you can get.I don't like watchdog timers for just this reason [1]. They give S/W developers and managers an excuse for not actually debugging their software and systems. Of course I see the utility of the function (what if the Pathfinder hand't had one?), but it seems that human nature begs their abuse. --Randy [1] I was first forced into using one by a manager circa 1983 and have disliked them ever since. -- % Randy Yates % "Ticket to the moon, flight leaves here today %% Fuquay-Varina, NC % from Satellite 2" %%% 919-577-9882 % 'Ticket To The Moon' %%%% <yates@ieee.org> % *Time*, Electric Light Orchestra http://home.earthlink.net/~yatescr
Reply by ●January 8, 20072007-01-08
Randy Yates wrote:> I don't like watchdog timers for just this reason [1]. They give S/W > developers and managers an excuse for not actually debugging their software > and systems. > > Of course I see the utility of the function (what if the Pathfinder > hand't had one?), but it seems that human nature begs their abuse.I disagree with that point of view --- and I'm actually shocked that, giving the argument yourself ("what if the Pathfinder hadn't had one?"), you still oppose to them. I mean, unless you're trying to sell the idea that the bug occured *because* they decided to put a WDT --- which I really doubt. Maybe I could concede that the probability of such bugs is *slightly higher* with a WDT than without one. But the thing is, the overall "average cost" (sum of all the cost of loss due to a particular event times the probability of that event) is infinitely higher without the WDT --- the probability of bugs may be half the probability without the WDT, but the cost is "infinite" in that event (for a suitable definition of "infinite", and for some subset of the set of possible bugs)> [1] I was first forced into using one by a manager circa 1983 and have > disliked them ever since.You should get over the fact that a *manager* was the person who forecd you to use one --- some times people can do the right thing for the wrong reasons (in that manager's mind, I don't doubt that he was simply in favor of sloppiness and the cheapest solution; so his reasons were wrong --- but he may quite likely have been right in demanding the use of a WDT) Carlos --
Reply by ●January 8, 20072007-01-08
Carlos Moreno <moreno_at_mochima_dot_com@mailinator.com> writes:> Randy Yates wrote: > >> I don't like watchdog timers for just this reason [1]. They give S/W >> developers and managers an excuse for not actually debugging their software >> and systems. >> Of course I see the utility of the function (what if the Pathfinder >> hand't had one?), but it seems that human nature begs their abuse. > > I disagree with that point of view --- and I'm actually shocked that, > giving the argument yourself ("what if the Pathfinder hadn't had one?"), > you still oppose to them. > > I mean, unless you're trying to sell the idea that the bug occured > *because* they decided to put a WDT --- which I really doubt. Maybe > I could concede that the probability of such bugs is *slightly higher* > with a WDT than without one. > > But the thing is, the overall "average cost" (sum of all the cost of > loss due to a particular event times the probability of that event) > is infinitely higher without the WDT --- the probability of bugs > may be half the probability without the WDT, but the cost is > "infinite" in that event (for a suitable definition of "infinite", > and for some subset of the set of possible bugs) > >> [1] I was first forced into using one by a manager circa 1983 and have >> disliked them ever since. > > You should get over the fact that a *manager* was the person who > forecd you to use one --- some times people can do the right thing > for the wrong reasons (in that manager's mind, I don't doubt that > he was simply in favor of sloppiness and the cheapest solution; > so his reasons were wrong --- but he may quite likely have been > right in demanding the use of a WDT)Carlos, Thanks for your opinion. Nothing you've stated has changed mine. -- % Randy Yates % "Rollin' and riding and slippin' and %% Fuquay-Varina, NC % sliding, it's magic." %%% 919-577-9882 % %%%% <yates@ieee.org> % 'Living' Thing', *A New World Record*, ELO http://home.earthlink.net/~yatescr
Reply by ●January 8, 20072007-01-08
Randy Yates wrote:> Jerry Avins <jya@ieee.org> writes: > >> http://feanor.sssup.it/~giorgio/mars/jones.html >> >> Jerry >> -- >> Engineering is the art of making what you want from things you can get. > > I don't like watchdog timers for just this reason [1]. They give S/W > developers and managers an excuse for not actually debugging their software > and systems. > > Of course I see the utility of the function (what if the Pathfinder > hand't had one?), but it seems that human nature begs their abuse. > > --Randy > > [1] I was first forced into using one by a manager circa 1983 and have > disliked them ever since.Randy. I don't like watchdog timers either. I begrudge the extra code to support them and the time to run it. As you say, they hide bugs, especially the subtle ones that are hard to find at best. They are an affront. We need them, but they are usually done wrong.* Hitting master reset during testing is a cop out. I simulate the watchdog with another timer -- tacked-on hardware if need be -- that initiates as close as I can get to a core dump, then stops. No reset. That gives me a fighting chance to see what happened. Only after thorough testing shows that no timeout happens at all in the lab do I enable the internal reset timer for production. So far as I know, no gizmo of mine has ever reset itself in the field. That's luck, but I like to think it isn't dumb luck. Jerry ________________________________ * If there were enough people doing it right, they would have a reset/~dump function built in. -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●January 8, 20072007-01-08
Randy Yates wrote:>>>I don't like watchdog timers for just this reason [1]. They give S/W >>>developers and managers an excuse for not actually debugging their software >>>and systems.Is it is too much of work to kick the dog at all time that you are complaining about? Watchdog is not an excuse for the software/hardware problems, however there is also no excuse for having watchdog not enabled when it is available. It is just not economical to foresee and test for everything. BTW, I have a cordless phone from Casio. It is a good phone except for one problem: if there is a severe thunderstorm outside, it hangs up and stays dead till the backup battery will run down completely. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
Reply by ●January 8, 20072007-01-08
Jerry Avins <jya@ieee.org> writes:> Randy Yates wrote: >> Jerry Avins <jya@ieee.org> writes: >> >>> http://feanor.sssup.it/~giorgio/mars/jones.html >>> >>> Jerry >>> -- >>> Engineering is the art of making what you want from things you can get. >> I don't like watchdog timers for just this reason [1]. They give S/W >> developers and managers an excuse for not actually debugging their software >> and systems. >> Of course I see the utility of the function (what if the Pathfinder >> hand't had one?), but it seems that human nature begs their abuse. >> --Randy >> [1] I was first forced into using one by a manager circa 1983 and >> have >> disliked them ever since. > > Randy. > > I don't like watchdog timers either. I begrudge the extra code to > support them and the time to run it. As you say, they hide bugs, > especially the subtle ones that are hard to find at best. They are an > affront. > > We need them, but they are usually done wrong.* Hitting master reset > during testing is a cop out. I simulate the watchdog with another > timer -- tacked-on hardware if need be -- that initiates as close as I > can get to a core dump, then stops. No reset. That gives me a fighting > chance to see what happened. Only after thorough testing shows that no > timeout happens at all in the lab do I enable the internal reset timer > for production. So far as I know, no gizmo of mine has ever reset > itself in the field. That's luck, but I like to think it isn't dumb > luck.That seems like a very diligent approach, Jerry - I can respect that type of use of the WD timer. -- % Randy Yates % "She's sweet on Wagner-I think she'd die for Beethoven. %% Fuquay-Varina, NC % She love the way Puccini lays down a tune, and %%% 919-577-9882 % Verdi's always creepin' from her room." %%%% <yates@ieee.org> % "Rockaria", *A New World Record*, ELO http://home.earthlink.net/~yatescr
Reply by ●January 8, 20072007-01-08
Vladimir Vassilevsky <antispam_bogus@hotmail.com> writes:> Randy Yates wrote: > > >>>>I don't like watchdog timers for just this reason [1]. They give S/W >>>>developers and managers an excuse for not actually debugging their software >>>>and systems. > > Is it is too much of work to kick the dog at all time that you are > complaining about?No, that's not it - it's the principle of the thing. The amount of code and/or hardware to support it is trivial (as you know).> Watchdog is not an excuse for the software/hardware problems, however > there is also no excuse for having watchdog not enabled when it is > available. It is just not economical to foresee and test for > everything.That is true, but like I stated, it seems to be abused.> BTW, I have a cordless phone from Casio. It is a good phone except for > one problem: if there is a severe thunderstorm outside, it hangs up > and stays dead till the backup battery will run down completely.The backup battery? -- % Randy Yates % "Midnight, on the water... %% Fuquay-Varina, NC % I saw... the ocean's daughter." %%% 919-577-9882 % 'Can't Get It Out Of My Head' %%%% <yates@ieee.org> % *El Dorado*, Electric Light Orchestra http://home.earthlink.net/~yatescr
Reply by ●January 8, 20072007-01-08
Randy Yates wrote:>>BTW, I have a cordless phone from Casio. It is a good phone except for >>one problem: if there is a severe thunderstorm outside, it hangs up >>and stays dead till the backup battery will run down completely. > > The backup battery?Yes, the backup battery inside the phone. In the case of AC fault, the battery powers the CPU so the RTC is active and the voice mail keeps the message memory. Unfortunately, the damn thing sometimes locks up into this state. Aside from the design problems, they are obviously not handling the watchdog properly. I have another example: the old Dlink DI-614 router. It also tends to hang up for good on certain occasions. VLV
