path: root/doc/protocols/ground-rxtx.txt

Features Needed:

* Download Images
* Download Piezo Sample Data
* Broadcast Messages (random or sequential)


Features Nice To Have:
* Download additional Telemetry
* Store and Forward Messaging
* Choose Best Image before Download


Additional Telemetry Information not included in TTX Beacon:
* RTC current time


Protocol Features Needed:
* scheduling broadcasts @time | @geolocation
* start download now



• VHF, 144-146MHz, Bmax = 18kHz
• UHF, 434.79-438MHz, Bmax = 30kHz
Due to the constraints imposed by the payload



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 ???



= Layers =

=== Physical Layer ===
GMSK NRZ-I 
=== Data Link Layer ===
HDLC / AX.25
=== Network Layer ===
(AX.25)
=== Transport Layer ===
(AX.25)
=== Session Layer ===
BC2P
=== Presentation Layer ===
BC2P
=== Application Layer ===
BC2P





= Optional HDLC + Custom or AX.25 = 

Both options are encapsulated within a synchronous HDLC Frame.

Data-Stream-Start-Flag: 01111110 
Data-Stream-End-Flag  : 01111110
Frame-Separator-Flag  : 01111110

If the Start/End-Flag sequence should occur withing the data-stream, bit-stuffing is applied.
I.e. On the sender side, after 5 consecutive 1s of data one 0 is appended.
     On the reciever's side, 5 consecutive 1s followed by one 0 is transformed to 5 consecutive 1s aka the 0 is removed.

e.g.
1010 1010 0100 1111 1111 1100
might be transformed into the following 2 frames
01111110 1010 1010 0100 01111110 1111 1011 1110 00 01111110


=== Option1: HDLC based custom framing (less overhead) ===

Content Types Bit Field:
3 orthogonal bit pattern values:
110  Data encoded with FEC scheme
011  Data only
101  separate FEC data



=== Option2: AX.25 Framing (more compatibility) ===


    .------------------------------------------------------------------------.
    . StartFlag | Address      | ControlInfo |  Data    | CRC     | StopFlag .
    .------------------------------------------------------------------------.
    . 01111110  | 112/224 bits | 8/16 bits   | n*8 bits | 16 bits | 01111110 .
    '------------------------------------------------------------------------'


= BC2P =

BC2P is the Bernhard Christian Patrick Protocol




Open Questions:
* frame bits !!
* maximum Frame length ????
* think it through..
* describe it properly
* bandbreite basisbandsignal gmsk
* bandbreite fertiges signal
* Layers ?
* ...