January 2023 - pacsat-dev - mailman.amsat.org

Fwd: BPSK on ax5043 Service Request #242527
by Rich Gopstein 13 Feb '23

13 Feb '23

---------- Forwarded message --------- From: <onhelp(a)onsemi.com> Date: Tue, Dec 17, 2019 at 11:51 AM Subject: Re: BPSK on ax5043 Service Request #242527 To: <rich(a)ourowndomain.com> Response From ON Semiconductor Service Request #242527 ON Semiconductor Technical Support Center Voice Mail: 800-282-9855 (US & Canada) Web Site: http://www.onsemi.com/pub/tech_support **************************************************************** Please do not reply to this email. Please submit any additional questions via our web site or by calling the ON Semiconductor Technical Support Center. Thank you. **************************************************************** Hello Rich Gopstein, Thank you for contacting ON Semiconductor. There is option for PSK mode only, configuration can be created with AX-RadioLab. You need to enter '1962' in the TX Periodic field on the main screen, and press enter. PSK mode, along with other more advanced options will be available in the PHY screen. If you have any further questions, please do not hesitate to contact us back. Regards, Martin ON Semiconductor Technical Support Center Subject: BPSK on ax5043 Description of customer request: I am working on software to drive an AX5043 which needs to transmit and receive BPSK. It doesn't look like AX-RadioLAB has BPSK as an option and I can't find any application notes about using BPSK on the ax5043.

2 1

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:[email protected]>> 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:[email protected]>> 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:[email protected]>> 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:[email protected]> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected]<https://url.emailprotection.link/?buUg7YY4HZLXKo6ZKNudC8bRTBdOsBlAV5C9rq-aq…> To unsubscribe send an email to pacsat-dev-leave(a)amsat.org<mailto:[email protected]> 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:[email protected]> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected] To unsubscribe send an email to pacsat-dev-leave(a)amsat.org<mailto:[email protected]> Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org

1 0

Re: Latchup Protection and Watchdog Parts
by Burns Fisher (AMSAT) 24 Jan '23

24 Jan '23

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> 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 > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/[email protected] > 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 > -- 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*

2 1

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

24 Jan '23

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

1 0

PACSAT - AO-16
by Jim McCullers 23 Jan '23

23 Jan '23

At our development meeting last Thursday night one of the discussed items were the uplink frequencies of the original PACSAT. Curiosity over the weekend lead to a bit of online research that produced a few QST articles from the time period revealing details on the original PACSAT. PACSAT was AO-16 launched 33 years ago on January 22, 1990 along with an almost twin LUSAT (OSCAR-19) built by AMSAT Argentina. They were launched into sun synchronous orbit from the ESA facility in French Guiana with an altitude of 800km. Both were a new generation of Microsats measuring 230x230x213mm. AO-16 received on 2-meters at 145.9, 145.92, 145.94 and 145.96 mhz and transmitted on 437.050 with 4 watts maximum. LUSAT received on 2-meters at 145.84, 145.86, 145.88 and 145.90 mhz and transmitted on 437.125 with 4 watts maximum with a backup transmitter at 437.150. The frequencies vary by article probably reflecting changing configurations and the above were taken from a post launch article. Power output was variable by command and on 70cm achieved 65% efficiency. Uplink was FM, 1200 BPS Manchester encoded FSK and downlink was 1200 bps RC-BPSK SSB. Storage space was 4mb RAM. Interestingly, one QST article it list the designers of the command module and one call is familiar, N5BRG. All questions are now to you Bob! 73 Jim McCullers WA4CWI

1 0

Re: Latchup Protection and Watchdog Parts
by Rich Gopstein 20 Jan '23

20 Jan '23

