- pacsat-dev - mailman.amsat.org

Pacsat dev mtg 9/5/2024
by Bill 05 Sep '24

05 Sep '24

Pacsat dev mtg 9/5/2024 Thu, Sep 5, 2024 7:00 PM - 9:00 PM (CDT) Please join my meeting from your computer, tablet or smartphone. https://meet.goto.com/550170213 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,,550170213# Access Code: 550-170-213 Join from a video-conferencing room or system. Dial in or type: 67.217.95.2 or inroomlink.goto.com Meeting ID: 550 170 213 Or dial directly: 550170213(a)67.217.95.2 or 67.217.95.2##550170213 Get the app now and be ready when your first meeting starts: https://meet.goto.com/install

1 0

Re: Thoughts on Dual-Board Configuration
by Bill Reed 31 Aug '24

31 Aug '24

Great idea. I like it. Let's discuss at Thur eve meeting. Bill On 8/29/2024 11:50 PM, Cameron Castillo via pacsat-dev wrote: > Good evening, > > I thought some more about how going to two boards might work > layout-wise. My first thought was that it would be very undesirable to > go to two boards, as we take up stack space which could be allocated > to other experiments. With conservative planning on the flight board > and some work to limit excess components on the current design, I > think it's entirely possible to fit the flight model on one board. > > Looking at the board space we have available (~26 in^2) and the > current schematic, there would be several steps I would take before > going to another board. First, we have a lot of bottom board space > which isn't used at all. Pullup resistors on the digital side, power > supplies, and even the CPU could be placed on the bottom of the board. > Just by removing the UFL connectors and replacing the 0603 components > with 0402s, we'd save around an inch for practically nothing. > Additionally, more layers on the board may allow greater route density > on the top and bottom layers. I think that 8 or 10 at maximum will be > sufficient and provide a shorter path than a second board would allow. > I made an *approximate *placement diagram which shows the current > configuration and possibilities for the new board. > > I'm not opposed to multiple boards for development purposes. We could > break all the circuits out onto different test platforms which could > be distributed to more people for software development. We could > troubleshoot each section individually before combining onto the > flight model. I think for the best performance on the flight model, it > should be a single board. > > Something Bill pointed out in the meeting was that heat dissipation > might become an issue with so many components packed onto the board. > While the board can do a lot to sink heat, perhaps additional sinking > will be necessary. On the RT-IHU, we plan to create a heat spreader > which presses a ceramic block onto the TMS570. Originally, this was > going to also have milled cavities to act as shielding for the > components, but the design was shrunk for unknown reasons (something > that Bob Davis had been working on). Perhaps something like this might > be beneficial, although it would be expensive and add weight and > height. Just a thought. > > This is my point of view from the layout side. While a challenge, I > definitely think a single board is possible. Thoughts? > > Thanks, > > Cameron > > > ------------------------------------------------- > > Cameron Castillo > > KJ7ILB > > /P/: (503) 752-8877 > > -------------------------------------------------- > > > ----------------------------------------------------------- > > pacsat-dev mailing list --pacsat-dev(a)amsat.org > View archives of this mailing list athttps://mailman.amsat.org/hyperkitty/list/pacsat-dev@amsat.org > To unsubscribe send an email topacsat-dev-leave(a)amsat.org > Manage all of your AMSAT-NA mailing list preferences athttps://mailman.amsat.org

1 0

Thoughts on Dual-Board Configuration
by Cameron Castillo 29 Aug '24

29 Aug '24

