MembersPage/Gabor

Table of contents

MembersPage/Gabor/MitsubishiColt/Iac

MembersPage/Gabor/MitsubishiColt/TachSignal


REALLY SERIOUS problem with my board, help needed...

Now what to do, it is very serious problem? Anyway the route cause was that VEMS got GND from ISP or RS232 brrr...

It seems that AVR has been damaged on given board (v3.1 serialNr 32). Even if it gets alive, not to be used in a vehicle. When GND5 is not connected (or gets accidentally disconnected and board powered up: serious mistake) usually TPIC6A259 and FETdrivers fry. When board is powered (gets ground) through ISP (which was a mistake to connect, when BootLoader can be activated with a loopback wire at powerup) the AVR gets damaged. When board gets powered from RS232 (which is also illegal of course), it might survive if no power outputs are switched on (injector, ignition, etc...) - but the max232 might die, or maybe other components too.


Twice happened problem (probably was an advance issue and obsolete)

Yesterday, I tuned a Mitsubishi Colt turbo on dyno. I was almost ready, I had Lambda 0.8 and EGT under ~850C at WOT at all RPM. Suddenly the power decreased one third of original at WOT and EGT increased quickly as well, but lambda remained 0.8. Knock limit ignadv was about 25 crankdegrees BTDC at WOT, big RPM's, but then I could raise over 30 degrees. There was no knock, Lambda didn't change but still high EGT. We thought something is going wrong with the car. Stopped the engine, checked oil and started again. Everything became right again without changing anything (only rebooted VEMS). On the road home, the same happened again. Without stopping the car, turned ingnition key off for a second and back on again. Power came back...

As I warned you 3..4 times, the compiler you are using to compile your firmware is proven broken. Actually you proved it yourself with the element0 of h[0] problem (read below) that was reproduced on other board with hex file compiled by you, but not with vems.hex compiled from same tree with a good compiler. (you still have to report the compiler version, remember?)

Understand that the broken compiler can produce different bad results. One time the element0 of h[0] misbehaves, other times other mistakes.

