Wiki porting bedtime dump II (#86)

* add error codes

* added to HOWTO Get Running

* convert some pages

* Frankenstein etc.

* Frankenstein pinout

* Prometheus

* More Prometheus

* more changes

* more pages

* a bunch more

* a bunch more

* a few more pages

* a few more pages

All_Supported_Triggers.md

@@ -1,6 +1,10 @@
 
 See also [Trigger](Trigger)
 
+To change your trigger settings, open TunerStudio, Engine->Trigger Configuration
+
+Dev note: unit_tests executable produces triggers.txt file - gen_trigger_images.bat reads triggers.txt and produces these .png files. TODO: automate this further?
+
 May, 2020: Subaru SVX added
 
 ![x](https://rusefi.com/images/triggers/trigger_49.png)
@@ -11,4 +15,174 @@ April, 2020: Honda K 12+1 added.
 
 April, 2020: Renix 44-2-2 added.
 
-![x](https://rusefi.com/images/triggers/trigger_44.png) 
+![x](https://rusefi.com/images/triggers/trigger_44.png) 
+
+## Universal skipped wheel
+A basic wheel - assumes equally spaced teeth with a number of missing teeth.
+Tuner studio allows up to 500 teeth with 500 missing - functional limits are not tested.
+
+## One tooth
+
+![One Tooth](Images/trigger_18.png)
+
+## 36/2/2
+
+![36/2/2](Images/trigger_23.png)
+
+## Dodge Neon 1995
+
+![Dodge Neon 1995](Images/trigger_2.png)
+
+## Dodge Neon 1995 only crankshaft sensor
+
+![Dodge Neon 1995 crank only](Images/trigger_39.png)
+
+## Dodge Ram
+
+![Dodge Ram](Images/trigger_19.png)
+
+## Dodge Neon 2003
+Chrysler NGC 4 cylinder
+
+![Dodge Neon 2003](Images/trigger_14.png)
+
+## Dodge Stratus
+Chrysler NGC 6 cylinder
+
+![Dodge Stratus](Images/trigger_22.png)
+
+## Ford Aspire
+
+![Ford Aspire](Images/trigger_1.png)
+
+## GM 7x
+
+![GM 7x](Images/trigger_5.png)
+
+## Mazda Protege SOHC
+
+![Mazda Protege SOHC](Images/trigger_7.png)
+
+## Mazda Miata NA
+
+![Mazda Miata NA](Images/trigger_3.png)
+
+## Mazda Miata NB1
+
+![Mazda Miata NB1](Images/trigger_4.png)
+
+## Mazda Miata NB2 VVT
+
+![Mazda Miata NB2 VVT](Images/trigger_33.png)
+
+## Mazda Protege 1993 DOHC
+
+![Mazda Protege 1993 DOHC](Images/trigger_15.png)
+
+## Mitsubishi
+
+![Mitsubishi](Images/trigger_11.png)
+
+## Nissan
+
+360 slot trigger not ready yet, no test vehicles :(
+
+![Nissan](Images/trigger_24.png)
+
+## Universal 36/1
+
+![36/1](Images/trigger_9.png)
+
+## Universal True 60/2
+
+If you also have a CAM sensor somewhere see https://rusefi.com/wiki/index.php?title=Manual:Software:VVT
+
+![60/2](Images/trigger_8.png)
+
+## 1 + 60/2
+
+Please use this one only if your CAM sensor position matches this picture exactly. For a CAM which does not match this picture exactly, see above for universal 60/2 with cam input.
+
+![1+60/2](Images/trigger_17.png)
+
+## VW 60/2
+VW special understanding of 60/2 with a wide tooth instead of of just missing tooth.
+
+See also https://rusefi.com/wiki/index.php?title=Manual:Software:Trigger#Universal_True_60.2F2
+
+![VW 60/2](Images/trigger_20.png)
+
+## Toyota 2JZ
+
+3/34 version
+
+![Toyota 2JZ 3/34](Images/trigger_25.png)
+
+1/12 version
+
+![Toyota 2JZ 1/12](Images/trigger_29.png)
+
+## GM LS 24 tooth
+
+![GM LS 24](Images/trigger_27.png)
+
+## Subaru 7+6 tooth
+
+![Subaru 7+6](Images/trigger_36.png)
+
+## Jeep 18-2-2-2
+
+![Jeep 18-2-2-2](Images/trigger_37.png)
+
+## Honda 1+24
+
+![Honda 1+24](Images/trigger_21.png)
+
+## Honda 4+24
+
+![Honda 4+24](Images/trigger_12.png)
+
+## Honda 1+4+24
+
+![Honda 1+4+24](Images/trigger_13.png)
+
+## Honda CBR600
+
+![Honda CBR600](Images/trigger_28.png)
+
+## Unknown trigger type
+
+Manual:Software:UnknownTrigger
+
+
+TODO: implement a feature so that trigger could be defined via TunerStudio
+
+
+If your have an unknown or an unsupported trigger shape, once you've confirmed that trigger events are getting into the software (see "troubleshooting" sections) you need to crank your engine while rusEfi console is connected with Engine Sniffer tab active.
+
+With long enough cranking you should get a visual log of your trigger signal, that would give you some idea of what kind of trigger shape you have. Save an image and post it on a forum. It's recommended to remove spark plugs while investigating trigger shape to make your cranking more even.
+
+Once preliminary shape of a new trigger is added into rusEfi firmware based on the Engine Sniffer image, second step is getting a more precise recording of the shape with exact angles. This is done with spark plugs removed and Sensor Sniffer mode set to TRIGGER. With long enough cranking a chart of trigger shape would appear on the Sensor Sniffer tab and the console log file (see out/ folder next to rusefi console binaries) would contain the angles. Please post this log file on the forum for the developers to encode the new trigger shape into the software.
+
+## How this works
+
+Trigger decoding cycle starts at 'synchronization point' - that's the trigger fall or rise event which satisfies the 'synchronization gap' condition. Since trigger synchronization point usually has nothing to do with top dead center #1 (TDC), we have have 'globalTriggerAngleOffset' parameter - that's the offset between synchronization point and TDC.
+
+For example, 'set global_trigger_offset_angle 0', TDC is set to synchronization point, the green vertical line is TDC mark:
+
+![Offset Angle 0](Images/offset_0.png)
+
+Now the real TDC, 'set global_trigger_offset_angle 175' command:
+
+![Offset Angle 175](Images/offset_175.png)
+
+Note the different location of the green TDC line. Also note how all Injector #1 pulse has moved (injector #3 is the lowest signal on these pictures) - that's because ignition and injection are scheduled based on TDC point.
+
+While running ignition is controlled by ignition timing map, you can also offset the whole ignition timing map using 'set ignition_offset' command. Ignition dwell is controlled by dwell time curve.
+
+Injection could be offset using 'set injection_offset X' command.
+
+While cranking, you can set angle-based ignition instead of timing map & dwell based ignition. In angle-based mode, dwell is defined in crankshaft angle duration and timing is constant. set cranking_charge_angle and set_cranking_timing_angle.
+
+
+See 'trigger decoding' in http://rusefi.com/docs/html/

Bluetooth.md

@@ -0,0 +1,5 @@
+== HC-06 Bluetooth Module serial RS232 TTL ==
+
+On start, HC-06 accepts AT commands @ 9600.
+
+the default pin is 1234

Breakout-Module.md

@@ -0,0 +1,49 @@
+## Summary
+
+This page is a general guide and general outline of how to use the breakout module. The breakout module allows you to replace an engine control unit wire by with using fuses as jumpers.
+
+![Breakout](Images/breakout.png)
+
+## Move a engine control to rusEFI
+Uses breakout module noted here http://rusefi.com/forum/viewtopic.php?f=4&t=454 This is an example of how you might move the wires, it may not work for you exactly this way, but this at least lays out the general process. For example, some setups connect all fuel channels to one ECU fuel channel. So you might need to do thing differently when trying to move one fuel channel as noted below. Items like that can vary. 
+
+### Capture RPM signal
+
+* Cut OEM harness for the crank angle wire(s), put the leads to the breakout module, use the fuse to simple pass the signal through the breakout module, and verify that the OEM engine is operational. 
+* Connect rusEFI cam and/or crank to breakout module.
+* Install 2nd fuse to connect both OEM control unit and rusEFI. Take note that VR signals may be loaded and may be problematic at low RPM with this approach. Or it may simply work. Give it a try and see what happens. If it doesn't start with both connected, try starting the engine with rusEFI jumper removed, then after started install rusEFI jumper. 
+* Capture crank signals via dev console. [http://rusefi.com/wiki/index.php?title=Manual:Software:User/en#Dev_Console dev console]
+* Either configure rusEFI to use the proper crank decoder, or get a decoder developed from the dev console logs, then configure rusEFI to use the proper decoder. 
+* See reliable RPM values displayed on the gauge, and noise free crank signals.
+
+### Capture MAP or MAF signal
+
+* Cut OEM harness for the MAP or MAF wire(s), or install a MAP sensor, then put the leads to the breakout module, use the fuse to simple pass the signal through the breakout module, and verify that the OEM engine is operational. 
+* Connect rusEFI analog signal to breakout module.
+* Install 2nd fuse to connect both OEM control unit and rusEFI. Take note that the signal may be loaded and may be problematic with this appraoch. Or it may simply work. Give it a try and see what happens. 
+* Capture MAF or MAP signals via dev console.
+* See reliable MAF or MAP values displayed on the gauge, and noise free signals.
+
+### Move one fuel channel
+
+* Cut OEM harness for one fuel channel and connect it to the breakout module. With OEM connections, verify the breakout module operates as expected on the OEM setup. 
+* Connect rusEFI fuel channel to breakout module.
+* Remove fuse for OEM fuel channel and put it on rusEFI fuel channel. This can be done with running engine, but keep in mind no fuel means no power on that cyl, it will run a bit rough.
+* Connect via tuner studio, and tune your fuel channel until the engine runs smoothly. (You may be able to connect the rusEFI analog signals to the fuel channels and measure that you are generating the same fuel pulse.) 
+* Continue until you have fuel control for one channel that matches perfectly for the entire RPM, loads, ect. 
+
+### Move one ignition channel
+
+* Cut OEM harness for one ignition channel and connect it to the breakout module. With OEM connections, verify the breakout module operates as expected on the OEM setup. Beware, ignition signals on the primary side of the coil can get in excess of 500V, you need to capture signal level signals, not the primary side of the coil. The coil primary will destroy the discovery. The discovery board needs an igntor to drive the primary side of the coil. 
+* Connect rusEFI ignition channel to breakout module.
+* Remove fuse for OEM fuel channel and put it on rusEFI fuel channel. This should be done when the engine is off. Moving this wire when operational will likely damage the ignition system.  
+* Connect via tuner studio, and tune your ignition channel until the engine runs smoothly. (You may be able to connect the rusEFI analog signals to the  channels and measure that you are generating the same fuel pulse.) 
+* Continue until you have fuel control for one channel that matches perfectly for the entire RPM, loads, ect. 
+
+### Move all fuel and ignition
+* Cut and move fuel channels one at a time moving them to rusEFI via break out module.
+* Cut and move ignition channels one at at time moving them to rusEFI via breakout module. 
+* Remove MAP and crank signals from OEM controller. 
+
+### Have a rusEFI party
+* Party time as you now have rusEFI, save this OEM tune and feel free to share the tune for other developers and other project to reference. 

CAN-Sniffer.md

@@ -0,0 +1,70 @@
+## HOWTO use custom build of rusEfi for CAN bus sniffing
+
+In this HOWTO I will explain how to see raw CAN message flow with less than $30 in hardware & some free software.
+
+## Step 1: shopping cart
+
+1. Get an [http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/PF252419 STM32F4DISCOVERY] micro-controller board - there are 'Order Now' buttons at the bottom of the official page.
+
+![STM32F4Discovery](Images/2014-08-21T15-20-24.645Z-stm32f4_discovery.jpg)
+
+2. Get an [http://www.wvshare.com/product/SN65HVD230-CAN-Board.htm SN65HVD230 CAN Board]
+
+![SN65HVD230 CAN Board](Images/sn65hvd230-can-board_l_1_5.jpg)
+
+3. Get a "OBD2 16-Pin Male to Female Diagnostic Extension Cable" on eBay
+
+![OBD2 16 Pin Male to Female Diagnostic Extension Cable](Images/OBD2_16_Pin_Male_to_Female_Diagnostic_Extension_Cable.jpg)
+
+4. Get a microUSB cable (one which comes with any Android phone)
+
+## Step 2: putting hardware together
+
+Cut the OBD extension cord into two pieces, we would need the part with the male connector. Find the wires for pins #6 and #14
+
+![OBD2 Connector Pinout](Images/obd2_connector.png)
+
+Run some wires from these pins to CANH (high) and CANL (low) screw terminals of the can module.
+
+Here is how the end result should look like:
+
+![CAN hardware end result](Images/CAN_hardware.png)
+
+Ignore the white wire - we do not need it.
+
+Run female-female jumper wires to connect TX on the CAN module with pin PB6 on the discovery board. RX on the module to pin PB12. GND to GND. +3v to +3v.
+
+Hardware is ready!
+
+![CAN hardware attached to Discovery](Images/CAN_hardware2.png)
+
+## Step 3: software
+1. Download and install [http://www.st.com/web/en/catalog/tools/PF258168 STSW-LINK004 STM32 ST-LINK utility]
+
+2. Firmware: download and unzip [http://rusefi.com/images/forum_posts/CAN/rusefi_can_sniffer.zip rusefi_can_sniffer.zip]
+
+2. Uploading the firmware: Connect stm32f4discovery to your laptop using a mini-USB cable (one should come with the board), install driver, start St-Link Utility.
+![ST Link Utility](Images/st_link_utility.png)
+
+click 'Target'>'Program...'
+
+![ST Link Start](Images/st_link_start.png)
+Point the utility to the rusefi_can_sniffer.hex file and hit 'Start'
+
+Close ST Link Utility.
+
+3. Now it's time to connect the micro USB cable. Keep miniUSB cable connected - you should have two USB cables connected. When you do this for the first time your Windows would prompt for drivers, you should download & install [http://www.st.com/web/en/catalog/tools/PF257938 virtual COM driver]
+
+Once the driver is installed, you can verify serial connectivity by opening your Device Manager - we are expecting to see a Virtual COM Port.
+![Device Manager](Images/device_manager.png)
+
+Remember the number of the COM port.
+
+4. Download and launch [http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html Putty] telnet application.
+
+![Putty](Images/putty.png)
+
+![CAN hardware attached to laptop](Images/CAN_hardware3.png)
+
+Now connect the obd connector to your vehicle and you should see the CAN messages flowing in putty.
+![CAN messages on computer screen](Images/CAN_end_result.jpg)

CL4490

@@ -0,0 +1,16 @@
+https://www.lairdtech.com/products/cl4490-series
+
+Support 800-492-2320 ext 3
+
+Power supply connector: OD 5.5mm/ID 2.8mm Adaptaplug "O" enercell 273-346
+
+For device firmware update Configuration Utility should be the tool.
+
+CTS/RTS recommended by support, DCD being required is a surprise.
+
+http://rusefi.com/forum/viewtopic.php?f=4&t=1226&hilit=rs232#p25672
+
+======================
+Product: CL4490 automatically switch to AC4490 on "Read Radio"
+======================
+Configuration/Test Utility can "open" port without radio attached

Console.md

@@ -1,5 +1,7 @@
 ## Gauges
 
+![Console Gauges](Images/java_console_1.png)
+
 ## Analog Chart
 
 You can sniff either trigger angles or MAP values. 

Cranking.md

@@ -150,6 +150,8 @@ To adjust cranking fuel, use ```set cranking_fuel XXX``` command, where XXX is t
 
 *If set to true, will use the specified duration for cranking dwell. If set to false, will use the specified dwell angle. Unless you have a really good reason to, leave this set to true to use duration mode.*
 
+*rusEFI Console command:
+```set cranking_charge_angle X```*
 
 ## IAC Settings
 ### Cranking IAC position

Dev-Console-Commands.md

@@ -0,0 +1,281 @@
+## Tuner Studio
+
+|Command|Number Of Parameters|Description|
+|-|-|-|
+|tsinfo|0 |Prints TunerStudio communication summary|
+|set_ts_speed|1 |Sets Tuner Studio communication speed. For example, `set_ts_speed 115400`|
+|reset_ts|0 |Resets TunerStudio debugging counters|
+
+## CAN
+|Command|Number Of Parameters|Description|
+|-|-|-|
+|caninfo|0 |Shows stats for CAN subsystem|
+|enable can|0 |Enable CAN hardware. Also `disable can`|
+|enable can_read|0 |Enable reading/sniffing CAN commands with echo. Also `disable can_read`|
+|enable can_write|0 |Enable sending out gauge info via CAN according with selected CAN configuration. Also `disable can_write`|
+
+## Knock Detection
+|Command|Number Of Parameters|Description|
+|-|-|-|
+|enable HIP9011|0|Enables HIP9011 driver|
+|enable tpic_advanced_mode|0|Enables TPIC advanced (digital) mode|
+|enable knockdebug|0|Verbose mode|
+|hipinfo|0|Shows HIP9011 driver state|
+|set_gain|1|Sets HIP gain parameter, betweb 0.1 and 2. New value would be applied on the fly|
+|set_band|1|Sets HIP target frequency, in kHz. New value would be applied on the fly|
+|set_hip_prescalerandsdo|1|Sets HIP prescaler and SDO. 0 for 4mHz, 6 for 8mHz|
+
+## General
+|Command|Number Of Parameters|Description|
+|-|-|-|
+|adc|1 |
+|adcDebug|1|
+|appendToLog|3|
+|chart|1|
+|chartsize|1|Sets the size of engine sniffing buffer in ECU. Nothing would change on your screen until a new larger packet of engine sniffing would arrive from ECU.|
+|get date|0 |Gets current real time clock|
+|set date XXX|1|XXX is time in seconds sins Unix epoch - see http://www.epochconverter.com|
+|echo|1|Just prints out the parameter - this is useful for troubleshooting connectivity|
+|fatal|0 |This command would cause the firmware to halt. I am not sure that you want to try this one :)|
+|fadc|0|
+|faststat|0 |
+|fl|1 |'full logging', Turns-off constant dev console data output. fl 1 would turn it back on. |
+|gfc|1|
+|gpsinfo|0 |
+|help|0|Prints the list of supported commands|
+|hello|0|Prints the version of firmware|
+|i2c|5|
+|injector|5|
+|ls|3|
+|mountsd|0|
+|performance info|0| [[Development:Software:performance#Event_handling]]|
+|readconfig|0 |read config from flash/EEPROM|
+|resetconfig|0|Resets configuration to default|
+|set ignition_offset|1|
+|set_analog_chart_mode|1 |
+|set cranking_rpm|1|Sets the RPM level at which we consider the engine to be cranking - not running|
+|rpm|1| For example, rpm 1200 sets the RPM for built-in position sensor simulator|
+|set engine_type|1 |This will change the configuration from the default Dodge Neon configuration.<br>You should reboot the firmware after changing engine type.<br>Hit the reset button or just power off/on the microcontroller.|
+|set global_trigger_offset_angle|1|Change the offset between trigger sync point and TDC#1|
+|sfm|5|
+|showconfig|0|Shows current configuration stored in the flash memory - that's where you can see your current fuel map etc.|
+|status|0 |
+|testmath|1|
+|threadsinfo|0 |list of ChibiOS threads|
+|umountsd|0 |Un-mount SD/MMC card|
+|writeconfig|0|Write config to flash (you only need this if you have used one of the 'setXXX' commands) TODO: implement a feature of not actually writing changes into flash while engine is running since flash writes freeze the CPU. TunerStudio burn has this feature of delayed until engine is stopped burn already.|
+|wm|5|
+|get_int, get_short, get_float|1|prints the configuration value at given offset|
+|set_int, set_short, set_float|2|changes configuration value at given offset, for example set_float 102 1.23|
+
+## Logging
+|Command|Number Of Parameters|Description|
+|-|-|-|
+|sdinfo|0 | Prints a report of SD/MMC usage|
+|umountsd|0 | Un-mount SD card|
+|enable sd/disable sd|0 |
+
+## Trigger
+Trigger is the camshaft or/and crankshaft position sensor(s)
+
+`triggerinfo`
+shows some info regarding trigger situation
+
+
+set global_trigger_offset_angle XX
+
+sets global trigger offset from synchronization point of trigger decoder to actual TDC #1
+
+TODO? rename command? rename variable?
+
+`enable/disable trigger_only_front`
+
+In 'only front' mode, only signal rises are used for trigger decoding. For example, `enable trigger_only_front`
+
+`enable/disable trigger_details`
+
+Trigger details additional output helps with troubleshooting trigger synchronization issues.
+
+`trigger_shape_info`
+
+Prints trigger shape definition
+
+## Sensors
+
+|analoginfo|0|Shows ADC intut values|
+|tempinfo|0| prints out some debug information on CLT and IAT sensors|
+|tpsinfo|0| prints out some debug information on TPS sensor|
+|mapinfo|0| prints out some debug information on MAP sensor|
+
+## Board Control
+set_injection_pin: 2 parameters: index, PIN
+
+For example, 
+set_injection_pin 1 PB7
+
+set injection_pin_mode: 1 parameter
+
+For example, 
+
+`set injection_pin_mode 1`
+
+Currently four modes are supported:
+
+OM_DEFAULT = 0 (GND for logical OFF, VCC for logical ON)
+and
+OM_INVERTED = 1 (GND for logical ON, VCC for logical OFF)
+
+OM_OPENDRAIN = 2
+OM_OPENDRAIN_INVERTED = 3
+
+set ignition_pin_mode: 1 parameter
+
+set idle_pin_mode: 1 parameter
+
+For example, 
+
+set idle_pin_mode 1
+
+set fuel_pump_pin_mode: 1 parameters, 
+
+set malfunction_indicator_pin_mode: 1 parameters,
+
+## Fuel Control
+See also http://rusefi.com/wiki/index.php?title=Manual:Software:Fuel_Control
+
+set_whole_fuel_map: 1 parameter: global value for the whole fuel map, in ms
+
+for example, `set_whole_fuel_map 11`
+
+set_fuel_map: 3 parameters
+For example `set_fuel_map 2200 4 15.66`
+Set 15.66ms value for 2200 rpm @ engine load 4
+
+set cranking_fuel: 1 parameters, for example
+
+`set cranking_fuel 5`
+
+
+set injection_offset: 1 parameter, for example
+
+`set injection_offset 80`
+
+Sets global fuel injection phase to 80 degrees after TDC.
+
+## Alternator Control
+`altinfo`
+Prints current alternator state
+
+`set alt_p X`
+
+for example, `set alt_p 10`
+
+`set alt_offset X`
+
+Set's alternator duty cycle offset. For example, `set alt_offset 10`
+
+`set alt_t X`
+
+for example, `set alt_t 100` (100ms PID time)
+
+`set_alternator_pin PIN`
+
+for example, `set_alternator_pin PE10`
+
+`enable/disable altdebug`
+
+for example, `enable altdebug`
+
+`enable/disable altcontrol`
+
+for example, `disable altcontrol`
+
+`set targetvbatt X`
+
+## Acceleration Enrichment
+
+set engine_load_accel_len X
+for example, `set engine_load_accel_len 6` Look back at MAP for period of last X injections.
+
+set engine_load_accel_multiplier X
+for example, `set engine_load_accel_multiplier 2.0` This coefficient controls how much extra fuel we inject during acceleration due to MAP change
+
+
+set engine_load_accel_threshold X
+for example, `set engine_load_accel_threshold 5.0` Ignore change below X kPa
+
+
+set tps_accel_len X
+for example, `set tps_accel_len 6` Look back at TPS for period of last X injections.
+
+set tps_accel_multiplier X
+for example, `set tps_accel_multiplier 2.0` This coefficient controls how much extra fuel we inject during acceleration due to TPS change
+
+
+set tps_accel_threshold X
+for example, `set tps_accel_threshold 10` Ignore change below X % tps
+
+See http://rusefi.com/wiki/index.php?title=Manual:Software:Fuel_Control#delta.28TPS.29
+
+set suckedOffCoef 0.4
+set addedToWallCoef 0.2
+
+See http://rusefi.com/wiki/index.php?title=Manual:Software:Fuel_Control#wall_wetting
+
+## Timing Control
+
+set global_trigger_offset_angle: 1 parameter: global TDC offset from trigger synchronization point
+
+set_whole_timing_map: 1 parameter: global timing for the whole timing map while engine is running
+
+set_timing_map: 3 parameters. timing map value for given RPM and engine load
+For example `et_timing_map 2200 4 60`
+sets timing to 60 degrees advance for rpm 2200 and engine load 4
+
+set cranking_timing_angle: 1 parameter
+sets timing advance while cranking
+
+set fixed_mode_timing: 1 parameters,
+
+set timing_mode: 1 parameters,
+
+## Idle Control
+
+See also http://rusefi.com/wiki/index.php?title=Manual:Software:Idle_control
+
+set idle_rpm PRM
+
+Set's target idle RPM
+
+`set idle_position X`
+
+set's idle duty cycle, value between 0 and 100, for example `set idle_position 50`
+
+enable/disable stepperidle
+
+for example, `enable stepperidle`
+
+
+**blipidle X Y**
+overrides idle position to X for Y duration of time
+
+for example `blipidle 20 2000` would set idle position to 80 for 2000 ms / 2 seconds
+
+## I/O testing
+
+|Command|Number Of Parameters|Description|
+|-|-|-|
+|fuelpumpbench|0|Turns fuel pump on for three seconds after a one second delay|
+|fuelbench2|5|for example, fuelbench2 10000 1 2 1200 3<br> This command would send out a series of 3 on/off squirts out to injector #1, on time: 2ms, off time: 1200ms, after a 10000ms (10 seconds) delay|
+|fuelbench|3|for example, fuelbench 5 2000 4 <br> This command would send out a series of 3 on/off squirts out to injector #1, on time: 5ms, off time: 2000ms|
+|fuelbench2|5|for example, fuelbench2 1000 2 9 200 10<br> This command would send out a series of 10 on/off squirts out to injector #2, on time: 9ms, off time: 200ms, after a 1000ms delay|
+|sparkbench|3|for example, sparkbench 5 200 3 <br> This command would send out a series of 3 on/off squirts out to coil #1, on time: 5ms, off time: 200ms|
+|sparkbench2|5|for example, sparkbench2 1000 2 4 200 10<br> This command would send out a series of 10 on/off squirts out to coil #2, on time: 4ms, off time: 200ms, after a 1000ms delay|
+|fanbench|0|Turns radiator fan on for three seconds after a one second delay|
+|milbench|0|Turns MIL on for three seconds after a one second delay|
+
+## Engineering support
+
+|Command|Number Of Parameters|Description|
+|-|-|-|
+|enable self_stimulation|0|Routes simulated trigger signal directly into trigger processing logic|

Dev-Console-Implementation.md

@@ -0,0 +1,32 @@
+## human readable protocol
+
+A typical line in rusEfi human-readable protocol look like
+
+`line:16:rpm,100,maf,3.3,`
+
+Here `line` is a magic prefix, `16` is the length of the payload, and the payload `rpm,100,maf,3.3,` is a comma separated list of keys and pairs, let's call this "a line of known length"
+
+As for sending commands to rusEfi, there are two options
+
+a) plain unwrapped command, for example
+
+`rpm 800<end of line>`
+
+b) a command with specified length (this case the firmware can validate the command):
+
+`sec!7!rpm 400<end of line>`
+
+Pretty much same was as with data coming from rusEfi, we have a prefix `sec` and `7` for the payload length.
+TODO: unify `line` and sec `one` day?
+
+## java classes
+Incoming data workflow:
+
+transport layer pushes data into EngineState.processNewData() which splits the data into jeys and value, pushing this data into the primary listener for
+the specified key. The main listener is SensorCentral which keeps track of 'Sensor' values and listeners. Another interesting key-value consumer is MessagesCentral which takes care of all the human-readable messages which end up in Messages UI console..
+
+
+Outgoing data flow:
+Outgoing data flow:
+
+CommandQueue is the class which takes care of sending commands, making sure a confirmation is recieved and re-trying outgoing data transfer if needed.

Error-Codes.md

@@ -0,0 +1 @@
+See https://github.com/rusefi/rusefi/blob/master/firmware/controllers/algo/obd_error_codes.h 

Frankenso-Hall-Input.md

@@ -0,0 +1,29 @@
+## Typical Hall
+
+For example, Mazda distributor sensors.
+
+![Frankenso setup for Mazda Hall sensor](Images/frankenso_set_for_Mazda_Hall.jpg)
+
+![Frankenso Trigger Pins](Images/Frankenso_trigger_pins.png)
+
+See http://rusefi.com/wiki/index.php?title=Manual:Hardware_Frankenso_board#Default_Pinout
+
+Use Trigger #1 N for first sensor signal & Trigger #2 N for second trigger with 1K pull-up configuration
+
+Leave Trigger #1 P & Trigger #2 P wires disconnected
+
+## Bench testing Mazda Hall
+ 
+Test 1.1: Expected resistance between +5v wire and Trigger #1 N wire: 1K (See http://rusefi.com/wiki/index.php?title=Manual:Hardware_Frankenso_board#Default_Pinout)
+
+Test 1.2: Expected resistance between +5v wire and Trigger #2 N wire: 1K
+
+Test 1.3: ground/unground Trigger #1 N wire, should see event counter in `triggerinfo` go up
+
+Test 1.4: ground/unground Trigger #2 N wire, should see event counter in `triggerinfo` go up
+
+Goto board info: http://rusefi.com/wiki/index.php?title=Manual:Hardware_Frankenso_board#VR_Input
+
+
+
+PS: technically MAX9926 is not really needed for Hall processing, two channels on the op-amp would do the job just fine and Frankenso has all the jumpers provisioned to make this happen on channels #9 and #11. See http://rusefi.com/wiki/index.php?title=Manual:Hardware_Frankenstein_board/ru#Step_2a:_Hall_sensor_input

Frankenso-VR-Input.md

@@ -0,0 +1,26 @@
+## Typical VR application
+
+For example, 1995 Honda Accord (and most OBD-I Honda vehicle), 2003 Dodge Neon.
+
+![Frankenso set for VR](Images/frankenso_set_for_VR.jpg)
+
+Use Trigger #1 N & Trigger #2 N wires with 0R pull-down configuration for sensor(s) negative side
+
+Use Trigger #1 P & Trigger #2 P wires for sensor(s) positive side
+
+## Bench testing VR configuration
+
+Test 2.1: Expected ground on Trigger #1 N wire
+
+Test 2.2: Expected ground on Trigger #2 N wire
+
+Test 2.3: take an AA or AAA battery, connect Battery+ to Trigger #1 N wire, touch battery- with Trigger #1 P wire a couple of times. 
+Then flip the battery and hold Battery+ to Trigger #1 P and touch Battery- with Trigger #1 N wire.
+Should see event counter in ''triggerinfo'' go up
+
+Test 2.4: take an AA or AAA battery, connect Battery+ to Trigger #2 N wire, touch battery- with Trigger #2 P wire a couple of times. 
+Then flip the battery and hold Battery+ to Trigger #2 P and touch Battery- with Trigger #2 N wire.
+Should see event counter in ''triggerinfo'' go up
+
+
+Goto board info: http://rusefi.com/wiki/index.php?title=Manual:Hardware_Frankenso_board#VR_Input

Fuel/Fuel_Control/Fuel-Overview.md

@@ -2,7 +2,7 @@
 
 The Air Fuel Ratio (AFR) is controlled by how much fuel is delivered to the cylinder for combustion. There are many factors and many sensors that come into play when trying to determine how much O2 is in the cylinder. rusEFI collects this information and makes a guess about how much O2 is in the cyl, then rusEFI has to determine how much fuel is needed to get the expected AFR and deliver that fuel charge. Below is a graphic that shows some common differences in AFR for a particular Toyota engine. Other engines are similar to this, but may have a different peak power area, or peak efficiency area, etc. To know this information for your particular setup you would need to run it on a Dyno, and determine the exact AFR's.
 
-![Airfuel](Airfuel.jpg)
+![Airfuel](Fuel/Fuel_Control/Airfuel.jpg)
 
 Most people who are installing tune-able ECU's like rusEFI are looking for more power at the track. However your fuel weight advantage is also commonly important. So it is common that an engine will be tuned for peak power when over a certain load, and peak economy when at a cruise load. OEM's are often concerned with minimal environmental impact, so they may tune to a different AFR. Once you have decided on what your AFR strategy is going to be, you'll have to tune rusEFI to deliver that strategy. As well you will probably use a wide band oxygen sensor to measure your AFR and ensure that you are meeting your desired AFR target.
 
@@ -20,14 +20,158 @@ rusEFI supports mono, individual/sequential and batched fuel injection using one
 Wideband Oxygen Sensor is pretty much a requirement for both manual and auto-tuning.
 
 
-![General Settings](general.png) 
+![General Settings](Fuel/Fuel_Control/general.png) 
 
 Within each fuel calculation mode there is coolant temperature correction ("warm-up mode"), battery voltage correction and injector open time ("injector lag") correction.
 
 
+
+Commands related to injector lag:
+
+
+set_flat_injector_lag LAG
+
+set_injector_lag VOLTAGE LAG
+
+set targetvbatt VOLTS
+
+
+sequential: set injection_mode 1
+
+batch: set injection_mode 2
+
 rusEFI could be used with MAF sensors sending out voltage (like Mazda Miata) or current (like Ford Aspire).
 
 
-![Table](table.png) 
+![Table](Fuel/Fuel_Control/table.png) 
  
 (also some content at http://rusefi.com/forum/viewtopic.php?f=2&t=1124)
+
+## I/O settings
+
+Here are examples of some relevant commands:
+
+set_injection_pin 1 PB7
+
+fuelbench 100 200 10a
+
+## Full Formulas
+
+### Aplha-N
+TPS-based table fuel lookup with interpolation (Alpha-N)
+
+fuel_squirt_duration = injector_lag_curve_lookup(V_BATT) + warm_up_curve_lookup(COOLANT_TEMPERATURE) * intake_air_correction_curve_lookup(INTAKE_AIR_TEMP) * fuel_table_lookup(RPM, TPS)
+
+where TPS is the reading at the start of engine cycle
+
+### MAF
+MAF-based table fuel lookup with interpolation
+
+fuel_squirt_duration = injector_lag_curve_lookup(V_BATT) + warm_up_curve_lookup(COOLANT_TEMPERATURE) * intake_air_correction_curve_lookup(INTAKE_AIR_TEMP) * fuel_table_lookup(RPM, MAF)
+
+where MAF is the reading at the start of engine cycle
+
+## Auto tune
+Fuel map auto-tune is a process of automatically preparing the configuration table based on the information gathered while vehicle is being operated. At the moment we rely on EFI Analytics Tuner Studio for fuel map (MAF mode) or VE map (Speed Density mode). 
+
+## Closed loop correction
+Last but not least closed-loop fuel correction dynamically corrects fuel to match target AFR. The better your maps are, the better your actual AFR would be as is. Closed-loop correction is the tool to fix the gap between your maps, our models and reality.
+
+![Fuel PID options](Images/Fuel_pid.png)
+
+## Acceleration Enrichment
+
+### Why Do We Need It?
+
+**(This only applies to gasoline engines; other fuels may react differently)**
+
+In order for the engine to run, the cylinders must be supplied with a combustible mixture of air and fuel. Under static or quasi-static conditions, the basic fuel algorithms take care of that. But under dynamic conditions in the intake area, especially with a quick change in throttle position things are different. Fuel enters the cylinder as a mix of evaporated fuel and droplets on most injected engines. How much evaporated fuel the air can hold depends on several factors, but most importantly on temperature of the air and pressure. 
+
+Pressing down on the gas pedal increases the pressure in the intake manifold which has the effect that it can't hold as much evaporated fuel anymore. As a result, some of the fuel contained in the air deposits on the intake runner walls. This is especially true coming off a strong vacuum such as idle or slow cruise/coast. Now this fuel is not available for combustion, creating a lean condition. This has to be corrected for and that's what acceleration enrichment is mostly about. There are plenty of other effects going on, such as the “puddle of fuel” that is explained under the wall-wetting theory. The main point is: When the pressure in the intake increases rapidly, we create a temporary lean condition.
+
+Of course the opposite is true as well: When lifting off the gas pedal, suddenly the pressure in the intake drops and the air can hold more fuel vapor which it will suck off the intake walls. This creates a temporary rich condition. This usually isn't harmful to how the engine is running, but it's detrimental to fuel efficiency and the environment.
+
+### Engine Load Delta Strategy
+
+The obvious way to deal with the effects is to adjust the amount of fuel injected based on the increase or decrease in pressure in the intake. When using the speed-density algorithm for fueling, this is fairly easy, as we have the pressure right from the MAP sensor. So basically you take a multiplier to the fuel you would ordinarily inject and base it on the delta in pressure. Small delta means small multiplier and big delta means big multiplier.
+
+#### Explanation of parameters:
+
+![Engine Load Parameters](Images/EL_based_parameters.png)
+
+The *Length(cycles)* specifies how many previous ignition events will be considered by the enrichment. This should probably be at least the number of cylinders in the engine.
+
+**Note: This parameter may not be needed anymore, there seems to be overlap with the taper-curve. Once the curve tapers to '0' we're done with this enrichment cycle.**
+
+The **Accel Threshold(roc)** specifies how much of a change is needed in order to trigger the enrichment algorithm- this essentially filters out sensor noise and quasi-static conditions
+
+The **Accel Multipier(coeff)** determines how much additional fuel is given. The current firmware (status Nov. 5th 2016 and earlier) calculates a virtual increase in MAP/ Engine Load, based on this factor. It then looks up the VE value in the fueling table based on this value. This will be replaced in future versions by just multiplying the amount of fuel injected and not changing the looked-up VE value.
+
+**Decel Threshold(roc)** and **Decel Multiplier(coeff)** are the same as the corresponding parameters, but for deceleration enleanment calculation.
+
+#### Taper:
+
+After an increase in MAP there is an immediate need for more fuel. So at least until all cylinders fired once we need to add fuel. But even after that, things usually haven’t quieted down completely, so for the next events we still need a little more additional fuel and so on. That’s where the taper multiplier comes in.
+
+![Engine Load Enrichment Taper](Images/EL_based_enrichment_taper.png)
+
+Other corrective factors may be needed in future. For example, at high air-velocities in the intake, meaning high rpm, the effects are not as pronounced, so less enrichment may be needed based on rpm.
+Load based enrichment has a few disadvantages. One major disadvantage is that it is just a hair slow. Especially with small throttle movements at high vacuum, the reaction of load based enrichment is not fast enough and can’t easily be tuned fine enough. For this we use a different strategy.
+
+### TPS Delta Strategy:
+
+TPS-movement can be used as a predictor of change in MAP. This is equivalent to the accelerator pump on carbureted engines. A slow push on the pedal (small delta) causes very little or no enrichment (dumped fuel), whereas a hefty stomp on the pedal and rapid movement result in a big additional shot of fuel. 
+
+The advantage of TPS based enrichment is that it reacts very quickly and can react to small amounts of change at or near closed throttle. The disadvantage is that it can’t react to changes in MAP that are not caused by a change in throttle position, like a turbo-charger spooling up. Usually a mix of load-based and TPS-based enrichment is employed.
+
+#### Explanation of parameters:
+The parameters for TPS-based enrichment have the same meaning as the Engine-Load based parameters. However, there is no multiplier- this is taken care of in a separate table. 
+
+![TPS Parameters](Images/TPS_based_parameters.png)
+
+#### TPS/TPS acceleration extra fuel
+
+![TPS Enrichment](Images/TPS_multiplier_table.png)
+
+TODO: fix error - we do not add 10% extra fuel, we add 10ms extra fuel! not multiplier any more, just extra fuel
+
+This table defines the amount of additional fuel injected, based on throttle movement. The X-Axis is the “From” TPS and the Y-Axis is the “To” TPS. So if the TPS changes from ‘0%’ to ‘1%’, we add 10% fuel. In the above table, if TPS changes from ‘0’ to ‘3’ the firmware adds 17% fuel. 
+
+Why so complicated? A throttle-body is not a linear device. Cracking it slightly open from completely closed will cause much more of an increase in MAP than opening it the last percent from 99% to 100%. This table allows to adjust for this degressive behavior.
+
+In future more adjustments may be needed- for example at low rpms a throttle that is just 10% open may essentially be considered fully open, since it does not cause a significant restriction to the low airflow, so opening the throttle from 10% to 100% may have only a negligible effect on MAP. But at high rpms there will still be a significant change in MAP, Even when the position changes from 90% to 100%. A calibration table for this behavior may be required in order to be able to tune enrichment perfectly.
+
+#### To Do:
+1. Come up with a strategy on how to deal with cumulative effects. Example: Push down on the gas pedal. What if that process takes longer than one engine rotation? 
+
+**Example:**
+| Rotation in deg | Throttle Pos | Addtl. fuel current | Addtl. Fuel Taper
+| - | - | - | - |
+| 0 | 0 | 0 | 0 |
+| 360 | 2 | 13 | 0 |
+| 720 | 4 | 5 | 8 |
+
+Should the fuel from the current change and the previous taper be added up? Or averaged? Or should the latest change completely override the previous change?
+
+2. Deal with warming up. During warmup more additional fuel is needed. We need a setting to adjust for that.
+
+#### Tuning Strategy:
+The point of enrichment tuning is to keep the engine from bogging down when stepping on the throttle. While it would be great to maintain perfect AFRs while this is happening, that goal is currently not realistic. OEM ECUs don’t get it perfect either.
+
+A gasoline engine will run without noticeable bogging at AFRs between 9 and 16, maybe 17 or so. So we’re shooting to stay within a very wide corridor. 
+
+On tuning there seem to be two main conflicting theories: 
+- Use mainly Load-based enrichment and fix the little blips that can’t be tuned with load-based enrichment by TPS-based.
+- Use mainly TPS-based enrichment and add a little bit of load-based enrichment to fix what TPS-based can’t take care of.
+
+Either way seems to work eventually. Lots of trial and error will be needed to get this just right.
+
+Pointers:
+
+- Only tune enrichment on a fully warmed up engine
+
+- Very sharp throttle movements are the hardest to tune, start with more gentle movements first
+
+- You can tune for sudden throttle-stabs without driving, just sitting in idle
+
+- The goal is drivability. If you don’t notice any bogging, no matter what you do with the throttle, you’re good- stop right there, no matter what your AFRs are

HOWTO-Get-Running.md

@@ -57,6 +57,79 @@ http://www.littelfuse.com/~/media/automotive/datasheets/fuses/passenger-car-and-
 
 Once connected you should test the wires. Especially the power wires like coil wires and injector wires. A poor connection with a slight resistance like .1 ohms can cause an electrical fire, which I'm sure you do not want. Once everything is connected measure both the voltage drop and current from the ECU connector, or where ever is applicably appropriate. Using your voltage and current readings, calculate the ohms, if it's above about .1 ohms fix the issue. Take note that .1 ohms at 1A is about .1watt that that connection will have to dissipate. If you have a 12 cyl, and 12 .1 ohm connections, the connector will have to dissipate 1.2 watts. 
 
+
+HOWTO start you engine with rusEfi for the first time
+
+
+
+### test outputs
+
+Both rusEfi console and TS allows you to test if rusEfi properly controls things like injectors (you would hear the clicks), cooling fan (you would hear it - if needed), fuel pump (you would usually hear it - if needed), ignition coil (that's challenging if you have a distributor)
+
+
+## get tachometer showing correct cranking rpm
+
+Your tuning software should show correct cranking RPM, usually between 150 and 300 with a fully-charged battery.
+
+See also http://rusefi.com/wiki/index.php?title=Manual:Software:Trigger
+
+See also http://rusefi.com/wiki/index.php?title=Manual:Hardware_Trigger
+
+## Confirm TDC position
+Assuming you have the hardware ready to spark we now need to find your TDC position - we know trigger shape but we do not know the trigger wheel position in relation to TDC#1 (Top Dead Center, cylinder #1).
+
+Set cranking advance angle to zero for now. Use a timing gun while cranking. We now need to try different values of Engine->Trigger->global trigger angle offset until we get spark at zero advance - that's because we might know the relation between TDC#1 and trigger signal. 
+
+On Engine Sniffer tab of rusEfi console TDC#1 is shown with the green vertical line.
+
+![Initial Cranking Parameters](Images/Initial_cranking_parameters.png)
+
+## cranking parameters
+
+rusEfi has separate cranking control strategy for your first couple of engine revolutions - usually you want more fuel, different timing and simultaneous injection to start an engine.
+
+![Cranking Dialog](Images/Cranking_dialog_jan_2017.png)
+
+Engine would start rich, as long as it's not too rich, as long as you have close-enough cranking timing angle. By default, cranking mode is active if RPM is below 500 RPM.
+
+To adjust cranking timing, use `set cranking_timing_angle XXX` command, where XXX is timing advance angle in relation to your trigger synchronization point. Please note that trigger synchronization point often does not match TDC, so just try different values between 0 and 720. For example, try 0, then 20, then 40 etc. Use `showconfig` to see current setting.
+
+See also http://rusefi.com/wiki/index.php?title=Manual:Software:dev_console_commands#Timing_Control
+
+
+To adjust cranking fuel, use `set cranking_fuel XXX` command, where XXX is number of total fuel squirt duration in milliseconds. See also http://rusefi.com/wiki/index.php?title=Manual:Software:dev_console_commands#Fuel_Control
+
+## running parameters
+
+For first run I suggest running based on MAF sensor - even if you do not have MAF sensor, and flat maps.
+
+`set algorithm 0` would set algorithm: plain MAF
+
+To adjust running timing for your first run, use `set_whole_timing_map XXX` command, where XXX is your timing advance.
+
+To adjust running fuel for your first run, use `set_whole_fuel_map XXX` command, where XXX is number of total fuel squirt duration in milliseconds. This value is usually between 3 and 12. See also http://rusefi.com/wiki/index.php?title=Manual:Software:dev_console_commands#Fuel_Control
+
+One plain MAF workk next step is running with proper MAP sensor calibration & flow rate setting.
+
+## next steps & troubleshooting
+
+There are three ways to produce similar logs - the intention is for these three to have same exact data.
+
+1. SD card logging
+2. rusEfi console logging
+3. TunerStudio logging
+
+See also https://svn.code.sf.net/p/rusefi/code/trunk/firmware/console/binary/tunerstudio_configuration.h
+
+See also http://rusefi.com/wiki/index.php?title=Manual:Error_codes
+
+See also http://rusefi.com/wiki/index.php?title=Manual:Debug_fields
+
+## External links
+
+https://www.youtube.com/watch?v=lgvt0mh_UB8
+
+
 ## Diagnostics and trouble shooting of your engine
 
 ### Basic tests

HOWTO-quick-start.md

@@ -67,7 +67,9 @@ To get the console working follow the below procedure, which assumes you have lo
 * You got it to open, great! Now install gray jumper wire as noted above between pins PD1 and PC6. 
 * Select "digital sniffer" in the dev console and you should see the simulated signal. 
 * Install the blue jumper wire as noted between pins PD2 and PA5.
+![Jumper Wire](Images/discovery_and_wires.jpg)
 * You should see the crank signals as noted in the "sniffer" tab.
+![Sniffer Tab](Images/java_console_2.png)
 
 Update: there is also a lazier way to self-stimulate now, you would not need the jumper wires. That's the "enable self_stimulation" command you invoke via the dev console. The downside? Do not forget to undo it at some point with "disable self_stimulation"
 

Hardware-Test-Mode.md

@@ -0,0 +1,14 @@
+rusEfi firmware has a **I/O hardware testing mode** feature - this comes handy if you've just soldered some I/O board like Frankenso.
+
+In order to activate I/O testing board you need to ground pin PB0. (You can confirm the current pin associated with this feature using `showconfig` command.)
+
+Once PB0 is ground, you need to reset rusEfi. 
+Currently dev console is not supported - in I/O testing mode you need to connect to the firmware using some terminal application like putty or hyperterminal. (TODO: add dev console support, for now you need to use putty)
+
+Same as with normal mode, console uses micro USB port for the data flow by default.
+
+The rest is self-explanatory - the firmware would be blinking output pins one by one, you can move to the next pin using 'n' command till you tell all the pins you wanted to test.
+
+This is still ugly as hell, but much better then nothing.
+
+![Hardware Test Output](Images/hardware_test.png)

Hardware/Frankenstein/Frankenstein-Pinout.md

@@ -0,0 +1,59 @@
+## P1
+
+|def|pin|pin|def
+|-|-|-|-|
+||GND|GND|
+||VDD|VDD|
+||GND|NRST|N/C|
+|Inp4/ADC11/CLT|PC1|PC0|EXT|
+|Inp3/ADC13/IAT|PC3|PC2|Inp6/ADC12/USER|
+|Inp1/ADC1/MAF|PA1|PA0|Inp5/ADC0/V_BATT|
+|Inp2/ADC3/TPS|PA3|PA2|Inp8/ADC2/USER|
+|EXT/TRIGGER IN 2|PA5|PA4|Inp7/ADC4/USER|
+|Inp10/adc7/USER|PA7|PA6|Inp9/adc6/USER|
+|Inp12/HALL/USER|PC5|PC4|Inp11/HALL/USER MAP?|
+|?|PB1|PB0|?|
+||GND|PB2|?|
+|YES|PE7|PE8|HIGH DRIVER 1|
+|HD44780_D6|PE9|PE10|HIGH DRIVER 2|
+|HD44780_D7|PE11|PE12|HIGH DRIVER 3|
+|DD HOLD|PE13|PE14|HIGH DRIVER 4|
+|SPI CS|PE15|PB10|EXT|
+|EXT|PB11|PB12|EXT/2CAN Rx|
+|SPI SCK|PB13|PB14|SPI SO|
+|SPI SI|PB15|PD8|EXT|
+|EXT|PD9|PD10|EXT|
+|EXT|PD11|PD12|LEDRUNNING ORANGE|
+|LED CRANKING GREEN|PD13|PD14|LED ERROR RED|
+|LED COMMUNICATION BLUE|PD15|NC|
+||GND|GND|
+
+## P2
+
+|def|def|pin|pin|def|def|
+|-|-|-|-|-|-|
+|||GND|GND|
+|||5V|5V|
+|||3V|3V|
+|||PH0 no_po|PH1 no_po|
+|EXTRA_LED_1|OUT 1 jumper!|PC14|PC15|OUT 2|
+|INJECTOR_5|OUT 3|PE6|PC13|OUT 4|FUEL_PUMP|
+|SPARK_2|OUT 5|PE4|PE5|OUT 6|INJECTOR_4|
+|IDLE_VALVE|OUT 7|PE2|PE3|OUT 8|INJECTOR_3|
+|SPARK_3|OUT 9|PE0|PE1|OUT 10|SPARK_4|
+|INJECTOR_2|OUT 11|PB8|PB9|OUT 12|INJECTOR_1|
+|||BOOT0|VDD|
+|2CAN Tx||PB6|PB7||spi cs2|
+|spi MISO||PB4|PB5||spi MOSI|
+|spi cs1||PD7|PB3||spi SCK|
+|spi cs3||PD5|PD6|
+|spi cs 4/ETB_LINE_3|ETB_LINE_3|PD3|PD4|
+|1 EMULATION||PD1|PD2||2 EMULATION|
+|HD44780_RS|YES|PC12|PD0|NC|
+|HD44780_CS|YES|PC10|PC11|YES|HD44780_D5|
+||NC|PA14|PA15|NC||
+|HD44780_D4|YES|PA10|PA13|NC|
+|||PA8|PA9|NC|
+|||PC8|PC9|HIGH DRIVER 5|
+|TRIGGER IN 1||	PC6|PC7|HIGH DRIVER 6|SPARK_1|
+|||GND|GND|

Hardware/Frankenstein/Hardware-Frankenstein.md

@@ -0,0 +1,111 @@
+## Current status
+Version 0.1 fabricated & tested, it's available @ [https://www.tindie.com/stores/russian/ our store]
+
+[http://rusefi.com/forum/viewtopic.php?f=4&t=359&p=4176 Frankenstein forum thread]
+
+
+Bare PCB
+
+![Frankenstein Front](Hardware/Frankenstein/Frankenstein_v01_front.jpg)
+![Frankenstein Back](Hardware/Frankenstein/Frankenstein_v01_back.jpg)
+
+3D render
+
+![Assembled Frankenstein](Hardware/Frankenstein/F_assembled.jpg)
+
+## Assembly instructions
+
+### Step 1: MMC/SD card & USB TTL
+
+Let's begin with [communication module](http://rusefi.com/forum/viewtopic.php?t=215)
+
+![Frankenstein Communication Module](Hardware/Frankenstein/comm_module.png)
+
+I'm impatient so P352 SD card module goes on first. Together with the right 25x2 header (P51/P353/P402) this gets me a working SD card. Hurray, this board is not a total failure! Now it's time to C357 to make things right.
+
+Now USB TTL interface: it would not work if you just solder the U351 chip and the J351 miniUSB connector. 
+C355 (0.1uF same thing as 100nF)
+
+### Step 2a: Hall sensor input
+While we can use the MAX9926 VR chip for Hall sensor, the small chip is a hard to solder and the chip is relatively expensive - so I'd rather use op-amp channels for Hall sensor input. I have two Hall sensors so I would build two identical channels.
+
+![Hall Input Op Amp](Hardware/Frankenstein/hall_input_op_amp.png)
+
+Both would use U203 quad op-amp
+C291 is 0.1uF
+C310 & C320: input RC filter 10000PF/0.01uF
+
+Inp11 would be trigger channel1: R310 1K pull-up, R311 500K pull-down, R312 10K current limiting, R313 100 smth, R314 1.5K & R315 1.5K voltage divider.
+Inp12 would be trigger channel2: R320 1K pull-up, R321 500K pull-down, R322 10K current limiting, R323 100 smth, R324 1.5K & R325 1.5K voltage divider.
+
+For trigger channel 1 there will be an ugly yellow wire between W211 and PC6, and for second channel it would be a green wire between W212 and PA5
+
+### step 3: Analog Inputs
+
+The legend on the back assigns throttle position sensor to INP2 (stm pin PA3/ADC channel 3), intake air to INP3 (stm pin PC3/ADC 13) coolant temperature sensor to INP4 (stm pin PC1/ADC 11).
+
+Inp2 (stm pin PA3/ADC3) would be throttle position sensor: no pull-up, R221 500K pull-down, R222 10K current limiting, R223 100 smth, R224 1.5K & R225 1.5K voltage divider.
+Inp3 (stm pin PC3/ADC13) would be intake air: R230 ??? pull-up, no pull-down, R232 10K current limiting, R233 100 smth, R234 1.5K & R235 1.5K voltage divider.
+Inp4 (stm pin PC1/ADC11) would be coolant temperature sensor: R24x ??? pull-up, no pull-down, R242 10K current limiting, R243 100 smth, R244 1.5K & R245 1.5K voltage divider.
+
+
+Inp1 (stm pin PA1/ADC1) is my MAP sensor: no pull-up, R211 1K pull-down
+
+Inp5 (stm pin PA0/ADC0) Battery voltage. Here we would need a voltage divider on the input side: 
+R252 10K current limiting, R253 100 smth, R254 1.5K & R255 1.5K voltage divider.
+
+### High side driver
+
+![Frankenstein High Side Circuit](Hardware/Frankenstein/high_side.png)
+
+C601, C602 & C603 are 0.1uF
+R609, R612 - 100R
+
+With the current issue - we've used MSOP case by mistake, this one is hard to solder. Be sure not to use too much paste. Not sure if you should even try it with soldering wire.
+
+### Low side driver
+The resistors in the left row are 20R, the ones in the right row are 1K.
+The MOSFETs are mounted upside down: the notch should be on top, the part number & ST logo are upside down.
+
+![Frankenstein Low Side Circuit](Hardware/Frankenstein/low_side.png)
+![Low Side Circuit Soldered](Hardware/Frankenstein/low_side_soldered.jpg)
+
+### CAN module
+
+![Frankenstein CAN Module](Hardware/Frankenstein/can_module.png)
+
+C471 is 0.1uF
+C472 is 4.7uF
+R472 10K something
+R473 120R CAN termination
+
+
+### VR input
+
+![Frankenstein VR Input circuit](Hardware/Frankenstein/vr_input.png)
+
+C101 & C102 are 1000pF
+C103 is 10uF
+C104 is 0.1uF
+R102, R103, R104, R106, R107, R108, R109 & R110 are 5K
+R113 & R114 are 10K
+
+## Random notes
+We are still working on our own power supply, for now you would probably need a "12 to 5v power supply module" from eBay:
+
+![Power Supply](Hardware/Frankenstein/power_supply_3A.jpg)
+
+For the "low side to high side" hack you would need to mount through-hole resistors in a tower/Manhattan style.
+
+There is no SD module part number from a major US supplier. TODO: figure this out, but just get them on eBay - see http://rusefi.com/forum/viewtopic.php?f=4&t=215&start=10#p4896
+
+FT232 validation:
+
+pin 15: USBDP 1.5K pull-up to to 3.3 - green USB wire
+pin 16: USBDM - white USB wire
+pin 17: 3vout 
+
+
+Q: 'USB Device cannot be recognized'? 
+
+A: Take a spare USB cable & cut it to check continuity between white wire and pin 16.

Hardware/Prometheus/Hardware-Prometheus.md

@@ -0,0 +1,49 @@
+## About Prometheus...
+
+
+The project is born as a lightweight alternative for a transition from SECU-3i EFI to a more powerful and innovative hardware platform.
+
+The idea is simple: take the existing SECU-3i housing and make a replacement of those two boards with one small PCB of the equal size.
+
+And try to put inside everyting needed for a 4-cylinder fuel injection engine, including ready-to-use ignition drivers and even a bit more ;) 
+
+The PCB is self inclusive, there is no need for STM32Discovery brain boards, external modules etc.
+
+
+*Assembled board, Rev.0.10, top side:*
+
+![Prometheus board](Hardware/Prometheus/Prometheus-pcb-top.jpg)
+
+---
+
+
+### DISCLAIMER:
+
+1. Prometheus board is an experimental hobby project. It's an independent design, not associated with the authors of rusEFI, but using rusEFI under the license. Please use only official rusEFI boards to avoid any problems - Frankenso, Frankenstein etc.
+
+2. We're NOT experts in electronics or EFI, and we can NOT guarantee the operation of this board or correctness of the documentation. We are not liable for any damage caused by them.
+
+3. The board is NOT universal, and has been designed for the limited specs of an "ordinary" 4-cylinder engine. We've made it for our own needs. It cannot do everything that official rusEFI boards do, and it's certainly NOT a complete replacement of them. See item 1.
+
+4. The whole idea of 'Prometheus' project was to stuff "everything and the kitchen sink" densely into one small board, without any additional boards needed. It's a reckless experiment, for sure. But we never give up!  8-) 
+
+5. The current board revision was developed for manual pcb assembly only (no thermal relief requirements satisfied and so on), and for components available in our region, also taking into account the compatibility with SECU-3i peripherals.
+
+Licensed under the TAPR Open Hardware License (http://www.tapr.org/OHL).
+
+---
+
+'''Special thanks to @Russian and @Kb1gtt for their brilliant work and inspiration!'''
+
+---
+
+## More...
+
+
+**See http://rusefi.com/forum/viewtopic.php?f=4&t=1215**
+
+Project files:
+https://github.com/andreika-git/prometheus/
+
+Interactive Map:
+https://rawgit.com/andreika-git/prometheus/master/html/prometheus-map.html

Hardware/Prometheus/Prometheus-Assembly-MCU.md

@@ -0,0 +1,73 @@
+## 2 MCU block
+
+## (a) - MCU:
+
+### Component List:
+![U5_2](Hardware/Prometheus/Prometheus_assembly_2a-comp.jpg)
+
+### PCB Top Side:
+![Orientation](Hardware/Prometheus/Prometheus_assembly_2a-pcb.jpg)
+
+## (b) - ground/power connections
+
+### Component List:
+![Components](Hardware/Prometheus/prometheus_assembly_2b-comp.jpg)
+
+### PCB Top Side:
+![Placement](Hardware/Prometheus/Prometheus_assembly_2b-pcb1.jpg)
+
+## (c) - minimal circuitry:
+### Component List:
+![Components](Hardware/Prometheus/Prometheus_assembly_2c-comp.jpg)
+
+### PCB Top Side:
+![Placement](Hardware/Prometheus/Prometheus_assembly_2c-pcb1.jpg)
+
+### PCB Bottom Side:
+![Placement Bottom Side](Hardware/Prometheus/Prometheus_assembly_2c-pcb2.jpg)
+
+**Warning for Rev0.1!** Be careful when soldering C42 and C43 - they should not be in contact!
+
+## (d) - pull-up resistors:
+### Component List:
+![Components](Hardware/Prometheus/Prometheus_assembly_2d-comp.jpg)
+
+### PCB Top Side:
+![Placement](Hardware/Prometheus/Prometheus_assembly_2d-pcb1.jpg)
+
+### PCB Bottom Side:
+![Placement Bottom Side](Hardware/Prometheus/Prometheus_assembly_2d-pcb2.jpg)
+
+## (e) - crystal:
+### Component List:
+![Component](Hardware/Prometheus/Prometheus_assembly_2e-comp.jpg)
+
+### PCB Top Side:
+![Placement](Hardware/Prometheus/Prometheus_assembly_2e-pcb.jpg)
+
+The 1st pin is marked with a little dash:
+![Placement Dash](Hardware/Prometheus/Prometheus_assembly_2e-pcb-dash.jpg)
+
+## (f) - LED and programmer connector:
+### Component List:
+![Components](Hardware/Prometheus/Prometheus_assembly_2f-comp.jpg)
+
+### PCB Top Side:
+![Placement](Hardware/Prometheus/Prometheus_assembly_2f-pcb.jpg)
+
+## Connecting the programmer:
+
+**Now check if MCU works using ST-Link/V2 programmer:**
+
+Make sure that an external +12V power supply is always connected when using the board:
+![Programmer](Hardware/Prometheus/Prometheus_assembly_programmer.jpg)
+
+### SWD Connector pinout:
+The programmer connector pinout (from left to right):
+1 - the first pin is not used
+2 - GND (ground)
+3 - NRST (reset)
+4 - SWCLK
+5 - SWDIO
+
+![Connector Pinout](Hardware/Prometheus/Prometheus_assembly_2f_swd_connector.jpg)

Hardware/Prometheus/Prometheus-Assembly-Power-Supply.md

@@ -0,0 +1,36 @@
+## 1 Power supply block
+
+## (a) - regulator circuits: 
+
+### Component List:
+![Components](Hardware/Prometheus/Prometheus_assembly_1a-comp.jpg)
+
+### PCB Top Side:
+![Placement](Hardware/Prometheus/Prometheus_assembly_1a-pcb.jpg)
+
+## (b) - minimal circuitry:
+
+### Component List:
+![Components](Hardware/Prometheus/Prometheus_assembly_1b-comp.jpg)
+
+### PCB Top Side:
+![Placement](Hardware/Prometheus/Prometheus_assembly_1b-pcb1.jpg)
+
+## (c) - feedback:
+### Component List:
+![Components](Hardware/Prometheus/Prometheus_assembly_1c-comp.jpg)
+
+### PCB Top Side:
+![Placement](Hardware/Prometheus/Prometheus_assembly_1c-pcb.jpg)
+
+## (d) - electrolytic capacitors & protection (observe the polarity!):
+### Component List:
+![Components](Hardware/Prometheus/Prometheus_assembly_1d-comp.jpg)
+
+### PCB Top Side:
+![Placement](Hardware/Prometheus/Prometheus_assembly_1d-pcb1.jpg)
+
+### PCB Bottom Side:
+![Placement Bottom Side](Hardware/Prometheus/Prometheus_assembly_1d-pcb2.jpg)
+
+**Now check voltages: +5В, +3.3В!**

Hardware/Prometheus/Prometheus-Assembly-USB.md

@@ -0,0 +1,29 @@
+## 3 USB block
+
+## (a) - driver & isolation:
+
+### Component List:
+![Components](Hardware/Prometheus/Prometheus_assembly_3a-comp.jpg)
+
+### PCB Top Side:
+![Placement](Hardware/Prometheus/Prometheus_assembly_3a-pcb.jpg)
+
+## (b) - minimal circuitry & protection:
+
+### Component List:
+![Components](Hardware/Prometheus/Prometheus_assembly_3b-comp.jpg)
+
+### PCB Top Side:
+![Placement](Hardware/Prometheus/Prometheus_assembly_3b-pcb1.jpg)
+
+### PCB Bottom Side:
+![Placement Bottom Side](Hardware/Prometheus/Prometheus_assembly_3b-pcb2.jpg)
+
+## (c) - USB connector:
+### Component List:
+![Components](Hardware/Prometheus/Prometheus_assembly_3c-comp.jpg)
+
+### PCB Top Side:
+![Placement](Hardware/Prometheus/Prometheus_assembly_3c-pcb.jpg)
+
+**Now check if USB works by connecting to your PC!**

Hardware/Prometheus/Prometheus-Assembly.md

@@ -0,0 +1,22 @@
+
+This is a recommended order of assembly:
+
+1. [Power supply block](Prometheus-Assembly-Power-Supply)
+![Prometheus Power Supply](Hardware/Prometheus/Prometheus_assembly_1-all.jpg)
+2. [MCU block](Prometheus-Assembly-MCU)
+![Prometheus MCU](Hardware/Prometheus/Prometheus_assembly_2-all.jpg)
+3. [USB block](Prometheus-Assembly-USB)
+![Prometheus USB](Hardware/Prometheus/Prometheus_assembly_3-all.jpg)
+4. Power output block (bottom side of the pcb)
+5. Crank/Cam Sensors block
+6. Analog sensors block
+7. Digital Inputs block
+8. Stepper IAC block
+9. SPI (optional, needed for knock & wide-band)
+10. Knock controller (optional)
+11. Wideband oxygen sensor controller (optional)
+12. CAN-bus controller (optional)
+13. SD-card connector (optional)
+14. Bluetooth-module (optional)
+15. Ignition coils block
+

Idle-Control.md

@@ -0,0 +1,27 @@
+
+rusEfi supports both solenoid-type IAC out of the box (well, with a fly-back diode - 1 or two wire) and http://rusefi.com/wiki/index.php?title=Hardware:Stepper_motor (4 to six wires, add-on board from eBay required)
+
+
+By default Idle control is in 'manual' mode, while in manual mode you can control the idle valve with
+`set idle_position X`
+command, where X should be between 1 and 100.
+
+In order to enable automatic idle control you would need `set_idle_enabled 1` command. Another command related to idle is `set idle_position X`, where X is desired idle speed
+
+
+In case of stepper idle valve, the position is a percent of the total stepper steps. On startup, rusEfi would move stepper all the way in in order order to find zero position.
+
+In case of solenoid valve, the % is just the PWM of the control signal - it has nothing to do with the actual percentage of valve opening and you should not expect it to be linear.
+
+
+## Warm-up correction in manual mode
+
+While the engine is still cold it's good to have a bit of extra idle air, we have idle warm up correction for that. This correction adjust the idle valve position according to current engine coolant temperature. More air causes engine to run higher revs, once engine goes warmer idle air goes down and so does idle RPM.
+
+For example, here we have a 10% extra open at 30C.
+
+![CLT Idle Correction](Images/clt_idle_correction.png)
+
+## Valve initialization
+
+In case of stepper valve we in order to get to a known position we retract the valve all the way in on startup and then go to the desired position. Solenoid-based valve does not require any initialization.

Ignition.md

@@ -0,0 +1,3 @@
+At this point timing is controlled by a single 16x16 table by RPM and engine load, with 3D interpolation. There is also a IAT-based timing correction table.
+
+Durining running dwell is controlled by a curve by RPM. At the moment there is no voltage correction for dwell time based on VBATT.