Good question... Maybe it was just during development you need to disable it in order to successfully flash new code since nothing would be resetting the wd? I know on my board, the jumper is always in place so I don't know that we've tested the hw wd. Btw, the tms570 has a software watchdog which we have code for and we have tested. I also vaguely recall a conversation about the timing of the hw wd. I don't remember if it was the wd on the 1.1 board or the 1.2 board, but Zach had proposed a chip with a maximum timeout of something pretty short - well under a second. I was concerned that if something went south, the wd chip would continuously power cycle the processor multiple times a second. These conversations were from a while ago and I likely have the details wrong. On Fri, Jan 20, 2023, 8:18 AM Jonathan Brandenburg via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > This I didn't know! Does anybody on the list know why the hardware > watchdog wasn't working as expected on the RT-IHU? > > Jonathan > On 1/19/23 17:43, Rich Gopstein wrote: > > And - as long as I'm thinking about it, we had to disable the hardware > watchdog on the RT-IHU to get it to run. I don't recall if that changed, > but if you get some RT-IHU boards, you might need to jumper the hardware WD > disable. > > Rich > > > On Thu, Jan 19, 2023 at 6:40 PM Rich Gopstein via pacsat-dev < > pacsat-dev(a)amsat.org> 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. >> >> Rich >> >> >> On Thu, Jan 19, 2023 at 5:46 PM Jonathan Brandenburg via pacsat-dev < >> pacsat-dev(a)amsat.org> wrote: >> >>> In last week's meeting, I noted I had been looking at the schematics for >>> Fox-1 and RT-IHU and found the circuits for the latchup protection and >>> watchdog functions. I admit this might be basic to some, but I'm finding >>> it fascinating! Anyway... >>> >>> Since last week's meeting, I researched the parts used: >>> >>> onsemi FPF2001 is a current limit switch used on both Fox-1 and half the >>> RT-IHU. It's obsolete, replaced by onsemi's FPF2000. But the FPF2000 is >>> listed as end-of-life. It's replacement part is the TI TPS22942. >>> >>> MAX4995 is a current limit switch used on the other half of the. This >>> part looks good for new designs. >>> >>> >>> For the watchdog functionality, both Fox-1 and RT-IHU use the >>> STWD100NYWY3F chip. this parts looks good for new designs. >>> >>> >>> That's as far as I got. Next, I want to research the Fox-1 and RT-IHU >>> designs to determine the thresholds of the current limit switches. In >>> particular, I want to see if the TPS22942 is a suitable replacement, >>> assuming we have the same current requirements. >>> >>> That's where I'm at, >>> >>> Jonathan >>> >>> >>> -- >>> Jonathan Brandenburg >>> Radio Amateur Satellite Corporation >>> 1-214-213-1066 >>> >>> >>> ----------------------------------------------------------- >>> >>> pacsat-dev mailing list -- pacsat-dev(a)amsat.org >>> View archives of this mailing list at >>> https://mailman.amsat.org/hyperkitty/list/[email protected] >>> 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 >>> >> >> ----------------------------------------------------------- >> >> pacsat-dev mailing list -- pacsat-dev(a)amsat.org >> View archives of this mailing list at >> https://mailman.amsat.org/hyperkitty/list/[email protected] >> 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 >> > -- > Jonathan Brandenburg > Radio Amateur Satellite Corporation > 1-214-213-1066 > > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/[email protected] > 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

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

20 Jan '23

