Email Detail

HTTP 200 OK
Allow: GET, HEAD, OPTIONS
Content-Type: application/json
Vary: Accept

{
    "url": "https://mailman.amsat.org/hyperkitty/api/list/[email protected]/email/7WXZ5IGQSKFZH5U4CEOJMAIEUUW7QCU7/",
    "mailinglist": "https://mailman.amsat.org/hyperkitty/api/list/[email protected]/",
    "message_id": "[email protected]",
    "message_id_hash": "7WXZ5IGQSKFZH5U4CEOJMAIEUUW7QCU7",
    "thread": "https://mailman.amsat.org/hyperkitty/api/list/[email protected]/thread/7WXZ5IGQSKFZH5U4CEOJMAIEUUW7QCU7/",
    "sender": {
        "address": "jbrandenburg (a) amsat.org",
        "mailman_id": "fba29bb05aa944e3b759fb437017d01e",
        "emails": "https://mailman.amsat.org/hyperkitty/api/sender/fba29bb05aa944e3b759fb437017d01e/emails/"
    },
    "sender_name": "Jonathan Brandenburg",
    "subject": "[pacsat-dev] Re: Latchup Protection and Watchdog Parts",
    "date": "2023-01-25T01:52:44Z",
    "parent": null,
    "children": [],
    "votes": {
        "likes": 0,
        "dislikes": 0,
        "status": "neutral"
    },
    "content": "Minor corrections marked by *** change ***... Not particularly big changes\n\nOn 1/24/23 19:49, Jonathan Brandenburg via pacsat-dev wrote:\n> Thank you for responding with your insight, Bob!\n>\n> On 1/24/23 19:15, Bob Stricklin via pacsat-dev wrote:\n>>\n>> First the Excel spread sheet I sent is a early look at currents \n>> needed. Since I put that together some of the parts have changed and \n>> some have been added.\n>> I am sure we have a power issue but taking the position of just \n>> trying to get everything we want done then we can back down on \n>> capability and reduce power later.\n>> There is not a limit or budget on power at this time.\n> Thank you. I meant to mention I considered the spreadsheet a first \n> order approximation but I may have missed that in my revisions.\n>>\n>> Each time you add one of these current monitors to the design you \n>> introduce another part that can fail due to latch-up and other reasons.\n>>\n>> The action taken for each monitor added may be different. Latch-ups \n>> are possible from radiation exposure. These can be single event or \n>> they can result in a hard failure of a part. When there is an event \n>> and high current the plan may be to power down and wait for a period \n>> of time and then try to restart. If it is the processor with an issue \n>> then you are restarting everything if it is a sub circuit then you \n>> may be able to do a quick recycle. There are different types of \n>> current monitors to help you with your action plan. It may also be \n>> necessary to build a subcircuit to get the results needed.\n> We're not necessarily dealing with hard failure of a part with this \n> current switch. We are specifically dealing with single-event upsets \n> leading to latchup from a radiation effect that further results in \n> unregulated power consumption. This result is considered transient and \n> is resolved with a power cycle, hence the use of this ***type \n> of***part in Fox and now Golf. From our recent experience, hard \n> failure of a part seems relatively rare and we haven't had a recent \n> satellite with batteries that lasted long enough to deal with total \n> ionizing dose, for example. (I don't know for sure which AMSAT \n> satellites used non-hardened integrated circuits and thus would be \n> ***suseptible*** to that affect.)\n>> <snip>\n>>\n>> I worked on optical ICs and since these were exposed to light we had \n>> to be careful not create an issue with latch-up. When a new design \n>> comes out of wafer fab it is one of the early test you do to see if \n>> you have issues. If you find a problem you have try and fix it by \n>> changing the die layout, adding more metal or modify the circuit. \n>> When a device is “radiation harden” this should also be done and \n>> hopefully the TMS570 had this done. Still could fail with radiation \n>> though.\n>\n> One thing to point out... I don't believe the TMS570 is radiation \n> hardened. I understand it's used in safety critical equipment and has \n> special circuitry to detect failure modes. But I wouldn't expect it to \n> be immune to single-event upsets. In the case of bit flips that impact \n> processing, the TMS570 could detect that as a failure when comparing \n> the results of the two cores and assert a failure. In the case of the \n> RT-IHU this would result in failover to the mirror processor. In the \n> case of the PACSAT payload, which I believe is running a single \n> TMS570, the failure line could be tied to the power circuit to reset. \n> If the power circuity of the TMS570 suffers a single-event upset that \n> latches up a power rail I'd expect we'll depend on the current switch \n> to detect and recycle power to recover. (On a related topic, it's \n> pretty fascinating to examine the Fox telemetry and observe the impact \n> of the SAA. I don't know if Fox reset every time it traversed the SAA \n> but it was quite impactful.)\n>\n> As long as we're talking about radiation affects, nothing we're doing \n> will mitigate total radiation affects that will ultimately degrade and \n> cause failure of our chips.\n>\n> Jonathan\n>\n-- \nJonathan Brandenburg\nRadio Amateur Satellite Corporation\n1-214-213-1066\n\n",
    "attachments": []
}