- pacsat-dev - mailman.amsat.org

Re: Blinky dimensions
by Bob Stricklin 18 Apr '24

18 Apr '24

Bill, I have revised the drawing to include the connector location based on the hole locations in the PCB drill file. I don’t think the LTC document provides an exact location for these holes. This board should match other AMSAT boards unless the connector was relocated. It is quite easy to accidentally select the connector in KiCAD and end up with it in a slightly different location. It would be good to research the connector drawing and see what the pin spacings are. I thought they were 2 mm. The dimensions I show here are slightly less than 2 mm in the length dimension. Probably still work fine. The dimensions in the LTC document are in metric and the dimensions used on the PCB layout are in mils. You can obtain more accurate placement with KiCad because of the way it handles rounding. I will push a copy of this to the GitHub Hardware rev C board. Bob On Apr 17, 2024, at 9:19 AM, Bill Reed <bill(a)brconnect.com<mailto:bill@brconnect.com>> wrote: Your drawing does not show the position of the 102 pin connector. Does the position of the 102 pin connector match the LTM document? On 4/16/2024 7:28 PM, Bob Stricklin wrote: Bill, Take a look at this ZIP file and you will find a mechanical drawing of the PCB. https://github.com/AMSAT-NA/PacSatDocs/blob/main/Hardware/PCB/PacSat_Dev_Re… The 104 pin connector is not specified here but the hole locations for the connector are included in the drill file. I will take a look at the dimensions and revise the drawing to include three of the connector corner pins later. These dimensions match the LTM document. Bob On Apr 16, 2024, at 11:24 AM, Bill Reed via pacsat-dev <pacsat-dev(a)amsat.org<mailto:pacsat-dev@amsat.org>> wrote: Do we have a document that specifies: 1. Blinky overall dimensions 2. Blinky mounting hole positions 3. Blinky 104 pin connector position Bill ----------------------------------------------------------- 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<https://mailman.amsat.org/>

1 0

Re: Blinky RTC
by Chris Thompson 17 Apr '24

17 Apr '24

I also don't think we need a battery to keep time for the pacsat file system. We only need accurate time for file uploads and to expire old files. Those processes can be automatically suspended if the time is not set. The time is then fixed by sending a command that sets the clock. If we need accurate time for another reason, such as an experiment, then that could change of course. For telemetry we can fall back on using reset and uptime. 73 Chris On Tue, Apr 16, 2024, 20:36 Bob Stricklin via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > I would say a battery is not needed. > > The clock chip is the only device on the board that has a volatile memory > and the current required to keep the data in place is very low. With the > capacitors on the PCB the time should be maintained over a month. This is > something we can test however it would be difficult to obtain an exact time > to live because when you power up to read the clock the caps will be > recharged. > > Assuming it will be possible to set the time shortly before launch or even > after launch it will be best not to have the added burden of a battery. > > Bob > > > On Apr 16, 2024, at 2:18 PM, Bill Reed via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > > > > Should the blinky RTC have a battery? > > > > > > ----------------------------------------------------------- > > > > 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 > > > ----------------------------------------------------------- > > 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

Re: Blinky RTC
by Bob Stricklin 17 Apr '24

17 Apr '24

I would say a battery is not needed. The clock chip is the only device on the board that has a volatile memory and the current required to keep the data in place is very low. With the capacitors on the PCB the time should be maintained over a month. This is something we can test however it would be difficult to obtain an exact time to live because when you power up to read the clock the caps will be recharged. Assuming it will be possible to set the time shortly before launch or even after launch it will be best not to have the added burden of a battery. Bob > On Apr 16, 2024, at 2:18 PM, Bill Reed via pacsat-dev <pacsat-dev(a)amsat.org> wrote: > > Should the blinky RTC have a battery? > > > ----------------------------------------------------------- > > 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

Re: Blinky RTC
by Burns Fisher (AMSAT) 17 Apr '24

17 Apr '24

The eval board has a super-cap that lasts for several days without a battery. I don't know if that is how it is designed on Blinky, but I'd guess yes. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Tue, Apr 16, 2024 at 3:18 PM Bill Reed via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > Should the blinky RTC have a battery? > > > ----------------------------------------------------------- > > 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