Jonathan, Attached is an Excel file I have worked on for PacSat power needs. Bob On Jan 20, 2023, at 7:17 AM, Jonathan Brandenburg via pacsat-dev <pacsat-dev(a)amsat.org<mailto:[email protected]>> wrote: I seem to remember that, too. As such, we may need to look at other parts or different versions of the same parts. That depends, obviously on the maximum current draw expected during normal operation. Does anybody on this list know if we have that information for the AX5043 chain? Jonathan 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. Rich On Thu, Jan 19, 2023 at 5:46 PM Jonathan Brandenburg via pacsat-dev <pacsat-dev(a)amsat.org<mailto:[email protected]>> wrote: In last week's meeting, I noted I had been looking at the schematics for Fox-1 and RT-IHU and found the circuits for the latchup protection and watchdog functions. I admit this might be basic to some, but I'm finding it fascinating! Anyway... Since last week's meeting, I researched the parts used: onsemi FPF2001 is a current limit switch used on both Fox-1 and half the RT-IHU. It's obsolete, replaced by onsemi's FPF2000. But the FPF2000 is listed as end-of-life. It's replacement part is the TI TPS22942. MAX4995 is a current limit switch used on the other half of the. This part looks good for new designs. For the watchdog functionality, both Fox-1 and RT-IHU use the STWD100NYWY3F chip. this parts looks good for new designs. That's as far as I got. Next, I want to research the Fox-1 and RT-IHU designs to determine the thresholds of the current limit switches. In particular, I want to see if the TPS22942 is a suitable replacement, assuming we have the same current requirements. That's where I'm at, Jonathan -- Jonathan Brandenburg Radio Amateur Satellite Corporation 1-214-213-1066 ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org<mailto:[email protected]> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected]<https://url.emailprotection.link/?buUg7YY4HZLXKo6ZKNudC8bRTBdOsBlAV5C9rq-aq…> To unsubscribe send an email to pacsat-dev-leave(a)amsat.org<mailto:[email protected]> Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org<https://url.emailprotection.link/?bO71JCUf8Kb7txAlIoAarNqcIdQhyb8VQQIN4j0Gi…> ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org<mailto:[email protected]> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected]<https://url.emailprotection.link/?buUg7YY4HZLXKo6ZKNudC8bRTBdOsBlAV5C9rq-aq…> To unsubscribe send an email to pacsat-dev-leave(a)amsat.org<mailto:[email protected]> Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org<https://url.emailprotection.link/?bO71JCUf8Kb7txAlIoAarNqcIdQhyb8VQQIN4j0Gi…> -- Jonathan Brandenburg Radio Amateur Satellite Corporation 1-214-213-1066 ----------------------------------------------------------- pacsat-dev mailing list -- pacsat-dev(a)amsat.org<mailto:[email protected]> View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected] To unsubscribe send an email to pacsat-dev-leave(a)amsat.org<mailto:[email protected]> Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org

1 0

Re: Latchup Protection and Watchdog Parts
by Rich Gopstein 20 Jan '23

20 Jan '23

And - as long as I'm thinking about it, we had to disable the hardware watchdog on the RT-IHU to get it to run. I don't recall if that changed, but if you get some RT-IHU boards, you might need to jumper the hardware WD disable. Rich On Thu, Jan 19, 2023 at 6:40 PM Rich Gopstein via pacsat-dev < pacsat-dev(a)amsat.org> 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. > > Rich > > > On Thu, Jan 19, 2023 at 5:46 PM Jonathan Brandenburg via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > >> In last week's meeting, I noted I had been looking at the schematics for >> Fox-1 and RT-IHU and found the circuits for the latchup protection and >> watchdog functions. I admit this might be basic to some, but I'm finding >> it fascinating! Anyway... >> >> Since last week's meeting, I researched the parts used: >> >> onsemi FPF2001 is a current limit switch used on both Fox-1 and half the >> RT-IHU. It's obsolete, replaced by onsemi's FPF2000. But the FPF2000 is >> listed as end-of-life. It's replacement part is the TI TPS22942. >> >> MAX4995 is a current limit switch used on the other half of the. This >> part looks good for new designs. >> >> >> For the watchdog functionality, both Fox-1 and RT-IHU use the >> STWD100NYWY3F chip. this parts looks good for new designs. >> >> >> That's as far as I got. Next, I want to research the Fox-1 and RT-IHU >> designs to determine the thresholds of the current limit switches. In >> particular, I want to see if the TPS22942 is a suitable replacement, >> assuming we have the same current requirements. >> >> That's where I'm at, >> >> Jonathan >> >> >> -- >> Jonathan Brandenburg >> Radio Amateur Satellite Corporation >> 1-214-213-1066 >> >> >> ----------------------------------------------------------- >> >> pacsat-dev mailing list -- pacsat-dev(a)amsat.org >> View archives of this mailing list at >> https://mailman.amsat.org/hyperkitty/list/[email protected] >> 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 >> > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/[email protected] > 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 >