Good evening, I thought some more about how going to two boards might work layout-wise. My first thought was that it would be very undesirable to go to two boards, as we take up stack space which could be allocated to other experiments. With conservative planning on the flight board and some work to limit excess components on the current design, I think it's entirely possible to fit the flight model on one board. Looking at the board space we have available (~26 in^2) and the current schematic, there would be several steps I would take before going to another board. First, we have a lot of bottom board space which isn't used at all. Pullup resistors on the digital side, power supplies, and even the CPU could be placed on the bottom of the board. Just by removing the UFL connectors and replacing the 0603 components with 0402s, we'd save around an inch for practically nothing. Additionally, more layers on the board may allow greater route density on the top and bottom layers. I think that 8 or 10 at maximum will be sufficient and provide a shorter path than a second board would allow. I made an *approximate *placement diagram which shows the current configuration and possibilities for the new board. I'm not opposed to multiple boards for development purposes. We could break all the circuits out onto different test platforms which could be distributed to more people for software development. We could troubleshoot each section individually before combining onto the flight model. I think for the best performance on the flight model, it should be a single board. Something Bill pointed out in the meeting was that heat dissipation might become an issue with so many components packed onto the board. While the board can do a lot to sink heat, perhaps additional sinking will be necessary. On the RT-IHU, we plan to create a heat spreader which presses a ceramic block onto the TMS570. Originally, this was going to also have milled cavities to act as shielding for the components, but the design was shrunk for unknown reasons (something that Bob Davis had been working on). Perhaps something like this might be beneficial, although it would be expensive and add weight and height. Just a thought. This is my point of view from the layout side. While a challenge, I definitely think a single board is possible. Thoughts? Thanks, Cameron ------------------------------------------------- Cameron Castillo KJ7ILB *P*: (503) 752-8877 --------------------------------------------------

1 0

foxplus dwg
by Bill Reed 29 Aug '24

29 Aug '24

Possible Fox-Plus B configuration:

1 0

pacsat dev mtg 8/29/2024
by Bill 29 Aug '24

29 Aug '24

pacsat dev mtg 8/29/2024 I have invited Mike Moore to join us this evening Thu, Aug 29, 2024 7:00 PM - 9:00 PM (CDT) Please join my meeting from your computer, tablet or smartphone. https://meet.goto.com/455524789 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,,455524789# Access Code: 455-524-789 Join from a video-conferencing room or system. Dial in or type: 67.217.95.2 or inroomlink.goto.com Meeting ID: 455 524 789 Or dial directly: 455524789(a)67.217.95.2 or 67.217.95.2##455524789 Get the app now and be ready when your first meeting starts: https://meet.goto.com/install

1 0

Re: UHF frequency not on PuTTY?
by Blumenthal, Alex 23 Aug '24

23 Aug '24

I didn't update the code beyond what was shipped with the board a few weeks ago. Would you be available at 5 pm on Monday for a call? ________________________________ From: Chris Thompson via pacsat-dev <pacsat-dev(a)amsat.org> Sent: Friday, August 23, 2024 5:07 PM To: Blumenthal, Alex <alex.blumenthal(a)und.edu> Cc: Pacsat Dev <pacsat-dev(a)amsat.org> Subject: [pacsat-dev] Re: UHF frequency not on PuTTY? It looks like it is not running the TX task as we see no message from it including no errors. There is also a strange message about PktStoreFlags that I don't remember. Are you running the latest branch of the code? Does this have some modifications? Maybe we should do a call and I can help you flash the code from your computer. You can then debug this sort of issue easily because you can step through the code with the debugger. Regards On Fri, Aug 23, 2024, 16:54 Blumenthal, Alex via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: Hi all, I was finally able to get some data from the PACSAT using the USB serial converter. I pressed the reset button a couple times and here's what was displayed. The VHF frequency shows up, but the UHF frequency does not. Is there a specific command I need to type in to see that? How does everything else look? Sincerely, Alex ----------------------------------------------------------- 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

2 1

Re: UHF frequency not on PuTTY?
by Chris Thompson 23 Aug '24

23 Aug '24

It looks like it is not running the TX task as we see no message from it including no errors. There is also a strange message about PktStoreFlags that I don't remember. Are you running the latest branch of the code? Does this have some modifications? Maybe we should do a call and I can help you flash the code from your computer. You can then debug this sort of issue easily because you can step through the code with the debugger. Regards On Fri, Aug 23, 2024, 16:54 Blumenthal, Alex via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > Hi all, > > I was finally able to get some data from the PACSAT using the USB serial > converter. I pressed the reset button a couple times and here's what was > displayed. The VHF frequency shows up, but the UHF frequency does not. Is > there a specific command I need to type in to see that? > > How does everything else look? > > Sincerely, > > Alex > > ----------------------------------------------------------- > > 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

