Data handling & packet format - PW-Sat2/PWSat2OBC GitHub Wiki
All experiments data are stored in non-volatile FLASH memory connected via SPI bus to OBC.
Storage is made with yaffs file system, providing abstraction layer of files in memory.
Each file is data from experiment or HK data (e.g. SunS experiment).
Maximum allowed payload to be send via AX.25 frame is 235 bytes, therefore is is necessary to provide mechanism to split experiment data into frames, which can be send to GS, as well as later discarded/retransmitted.
Frame formats are described here
Each FLASH bank is 16 MB. At this stage is it sure that on PLD board there will be no more than 8 memory banks. This leads to value of 128 MB accessible memory from OBC. Therfore, there is a limit of 571139 blocks in memory, which is ~ 2^19.
Communication window histogram is depicted above (Location: Warsaw 130 m a.s.l, Minimum elevation angle for satellite visibility: 30°, Omni-directional antenna).
Assuming longest communication session to be ~4 minutes and data rate of about 9600 bit/s and overhead of ~10% (AX.25) is was calculated that amount of data which could be send within one window is TBD kB.
Is is assumed that number of files will be less than 64 - so the number of 6 bits for APID was fixed.
The length of SEQ is just filling remaining bytes. 10 bits would be to less for one file (245 kB limit), so the value of 18 bits was chosen.
With this kind of block numbering GS can access every block in OBC memory to be transmitted.
Each block in memory will have its unique pair of (APID, SEQ) - so even in case of packet loss during transmission GS can ask OBC to re-send particular block.
It is proposed to add following telecommands:
- Parameters: APID + first and last block to be send (block range)
- Reponse: ACK + following blocks from memory.
With this telecommand GS can automatically ask for particular block in case of packet loss (due to e.g. random noise).
Inside files on FLASH memory data from measurement channels has to be stored.
It was proposed to hold each values in each block as (key, value) pairs:
|
|
|
... |
This will induce very large overhead, but it is considered as most reliable and easy to code solution.
Each measurement channel ID will be unique number, meaning one telemetry channel in the whole satellite.
Most probably ID will be two bytes long, because it is thought that there will be more that 255 channels.
But, if many data channels could be merged into one ID (e.g. 3 gyro axis send with 1 byte ID and 3*n bytes value) changing to 8 bit ID could be concidered.