Protokoll:

self made downlink protokoll:

* intelligenter Image Dump
* Audio Memory Dump
* Image Bewertungs Index Dump
* Telemetrie und Counter Dump
* random Text-Message Dump (wenn Power da ist)

encapsulated in:
* CCSDS Frames
  GMSK (braucht ~10kHz Bandbreite)
* BPSK 1000 (QPSK 500)
* Turbo-Codec (if licencse allowed)
  Reed-Solomon

alt:
* Nix, raw data via FSK31 (or hither)
* Turbo-Phi-Code
* FX.25
* AX.25
(depends on content and configuration Flags)


Frame:
Option 1:
GMSK(CCSDS(Data,Reed-Solomon))
Option 2:
GMSK(CCSDS(TurboCode(Data)))
Option 3:
BPSK500(CCSDS(TurboCode(Data)))
Option 4:
BPSK500(CCSDS(Data,Reed-Solomon))
...



Protokoll:
Downlink:

+--------------------+-----------------+-------+
| Data Frame Type ID | Frame Type Data | CRC32 |
+--------------------+-----------------+-------+


Downlink Frame Types (Frame Type Data):
* Memory Area Dump Start (new DumpID (inc) , from Address)
* Random Text Message Start (new DumpID)
* Image Data Start Frame (new DumpID, Image ID, from Offset)

* DataDump (current DumpID, Packet ID, Data Length, Data))

* Image Metadata Single Frame (Image ID, file size, Quality Factor, DCT-Coefficients Mean, DCT-Coefficients StdDev, simplified rgb image historgram [3 colours * 64 division * 8 Bytes])

DataDump (current DumpID, Packet ID, Data Length, Data))
Image Metadata Single Frame\\(Image ID, Quality Factor, DCT-Coefficients Mean, DCT-Coefficients StdDev, simplified historgram)

Note:
 new DumpId with every "Start"-type frame. Only HARD requirement: dumpid must be different from previous dumpId
 PacketID increments with every frame and resets to 0 with "Start"-type frame
 DumpId ensures that DataDump streams can be differentiated if in-between StartFrame goes missing


most errors should be corrected by FEC
if Recieve Error of Frame still happens:
* rerequest memory area with offset
* rerequest ImageID (w/offset)
* rerequest whole Dump by explicitly repeating command (can't request dumpid since they are not meant to be uniqe)


Uplink Todo ??
 ?? ability to resend commands in queue before execute -> QueueSlots and "Insert Command into QueueSlot#" instead of "Append Command"
      contra argument: fading signal will propably wane slower than it takes to fill command queue. so sending full command queue multiple times is
      more likely to succeed than sending single commands multiple times.

Uplink Commands:
* Clear Command Queue
* Append Command WriteConfigArea (Data, CRC32)
* Append Command DumpMemoryArea (StartAddress, Length)
* Append Command WriteMemoryArea (StartAddress, Length, Data, CRC32)
* Append Command AppendNewTextMessage (Length, Data, CRC32)
* Append Command GetImageMetaData (from ImageID, NumImages)
* Append Command GetImage (ImageID, fromOffset, max Data to transmit or 0 for all data)
* Append Command Send Random Text Message
* Append Command WaitDuration and switch off transciever (Seconds)
* Append Command WaitUntil and switch of Transc (TimeOfDay)
* Execute Command Queue (Num Commands, ExecSeqNum, MAC(Full CmdQueue Contents incl Data . Num Commands . ExecSeqNum))


Note:
 Password should be random and 160 bit long
 MAC(x) = sha1(password . sha1(x . password))
 Satellite keeps track of highest last used ExecSeqNum and rejects lower
 Stored ExecSeqNum get's reset to 0 on CRX Reset-Settings

 single commands usually don't carry CRC checks, because they are only ever executed as a whole cmd queue.
 so it's enough to have integrity check in the last cmd. This also saves bandwidth.
 As a side effect, the amound of uplink data to be integrity checked becomes dynamic (i.e. on bad link, just send less commands at once)

To Consider:
 maybe CRC32 SHOULD be added to every Clear/Append command, and every append command should be ack in TTX,
 so it can be resend on transmission error and execute command has then higher chance of succeeding ?
 downside: uplink would be much much slower if (optional) we wait for TTX Acks
 upside: execute command has higher chance of executing

Never: substitute sha1 of individual crc32 with sha1 of whole contents in execute command


Attacks:

 Substitution Attack:
  should not be possible since MAC is calculated over full CmdQueue contents

 Repeat Attack:
  should be hard, because Nonces are not reusable, unlesss attacker also manages to reset cpu via dtmf

 Man-In-The-Middle Attack:
  no two way handshake, so no better than other attacks

 Brute Force:
  can capture uplink stream and brute fore password at home
  thus password should utilize full bit range and be sufficiently long e.g. 32 byte random number

 Denial Of Service:
  If password cracked, nonces can be used up
  Uplink Channel can be actively jammed
  Append Command can be inserted after our ClearCmdQueue, making sure ExecuteCmd won't suceed


To Consider:
 Does Arm Cortex M3 have enough speed/power for RSA | DSA | ECC-DSA ?








Msg Store/Forward Feature Wishes:
* Store Msg: Group(byte), Msg(bytes[])
* Get Msg: Group(byte), last_x_msgs(word)   (i.e. 9999 for all) 
* AutoBroadcast von Group 0 ???
* Schedule Random Broadcast of Msgs in Group: Group(byte), Time(TS)
-> AFU Store Forward Protokolle ???