Blinky RTC
by Bill Reed 17 Apr '24

17 Apr '24

Should the blinky RTC have a battery?

1 0

Blinky dimensions
by Bill Reed 17 Apr '24

17 Apr '24

Do we have a document that specifies: 1. Blinky overall dimensions 2. Blinky mounting hole positions 3. Blinky 104 pin connector position Bill

1 0

Re: URGENT Possible Pacsat launch
by Bob Stricklin 16 Apr '24

16 Apr '24

Sorry just now seeing these emails… I am not motivated to get involved in supporting any of the new projects. I am ok with helping to fix any issues with the board we have built but beyond that I would not like to be involved. I do not feel AMSAT is really behind these projects and has too many issues in the organization at this point for me to be willing to work on a project. Bob > On Apr 15, 2024, at 11:06 AM, Jim McCullers via pacsat-dev <pacsat-dev(a)amsat.org> wrote: > > Bill, > > Make certain you get a good idea of what they are doing for communications. > With a 3U I would assume they have communication requirements and plans defined. > We have to insure the addition of Pacsat would not result in interference to either party. > > Jim McCullers > WA4CWI > > > Team, > > Well, we learned from the budget situation that our ASCENT direction was to build a"proof of concept" solution. > I am not sure at this point why we are restricted and if this is an AMSAT officer (Jerry or Robert) or a BOD restriction. > > With that in mind, I was contacted over the weekend by a university that wants to launch pacsat. > The University of North Dakota is launching a 3U cubesat, probably in mid to late 2025. They have a commitment for an ELANA launch but no firm dates yet. They have .5U available out of 3U. > > So we need to make a decision here: > > 1. Do we want to support this launch? (Don't know yet how much support they will need. Probably lots.) > > 2. Do we have the time to provide support? > > 3. If you think it is good timing, I will invite the UND project lead ( Dr. Ron Fevig ) to our Thursday meeting. > > If we decide to move forward with this we will need to get Jerry's permission to move beyond a pure ASCENT project. > > Please let me know your feelings ASAP. I have a meeting with Dr. Fevig this afternoon and will try to better understand their requirements. > > Please let me know your feelings ASAP. ( 2nd request) I want to kill this if we don't think we can do it. > > Bill > > > ----------------------------------------------------------- > > 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 > > > ----------------------------------------------------------- > > 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

Timekeeping on Fox and Golf
by Burns Fisher (AMSAT) 16 Apr '24

16 Apr '24

I wrote this in a private email but given a lot of new people who had no experience with Fox, it seems worth posting to the list (and also to PacSat whose OBC is similar, although it does keep UTC somehow/somewhere, I think). ===================== Ever since Fox-1A and up through the Golf, the OBCs do not have a Real Time Clock (RTC), have never had a clue about the actual UTC time, and have only kept any time as accurate as their built-in timed interrupts are. The OBCs main time metric is Epochs (in general, the number of processor resets) and Seconds since the last Epoch start. The main thing that these times get used for are timestamps on telemetry, and the most critical thing is to ensure that telemetry downlinks can be sorted by time order on the ground even if they arrive at the AMSAT server out of order. In addition, on the ground we (really Alan Biddle) determines the UTC time of each reset. Given that, we can display the UTC telemetry time in FoxTelem. Sometimes this is more useful if it is reasonably accurate (like if you want to correlate something on the s/c to an orbital location like the South Atlantic Anomaly or the aurora or something like that, but generally even that is not terribly critical. All the software is geared to that Epoch/Second timekeeping, but on Golf I also planned to downlink the UTC time matched with a s/c time when/if it was available (there is a GPS on the Ettus, but whether it could give UTC without CoCom is unclear) in order to save Alan some work. Now that we will have a CoCom GPS available we will certainly have the time, but I have no plans to use it on the OBC except to downlink as above. The UTC time also comes with GPS coordinates so that time can be used to convert a coordinate list to TLE, but it is a timestamp, not realtime. The OBC still does not have an accurate RTC nor does it need one. Note to avoid a few emails: At least the ST32L151 processor does contain an RTC, but we don't use it. It would require an extra super-accurate crystal, plus it still has to be set in orbit, since we can't have any power on before release in orbit. And why do we use the epoch/seconds hoke? Because that is accurate from the moment the processor reboots. It does not have to wait for a GPS lock or a UTC uplink. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*

1 0

Re: URGENT Possible Pacsat launch
by Jim McCullers 16 Apr '24

16 Apr '24

Bill, Make certain you get a good idea of what they are doing for communications. With a 3U I would assume they have communication requirements and plans defined. We have to insure the addition of Pacsat would not result in interference to either party. Jim McCullers WA4CWI Team, Well, we learned from the budget situation that our ASCENT direction was to build a"proof of concept" solution. I am not sure at this point why we are restricted and if this is an AMSAT officer (Jerry or Robert) or a BOD restriction. With that in mind, I was contacted over the weekend by a university that wants to launch pacsat. The University of North Dakota is launching a 3U cubesat, probably in mid to late 2025. They have a commitment for an ELANA launch but no firm dates yet. They have .5U available out of 3U. So we need to make a decision here: 1. Do we want to support this launch? (Don't know yet how much support they will need. Probably lots.) 2. Do we have the time to provide support? 3. If you think it is good timing, I will invite the UND project lead ( Dr. Ron Fevig ) to our Thursday meeting. If we decide to move forward with this we will need to get Jerry's permission to move beyond a pure ASCENT project. Please let me know your feelings ASAP. I have a meeting with Dr. Fevig this afternoon and will try to better understand their requirements. Please let me know your feelings ASAP. ( 2nd request) I want to kill this if we don't think we can do it. Bill ----------------------------------------------------------- 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

Re: URGENT Possible Pacsat launch
by Chris Thompson 15 Apr '24

15 Apr '24

I also agree with all the comments. I would tend to take any opportunity for a launch because they are so rare. But find out some more and we can make a decision. 73 Chris On Mon, Apr 15, 2024, 10:59 Bill Reed via pacsat-dev <pacsat-dev(a)amsat.org> wrote: > good comments, thanks. 1 week delay is good idea. > > On 4/15/2024 9:25 AM, Jim McCullers via pacsat-dev wrote: > > Bill, > > > > I believe it would be best for you to do the meeting, get a firm idea of > where they are, then make a decision. > > I would also suggest the invitation to join our meeting be a week later > so we can here your thoughts from the conversation and make a > go/no-go/maybe decision before getting in deeper. > > > > Jonathan explained to me way back when the project was a "proof of > concept" but with a possibility of flight. > > I'm still too green to know the whys of what's going on. > > > > Jim McCullers > > WA4CWI > > > > > > > > Team, > > > > Well, we learned from the budget situation that our ASCENT direction was > to build a"proof of concept" solution. > > I am not sure at this point why we are restricted and if this is an > AMSAT officer (Jerry or Robert) or a BOD restriction. > > > > With that in mind, I was contacted over the weekend by a university that > wants to launch pacsat. > > The University of North Dakota is launching a 3U cubesat, probably in > mid to late 2025. They have a commitment for an ELANA launch but no firm > dates yet. They have .5U available out of 3U. > > > > So we need to make a decision here: > > > > 1. Do we want to support this launch? (Don't know yet how much support > they will need. Probably lots.) > > > > 2. Do we have the time to provide support? > > > > 3. If you think it is good timing, I will invite the UND project lead ( > Dr. Ron Fevig ) to our Thursday meeting. > > > > If we decide to move forward with this we will need to get Jerry's > permission to move beyond a pure ASCENT project. > > > > Please let me know your feelings ASAP. I have a meeting with Dr. Fevig > this afternoon and will try to better understand their requirements. > > > > Please let me know your feelings ASAP. ( 2nd request) I want to kill > this if we don't think we can do it. > > > > Bill > > > > > > ----------------------------------------------------------- > > > > 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 > > > > > > ----------------------------------------------------------- > > > > 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 > > ----------------------------------------------------------- > > 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