Changes RSS

====== Differences ====== This shows you the differences between two versions of the page.

Link to this comparison view

projects:rc:rf:diy-transmitter [2011/02/06 11:19]
fishy Block diagram
projects:rc:rf:diy-transmitter [2011/02/06 12:38] (current)
fishy
Line 9: Line 9:
   * A modern transmitter should support features like mixing, dual-rates, exponential curves in a user-configurable environment. Feature-completeness is not required initially, but hardware for user interaction needs to be included from the start, and the architecture should allow for such software features. Some features will require dedicated hardware switches, like the dual-rate features. This requires additional inputs.   * A modern transmitter should support features like mixing, dual-rates, exponential curves in a user-configurable environment. Feature-completeness is not required initially, but hardware for user interaction needs to be included from the start, and the architecture should allow for such software features. Some features will require dedicated hardware switches, like the dual-rate features. This requires additional inputs.
   * Avoid feature-creep early on. The hardware should be small enough to premit being built into a "standard sized" Transmitter chassis (Common transmitters that are seen as "underfeatured", and very likely candidates for rebuild are e.g. Protec Avenger, Graupner MC12, Hitec Optic). Additional advanced features and I/O capabilities may be solved by the use of expansions, using expansion ports or data i/o bus systems (think Arduino-like, base module with plug-on features).   * Avoid feature-creep early on. The hardware should be small enough to premit being built into a "standard sized" Transmitter chassis (Common transmitters that are seen as "underfeatured", and very likely candidates for rebuild are e.g. Protec Avenger, Graupner MC12, Hitec Optic). Additional advanced features and I/O capabilities may be solved by the use of expansions, using expansion ports or data i/o bus systems (think Arduino-like, base module with plug-on features).
 +
 +===== Implementation ideas =====
 +
  
 {{ :projects:rc:rf:rc_tx_concept_block.png?500 |}} {{ :projects:rc:rf:rc_tx_concept_block.png?500 |}}
 +
 +==== Channel input module (CIM) ====
 +
 +Microcontroller with several A/D inputs and a set of additional digital inputs. Update-loop reads input values, converts and stores as in-memory representation of last read value. SPI based communication interface used by output module to query the last known value of each channel. Very simple uC software with onlye those two tasks: read and store input values, respond to channel value requests over SPI. All inputs should be considered to be possible channel values.
 +
 +==== User interface module (UIM) ====
 +
 +Handle display on LCD, input from a simplified user keypad (direction, enter, esc). All user interface menus etc. is generated bu this module. Should probably be a slave on the SPI bus, to avoid disturbing the processing on the Output module. Configuration and input-to-channel/mix mapping should probably be stored by this module, to free up resources on the output module.
 +
 +==== Output module (OM) ====
 +
 +Responsible for reading configuration/mapping from UIM, reading input values from CIM, calculating final channel values, and generation of result output waveform. For this module, timing is critical. This module should/must be the master for communication with modules, to ensure stable timing. Initial I/O requirements on the module is very low; SPI bus, Slave Select signals an a single fPWM output. This means that regardless of uC chosen, digital I/O lines will be available to perform parameter control inputs for Dual Rate and similar. This means that a set of function select inputs (not menu/UI inputs) should be handled directly by this module.
 +
 +===== Misc resources =====
 +
 +Futaba (and HiTec) PPM module interfacing
 +{{:projects:rc:rf:fp-tp-fm.gif?620|}}
 +http://www.thaltech.com/media/jon/FP-TP-FM.gif 
 +
 +