2 1

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

20 Jan '23

I seem to remember that, too. As such, we may need to look at other parts or different versions of the same parts. That depends, obviously on the maximum current draw expected during normal operation. Does anybody on this list know if we have that information for the AX5043 chain? Jonathan 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. > > Rich > > > On Thu, Jan 19, 2023 at 5:46 PM Jonathan Brandenburg via pacsat-dev > <pacsat-dev(a)amsat.org> wrote: > > In last week's meeting, I noted I had been looking at the > schematics for > Fox-1 and RT-IHU and found the circuits for the latchup protection > and > watchdog functions. I admit this might be basic to some, but I'm > finding > it fascinating! Anyway... > > Since last week's meeting, I researched the parts used: > > onsemi FPF2001 is a current limit switch used on both Fox-1 and > half the > RT-IHU. It's obsolete, replaced by onsemi's FPF2000. But the > FPF2000 is > listed as end-of-life. It's replacement part is the TI TPS22942. > > MAX4995 is a current limit switch used on the other half of the. This > part looks good for new designs. > > > For the watchdog functionality, both Fox-1 and RT-IHU use the > STWD100NYWY3F chip. this parts looks good for new designs. > > > That's as far as I got. Next, I want to research the Fox-1 and RT-IHU > designs to determine the thresholds of the current limit switches. In > particular, I want to see if the TPS22942 is a suitable replacement, > assuming we have the same current requirements. > > That's where I'm at, > > Jonathan > > > -- > Jonathan Brandenburg > Radio Amateur Satellite Corporation > 1-214-213-1066 > > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/[email protected] > 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 > > > ----------------------------------------------------------- > > pacsat-dev mailing list --pacsat-dev(a)amsat.org > View archives of this mailing list athttps://mailman.amsat.org/hyperkitty/list/[email protected] > To unsubscribe send an email topacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences athttps://mailman.amsat.org -- Jonathan Brandenburg Radio Amateur Satellite Corporation 1-214-213-1066

1 0

Re: Latchup Protection and Watchdog Parts
by Rich Gopstein 19 Jan '23

19 Jan '23

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. Rich On Thu, Jan 19, 2023 at 5:46 PM Jonathan Brandenburg via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > In last week's meeting, I noted I had been looking at the schematics for > Fox-1 and RT-IHU and found the circuits for the latchup protection and > watchdog functions. I admit this might be basic to some, but I'm finding > it fascinating! Anyway... > > Since last week's meeting, I researched the parts used: > > onsemi FPF2001 is a current limit switch used on both Fox-1 and half the > RT-IHU. It's obsolete, replaced by onsemi's FPF2000. But the FPF2000 is > listed as end-of-life. It's replacement part is the TI TPS22942. > > MAX4995 is a current limit switch used on the other half of the. This > part looks good for new designs. > > > For the watchdog functionality, both Fox-1 and RT-IHU use the > STWD100NYWY3F chip. this parts looks good for new designs. > > > That's as far as I got. Next, I want to research the Fox-1 and RT-IHU > designs to determine the thresholds of the current limit switches. In > particular, I want to see if the TPS22942 is a suitable replacement, > assuming we have the same current requirements. > > That's where I'm at, > > Jonathan > > > -- > Jonathan Brandenburg > Radio Amateur Satellite Corporation > 1-214-213-1066 > > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/[email protected] > 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

Latchup Protection and Watchdog Parts
by Jonathan Brandenburg 19 Jan '23

19 Jan '23

