====== HGG: Backplane v1 Design Idea ======
===== Bus =====
  * Data (possibilities)
    * RS485 (Single master, Multi point)
    * CAN (Multi master)
  * Timing
    * PPS
    * High accuracy clock

===== Timing Bus =====

Information on the timing Bus can be found on the [[project:hgg:hardware:timing_bus]]-Article

===== Module <> Bus Interface =====

A high precision clock source (compensated VCXO or OCXO) is used to increment a counter which can cover the time of one second without roll-over.
The counter is reset via the PPS signal. Time since last PPS is thus tracked by the adder. To read the time the adder state is latched to a series of parallel-in/serial-out and then lazily clocked out to the uC.

Prototype implementation by [[leute:hadez]], [[leute:armin]] et al in shackspace


===== OSI-like Layer Model for Data Transfer ===== 

The groundstation should be as modular as possible. It should be possible to implemente different kinds of modules as 
  * Clock Sources (those feed the timing bus)
  * Position Sources (those can determine a position)
  * Data Sources (those receive data, eg HAMSAT, ADS-B, packet radio, information is highly timing critical)
  * Sensors (those also measure data, eg radiation, temperature and weather data, etc but are less timing critical)
  * Sniffer Modules (used for debugging or visualisation, just passively listen on the data bus)
  * Output modules (used for sending measured data / received data to a PC)

The current idea is to use RS485 as a data-bus that runs on the backplane of the station in parallel to the timing bus. 


==== Layer 1 ====

should be somthing like RS485 since this is implemented in most microcontrollers and for most FPGAs. 

Needs are:
  * modules can be enumerated (possibly chipselect)
  * transfers between two modules are possible
  * should use a fixed frame length (use finite state automaton for validity checking)


==== Layer 2 ==== 

layer 2 should be able to perform enumeration of modules, transferring data between two modules, define the frame format and 
a protocol number for selecting the information.

==== Layer 3 ==== 

data payload, defined for each module format, every module should support raading a config rom that contains information about the module in key/value pairs. Minimum information for a module is it's type, manufactor name, it's serial number and it's name. It should also be used to encode capabilities and calibration data as needed for the module. 
We could also think about giving out a module unique ID.

This part of the backplane is currently a TODO.

===== Module specification (formfactor, shielding, ...) =====