Switching to Genboard on my Golf racer before next season, because K-Jet isn't cutting it. Later on I will be doing forced induction, so I need room for change.
Pictures and some info:
http://proton.shadowflux.com/vwracing/
email james at shadowflux dot com
Ignition h[2] sequence questions:
In the manual there are two tables describing what should be used in the h[2] array, but I don't see how they could possibly be correct. If EC36-35 was ignition output numbered 00, then it would fire on every h[2] element; how does it know we added 00 to any number? Shouldn't h[2] values be treated the same as h[0] values? eg ign channel 0 in h[2] = 01, ign ch.1=02, ign ch.2=04, ign ch.3=08, ign ch.4=10, ign ch.5=20, ign ch.6=40, ign ch.07=80. Adding ignition channel outputs bitwise would give unique h[2] entries, not like is used as example presently.
I see the manual has been updated regarding ignition and injection h[] sequences, which helps a lot. Crystal clear now.
I want to connect to all sensors while old management system is working to test everything and do some datalogging before implementing v3.2, but don't want to actually run engine with it:
- leave coils/injectors disconnected. This is sufficient in itself. If outputs are connected for some reason:
- disable ignition with ign_out=FF
- disable injection with h[0]=00 00 00 ..
More config related questions:
- What is crank_minper?
- trigger periods (which is another_trigger_tooth number of teeth in case of multitooth) shorter than this are considered error (eg. due to noise)
- battfac: amount of time to add per X volts decrease in supply voltage. What is X?
- battfac is the slope. Exact formula from fuelcalc.c: linear_interp( BATT_7V, BATT_19V, config.injopen + config.battfac, config.injopen - config.battfac, engine.batt );
- Is injpwmt the same as injopen?
- no. injpwmt is 1 .. 1.3 msec to charge enough current into the injector. injopen is a parameter of the nice GenBoard/Manual/Config/InjectorOpening model usually 0.. 0.3 msec with low voltage flyback.
- Does calibrating the TPS in Megatune take care of the values (tps_low, tps_high) in config?
- TODO: I don't know. Check with mcd
- TPSDOT should be used only with Alpha-N for acceleration enrichment? MAPDOT should be used only with Speed-density for acceleration enrichment?
- actualy, TPSDOT is usually used for speed-density as well. It is a compromise, since TPS is highly nonlinear (especially at low RPM). The reason for this choice is that MAP signal can lag TPS a bit, usually (especially with long hose).
- What are valid values for tps_thresh? Can tps_thresh be less than tpsdotrate[0]?
- tpsdotrate[] are the "bins" on x axis (rate of tps change, usually the change in 100msec time )
- if (tps_thresh > tpsdotrate[0]) than config.tpsaq[0] is actually never applied (but otherwise fine)
- Is tpsasync the 't' in delta over time (tps/map DOT) or the amount of time to add the acceleration enrichment?
- the latter: amount of time ("Acceleration duration [0.1 sec]" in global.h or on LCD) seems right
- Why don't we apply warmup enrichment to acceleration enrichment instead of seperate bin (as acmult and tpsacold)?
- good question. We should ask mik. I'd just apply corr.warm multiplier in the final calc after accel enrichment is applied, and be done with it.
- Does batt_cal change fueling or just readings in MegaTune/MegaTunix?
- the MegaTune readings are (fortunately) engine.batt so indeed it changes fueling a little (and injector PWM duty if PWMing is used)
- Should fastidle be set to target idle rpm when not using IAC?
- no, it's a temperature value (0 means -40 Fahrenheit, 200 means 160 Fahrenheit). iac.c: if (engine.coolant >= config.fastidle) { ...
- What is iac_step_seq?
- C9 or D8 , read "Idle air" section on MembersPage/MarcellGal/EngineSwap/AirFeed
- ve_learn_conf bit2=2x2 box. bit2 is just the bit that has value=4
- 0x05=2x2 mode (discouraged)
- 0x01=1x1 mode (recommended, during early phase of tuning)
- 0x00=ve_learn disabled (recommended during normal conditions)
Your questions are marvellous. Can you help in putting answers the to the XML manual?
Config
Latest/revised comments config: MembersPage/JimW/Config
I have edited a config file and would like to submit it for review. I hope it will be an improvement on the one everyone has been using.
There are many questions I could not find answers to on the wiki, all denoted in CAPS.
Notes about subsystems (to verify/justify config variables) on pages below
- MembersPage/JimW/FuelSystem
- MembersPage/JimW/InputTrigger
- MembersPage/JimW/IgnitionOutput
- MembersPage/JimW/AirFeed
- MembersPage/JimW/Wiring
My installation to date:
Testing, experimenting, and learning with Genboard/PC.
Starting a new job, so time and money have been in short supply. More parts and testing are necessary before installation is complete.
When uploading the firmware via avrprog: Click 'Exit' after finished uploading, window greyed and only available action is to click X to close (no matter how much time passes). Was worried that the upper bits would not be written to flash, but everything seems okay. Update (3/18): Have repeated this several times and everything works out okay.
I am trying to learn how to edit the XML manual. Tonight was the first night I've even had a chance to look at it, and it doesn't seem too bad. A few questions that probably aren't appropriate on the manual pages:
- what is the preferred editing method/program? I'm using Morphon and its very slow (on computer .... MHz, ... RAM and OS .... ). P4 1.4ghz, 384mb rambus rdram, win2k. Not a slow machine, never have trouble with anything else I want to run (don't play games on this machine, so exclude those processer hogs)
- Morphon was preferred, but any text or XML editor works. Just keep to the DocBook format and it'll be fine.
Please split historical info from the uptodate project pages: the latter must be thematically organized.
My Genboard and LCD display currently:
36-1 crankwheel and crank trigger setup on spare (and dirty) engine block:
```[http://proton.shadowflux.com/vems/crank_sens_mtd.jpg]``` [1]
![[1]](http://proton.shadowflux.com/vems/crank_sens_mtd.jpg){kind=link}
```[http://proton.shadowflux.com/vems/sens_block.jpg]``` [2] ```[http://proton.shadowflux.com/vems/sens_gap.jpg]```
![[2]](http://proton.shadowflux.com/vems/sens_block.jpg){kind=link}
[3] ```[http://proton.shadowflux.com/vems/crank_trigger_machined.jpg]```
![[3]](http://proton.shadowflux.com/vems/sens_gap.jpg){kind=link}
[4] ```[http://proton.shadowflux.com/vems/crank_trigger_mounted.jpg]```
![[4]](http://proton.shadowflux.com/vems/crank_trigger_machined.jpg){kind=link}
![[5]](http://proton.shadowflux.com/vems/crank_trigger_mounted.jpg){kind=link}
Here you can see the TDC mark in the pulley aligned with the missing tooth. You are looking at the back of the pulley, so from this angle it would rotate counter-clockwise.
The TDC is 15 degrees after the center of the missing tooth.
..so we set up the sum of trigger_tooth + ign_tdcdelay for 195 degrees.
Offsetting 180 degrees is absolutely reasonable because max ignition advance is limited by ign_tdcdelay. 15 degrees of max ignadv is not enough. Actually, ign_tdcdelay should be at least 30 crankdegrees larger than ignition advance at cranking. Common ign_tdcdelay values are 55..65 degrees.
igntdc_delay=0x1e (30 decimal, that is 15 crankdegrees) is very bad, see above. trigger_tooth=00 and igntdc_delay=0x1e, at n[]=0, the coil would fire at TDC, yes. But you might not be happy with max advance of 15 degrees, and timing from previous tooth would be active even for very low RPMs (where RPM variations are significant => BAD for dwell precision at lowRPM).
- let's assume a normal tooth=10 crankdegrees (=360/36 if it's 36-1)
- trigger_tooth=0d (decimal 13), that is 13*10=130 crankdegrees because one tooth is 10 degrees.
trigger_tooth=00 means the tooth after the missing tooth will act as the trigger. Please correct it whereever you see it wrong.
- ign_tdcdelay=82 (decimal 130, which is 65 degrees)
Mik uses a similar missing-tooth placement.
Intake Air Temperature Sensor
Using Bosch air temp sensor, part number 0 280 130 085. Sensor comes from a VW 1.8t 20 valve, small port head.
Values in EasyTherm are:
50F=4800ohm
82F=1900ohm
208F=230ohm
Still have to test these values to be certain but thats what I have now. I believe these are +/-2F of actual temp.
Note about Megatune: When tuning sensors it is not necessary to recompile and upload firmware each time. Simply update the .inc files in the Megatune directory and watch values change in Megatune. Recompile and upload firmware when values are correct.
I am now looking for sensors and other hardware.
Two MSD 8224 (GM DIS) coils for the ignition. These coils have two blade terminals which control charging and firing, just like any other wasted spark coils out there.
I am using the GM ignition module as a mounting base - it is already built and provides connection to the coils. I pryed the back off of the module and ground the electronics out of it. I then wired the inside so that the Weatherpack connector wires directly to the coil blade terminals. I would have a picture of the inside of the base, but I didn't think to take any pictures before I epoxied it back together. duh.
Aqua colored lines indicate wires I added after removing the guts.
All others indicate already present internal connections. Pin A on 6-pin connector used for +12VDC, Pin B for charging/firing coil #1, Pin C for charging/firing coil #2.
Picked up a Ford (Echlin brand name actually) VR sensor and trigger wheel from NAPA auto parts. I will be having the trigger wheel machined flat on one side and precision drilled to bolt directly to the timing belt pulley on the crank. Those of you using the Ford VR sensor: which terminal is wired to which pin on EC36 for correct polarity?
Any VR sensor pinout info near EdisIgnition ?
- GND signal VR-
- primary_trigger VR+
Trigger wheel: NAPA PN# CSS304
VR Sensor: NAPA PN# CSS400
Notes: