- pacsat-dev - mailman.amsat.org

Re: Is there a pacsat meeting tonight?
by Chris Thompson 04 Feb '23

04 Feb '23

I joined on Thursday but there was no meeting. Did the meeting move to Fridays? 73 Chris On Sat, Feb 4, 2023, 00:44 Burns Fisher (AMSAT) via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > I have not seen an invite. > > 73, > > Burns Fisher, WB1FJ > *AMSAT(R) Engineering -- Flight Software* > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at > https://mailman.amsat.org >

1 0

Fwd: [AMSAT-BB] Possible way to alleviate Greencube congestion: Internet server queue manager integrated with UZ7HO Digipeater software
by Bob Stricklin 03 Feb '23

03 Feb '23

Here is a message John Brier spent a good deal of time thinking though. Its a different idea on how to use digital packets. Begin forwarded message: From: "Timokhov, Sasha via AMSAT-BB" <amsat-bb(a)amsat.org<mailto:amsat-bb@amsat.org>> Subject: [AMSAT-BB] Re: Possible way to alleviate Greencube congestion: Internet server queue manager integrated with UZ7HO Digipeater software Date: February 1, 2023 at 10:01:45 AM CST To: John Brier <johnbrier(a)gmail.com<mailto:johnbrier@gmail.com>> Cc: AMSAT BB <amsat-bb(a)amsat.org<mailto:amsat-bb@amsat.org>> Reply-To: "Timokhov, Sasha" <sasha.timokhov(a)student.tdsb.on.ca<mailto:sasha.timokhov@student.tdsb.on.ca>> Hey John! Cool idea! 73! VE3SVF On Wed, Feb 1, 2023 at 8:53 AM John Brier via AMSAT-BB <amsat-bb(a)amsat.org<mailto:amsat-bb@amsat.org>> wrote: Hi sat ops, Would it be possible/legal to add functionality to UZ7HO Digpeater software to enable a VOLUNTARY / opt-in feature where when you click Send, CQ etc. (to TX a packet), instead of immediately keying the radio, a TX request is sent to a central Internet server (to be created) that sorts requests in some sort of fair sequence and then one by one commands/allows the various requesters to actually TX their packet? The sequence could be sorted by time, i.e. whoever sent the request first gets in line first. It could be partially random to account for latency (whoever is closest to the server doesn't always go first). Additional functionality could be added to the Digpeater software, or a central website, to display the queue so you can see your place and watch the people in front of you send their packets and see yourself move up the queue. This would allow everyone to calm down, knowing their turn is coming. On the IO-117 side hopefully this would mean less long gaps with no packets digpeated/much higher rate of digipeats. Imagine if everyone used it: when busy, IO-117 would be digipeating practically non-stop with gaps to RX as short as a single transmission. The Digipeater software could give each operator a certain number of tries to get the packet digipeated (say 3) before putting them at the back of the queue again if they all fail to be digipeated. The Digipeater software could determine if they are successfully digipeated by checking the RX packets for its own message, and reporting back to the Internet server. The Internet server could even check SatNOGS to verify if the packet was digipeated (it seems telemetry is uploaded in real time). The Internet server software could even be on SatNOGS. You could also do something like WSJT-X and require everyone to have accurate NTP time and packets are sent at specific intervals, RX happens at specific intervals, but all in order, this way there isn't an issue with varied latencies between the server and the requesters. The sorting happens as fast as possible but the scheduling in the intervals is a bit delayed. You could program all sorts of sorting heuristics to make things fair or optimize for certain things. If a new station DX station comes on the digipeater and a pile up starts, maybe the Internet server can be enabled to see who is near their LOS and put them at the top of the queue, or just prioritize anyone near LOS. If a DX station goes out of IO-117 FP, requests to TX to it would not be allowed and the requester could be denied and told why. If stations have contacted each other before from the same grids maybe they could have lower priority. You could even let people complete whole QSOs quickly before moving to the next person in the queue if they are all calling the same DX station, if the DX station is also using the new feature and/or following a set QSO format/exchange. Another benefit of this is it helps low power stations as there is less need to run high power to compete. In the FCC rules at least, it is a requirement that you use the lowest power necessary to achieve the radio comms goal, so if this proposal is possible it is very much in the spirit of the rules and maybe even necessary. It seems a little ridiculous for everyone to be running as much power and gain as possible when I can get in easily with 5-7 watts and 10 elements when the bird is mostly over SA. Of course rovers without internet service can't use this, many people will never use this for various reasons, and they could just not enable the feature and use the Digipeater software as they do today, sending TX commands immediately. Adding this code and creating an Internet server would take a lot of work. I have no solution for that but maybe if UZ7HO can't do it an extension interface can be added to it and someone else can write an extension that communicates with the Internet server. Someone else could also make the Internet server. Or someone could write a new Digipeater software that has all this functionality. If any of this is possible/doable I think it could make IO-117 / GreenCube a lot more easy and fun to work. 73, John Brier KG4AKV P.S. Sorry this isn't more well thought out. I'm not a programmer and I'm just throwing out as many ideas as I can think of. Maybe some are possible. ----------------------------------------------------------- Sent via AMSAT-BB(a)amsat.org<https://url.emailprotection.link/?bWHOqmuFCpfOhnILToqf6ps3f0aWOOFhj2DUZrSti…>. AMSAT-NA makes this open forum available to all interested persons worldwide without requiring membership. Opinions expressed are solely those of the author, and do not reflect the official views of AMSAT-NA. Acceptable Use and Privacy Policies available at https://www.amsat.org/about-amsat/<https://url.emailprotection.link/?bJ-dwWnUgqH9nPOKGILHrfZSs2w22pZXugJCxYz_D…> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/amsat-bb@amsat.org<https://url.emailprotection.link/?bxxCC5TuKmCFb1TRunmlCokCC1HV1MDXUW3I4GHLF…> To unsubscribe send an email to amsat-bb-leave(a)amsat.org<https://url.emailprotection.link/?bWHOqmuFCpfOhnILToqf6ps3f0aWOOFhj2DUZrSti…> Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org<https://url.emailprotection.link/?bO71JCUf8Kb7txAlIoAarNqcIdQhyb8VQQIN4j0Gi…> ----------------------------------------------------------- Sent via AMSAT-BB(a)amsat.org<http://amsat.org>. AMSAT-NA makes this open forum available to all interested persons worldwide without requiring membership. Opinions expressed are solely those of the author, and do not reflect the official views of AMSAT-NA. Acceptable Use and Privacy Policies available at https://www.amsat.org/about-amsat/ View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/amsat-bb@amsat.org To unsubscribe send an email to amsat-bb-leave(a)amsat.org Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org

1 0

Tonights meeting
by Bill 03 Feb '23

03 Feb '23

It looks like my invitation that I sent today did not go out for some reason. My apologies. Bill

1 0

Is there a pacsat meeting tonight?
by Burns Fisher (AMSAT) 03 Feb '23

03 Feb '23

I have not seen an invite. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*

1 0

Pacsat dev meeting 2-2-2023
by Bill 02 Feb '23

02 Feb '23

Pacsat dev meeting 2-2-2023 Thu, Feb 2, 2023 7:00 PM - 9:00 PM (CST) Please join my meeting from your computer, tablet or smartphone. https://meet.goto.com/239406461 You can also dial in using your phone. (For supported devices, tap a one-touch number below to join instantly.) United States: +1 (571) 317-3122 - One-touch: tel:+15713173122,,239406461# Access Code: 239-406-461 Get the app now and be ready when your first meeting starts: https://meet.goto.com/install

1 0

Pacsat dev meeting 1-26-2023
by Bill 26 Jan '23

26 Jan '23

Pacsat dev meeting 1-26-2023 Thu, Jan 26, 2023 7:00 PM - 9:00 PM (CST) Please join my meeting from your computer, tablet or smartphone. https://meet.goto.com/580402901 You can also dial in using your phone. (For supported devices, tap a one-touch number below to join instantly.) United States: +1 (408) 650-3123 - One-touch: tel:+14086503123,,580402901# Access Code: 580-402-901 Get the app now and be ready when your first meeting starts: https://meet.goto.com/install

1 0

Can we improve reliability?
by Jonathan Brandenburg 25 Jan '23

25 Jan '23

In my previous emails with Burns and Bob I was speaking from a position of power rail latchup protection as used on Fox and planned for Golf. I've previously received direction from current and previous VPEs to keep it simple rather than add complexity to improve reliability. Can we do better? Can we improve? Bob raised the possibility of protecting from broader failures, perhaps putting in additional circuity to deal with single-points of failure and such. Certainly I can see us improving our radiation tolerance and failure tolerance with each new project. I admit I don't know exactly what that means in the context of this PACSAT payload but at least want to open to door to such conversations. Thoughts? Jonathan -- Jonathan Brandenburg Radio Amateur Satellite Corporation 1-214-213-1066

1 0

Re: Latchup Protection and Watchdog Parts
by Jonathan Brandenburg 25 Jan '23

25 Jan '23

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

1 0

Re: Latchup Protection and Watchdog Parts
by Jonathan Brandenburg 25 Jan '23

25 Jan '23

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

1 0

Re: Latchup Protection and Watchdog Parts
by Bob Stricklin 25 Jan '23

25 Jan '23

Jonathan, This is a complicated issue that will require some time to study. First the Excel spread sheet I sent is a early look at currents needed. Since I put that together some of the parts have changed and some have been added. I am sure we have a power issue but taking the position of just trying to get everything we want done then we can back down on capability and reduce power later. There is not a limit or budget on power at this time. Each time you add one of these current monitors to the design you introduce another part that can fail due to latch-up and other reasons. The action taken for each monitor added may be different. Latch-ups are possible from radiation exposure. These can be single event or they can result in a hard failure of a part. When there is an event and high current the plan may be to power down and wait for a period of time and then try to restart. If it is the processor with an issue then you are restarting everything if it is a sub circuit then you may be able to do a quick recycle. There are different types of current monitors to help you with your action plan. It may also be necessary to build a subcircuit to get the results needed. It is likely that we never see this happen but if it does happen we will want to capture the event in some way. If a problem is happening in orbit in a particular die/circuit we may be able to work around the problem. If it is the processor that is more difficult to capture events. The processor and memory will have larger die size and more gates so more likely that if we do have any events these will be the parts with a problem. I worked on optical ICs and since these were exposed to light we had to be careful not create an issue with latch-up. When a new design comes out of wafer fab it is one of the early test you do to see if you have issues. If you find a problem you have try and fix it by changing the die layout, adding more metal or modify the circuit. When a device is “radiation harden” this should also be done and hopefully the TMS570 had this done. Still could fail with radiation though. These are some of my thoughts. Bob On Jan 24, 2023, at 4:54 PM, Jonathan Brandenburg (KF5IDY) via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: Now that you mention it, not my forté either! I was working in the abstract without really thinking about what a latchup actually results in… I think I was just assuming “super high” current without any real idea of what that really means. I conceptually like the idea of each “subsystem” having its own current limiter that is tuned to that particular device. Takes a bit of real estate but these are small chips. Jonathan Sent from my iPad On Jan 24, 2023, at 5:43 PM, Burns Fisher (AMSAT) <wb1fj(a)fisher.cc<mailto:wb1fj@fisher.cc>> wrote: Not really my forté but I’d worry that a higher current load switch for two devices would allow a higher current due to a SEU on a single device. Too much current and device fails before the load switch cuts it off? On Wed, Jan 25, 2023 at 11:37 AM Jonathan Brandenburg via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: On 1/19/23 17:40, Rich Gopstein via pacsat-dev wrote: > Burns might remember the details (or Zach certainly would), but one of > those parts was undersized for the RT-IHU and would cut out when we > were transmitting with the ax5043. I think we had to back down the > xmit power in order for the device not to reset. > > It didn't take a whole lot of research for me to figure this one out. The FPF2001 used on the Fox boards has a fixed current limit of 50mA. I can see that could be sufficient for the Fox IHU since it uses a low power processor and doesn't have transceivers or the power amplifier. The direct replacement part for the FPF2001 is the TI TPS22942 and it appears to be pin compatible with a fixed limit of 100mA. Would a 100mA be a problem on Fox? I wouldn't think it would cause failure in the 10ms it takes to blank the current but I make that statement without any real basis. Perhaps the 40mA limit of the TI TPS22942 would be sufficient. Anyway, back to PACSAT... With the higher current capacity of the MAX4995, adjustable between 0 and 600 mA, it could be the better choice than the fixed TI TPS22942. I'm not aware of flight experience with either so I tend to look to the MAX4995 with the adjustable and higher current limits. With this decision and looking at the approach employed on the RT-IHU I could see the following: 1 - The TMS570 and associated circuitry get their own MAX4995. As a first order pass contained in Bob Stricklin's spreadsheet the current requirement is 458.3mA, within the MAX4995's capabilities. If we want to further "derate" we could put the TMS570 on one MAX4995 and have a second MAX4995 for the peripherals. 2 - All five AX5043's require 100mA. Would we want to have 2 of the AX5043's on one MAX4995 and the remaining AX5043's on the other MAX4995 in case one MAX4995 fails prematurely? The value of this would depend on all the AX5043's being equivalent in function (i.e., all could be used for command and/or telemetry). This only takes care of this particular failure mode and still leaves a lot of other failure modes in which an early MAX4995 death would leave the system INOP so there may be limited value in using two MAX4995's for the AX5043's. 3 - Finally, the amplifier/pre-amp is an additional 415mA. Again, if we want to "derate" we could put the power amp on it's own MAX4995. It looks like we need a minimum of 3 MAX4995's and a possible max of 6 MAX4995's. (With further analysis, we might need one more to split the 1.2V and 3.3V power lines to the TMS570.) The MAX4995 are small chips so don't require a lot of real estate. We can discuss the risk vs reward of using more MAX4995's at some point. I welcome comments Jonathan -- Jonathan Brandenburg Radio Amateur Satellite Corporation 1-214-213-1066 ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org<https://url.emailprotection.link/?buUg7YY4HZLXKo6ZKNudC8bRTBdOsBlAV5C9rq-aq…> To unsubscribe send an email to pacsat-dev-leave(a)amsat.org<mailto:pacsat-dev-leave@amsat.org> Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org<https://url.emailprotection.link/?bO71JCUf8Kb7txAlIoAarNqcIdQhyb8VQQIN4j0Gi…> -- 73, Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org To unsubscribe send an email to pacsat-dev-leave(a)amsat.org<mailto:pacsat-dev-leave@amsat.org> Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org

1 0