UHF frequency not on PuTTY?
by Blumenthal, Alex 23 Aug '24

23 Aug '24

Hi all, I was finally able to get some data from the PACSAT using the USB serial converter. I pressed the reset button a couple times and here's what was displayed. The VHF frequency shows up, but the UHF frequency does not. Is there a specific command I need to type in to see that? How does everything else look? Sincerely, Alex

1 0

Re: Followup on tonight's (Aug 22) meeting
by Bob Stricklin 23 Aug '24

23 Aug '24

The drawing should also have Pin 104 labeled. This at the top right side of the connector near the edge of the overall PCB. The numbers flow up the columns starting from the left side of connector and Pin 1. Bob > On Aug 23, 2024, at 11:35 AM, Bob Stricklin via pacsat-dev <pacsat-dev(a)amsat.org> wrote: > > <PacSatPCB_Rev_A.PDF>

1 0

Re: Followup on tonight's (Aug 22) meeting
by Bob Stricklin 23 Aug '24

23 Aug '24

Patrick, You are correct about the PC104 issue. I brought this up early on in our project but people are use to referring to it as PC104. I read where the name PC104 is also copyright protected and there are some potential issues using this unless you pay them the license fee. A part of this is how you number the pins. The LTM numbers them as a A and B group. I was having difficulty with that so I I numbered them 1 through 104. If you use the A and B method there is a change of getting the connector mixed up and as you are working on the board and flipping it over the A and B numbering is a challenge. I found a particular Samtec Q series (PTHF-126-02-GF-Q-368) connector which had the correct configuration and put this on the BOM. This connector is available in a press fit version and a slip fit. The press fit is preferred because this means the pin holes will be a bit smaller giving more room for traces between the pins. Our vendor did not have a fixture to support the press fit so they soldered them in place with the connectors up off the board more than they should be. This is important later and will need to specified and controlled to support proper board stacking later. The fixture needed is a support block and a press block for an arbor press. Attached is a drawing I made for the PCB fab and the subcontractor with a few dimension. This should match the LTM exactly. No one has verified any of this but we have boards that could be tested together if we had a board from another project. Regarding the location of the 104 connector I followed Zack’s original layout work which I got off AMSAT GitHub. This should turn out to match other projects and boards. Bob On Aug 22, 2024, at 9:41 PM, Patrick Thomas via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: Hi all, First off, sorry I couldn't provide a better "customer experience" with solid answers on all the very on-point LTM questions tonight. I think it will definitely help to get an expert in to give a technical presentation and do some Q&A. I did want to clarify one thing which may've been causing some confusion. We have been using the term "PC-104 connector," and if you search around for this online you will likely find the formal spec<https://pc104.org/wp-content/uploads/2015/02/PC104_Spec_v2_6.pdf> (from pc104.org<http://pc104.org>) for the actual PC-104 connector, an ISA-derived 64 + 40 = 104-pin interface which looks like this: <09fFDU0WuGkm2PyW.png> The cubesat community seems to use the term "PC-104 connector" to refer to the CubeSat Kit Bus (CSKB) connector, which is 26x4 = 104 pins (two 2x26 headers next to each other), which looks like this (top of the diagram, from the AMSAT LTM Brochure): <wvIuNHMbeUwkJ0qi.png> I think this may have been the origin of some of the "it won't fit" or "the pinout isn't close" comments. Let me know if I'm on the right track. I will be sure this is clear in the new LTM ICD. As to where the connector is positioned, that is what I thought the Cal Poly cubesat design spec may have defined when I mentioned that in the meeting, but it looks like it had origins in Pumpkin, Inc. instead and then was more broadly adopted. I am going to do some further digging for a formal physical spec that I can point to. Meanwhile it should be easily derived from our layout files. (Or if someone on the list can answer, please speak up.) Thanks, Patrick ----------------------------------------------------------- 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