We need to address Pacsat memory considerations.
The MR25H40 is arranged as 8 x 512k bytes and is SPI.
The higher capacity models are parallel interface that would significantly complicate the design and board space.
In addition, they operate at much higher power consumption than the MR25H40.
With multiple MR25H40s there will de design issues with the file system when crossing memory bounds.
Burns or Rich, do you know what speed you are clocking the MR25H40?
There is considerable difference in power consumption between clocking speeds of 1mhz and 40mhz.
Thanks
Jim McCullers
WA4CWI
Wouldn't you think that would be an easy question to answer? Ha ha! On the TMS570, you set up "data formats" using HAL. Data format 1 is currently set up to 10MHz, and the others are set to 1MHz. Then tracking back through the code, the MRAM uses data format 1, so it is running at 10MHz. The DCT (Digital Communications Tranceiver, that is the AX5043) has its SPI at 1MHz. As I recall, I increased the MRAM speed largely because on Golf there was a lot more data being sent (the Whole Orbit Data) relatively regularly. I could look back at Fox, which saves much less data in MRAM, if you care.
Just a comment re the MRAM: It's only clock is the SPI Clock which says to me that the clock speed only makes a difference while there is communication on the bus. I'd think that would be a relatively small % of the time, right? Or am I really missing something?
73,
Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*
On Fri, Nov 18, 2022 at 10:07 AM Jim McCullers [email protected] wrote:
We need to address Pacsat memory considerations.
The MR25H40 is arranged as 8 x 512k bytes and is SPI.
The higher capacity models are parallel interface that would significantly complicate the design and board space.
In addition, they operate at much higher power consumption than the MR25H40.
With multiple MR25H40s there will de design issues with the file system when crossing memory bounds.
Burns or Rich, do you know what speed you are clocking the MR25H40?
There is considerable difference in power consumption between clocking speeds of 1mhz and 40mhz.
Thanks
Jim McCullers
WA4CWI
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
Oh, one more thing about memory. In the existing code, there is a module called "nonvol.c" which has routines like "write NV(data, datalength, address). I should be relatively easy to assign address ranges to different MRAM chips so that callers of writeNV, readNV, etc don't need to know anything about where they are. In other words, I don't think that multiple chips are a big problem.
FWIW, I did not design that particular code as being block-oriented as most disks would be, for example. It is just byte-address and byte-length. We could do it block-wise and even include a CRC for each block (although I've never seen an error). Design decision to be made.
73,
Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*
On Fri, Nov 18, 2022 at 10:51 AM Burns Fisher (AMSAT) [email protected] wrote:
Wouldn't you think that would be an easy question to answer? Ha ha! On the TMS570, you set up "data formats" using HAL. Data format 1 is currently set up to 10MHz, and the others are set to 1MHz. Then tracking back through the code, the MRAM uses data format 1, so it is running at 10MHz. The DCT (Digital Communications Tranceiver, that is the AX5043) has its SPI at 1MHz. As I recall, I increased the MRAM speed largely because on Golf there was a lot more data being sent (the Whole Orbit Data) relatively regularly. I could look back at Fox, which saves much less data in MRAM, if you care.
Just a comment re the MRAM: It's only clock is the SPI Clock which says to me that the clock speed only makes a difference while there is communication on the bus. I'd think that would be a relatively small % of the time, right? Or am I really missing something?
73,
Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*
On Fri, Nov 18, 2022 at 10:07 AM Jim McCullers [email protected] wrote:
We need to address Pacsat memory considerations.
The MR25H40 is arranged as 8 x 512k bytes and is SPI.
The higher capacity models are parallel interface that would significantly complicate the design and board space.
In addition, they operate at much higher power consumption than the MR25H40.
With multiple MR25H40s there will de design issues with the file system when crossing memory bounds.
Burns or Rich, do you know what speed you are clocking the MR25H40?
There is considerable difference in power consumption between clocking speeds of 1mhz and 40mhz.
Thanks
Jim McCullers
WA4CWI
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
In the prototype I hold the PACSAT File Headers in memory in a linked list. If we have enough memory to follow the same approach then they would not be read from MRAM except at boot. Each header is about 256 bytes, sometimes shorter. Can be longer. Of course we could read them directly from MRAM but then we would be constantly traversing the MRAM memory every time someone requests a directory listing. We have to scan it to find the entries they want. We could compromise and just hold a linked list of the file-Id a its upload_time in memory. If we will only have enough room in MRAM. That would also avoid duplicating the PACSAT File Header information between MRAM and memory.
When a file is requested we do need to read that from the MRAM, but only a block at a time and at the speed that the downlink can cope with. So that would really minimize the traffic from the MRAM. The same is true for writing. We would only write at the speed we can receive from the uplink. The header is cached in the linked list in memory when it is received, though in the prototype I read it back from the Disk once the file is complete. And I do some lazy things like re-write a whole file rather than seeking the byte offset for the upload time and just updating that. Clearly we would need to do that.
Also, is the MRAM 8 x 512 bits. i.e. 512 bytes? Or its 8 x 512 bytes, so 2MB? Either way, that is not going to be enough to store files where the header alone is 256 bytes. An image might be 65k or more.
To see what I mean, I have attached a copy of this same message (without this last line) as it would be stored on the PACSAT, after upload. It is 1777 bytes.
73 Chris
On Fri, Nov 18, 2022 at 11:03 AM Burns Fisher (AMSAT) [email protected] wrote:
Oh, one more thing about memory. In the existing code, there is a module called "nonvol.c" which has routines like "write NV(data, datalength, address). I should be relatively easy to assign address ranges to different MRAM chips so that callers of writeNV, readNV, etc don't need to know anything about where they are. In other words, I don't think that multiple chips are a big problem.
FWIW, I did not design that particular code as being block-oriented as most disks would be, for example. It is just byte-address and byte-length. We could do it block-wise and even include a CRC for each block (although I've never seen an error). Design decision to be made.
73,
Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*
On Fri, Nov 18, 2022 at 10:51 AM Burns Fisher (AMSAT) [email protected] wrote:
Wouldn't you think that would be an easy question to answer? Ha ha! On the TMS570, you set up "data formats" using HAL. Data format 1 is currently set up to 10MHz, and the others are set to 1MHz. Then tracking back through the code, the MRAM uses data format 1, so it is running at 10MHz. The DCT (Digital Communications Tranceiver, that is the AX5043) has its SPI at 1MHz. As I recall, I increased the MRAM speed largely because on Golf there was a lot more data being sent (the Whole Orbit Data) relatively regularly. I could look back at Fox, which saves much less data in MRAM, if you care.
Just a comment re the MRAM: It's only clock is the SPI Clock which says to me that the clock speed only makes a difference while there is communication on the bus. I'd think that would be a relatively small % of the time, right? Or am I really missing something?
73,
Burns Fisher, WB1FJ *AMSAT(R) Engineering -- Flight Software*
On Fri, Nov 18, 2022 at 10:07 AM Jim McCullers [email protected] wrote:
We need to address Pacsat memory considerations.
The MR25H40 is arranged as 8 x 512k bytes and is SPI.
The higher capacity models are parallel interface that would significantly complicate the design and board space.
In addition, they operate at much higher power consumption than the MR25H40.
With multiple MR25H40s there will de design issues with the file system when crossing memory bounds.
Burns or Rich, do you know what speed you are clocking the MR25H40?
There is considerable difference in power consumption between clocking speeds of 1mhz and 40mhz.
Thanks
Jim McCullers
WA4CWI
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
The MR25H50 is 512k Bytes or 4 megabits. I consistently confuse MB and mb, similar to Tx/Rx with DB9 connectors.
Do you have any speculation on the memory size of FalconSat-3 based on working with it?
I’ve never seen a published spec.
Jim McCullers
WA4CWI
In the prototype I hold the PACSAT File Headers in memory in a linked list. If we have enough memory to follow the same approach then they would not be read from MRAM except at boot. Each header is about 256 bytes, sometimes shorter. Can be longer. Of course we could read them directly from MRAM but then we would be constantly traversing the MRAM memory every time someone requests a directory listing. We have to scan it to find the entries they want. We could compromise and just hold a linked list of the file-Id a its upload_time in memory. If we will only have enough room in MRAM. That would also avoid duplicating the PACSAT File Header information between MRAM and memory.
When a file is requested we do need to read that from the MRAM, but only a block at a time and at the speed that the downlink can cope with. So that would really minimize the traffic from the MRAM. The same is true for writing. We would only write at the speed we can receive from the uplink. The header is cached in the linked list in memory when it is received, though in the prototype I read it back from the Disk once the file is complete. And I do some lazy things like re-write a whole file rather than seeking the byte offset for the upload time and just updating that. Clearly we would need to do that.
Also, is the MRAM 8 x 512 bits. i.e. 512 bytes? Or its 8 x 512 bytes, so 2MB? Either way, that is not going to be enough to store files where the header alone is 256 bytes. An image might be 65k or more.
To see what I mean, I have attached a copy of this same message (without this last line) as it would be stored on the PACSAT, after upload. It is 1777 bytes.
73
Chris
On Fri, Nov 18, 2022 at 11:03 AM Burns Fisher (AMSAT) <[email protected] mailto:[email protected] > wrote:
Oh, one more thing about memory. In the existing code, there is a module called "nonvol.c" which has routines like "write NV(data, datalength, address). I should be relatively easy to assign address ranges to different MRAM chips so that callers of writeNV, readNV, etc don't need to know anything about where they are In other words, I don't think that multiple chips are a big problem.
FWIW, I did not design that particular code as being block-oriented as most disks would be, for example. It is just byte-address and byte-length. We could do it block-wise and even include a CRC for each block (although I've never seen an error). Design decision to be made.
73,
Burns Fisher, WB1FJ
AMSAT(R) Engineering -- Flight Software
On Fri, Nov 18, 2022 at 10:51 AM Burns Fisher (AMSAT) <[email protected] mailto:[email protected] > wrote:
Wouldn't you think that would be an easy question to answer? Ha ha! On the TMS570, you set up "data formats" using HAL. Data format 1 is currently set up to 10MHz, and the others are set to 1MHz. Then tracking back through the code, the MRAM uses data format 1, so it is running at 10MHz. The DCT (Digital Communications Tranceiver, that is the AX5043) has its SPI at 1MHz. As I recall, I increased the MRAM speed largely because on Golf there was a lot more data being sent (the Whole Orbit Data) relatively regularly. I could look back at Fox, which saves much less data in MRAM, if you care.
Just a comment re the MRAM: It's only clock is the SPI Clock which says to me that the clock speed only makes a difference while there is communication on the bus. I'd think that would be a relatively small % of the time, right? Or am I really missing something?
73,
Burns Fisher, WB1FJ
AMSAT(R) Engineering -- Flight Software
On Fri, Nov 18, 2022 at 10:07 AM Jim McCullers <[email protected] mailto:[email protected] > wrote:
We need to address Pacsat memory considerations.
The MR25H40 is arranged as 8 x 512k bytes and is SPI.
The higher capacity models are parallel interface that would significantly complicate the design and board space.
In addition, they operate at much higher power consumption than the MR25H40.
With multiple MR25H40s there will de design issues with the file system when crossing memory bounds.
Burns or Rich, do you know what speed you are clocking the MR25H40?
There is considerable difference in power consumption between clocking speeds of 1mhz and 40mhz.
Thanks
Jim McCullers
WA4CWI
----------------------------------------------- pacsat-dev mailing list -- [email protected] mailto:[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] mailto:[email protected] Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org
----------------------------------------------- pacsat-dev mailing list -- [email protected] mailto:[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] mailto:[email protected] Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org
Chris,
I suggest you recommend a memory size we should be considering based on your experience with the messages and sizes. If we need to study more we can.
We can add additional banks of memory if needed. Idle memory will pull some current but more when operating. We may even power individual memory chips down when not in use. We also will need to have a plan for how long a message can live in memory.
Write the code to be most efficient with writing to conserve power.
Having an idea of message sizes is important. We have the option set the speed needed to read the memory. Slower read speeds means lower currents. The data is going out over transmissions slowly so we may not need to read memory too fast. Since we are looking at spi memory we are moving one bit at a time so it will add up and push the clock speed. I looked at converting to parallel memory but the currents look higher on those chips. Didn’t look at very many chips though.
We will also be wasting time sending data when the user has lost the ability to receive. So we will have inefficiency to deal with. If we have a long message to dump and the user is gone we wasted our time and power. So there is some ideal block size to work with. Hard to say what that is.
Bob
On Nov 18, 2022, at 11:08 AM, Jim McCullers <[email protected]mailto:[email protected]> wrote:
The MR25H50 is 512k Bytes or 4 megabits. I consistently confuse MB and mb, similar to Tx/Rx with DB9 connectors.
Do you have any speculation on the memory size of FalconSat-3 based on working with it? I’ve never seen a published spec.
Jim McCullers WA4CWI
In the prototype I hold the PACSAT File Headers in memory in a linked list. If we have enough memory to follow the same approach then they would not be read from MRAM except at boot. Each header is about 256 bytes, sometimes shorter. Can be longer. Of course we could read them directly from MRAM but then we would be constantly traversing the MRAM memory every time someone requests a directory listing. We have to scan it to find the entries they want. We could compromise and just hold a linked list of the file-Id a its upload_time in memory. If we will only have enough room in MRAM. That would also avoid duplicating the PACSAT File Header information between MRAM and memory.
When a file is requested we do need to read that from the MRAM, but only a block at a time and at the speed that the downlink can cope with. So that would really minimize the traffic from the MRAM. The same is true for writing. We would only write at the speed we can receive from the uplink. The header is cached in the linked list in memory when it is received, though in the prototype I read it back from the Disk once the file is complete. And I do some lazy things like re-write a whole file rather than seeking the byte offset for the upload time and just updating that. Clearly we would need to do that.
Also, is the MRAM 8 x 512 bits. i.e. 512 bytes? Or its 8 x 512 bytes, so 2MB? Either way, that is not going to be enough to store files where the header alone is 256 bytes. An image might be 65k or more.
To see what I mean, I have attached a copy of this same message (without this last line) as it would be stored on the PACSAT, after upload. It is 1777 bytes.
73 Chris
On Fri, Nov 18, 2022 at 11:03 AM Burns Fisher (AMSAT) <[email protected]mailto:[email protected]> wrote: Oh, one more thing about memory. In the existing code, there is a module called "nonvol.c" which has routines like "write NV(data, datalength, address). I should be relatively easy to assign address ranges to different MRAM chips so that callers of writeNV, readNV, etc don't need to know anything about where they are In other words, I don't think that multiple chips are a big problem.
FWIW, I did not design that particular code as being block-oriented as most disks would be, for example. It is just byte-address and byte-length. We could do it block-wise and even include a CRC for each block (although I've never seen an error). Design decision to be made.
73,
Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software
On Fri, Nov 18, 2022 at 10:51 AM Burns Fisher (AMSAT) <[email protected]mailto:[email protected]> wrote: Wouldn't you think that would be an easy question to answer? Ha ha! On the TMS570, you set up "data formats" using HAL. Data format 1 is currently set up to 10MHz, and the others are set to 1MHz. Then tracking back through the code, the MRAM uses data format 1, so it is running at 10MHz. The DCT (Digital Communications Tranceiver, that is the AX5043) has its SPI at 1MHz. As I recall, I increased the MRAM speed largely because on Golf there was a lot more data being sent (the Whole Orbit Data) relatively regularly. I could look back at Fox, which saves much less data in MRAM, if you care.
Just a comment re the MRAM: It's only clock is the SPI Clock which says to me that the clock speed only makes a difference while there is communication on the bus. I'd think that would be a relatively small % of the time, right? Or am I really missing something?
73,
Burns Fisher, WB1FJ AMSAT(R) Engineering -- Flight Software
On Fri, Nov 18, 2022 at 10:07 AM Jim McCullers <[email protected]mailto:[email protected]> wrote: We need to address Pacsat memory considerations.
The MR25H40 is arranged as 8 x 512k bytes and is SPI. The higher capacity models are parallel interface that would significantly complicate the design and board space. In addition, they operate at much higher power consumption than the MR25H40.
With multiple MR25H40s there will de design issues with the file system when crossing memory bounds.
Burns or Rich, do you know what speed you are clocking the MR25H40? There is considerable difference in power consumption between clocking speeds of 1mhz and 40mhz.
Thanks
Jim McCullers WA4CWI ----------------------------------------------- pacsat-dev mailing list -- [email protected]mailto:[email protected] View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected]https://url.emailprotection.link/?buUg7YY4HZLXKo6ZKNudC8bRTBdOsBlAV5C9rq-aqxOQfa9Eqh8kfGK8xAPNkaYeV4y3Z5HVIEvNBaAimp_ZfFMwcw8QT0XZxGj2iXsHa3mcBRxu810JiHLaLtHS4Ej_7 To unsubscribe send an email to [email protected]mailto:[email protected] Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.orghttps://url.emailprotection.link/?bO71JCUf8Kb7txAlIoAarNqcIdQhyb8VQQIN4j0Gik24jnwI-Byk6ZVn92BYiD7Bxz61XZBoNoJE1TKqdfKnwFw~~ ----------------------------------------------- pacsat-dev mailing list -- [email protected]mailto:[email protected] View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected]https://url.emailprotection.link/?buUg7YY4HZLXKo6ZKNudC8bRTBdOsBlAV5C9rq-aqxOQfa9Eqh8kfGK8xAPNkaYeV4y3Z5HVIEvNBaAimp_ZfFMwcw8QT0XZxGj2iXsHa3mcBRxu810JiHLaLtHS4Ej_7 To unsubscribe send an email to [email protected]mailto:[email protected] Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.orghttps://url.emailprotection.link/?bO71JCUf8Kb7txAlIoAarNqcIdQhyb8VQQIN4j0Gik24jnwI-Byk6ZVn92BYiD7Bxz61XZBoNoJE1TKqdfKnwFw~~
-- Chris E. Thompson [email protected]mailto:[email protected] [email protected]mailto:[email protected] ----------------------------------------------- pacsat-dev mailing list -- [email protected]mailto:[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]mailto:[email protected] Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org
Falconsat-3 has two 16MB SRAM banks that operate as a single 31 MB RAM disk. I believe this also holds the software as well as the files. Only the bootloader and basic OS is in the PROM. This is why Mark has to keep reloading the software now the batteries are failing. It forgets nearly everything.
There is a really good document here that describes Falconsat-3 and the fun they had making it work after launch https://www.google.com/url?sa=t&source=web&rct=j&url=https://app...
Note that Falconsat-3 also had a lot of battery power using NiCad D cells. So I don't expect we can support the same amount of memory. Let me do some modelling and come up with a recommendation.
73 Chris
On Fri, Nov 18, 2022, 12:38 Bob Stricklin via pacsat-dev < [email protected]> wrote:
Chris,
I suggest you recommend a memory size we should be considering based on your experience with the messages and sizes. If we need to study more we can.
We can add additional banks of memory if needed. Idle memory will pull some current but more when operating. We may even power individual memory chips down when not in use. We also will need to have a plan for how long a message can live in memory.
Write the code to be most efficient with writing to conserve power.
Having an idea of message sizes is important. We have the option set the speed needed to read the memory. Slower read speeds means lower currents. The data is going out over transmissions slowly so we may not need to read memory too fast. Since we are looking at spi memory we are moving one bit at a time so it will add up and push the clock speed. I looked at converting to parallel memory but the currents look higher on those chips. Didn’t look at very many chips though.
We will also be wasting time sending data when the user has lost the ability to receive. So we will have inefficiency to deal with. If we have a long message to dump and the user is gone we wasted our time and power. So there is some ideal block size to work with. Hard to say what that is.
Bob
On Nov 18, 2022, at 11:08 AM, Jim McCullers [email protected] wrote:
The MR25H50 is 512k Bytes or 4 megabits. I consistently confuse MB and mb, similar to Tx/Rx with DB9 connectors.
Do you have any speculation on the memory size of FalconSat-3 based on working with it? I’ve never seen a published spec.
Jim McCullers WA4CWI
In the prototype I hold the PACSAT File Headers in memory in a linked list. If we have enough memory to follow the same approach then they would not be read from MRAM except at boot. Each header is about 256 bytes, sometimes shorter. Can be longer. Of course we could read them directly from MRAM but then we would be constantly traversing the MRAM memory every time someone requests a directory listing. We have to scan it to find the entries they want. We could compromise and just hold a linked list of the file-Id a its upload_time in memory. If we will only have enough room in MRAM. That would also avoid duplicating the PACSAT File Header information between MRAM and memory.
When a file is requested we do need to read that from the MRAM, but only a block at a time and at the speed that the downlink can cope with. So that would really minimize the traffic from the MRAM. The same is true for writing. We would only write at the speed we can receive from the uplink. The header is cached in the linked list in memory when it is received, though in the prototype I read it back from the Disk once the file is complete. And I do some lazy things like re-write a whole file rather than seeking the byte offset for the upload time and just updating that. Clearly we would need to do that.
Also, is the MRAM 8 x 512 bits. i.e. 512 bytes? Or its 8 x 512 bytes, so 2MB? Either way, that is not going to be enough to store files where the header alone is 256 bytes. An image might be 65k or more.
To see what I mean, I have attached a copy of this same message (without this last line) as it would be stored on the PACSAT, after upload. It is 1777 bytes.
73 Chris
On Fri, Nov 18, 2022 at 11:03 AM Burns Fisher (AMSAT) [email protected] wrote:
Oh, one more thing about memory. In the existing code, there is a module called "nonvol.c" which has routines like "write NV(data, datalength, address). I should be relatively easy to assign address ranges to different MRAM chips so that callers of writeNV, readNV, etc don't need to know anything about where they are In other words, I don't think that multiple chips are a big problem.
FWIW, I did not design that particular code as being block-oriented as most disks would be, for example. It is just byte-address and byte-length. We could do it block-wise and even include a CRC for each block (although I've never seen an error). Design decision to be made.
73,
Burns Fisher, WB1FJ *AMSAT**(R) **Engineering -- Flight Software*
On Fri, Nov 18, 2022 at 10:51 AM Burns Fisher (AMSAT) [email protected] wrote:
Wouldn't you think that would be an easy question to answer? Ha ha! On the TMS570, you set up "data formats" using HAL. Data format 1 is currently set up to 10MHz, and the others are set to 1MHz. Then tracking back through the code, the MRAM uses data format 1, so it is running at 10MHz. The DCT (Digital Communications Tranceiver, that is the AX5043) has its SPI at 1MHz. As I recall, I increased the MRAM speed largely because on Golf there was a lot more data being sent (the Whole Orbit Data) relatively regularly. I could look back at Fox, which saves much less data in MRAM, if you care.
Just a comment re the MRAM: It's only clock is the SPI Clock which says to me that the clock speed only makes a difference while there is communication on the bus. I'd think that would be a relatively small % of the time, right? Or am I really missing something?
73,
Burns Fisher, WB1FJ *AMSAT**(R) **Engineering -- Flight Software*
On Fri, Nov 18, 2022 at 10:07 AM Jim McCullers [email protected] wrote:
We need to address Pacsat memory considerations.
The MR25H40 is arranged as 8 x 512k bytes and is SPI. The higher capacity models are parallel interface that would significantly complicate the design and board space. In addition, they operate at much higher power consumption than the MR25H40.
With multiple MR25H40s there will de design issues with the file system when crossing memory bounds.
Burns or Rich, do you know what speed you are clocking the MR25H40? There is considerable difference in power consumption between clocking speeds of 1mhz and 40mhz.
Thanks
Jim McCullers WA4CWI
pacsat-dev mailing list -- [email protected] View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected] https://url.emailprotection.link/?buUg7YY4HZLXKo6ZKNudC8bRTBdOsBlAV5C9rq-aqxOQfa9Eqh8kfGK8xAPNkaYeV4y3Z5HVIEvNBaAimp_ZfFMwcw8QT0XZxGj2iXsHa3mcBRxu810JiHLaLtHS4Ej_7 To unsubscribe send an email to [email protected] Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org https://url.emailprotection.link/?bO71JCUf8Kb7txAlIoAarNqcIdQhyb8VQQIN4j0Gik24jnwI-Byk6ZVn92BYiD7Bxz61XZBoNoJE1TKqdfKnwFw~~
pacsat-dev mailing list -- [email protected] View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected] https://url.emailprotection.link/?buUg7YY4HZLXKo6ZKNudC8bRTBdOsBlAV5C9rq-aqxOQfa9Eqh8kfGK8xAPNkaYeV4y3Z5HVIEvNBaAimp_ZfFMwcw8QT0XZxGj2iXsHa3mcBRxu810JiHLaLtHS4Ej_7 To unsubscribe send an email to [email protected] Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org https://url.emailprotection.link/?bO71JCUf8Kb7txAlIoAarNqcIdQhyb8VQQIN4j0Gik24jnwI-Byk6ZVn92BYiD7Bxz61XZBoNoJE1TKqdfKnwFw~~
-- Chris E. Thompson [email protected] [email protected]
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
Thanks Chris.
That’s good information and I look forward to reading the document.
I’d been hoping something like that would be available.
Jim McCullers
WA4CWI
Falconsat-3 has two 16MB SRAM banks that operate as a single 31 MB RAM disk. I believe this also holds the software as well as the files. Only the bootloader and basic OS is in the PROM. This is why Mark has to keep reloading the software now the batteries are failing. It forgets nearly everything.
There is a really good document here that describes Falconsat-3 and the fun they had making it work after launch
https://www.google.com/url?sa=t https://www.google.com/url?sa=t&source=web&rct=j&url=https://apps.dtic.mil/sti/pdfs/ADA543958.pdf&ved=2ahUKEwjBhb65orj7AhV-jYkEHdu-D6MQFnoECBIQAQ&usg=AOvVaw15cjpm54pBDjDDLSOCQ80X &source=web&rct=j&url=https://apps.dtic.mil/sti/pdfs/ADA543958.pdf&ved=2ahUKEwjBhb65orj7AhV-jY...
Note that Falconsat-3 also had a lot of battery power using NiCad D cells. So I don't expect we can support the same amount of memory. Let me do some modelling and come up with a recommendation.
73
Chris
On Fri, Nov 18, 2022, 12:38 Bob Stricklin via pacsat-dev <[email protected] mailto:[email protected] > wrote:
Chris,
I suggest you recommend a memory size we should be considering based on your experience with the messages and sizes. If we need to study more we can.
We can add additional banks of memory if needed. Idle memory will pull some current but more when operating. We may even power individual memory chips down when not in use. We also will need to have a plan for how long a message can live in memory.
Write the code to be most efficient with writing to conserve power.
Having an idea of message sizes is important. We have the option set the speed needed to read the memory. Slower read speeds means lower currents. The data is going out over transmissions slowly so we may not need to read memory too fast. Since we are looking at spi memory we are moving one bit at a time so it will add up and push the clock speed. I looked at converting to parallel memory but the currents look higher on those chips. Didn’t look at very many chips though.
We will also be wasting time sending data when the user has lost the ability to receive. So we will have inefficiency to deal with. If we have a long message to dump and the user is gone we wasted our time and power. So there is some ideal block size to work with. Hard to say what that is.
Bob
On Nov 18, 2022, at 11:08 AM, Jim McCullers <[email protected] mailto:[email protected] > wrote:
The MR25H50 is 512k Bytes or 4 megabits. I consistently confuse MB and mb, similar to Tx/Rx with DB9 connectors.
Do you have any speculation on the memory size of FalconSat-3 based on working with it?
I’ve never seen a published spec.
Jim McCullers
WA4CWI
In the prototype I hold the PACSAT File Headers in memory in a linked list. If we have enough memory to follow the same approach then they would not be read from MRAM except at boot. Each header is about 256 bytes, sometimes shorter. Can be longer. Of course we could read them directly from MRAM but then we would be constantly traversing the MRAM memory every time someone requests a directory listing. We have to scan it to find the entries they want. We could compromise and just hold a linked list of the file-Id a its upload_time in memory. If we will only have enough room in MRAM. That would also avoid duplicating the PACSAT File Header information between MRAM and memory.
When a file is requested we do need to read that from the MRAM, but only a block at a time and at the speed that the downlink can cope with. So that would really minimize the traffic from the MRAM. The same is true for writing. We would only write at the speed we can receive from the uplink. The header is cached in the linked list in memory when it is received, though in the prototype I read it back from the Disk once the file is complete. And I do some lazy things like re-write a whole file rather than seeking the byte offset for the upload time and just updating that. Clearly we would need to do that.
Also, is the MRAM 8 x 512 bits. i.e. 512 bytes? Or its 8 x 512 bytes, so 2MB? Either way, that is not going to be enough to store files where the header alone is 256 bytes. An image might be 65k or more.
To see what I mean, I have attached a copy of this same message (without this last line) as it would be stored on the PACSAT, after upload. It is 1777 bytes.
73
Chris
On Fri, Nov 18, 2022 at 11:03 AM Burns Fisher (AMSAT) <[email protected] mailto:[email protected] > wrote:
Oh, one more thing about memory. In the existing code, there is a module called "nonvol.c" which has routines like "write NV(data, datalength, address). I should be relatively easy to assign address ranges to different MRAM chips so that callers of writeNV, readNV, etc don't need to know anything about where they are In other words, I don't think that multiple chips are a big problem.
FWIW, I did not design that particular code as being block-oriented as most disks would be, for example. It is just byte-address and byte-length. We could do it block-wise and even include a CRC for each block (although I've never seen an error). Design decision to be made.
73,
Burns Fisher, WB1FJ
AMSAT(R) Engineering -- Flight Software
On Fri, Nov 18, 2022 at 10:51 AM Burns Fisher (AMSAT) <[email protected] mailto:[email protected] > wrote:
Wouldn't you think that would be an easy question to answer? Ha ha! On the TMS570, you set up "data formats" using HAL. Data format 1 is currently set up to 10MHz, and the others are set to 1MHz. Then tracking back through the code, the MRAM uses data format 1, so it is running at 10MHz. The DCT (Digital Communications Tranceiver, that is the AX5043) has its SPI at 1MHz. As I recall, I increased the MRAM speed largely because on Golf there was a lot more data being sent (the Whole Orbit Data) relatively regularly. I could look back at Fox, which saves much less data in MRAM, if you care.
Just a comment re the MRAM: It's only clock is the SPI Clock which says to me that the clock speed only makes a difference while there is communication on the bus. I'd think that would be a relatively small % of the time, right? Or am I really missing something?
73,
Burns Fisher, WB1FJ
AMSAT(R) Engineering -- Flight Software
On Fri, Nov 18, 2022 at 10:07 AM Jim McCullers <[email protected] mailto:[email protected] > wrote:
We need to address Pacsat memory considerations.
The MR25H40 is arranged as 8 x 512k bytes and is SPI.
The higher capacity models are parallel interface that would significantly complicate the design and board space.
In addition, they operate at much higher power consumption than the MR25H40.
With multiple MR25H40s there will de design issues with the file system when crossing memory bounds.
Burns or Rich, do you know what speed you are clocking the MR25H40?
There is considerable difference in power consumption between clocking speeds of 1mhz and 40mhz.
Thanks
Jim McCullers
WA4CWI
----------------------------------------------- pacsat-dev mailing list -- [email protected] mailto:[email protected] View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected] https://url.emailprotection.link/?buUg7YY4HZLXKo6ZKNudC8bRTBdOsBlAV5C9rq-aqxOQfa9Eqh8kfGK8xAPNkaYeV4y3Z5HVIEvNBaAimp_ZfFMwcw8QT0XZxGj2iXsHa3mcBRxu810JiHLaLtHS4Ej_7 To unsubscribe send an email to [email protected] mailto:[email protected] Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org https://url.emailprotection.link/?bO71JCUf8Kb7txAlIoAarNqcIdQhyb8VQQIN4j0Gik24jnwI-Byk6ZVn92BYiD7Bxz61XZBoNoJE1TKqdfKnwFw~~
----------------------------------------------- pacsat-dev mailing list -- [email protected] mailto:[email protected] View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected] https://url.emailprotection.link/?buUg7YY4HZLXKo6ZKNudC8bRTBdOsBlAV5C9rq-aqxOQfa9Eqh8kfGK8xAPNkaYeV4y3Z5HVIEvNBaAimp_ZfFMwcw8QT0XZxGj2iXsHa3mcBRxu810JiHLaLtHS4Ej_7 To unsubscribe send an email to [email protected] mailto:[email protected] Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org https://url.emailprotection.link/?bO71JCUf8Kb7txAlIoAarNqcIdQhyb8VQQIN4j0Gik24jnwI-Byk6ZVn92BYiD7Bxz61XZBoNoJE1TKqdfKnwFw~~
Actually, knock on wood—TX cuts off at a voltage that prevents a reload. The OS keeps running and WOD continues to be collected. When I turn off BATT MGT l, I have to watch and be careful. That allows the 24 hr sessions (which I hope to start tonight, we’ll see—traveling!) I am trying to NOT hit whatever is the bottom where what you describe happens:)
Mark N8MH
On Fri, Nov 18, 2022 at 1:02 PM Chris Thompson [email protected] wrote:
Falconsat-3 has two 16MB SRAM banks that operate as a single 31 MB RAM disk. I believe this also holds the software as well as the files. Only the bootloader and basic OS is in the PROM. This is why Mark has to keep reloading the software now the batteries are failing. It forgets nearly everything.
There is a really good document here that describes Falconsat-3 and the fun they had making it work after launch
https://www.google.com/url?sa=t&source=web&rct=j&url=https://app...
Note that Falconsat-3 also had a lot of battery power using NiCad D cells. So I don't expect we can support the same amount of memory. Let me do some modelling and come up with a recommendation.
73 Chris
On Fri, Nov 18, 2022, 12:38 Bob Stricklin via pacsat-dev < [email protected]> wrote:
Chris,
I suggest you recommend a memory size we should be considering based on your experience with the messages and sizes. If we need to study more we can.
We can add additional banks of memory if needed. Idle memory will pull some current but more when operating. We may even power individual memory chips down when not in use. We also will need to have a plan for how long a message can live in memory.
Write the code to be most efficient with writing to conserve power.
Having an idea of message sizes is important. We have the option set the speed needed to read the memory. Slower read speeds means lower currents. The data is going out over transmissions slowly so we may not need to read memory too fast. Since we are looking at spi memory we are moving one bit at a time so it will add up and push the clock speed. I looked at converting to parallel memory but the currents look higher on those chips. Didn’t look at very many chips though.
We will also be wasting time sending data when the user has lost the ability to receive. So we will have inefficiency to deal with. If we have a long message to dump and the user is gone we wasted our time and power. So there is some ideal block size to work with. Hard to say what that is.
Bob
On Nov 18, 2022, at 11:08 AM, Jim McCullers [email protected] wrote:
The MR25H50 is 512k Bytes or 4 megabits. I consistently confuse MB and mb, similar to Tx/Rx with DB9 connectors.
Do you have any speculation on the memory size of FalconSat-3 based on working with it? I’ve never seen a published spec.
Jim McCullers WA4CWI
In the prototype I hold the PACSAT File Headers in memory in a linked list. If we have enough memory to follow the same approach then they would not be read from MRAM except at boot. Each header is about 256 bytes, sometimes shorter. Can be longer. Of course we could read them directly from MRAM but then we would be constantly traversing the MRAM memory every time someone requests a directory listing. We have to scan it to find the entries they want. We could compromise and just hold a linked list of the file-Id a its upload_time in memory. If we will only have enough room in MRAM. That would also avoid duplicating the PACSAT File Header information between MRAM and memory.
When a file is requested we do need to read that from the MRAM, but only a block at a time and at the speed that the downlink can cope with. So that would really minimize the traffic from the MRAM. The same is true for writing. We would only write at the speed we can receive from the uplink. The header is cached in the linked list in memory when it is received, though in the prototype I read it back from the Disk once the file is complete. And I do some lazy things like re-write a whole file rather than seeking the byte offset for the upload time and just updating that. Clearly we would need to do that.
Also, is the MRAM 8 x 512 bits. i.e. 512 bytes? Or its 8 x 512 bytes, so 2MB? Either way, that is not going to be enough to store files where the header alone is 256 bytes. An image might be 65k or more.
To see what I mean, I have attached a copy of this same message (without this last line) as it would be stored on the PACSAT, after upload. It is 1777 bytes.
73 Chris
On Fri, Nov 18, 2022 at 11:03 AM Burns Fisher (AMSAT) [email protected] wrote:
Oh, one more thing about memory. In the existing code, there is a module called "nonvol.c" which has routines like "write NV(data, datalength, address). I should be relatively easy to assign address ranges to different MRAM chips so that callers of writeNV, readNV, etc don't need to know anything about where they are In other words, I don't think that multiple chips are a big problem.
FWIW, I did not design that particular code as being block-oriented as most disks would be, for example. It is just byte-address and byte-length. We could do it block-wise and even include a CRC for each block (although I've never seen an error). Design decision to be made.
73,
Burns Fisher, WB1FJ *AMSAT**(R) **Engineering -- Flight Software*
On Fri, Nov 18, 2022 at 10:51 AM Burns Fisher (AMSAT) [email protected] wrote:
Wouldn't you think that would be an easy question to answer? Ha ha! On the TMS570, you set up "data formats" using HAL. Data format 1 is currently set up to 10MHz, and the others are set to 1MHz. Then tracking back through the code, the MRAM uses data format 1, so it is running at 10MHz. The DCT (Digital Communications Tranceiver, that is the AX5043) has its SPI at 1MHz. As I recall, I increased the MRAM speed largely because on Golf there was a lot more data being sent (the Whole Orbit Data) relatively regularly. I could look back at Fox, which saves much less data in MRAM, if you care.
Just a comment re the MRAM: It's only clock is the SPI Clock which says to me that the clock speed only makes a difference while there is communication on the bus. I'd think that would be a relatively small % of the time, right? Or am I really missing something?
73,
Burns Fisher, WB1FJ *AMSAT**(R) **Engineering -- Flight Software*
On Fri, Nov 18, 2022 at 10:07 AM Jim McCullers [email protected] wrote:
We need to address Pacsat memory considerations.
The MR25H40 is arranged as 8 x 512k bytes and is SPI. The higher capacity models are parallel interface that would significantly complicate the design and board space. In addition, they operate at much higher power consumption than the MR25H40.
With multiple MR25H40s there will de design issues with the file system when crossing memory bounds.
Burns or Rich, do you know what speed you are clocking the MR25H40? There is considerable difference in power consumption between clocking speeds of 1mhz and 40mhz.
Thanks
Jim McCullers WA4CWI
pacsat-dev mailing list -- [email protected] View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected] https://url.emailprotection.link/?buUg7YY4HZLXKo6ZKNudC8bRTBdOsBlAV5C9rq-aqxOQfa9Eqh8kfGK8xAPNkaYeV4y3Z5HVIEvNBaAimp_ZfFMwcw8QT0XZxGj2iXsHa3mcBRxu810JiHLaLtHS4Ej_7 To unsubscribe send an email to [email protected] Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org https://url.emailprotection.link/?bO71JCUf8Kb7txAlIoAarNqcIdQhyb8VQQIN4j0Gik24jnwI-Byk6ZVn92BYiD7Bxz61XZBoNoJE1TKqdfKnwFw~~
pacsat-dev mailing list -- [email protected] View archives of this mailing list at https://mailman.amsat.org/hyperkitty/list/[email protected] https://url.emailprotection.link/?buUg7YY4HZLXKo6ZKNudC8bRTBdOsBlAV5C9rq-aqxOQfa9Eqh8kfGK8xAPNkaYeV4y3Z5HVIEvNBaAimp_ZfFMwcw8QT0XZxGj2iXsHa3mcBRxu810JiHLaLtHS4Ej_7 To unsubscribe send an email to [email protected] Manage all of your AMSAT-NA mailing list preferences at https://mailman.amsat.org https://url.emailprotection.link/?bO71JCUf8Kb7txAlIoAarNqcIdQhyb8VQQIN4j0Gik24jnwI-Byk6ZVn92BYiD7Bxz61XZBoNoJE1TKqdfKnwFw~~
-- Chris E. Thompson [email protected] [email protected]
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
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
-
Bob Stricklin -
Burns Fisher (AMSAT) -
Chris Thompson -
Jim McCullers -
Mark L. Hammond