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/KXVNXSWWBSB3BXSBDPAVSH7OE7V767GR/",
    "mailinglist": "https://mailman.amsat.org/hyperkitty/api/list/[email protected]/",
    "message_id": "[email protected]",
    "message_id_hash": "KXVNXSWWBSB3BXSBDPAVSH7OE7V767GR",
    "thread": "https://mailman.amsat.org/hyperkitty/api/list/[email protected]/thread/KXVNXSWWBSB3BXSBDPAVSH7OE7V767GR/",
    "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:49:27Z",
    "parent": null,
    "children": [],
    "votes": {
        "likes": 0,
        "dislikes": 0,
        "status": "neutral"
    },
    "content": "Thank you for responding with your insight, Bob!\n\nOn 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 trying \n> to get everything we want done then we can back down on capability and \n> reduce power later.\n> There is not a limit or budget on power at this time.\nThank you. I meant to mention I considered the spreadsheet a first order \napproximation 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 may \n> be able to do a quick recycle. There are different types of current \n> monitors to help you with your action plan. It may also be necessary \n> to build a subcircuit to get the results needed.\nWe're not necessarily dealing with hard failure of a part with this \ncurrent switch. We are specifically dealing with single-event upsets \nleading to latchup from a radiation effect that further results in \nunregulated power consumption. This result is considered transient and \nis resolved with a power cycle, hence the use of this part in Fox and \nnow Golf. From our recent experience, hard failure of a part seems \nrelatively rare and we haven't had a recent satellite with batteries \nthat lasted long enough to deal with total ionizing dose, for example. \n(I don't know for sure which AMSAT satellites used non-hardened \nintegrated circuits and thus would be resistant 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. When \n> a device is “radiation harden” this should also be done and hopefully \n> the TMS570 had this done. Still could fail with radiation though.\n\nOne thing to point out... I don't believe the TMS570 is radiation \nhardened. I understand it's used in safety critical equipment and has \nspecial circuitry to detect failure modes. But I wouldn't expect it to \nbe immune to single-event upsets. In the case of bit flips that impact \nprocessing, the TMS570 could detect that as a failure when comparing the \nresults of the two cores and assert a failure. In the case of the RT-IHU \nthis would result in failover to the mirror processor. In the case of \nthe PACSAT payload, which I believe is running a single TMS570, the \nfailure line could be tied to the power circuit to reset. If the power \ncircuity of the TMS570 suffers a single-event upset that latches up a \npower rail I'd expect we'll depend on the current switch to detect and \nrecycle power to recover. (On a related topic, it's pretty fascinating \nto examine the Fox telemetry and observe the impact of the SAA. I don't \nknow if Fox reset every time it traversed the SAA but it was quite \nimpactful.)\n\nAs long as we're talking about radiation affects, nothing we're doing \nwill mitigate total radiation affects that will ultimately degrade and \ncause failure of our chips.\n\nJonathan\n\n-- \nJonathan Brandenburg\nRadio Amateur Satellite Corporation\n1-214-213-1066\n\n",
    "attachments": []
}