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 < [email protected]> wrote:
Nice job on this documenttion Burns.
Bob
On Mar 1, 2024, at 10:34 AM, Burns Fisher (AMSAT) via pacsat-dev < [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 -- [email protected] View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected] To unsubscribe send an email to [email protected] Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org
pacsat-dev mailing list -- [email protected] View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected] To unsubscribe send an email to [email protected] Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org