In last week's meeting, I noted I had been looking at the schematics for Fox-1 and RT-IHU and found the circuits for the latchup protection and watchdog functions. I admit this might be basic to some, but I'm finding it fascinating! Anyway... Since last week's meeting, I researched the parts used: onsemi FPF2001 is a current limit switch used on both Fox-1 and half the RT-IHU. It's obsolete, replaced by onsemi's FPF2000. But the FPF2000 is listed as end-of-life. It's replacement part is the TI TPS22942. MAX4995 is a current limit switch used on the other half of the. This part looks good for new designs. For the watchdog functionality, both Fox-1 and RT-IHU use the STWD100NYWY3F chip. this parts looks good for new designs. That's as far as I got. Next, I want to research the Fox-1 and RT-IHU designs to determine the thresholds of the current limit switches. In particular, I want to see if the TPS22942 is a suitable replacement, assuming we have the same current requirements. That's where I'm at, Jonathan -- Jonathan Brandenburg Radio Amateur Satellite Corporation 1-214-213-1066

1 0

Re: Pacsat dev meeting 1-19-2023
by Jonathan Brandenburg 19 Jan '23

19 Jan '23

I'm afraid I won't make this evening's meeting... I'm out of town for almost two entire weeks with only a few hours at home and if I want to stay married, I won't get on any meetings tonight! I'll send a separate email with a brief update. Jonathan On 1/19/23 12:06, Bill via pacsat-dev wrote: > Pacsat dev meeting 1-19-2023 > Thu, Jan 19, 2023 7:00 PM - 9:00 PM (CST) > > Please join my meeting from your computer, tablet or smartphone. > > https://meet.goto.com/210641357 > > You can also dial in using your phone. > (For supported devices, tap a one-touch number below to join instantly.) > > United States: +1 (224) 501-3412 > - One-touch: tel:+12245013412,,210641357# > > Access Code: 210-641-357 > > > Get the app now and be ready when your first meeting starts: > https://meet.goto.com/install > > > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/[email protected] > 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 -- Jonathan Brandenburg Radio Amateur Satellite Corporation 1-214-213-1066

1 0

Re: AX5043 Booster Board
by Burns Fisher (AMSAT) 19 Jan '23

19 Jan '23

Oh totally understand and agree about only 2 Ax5043. I was just thinking this would be an opportunity also to test hardware and software for using both RF pins on the chip, but you are the hardware designer, not me. 😀 On Fri, Jan 20, 2023 at 3:54 AM Jim McCullers via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > Burns, > > > > My thinking is this is a generalized starter board for all groups, simple > but inclusive. > > We have a long way to go to have the actual RF requirements for the > receivers and transmitter and can do a lot with this configuration. > > In addition I don’t believe we have pin availability on the LaunchPad for > chip select and interrupt lines for three additional AX5043s. > > We may be forced into more of a prototype flight board to test the full RF > stack. That’s another topic for discussion. > > > > As a note to all, component values given in the schematic are preliminary > and essentially placeholders to get the basic schematic and board layout > completed. > > > > 73 > > > > Jim McCullers > > WA4CWI > > > > > > > > If fligHt version has multi receivers anD one tx we reall y wants to be > ab.le to be flexible with which device does what. Which means using one of > the rf pins for tx and one for rx and matched to appropriate band. And we > want to be test that setup on the current launchpad card tHa Jim is making. > My thought from a distance! > > *light Software* > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/[email protected] > 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 > -- 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*

2 1

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

19 Jan '23

Pacsat dev meeting 1-19-2023 Thu, Jan 19, 2023 7:00 PM - 9:00 PM (CST) Please join my meeting from your computer, tablet or smartphone. https://meet.goto.com/210641357 You can also dial in using your phone. (For supported devices, tap a one-touch number below to join instantly.) United States: +1 (224) 501-3412 - One-touch: tel:+12245013412,,210641357# Access Code: 210-641-357 Get the app now and be ready when your first meeting starts: https://meet.goto.com/install

1 0

Re: AX5043 Booster Board
by Burns Fisher (AMSAT) 19 Jan '23

