March 2024 - pacsat-dev - mailman.amsat.org

Re: Blinky Transmiter
by Bob Stricklin 05 Mar '24

05 Mar '24

Jim, Thanks for your report. I did reconnect the transformer to the 4X splinters using the fine coax and things seem to be working fine that way. I have not tried it with packet data yet but will do that when I can. The image below is the dif input to one of the receivers. The south trace is offset by 1 cm so we can it it better. Phasing looks good. Noise is due to poor ground in my setup mostly I feel. I received my 3D printer and I have printed three more of the plastic boxes for the programming board. I will mail you and Chris one maybe tomorrow. Bob [cid:[email protected]] On Mar 5, 2024, at 4:02 PM, Jim McCullers via pacsat-dev <pacsat-dev(a)amsat.org<mailto:[email protected]>> wrote: I did some analysis on Blinky’s transmitter last night and did not see the spurs Bob saw on his board. My experience with using a spectrum analyzer close in looking for spurs or phase noise is limited so more analysis is needed. I did look at the harmonics and the second was down 48 db from the fundamental (+15 to -33 dbm). The third harmonic was in the noise and undetectable. Now, for receiver board surgery. Jim McCullers WA4CWI ----------------------------------------------------------- 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<https://mailman.amsat.org/>

1 0

Blinky Transmiter
by Jim McCullers 05 Mar '24

05 Mar '24

I did some analysis on Blinky's transmitter last night and did not see the spurs Bob saw on his board. My experience with using a spectrum analyzer close in looking for spurs or phase noise is limited so more analysis is needed. I did look at the harmonics and the second was down 48 db from the fundamental (+15 to -33 dbm). The third harmonic was in the noise and undetectable. Now, for receiver board surgery. Jim McCullers WA4CWI

1 0

Re: Chrs and others asked for details about initialization comands. Here they are:
by Burns Fisher (AMSAT) 01 Mar '24

01 Mar '24