Please understand that no report with firmware compiled with a proven broken compiler can be evaluated, especially if there is no compiled binary (vems.hex file) attached (if there is vems.hex attached, it is possible to stresstest it, but it's likely a waste of time since the gcc bug has probably been corrected since).

Also, just to be sure, don't forget to verify that firmware in flash is not corrupted (verify with prog.pl without w option, practically Etf options).

I updated to the lastest WinAVR, when you mentioned first time that it should have been a compiler bug. Just now I'm using gcc version 3.4.3, and also compiled the firmware which produced the issue described above. I've made it available: http://www.vems.hu/files/Gabor/firmware_szekeresg2.zip . This firmware has minor differences from the v13: the few lines of stepper (MembersPage/Gabor/MitsubishiColt/Iac) and I259(DHIGH, 4); I259(DLOW, 4); in edis.c, because DRIVE_04 is used for tach signal.

MembersPage/Fero did not experience anything with the Peugeot race car. He did not drive the car at all. First, the racecar ran out of gas. Another time, something was wrong (maybe the driver made a mistake) and the computer was the easiest to be blamed (there is some minor chance it was a HW problem and very slim chance it was a firmware problem but we just don't know - unfortunately runtime logging to MMC is not implemented yet).


Injector h[0] problem, SOLVED: it was a compiler bug

PLEASE HELP OTHERS by reporting the version and origin of your proven-broken gcc

I'm installing a VEMS 3.1 on a turbocharged Mitsubishi Colt (port injection, 4 cylinders). Since I wired injectors from OEM ECU to VEMS, 1 cylinder is not working. The injector setting was sequential; h[0]=01 02 04 08 ..., alternate=3. I turned off one and one injectors in h[0], so determined which cylinder has the problem (01 alias INJA) I tried:

And the astonishing solution: I put 01 injector one step right in h[0] and the problem solved (h[0]=00 03 04 08). After I tried many combinations. Some of them explained below:

h[0]= 00 04 01 0A passed
h[0]= 04 01 0A 00 failed

h[0]= 00 04 0A 01 passed
h[0]= 01 00 04 0A failed

Notice that row 1 and 2 should have been the same, but only one of them working, in the other case 04 cylinder is not working. The situation is the same in the second two cases as well.

Just now I'm using h[0]= 00 05 00 0A setting and engine is working right. BUT WHY DO I HAVE PROBLEM WITH THE FIRST BIN OF h[0]?

Everyone was thinking (reasonably) that another function is using the injector channel. Marcell checked himself that all channel settings was FF in mcd output.

Problem is under investigation, see bottom of GenBoard/Manual/DigitalOut/Table. Hopefully not a loose pointer or sg. As a test I tried to disable some functions like LCD with mdd01 (also tried mdd0f mddf0 mddff) command, but mdh80 still ligths up test-LED for a very short time.

Firmware used (anyway experiences were the same with the lastest firmware): http://www.vems.hu/files/Gabor/firmware_szekeresg1.zip


Introduction

I installed a GenBoard v3.0 on a Suzuki Swift 1.3 8V.

Now the stock ECU handles only the ignition. A self-built GenBoard/VerThree v3.0 handles injection.

VE Learning experiences

I logged the factory ECU at almost all RPM-MAP area, and experienced, that lambda is 0.5V at low MAP and it is _ALWAYS_ 0.7-0.75V at high MAP (1 wire narrow band lambda sond). After I did some log with AVR in open-loop (my j[] table tuning) and saw that lambda variables between 0V and 0.9V depending on VE value. I did the logs above more times and draw the lesson: I should try to operate my EGO correction in closed loop mode always.

I completed the firmware (not committed, it is only in my firmware):

static inline void bangbang_ego(void)
{
	uint8_t target, ego_volt;

	if (engine.kpa250<260) target = config.ego_target; // 0.5V, 1kpa=4, 65kpa=260
	else if (engine.kpa250<320) target = 0x1F; // 0.62V, 80kpa=320
	else target = 0x26; // 0.75V

	ego_volt = ego_voltage();

Maybe you think this is dummy, but it works. There was a better solution a year ago (it was dropped when WideBand was proven; maybe it could come back instead of above hack): get the target voltage from l[] table.


Trigger in detail

I always had problem with cranking. I noticed that usually AVR doesn't get trigger at low RPM < 500 (LCD and logging with megatune confirms this). This installation problem is explained above.

I examined my trigger. I have two trigger wires (purple and green) which come from the distributor. I used ONLY the stock ecu for this measurement.

The results:

Alternating Voltage values measured with a simple DVM in V~ mode are peak2peak values divided by 2.82 (fake-RMS).

The lower-peak voltage must go below 0V. With 665mV DC and 60mV amplitude it obviously will stay above 600mV (not go below 0mV in any way). Obviously not good. Take 8 mins to review InputTrigger/AnalogSide and LM1815 datasheet. You need to use a series capacitor: eg. the 10uF 35V 1210 size cap that has pads onboard (from v3.1) so the signal on LM1815 input goes below 0V.

Unfortunately this board is a v3.0, and it has no pad for this series cap - because normally this is not needed at all (series cap added from v3.1 exactly for such hacks).

Just put the cap in instead of the 5k6 resistor, or cut a trace, or put into the external wiring.

PROBLEM SOLVED. I put a series 1uF cap into the external wiring, and now I have trigger at all rpm. I will change the 5k6 resistor soon to cap, but I have to buy one before.

Good. Could you please write 10..15 lines about ve-learning for newbies? Maybe onto page GenBoard/Manual/Fuel/VeLearning?.

Stealing the trigger signal

The switched ignition signal (B16 on the schematic below), is tapped, and connected to AVR as primary trigger (trigg1).

The service manual, with the wire tapped and connected to AVR:

trigger.png

The circuit that I use to get this into the AVR 3.0

LM1815.jpg

OK, I see this is an early v3.0 with LM1815 soldered by you as the very first SMD soldering in your life :-)

MAPDOT

MAPDOT is working now and has been already in the firmware.

AVR vs stock ECU

I compared the stock ECU with a roughly tuned Genboard 3.0. I did some kickdowns and tuned the VE table at max MAP to be the NBO value about 0.7-0.8 V. So there are some more HP in the engine. I my opinion it will be at least 2-3% stronger above 5000 RPM.

I did the measure with street dyno 0.6.0

AVRvsSTOCK.png

AVR-STOCK.png

My wiring

I have throttle body injection so I used INJ_A (pin7 on Econoseal 36) on AVR. The connected an 5 ohm resistor to the injector channel of stock ECU (check engine don't lights). The wiring of the injector could be simpler but now I can change the injector control from AVR to Stock ECU or v.v. in 30 secs.

Of course the +13.8V RED wire is not directly connected to the battery, it is after the main relay. The injector's common should be after the relay of fuel pump, but if you don't want to wire a lot, you can connect it directly to AVR's 13.8V (RED wire).

Stock sensors on the car:

So here is my wiring. It's customized to my car so maybe you have to modify a little bit for yours.

Genboard_3.0_suzuki_wiring.gif

---

Could you upload your config and tables? Would like to take a look at the NBO2 config.. //Emil