19 Jan '23

If fligHt version has multi receivers anD one tx we reall y wants to be ab.le to be flexible with which device does what. Which means using one of the rf pins for tx and one for rx and matched to appropriate band. And we want to be test that setup on the current launchpad card tHa Jim is making. My thought from a distance! On Thu, Jan 19, 2023 at 3:47 PM Jim McCullers via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > The values on the schematic should be at the moment considered placeholder > values. > > I still need to go through the schematic and insert the correct values for > both AX5043s. > > Rich you are correct, the matching network is unique and tuned for each > band. > > The plan is to work on the VHF network using one of the Raspberry Pi > boards I’m building then transfer those to the schematic. > > As VHF is uplink it will require fine tuning for optimum performance. > > > > The MRAMs show pullups on the chip selects which may not be needed as well > as load resistors on the MISO leads that Kicad balks about when paralleling > outputs. > > Need to do more research but zero ohm resistors are less expensive than > new boards and a lot less time consuming than trace surgery. > > > > In a flight version the matching network on the UHF is not required unless > a need arises for 70cm receiver optimum. > > I actually laid out the VHF schematic then duplicated it for the UHF and > never deleted the inductor which for UHF is a zero ohm resistor > > > > Jim McCullers > > WA4CWI > > > > BTW - the external 90nH inductor isn't needed for the UHF chip. No harm > in leaving it in, though. > > > > On Wed, Jan 18, 2023 at 4:07 PM Jim McCullers via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > > Attached are the schematic and layout for the TMS-570 LaunchPad booster > board. > > > > It contains two AX5043 circuits configurable for VHF or UHF and places for > four MRAMs. > > Not all positions are required to be present so the build can be by need. > > It does contain the resistors I discussed that may not be required in > future versions. > > > > Please give it a review as I’m preparing to send the design to the PCB > board maker for a first trial run. > > > > 73 > > > > Jim McCullers > > WA4CWI > > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/[email protected] > 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 > > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/[email protected] > 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 > -- 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*

2 1

Re: AX5043 Booster Board
by Rich Gopstein 19 Jan '23

19 Jan '23

BTW - the external 90nH inductor isn't needed for the UHF chip. No harm in leaving it in, though. On Wed, Jan 18, 2023 at 4:07 PM Jim McCullers via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > Attached are the schematic and layout for the TMS-570 LaunchPad booster > board. > > > > It contains two AX5043 circuits configurable for VHF or UHF and places for > four MRAMs. > > Not all positions are required to be present so the build can be by need. > > It does contain the resistors I discussed that may not be required in > future versions. > > > > Please give it a review as I’m preparing to send the design to the PCB > board maker for a first trial run. > > > > 73 > > > > Jim McCullers > > WA4CWI > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/[email protected] > 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 >

2 1

Re: AX5043 Booster Board
by Rich Gopstein 19 Jan '23

19 Jan '23

I suspect the matching network is tuned for UHF... On Wed, Jan 18, 2023 at 9:30 PM Burns Fisher (AMSAT) via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > Leaving it will allow a fallback half duplex configuration > > On Thu, Jan 19, 2023 at 3:29 PM Rich Gopstein via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > >> BTW - the external 90nH inductor isn't needed for the UHF chip. No harm >> in leaving it in, though. >> >> On Wed, Jan 18, 2023 at 4:07 PM Jim McCullers via pacsat-dev < >> pacsat-dev(a)amsat.org> wrote: >> >>> Attached are the schematic and layout for the TMS-570 LaunchPad booster >>> board. >>> >>> >>> >>> It contains two AX5043 circuits configurable for VHF or UHF and places >>> for four MRAMs. >>> >>> Not all positions are required to be present so the build can be by need. >>> >>> It does contain the resistors I discussed that may not be required in >>> future versions. >>> >>> >>> >>> Please give it a review as I’m preparing to send the design to the PCB >>> board maker for a first trial run. >>> >>> >>> >>> 73 >>> >>> >>> >>> Jim McCullers >>> >>> WA4CWI >>> >>> ----------------------------------------------------------- >>> >>> pacsat-dev mailing list -- pacsat-dev(a)amsat.org >>> View archives of this mailing list at >>> https://mailman.amsat.org/hyperkitty/list/[email protected] >>> 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 >>> >> >> ----------------------------------------------------------- >> >> pacsat-dev mailing list -- pacsat-dev(a)amsat.org >> View archives of this mailing list at >> https://mailman.amsat.org/hyperkitty/list/[email protected] >> 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 >> > -- > 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/[email protected] > 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