Thanks, Bob. I just realized that I changed "raise/lower rx freq" to take the number of the receiver as well. And also Chris mentioned that the device numbers are inconsistent. I *intended* the receivers to be numbered Rx1 Rx2 Rx3 and Rx4 and then Tx. I think those are 5043 number 0,1,2,3,4 (in the places where you want to use the device number). This may not be the best way to do it. Maybe the receiver 5043s should be number 0 1 2 3 to match the device numbers, but somewhere I saw the numbers were 1-based and that is what I used. 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software* On Fri, Mar 1, 2024 at 12:39 PM Bob Stricklin via pacsat-dev < pacsat-dev(a)amsat.org> wrote: > Nice job on this documenttion Burns. > > Bob > > On Mar 1, 2024, at 10:34 AM, Burns Fisher (AMSAT) via pacsat-dev < > pacsat-dev(a)amsat.org> wrote: > > *init new proc: * > Does some initialization that should only be done one time. > Specifically: > --Finds the right size for MRAM etc (which wipes out previous contents). > --Initializes the values for things that are generally going to be tweaked > on the bench, and not after the satellite is assembled, namely the default > values of the 4 Rx frequencies, the Tx frequency and the values of the high > and low power. > ++++Note that these values are at the early address of the MRAM, so if you > add stuff to MRAM, these locations should not change. > --Does "clear mram" (see below) > > *preflight init* > --Initializes all values in MRAM that want to be fresh when first > launched. For example, Min/Max values, Epoch, time, startup state, > autosafe voltages, frequency of saving WOD, etc. (Maybe some of these are > not relevant for PacSat) > --Initializes the MRAM version number. (See below) > --Probably by rights it should format the filesystem too. Right now, it > zaps the MRAM so 'main' sees that the file system can't be initialized and > formats it. A bit convoluted. > --Clears the "in orbit" flag so that the satellite code waits about 50 > minutes after power on before transmitting or doing anything else other > than waiting. This is so it can clear the Launch Vehicle. > > *clear mram* > --The same as preflight init, except that it SETS the "in orbit" flag. and > starts right away. > > *Note on the "default frequency"* > Currently the Rx default freqs are all the same. Fix in > "IHUInitSaved", module nonvolManagement.c. I'd change from a do to 4 > WriteMRAMReceiveFreq calls each with a different DCT_DEFAULT_RX_FREQ > (defined in config.h. Look for comment "AX5043 radio constants". > In the module "nonvolManagement.c" there are routines called > ReadMRAMReceiveFreq (which takes an integer indicating the receiver number > as an argument). This routine/macro reads the value and its check value > out of MRAM. If the checkvalue is wrong, it returns DCT_DEFAULT_RX_FREQ. > Note that it does NOT write the default Rx frequency back. It would be > best to arrange to return the defualt frequency for the specifiied receiver > on error rather than the generic frequency. > > *Note on "raise/lower rx freq" etc* > These routines allow you to tweak (or more) the receive and transmit > frequencies. You specify the amount you want to tweak by (example: "raise > rx freq 10" raises the frequency by 10Hz. It will be changed immediately > for testing purposes, but it is not saved in MRAM until you give the > command "save freq". If you do not issue 'save freq' the frequency will > revert to the currently saved value on the next reboot. Please don't > change the frequencies anywhere else, or this whole scheme will be broken. > You really need to be able to tweak frequencies on individual boards due to > differing crystals, caps, etc, and you do not want to have to redo those > tweaks each time you clear mram or preflight init. > > *Notes on the MRAM version number:* > In MRAMmap.h, there is a #define for a version number (currently 6). This > value should be changed anytime you change something in the MRAM map. It > works by being written into the MRAM itself. The flight software compares > what is in the MRAM to what is MRAMmap.h and will complain frequently if > they do not match. (This has saved me a number of times! Before I put > this feature in I spent hours figuring out why something did not work, and > it was only because the MRAM was screwed up!) Either "clear mram" or > "preflight init" updates the version number in MRAM, and of course puts > stuff in its new location. Please do not comment out the prints that > complain about the version number--you really do not want to do any testing > if the version number is wrong! > > 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 > > > > ----------------------------------------------------------- > > 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: Chrs and others asked for details about initialization comands. Here they are:
by Bob Stricklin 01 Mar '24

01 Mar '24

Nice job on this documenttion Burns. Bob On Mar 1, 2024, at 10:34 AM, Burns Fisher (AMSAT) via pacsat-dev <pacsat-dev(a)amsat.org<mailto:[email protected]>> wrote: init new proc: Does some initialization that should only be done one time. Specifically: --Finds the right size for MRAM etc (which wipes out previous contents). --Initializes the values for things that are generally going to be tweaked on the bench, and not after the satellite is assembled, namely the default values of the 4 Rx frequencies, the Tx frequency and the values of the high and low power. ++++Note that these values are at the early address of the MRAM, so if you add stuff to MRAM, these locations should not change. --Does "clear mram" (see below) preflight init --Initializes all values in MRAM that want to be fresh when first launched. For example, Min/Max values, Epoch, time, startup state, autosafe voltages, frequency of saving WOD, etc. (Maybe some of these are not relevant for PacSat) --Initializes the MRAM version number. (See below) --Probably by rights it should format the filesystem too. Right now, it zaps the MRAM so 'main' sees that the file system can't be initialized and formats it. A bit convoluted. --Clears the "in orbit" flag so that the satellite code waits about 50 minutes after power on before transmitting or doing anything else other than waiting. This is so it can clear the Launch Vehicle. clear mram --The same as preflight init, except that it SETS the "in orbit" flag. and starts right away. Note on the "default frequency" Currently the Rx default freqs are all the same. Fix in "IHUInitSaved", module nonvolManagement.c. I'd change from a do to 4 WriteMRAMReceiveFreq calls each with a different DCT_DEFAULT_RX_FREQ (defined in config.h. Look for comment "AX5043 radio constants". In the module "nonvolManagement.c" there are routines called ReadMRAMReceiveFreq (which takes an integer indicating the receiver number as an argument). This routine/macro reads the value and its check value out of MRAM. If the checkvalue is wrong, it returns DCT_DEFAULT_RX_FREQ. Note that it does NOT write the default Rx frequency back. It would be best to arrange to return the defualt frequency for the specifiied receiver on error rather than the generic frequency. Note on "raise/lower rx freq" etc These routines allow you to tweak (or more) the receive and transmit frequencies. You specify the amount you want to tweak by (example: "raise rx freq 10" raises the frequency by 10Hz. It will be changed immediately for testing purposes, but it is not saved in MRAM until you give the command "save freq". If you do not issue 'save freq' the frequency will revert to the currently saved value on the next reboot. Please don't change the frequencies anywhere else, or this whole scheme will be broken. You really need to be able to tweak frequencies on individual boards due to differing crystals, caps, etc, and you do not want to have to redo those tweaks each time you clear mram or preflight init. Notes on the MRAM version number: In MRAMmap.h, there is a #define for a version number (currently 6). This value should be changed anytime you change something in the MRAM map. It works by being written into the MRAM itself. The flight software compares what is in the MRAM to what is MRAMmap.h and will complain frequently if they do not match. (This has saved me a number of times! Before I put this feature in I spent hours figuring out why something did not work, and it was only because the MRAM was screwed up!) Either "clear mram" or "preflight init" updates the version number in MRAM, and of course puts stuff in its new location. Please do not comment out the prints that complain about the version number--you really do not want to do any testing if the version number is wrong! 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

Chrs and others asked for details about initialization comands. Here they are:
by Burns Fisher (AMSAT) 01 Mar '24

01 Mar '24

*init new proc: * Does some initialization that should only be done one time. Specifically: --Finds the right size for MRAM etc (which wipes out previous contents). --Initializes the values for things that are generally going to be tweaked on the bench, and not after the satellite is assembled, namely the default values of the 4 Rx frequencies, the Tx frequency and the values of the high and low power. ++++Note that these values are at the early address of the MRAM, so if you add stuff to MRAM, these locations should not change. --Does "clear mram" (see below) *preflight init* --Initializes all values in MRAM that want to be fresh when first launched. For example, Min/Max values, Epoch, time, startup state, autosafe voltages, frequency of saving WOD, etc. (Maybe some of these are not relevant for PacSat) --Initializes the MRAM version number. (See below) --Probably by rights it should format the filesystem too. Right now, it zaps the MRAM so 'main' sees that the file system can't be initialized and formats it. A bit convoluted. --Clears the "in orbit" flag so that the satellite code waits about 50 minutes after power on before transmitting or doing anything else other than waiting. This is so it can clear the Launch Vehicle. *clear mram* --The same as preflight init, except that it SETS the "in orbit" flag. and starts right away. *Note on the "default frequency"* Currently the Rx default freqs are all the same. Fix in "IHUInitSaved", module nonvolManagement.c. I'd change from a do to 4 WriteMRAMReceiveFreq calls each with a different DCT_DEFAULT_RX_FREQ (defined in config.h. Look for comment "AX5043 radio constants". In the module "nonvolManagement.c" there are routines called ReadMRAMReceiveFreq (which takes an integer indicating the receiver number as an argument). This routine/macro reads the value and its check value out of MRAM. If the checkvalue is wrong, it returns DCT_DEFAULT_RX_FREQ. Note that it does NOT write the default Rx frequency back. It would be best to arrange to return the defualt frequency for the specifiied receiver on error rather than the generic frequency. *Note on "raise/lower rx freq" etc* These routines allow you to tweak (or more) the receive and transmit frequencies. You specify the amount you want to tweak by (example: "raise rx freq 10" raises the frequency by 10Hz. It will be changed immediately for testing purposes, but it is not saved in MRAM until you give the command "save freq". If you do not issue 'save freq' the frequency will revert to the currently saved value on the next reboot. Please don't change the frequencies anywhere else, or this whole scheme will be broken. You really need to be able to tweak frequencies on individual boards due to differing crystals, caps, etc, and you do not want to have to redo those tweaks each time you clear mram or preflight init. *Notes on the MRAM version number:* In MRAMmap.h, there is a #define for a version number (currently 6). This value should be changed anytime you change something in the MRAM map. It works by being written into the MRAM itself. The flight software compares what is in the MRAM to what is MRAMmap.h and will complain frequently if they do not match. (This has saved me a number of times! Before I put this feature in I spent hours figuring out why something did not work, and it was only because the MRAM was screwed up!) Either "clear mram" or "preflight init" updates the version number in MRAM, and of course puts stuff in its new location. Please do not comment out the prints that complain about the version number--you really do not want to do any testing if the version number is wrong! 73, Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*

1 0

Slides I showed tonight
by Bob Stricklin 29 Feb '24

29 Feb '24

1 0