Re: AX5043 Booster Board
by Burns Fisher (AMSAT) 19 Jan '23

19 Jan '23

Leaving it will allow a fallback half duplex configuration On Thu, Jan 19, 2023 at 3:29 PM Rich Gopstein via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > BTW - the external 90nH inductor isn't needed for the UHF chip. No harm > in leaving it in, though. > > On Wed, Jan 18, 2023 at 4:07 PM Jim McCullers via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > >> Attached are the schematic and layout for the TMS-570 LaunchPad booster >> board. >> >> >> >> It contains two AX5043 circuits configurable for VHF or UHF and places >> for four MRAMs. >> >> Not all positions are required to be present so the build can be by need. >> >> It does contain the resistors I discussed that may not be required in >> future versions. >> >> >> >> Please give it a review as I’m preparing to send the design to the PCB >> board maker for a first trial run. >> >> >> >> 73 >> >> >> >> Jim McCullers >> >> WA4CWI >> >> ----------------------------------------------------------- >> >> pacsat-dev mailing list -- pacsat-dev(a)amsat.org >> View archives of this mailing list at >> https://mailman.amsat.org/hyperkitty/list/[email protected] >> 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 >> > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/[email protected] > 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 > -- 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*

1 0

AX5043 Booster Board
by Jim McCullers 17 Jan '23

17 Jan '23

Attached are the schematic and layout for the TMS-570 LaunchPad booster board. It contains two AX5043 circuits configurable for VHF or UHF and places for four MRAMs. Not all positions are required to be present so the build can be by need. It does contain the resistors I discussed that may not be required in future versions. Please give it a review as I'm preparing to send the design to the PCB board maker for a first trial run. 73 Jim McCullers WA4CWI

1 0

Re: Pacsat dev meeting 1/12/2023
by Bob Stricklin 13 Jan '23

13 Jan '23

Sorry Bill, Lost track of time and looks like meeting is over. See you next week not a lot to report from me. Bob N5BRG > On Jan 12, 2023, at 1:39 PM, Bill via pacsat-dev <pacsat-dev(a)amsat.org> wrote: > > Pacsat dev meeting 1/12/2023 > Thu, Jan 12, 2023 7:00 PM - 9:00 PM (CST) > > Please join my meeting from your computer, tablet or smartphone. > > https://url.emailprotection.link/?baWZQlhBxtYNcUWAj3ZavKMd7XVTssky7_-fpEVvK… > > You can also dial in using your phone. > (For supported devices, tap a one-touch number below to join instantly.) > > United States: +1 (872) 240-3212 > - One-touch: tel:+18722403212,,846793741# > > Access Code: 846-793-741 > > > Get the app now and be ready when your first meeting starts: https://url.emailprotection.link/?baWZQlhBxtYNcUWAj3ZavKIXRVUIGqulVnUk2vQrN… > > > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at https://url.emailprotection.link/?buUg7YY4HZLXKo6ZKNudC8bRTBdOsBlAV5C9rq-aq… > To unsubscribe send an email to pacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences at https://url.emailprotection.link/?bO71JCUf8Kb7txAlIoAarNqcIdQhyb8VQQIN4j0Gi…

1 0

Pacsat dev meeting 1/12/2023
by Bill 12 Jan '23

12 Jan '23

Pacsat dev meeting 1/12/2023 Thu, Jan 12, 2023 7:00 PM - 9:00 PM (CST) Please join my meeting from your computer, tablet or smartphone. https://meet.goto.com/846793741 You can also dial in using your phone. (For supported devices, tap a one-touch number below to join instantly.) United States: +1 (872) 240-3212 - One-touch: tel:+18722403212,,846793741# Access Code: 846-793-741 Get the app now and be ready when your first meeting starts: https://meet.goto.com/install

1 0

AX5043 Rx and Tx working
by Burns Fisher (AMSAT) 06 Jan '23

06 Jan '23

Thanks to help from Rich, I did get the Launchpad+Jonathan Pi 5043 board to both transmit on 70cm and receive on 2m. Hint: Among other things the 5043 really needs an antenna, not just a dummy load, in order to transmit even a foot or two! 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*

1 0

Re: pacsat dev meeting 1-5-2023
by Chris Thompson 06 Jan '23

06 Jan '23

I'm unable to attend today. Sorry about the late notice. I hope to attend next time. 73 Chris On Thu, Jan 5, 2023, 15:21 Bill via pacsat-dev <pacsat-dev(a)amsat.org> wrote: > Welcome to 2023, see you at 7PM > > pacsat dev meeting 2023-1 > Thu, Jan 5, 2023 7:00 PM - 9:00 PM (CST) > > Please join my meeting from your computer, tablet or smartphone. > > https://meet.goto.com/444756509 > > 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,,444756509# > > Access Code: 444-756-509 > > > Get the app now and be ready when your first meeting starts: > https://meet.goto.com/install > > > > ----------------------------------------------------------- > > pacsat-dev mailing list -- pacsat-dev(a)amsat.org > View archives of this mailing list at > https://mailman.amsat.org/hyperkitty/list/[email protected] > 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

pacsat dev meeting 1-5-2023
by Bill 05 Jan '23

05 Jan '23

Welcome to 2023, see you at 7PM pacsat dev meeting 2023-1 Thu, Jan 5, 2023 7:00 PM - 9:00 PM (CST) Please join my meeting from your computer, tablet or smartphone. https://meet.goto.com/444756509 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,,444756509# Access Code: 444-756-509 Get the app now and be ready when your first meeting starts: https://meet.goto.com/install

1 0

Satellite use of the AX5043
by Jim McCullers 04 Jan '23

04 Jan '23

Over the holiday break I did some Google searches on the use of the AX5043 in satellite service and found the following references. These two publications cover the OreSat developed at Portland State University. The Ax5043 is employed as UHF transceiver as well as IF for an L-Band receiver. As of yet, I have not received a signal from OreSat0 but as it is a telemetry only satellite the transmitter is possibly only activated for passes over the Oregon area. I've reached out to them via email but have yet to receive a response. https://digitalcommons.usu.edu/cgi/viewcontent.cgi?article=5110&context=smal lsat https://pdxscholar.library.pdx.edu/cgi/viewcontent.cgi?article=6639 <https://pdxscholar.library.pdx.edu/cgi/viewcontent.cgi?article=6639&context =open_access_etds> &context=open_access_etds This paper deals with detection of UHF uplink interference using the AX5042 similar to the AX5043 and makes an interesting case not to use 70cm uplinks due to interference caused by the shared services in the 70cm band. They used a single antenna and LNA into a 4-way splitter similar to what is planned for Pacsat. https://www.sciencedirect.com/science/article/pii/S0273117721007778 The final paper is an interesting study of the AX5043 capabilities. They examined the radiation resistance of the AX5043 and found it held up well. Also is an interesting discussion of LNA requirements as well as radiation resistance of various transistor types. It should be noted the original project was canceled and a follow on is due to launch in 2023. How it might vary in configuration is not published. https://core.ac.uk/download/pdf/295596877.pdf Jim McCullers WA4CWI

1 0