I'm building my own data acquisition system and I want to include Wbo2 logging. I am collecting info on how to control the LSU sensor.
I don't fully understand something in the Wbo2 comments (maybe an error?). In the Vs amplifier part, the code is Wbo2.nernst_target=0x8d. The first stage gain is, based on the schematic, Uout= 5 - ((5-Vs) x 4.6). For our application, we have 5-((5-4.45) x 4.6) = 2.47V => 0x7E and not 0x8D like in the code
- wbo2_nernstdc_target is not wired in the code, but configurable
- "edgetime correction" makes the case a bit more complex than that (otherwise 0x7E would be right).
An other thing I can't understand: How do you calculate the real Ip in the sensor only, without knowing the sensor's resistance. A part of the current generated by the OPA is flowing also in the 10k resistor. With my sensor, I measure 4.7V at pump+ => 0.7/10000 = 70uA. Compared to Ipumptotal = 3.64mA : 0.07/3.64 = 1.9%
- but the error (cause by this) is much smaller than this, because the pump resistance is consistent with Ri resistance and the 10k resistor is also there during calibration. The 10k could be removed but it seems to me the gains are nowhere near the risk.
Where can I find the table lambda=f(Ip) ?
- in wbo2.c ip_to_afr
I suggest to contact the team, especially MembersPage/JörgenKarlsson.
Also, maybe you could consider to share some of your developments or tuning (like PID tuning) if you make experiments (not necessarily fully publicly, if you like, but among core developers). Or even co-develop some gizmo together, you could benefit from the manufacturing capabilities and cooperation between your units and VEMS units, and cooperation with other developers.
Sorry, but some more questions. I like to understand what my electronics do. I spent hours to understand how the right AFR is calculated in the calc_afr() subroutine. I made an excel file simulating each line of code and I will post it as soon it is finished. I found that when the pump PW is equal to pump_pw_zero, 102, meaning no current in the pump, the calculated AFR is 15.11, instead of 14.7 ??????
My sensor has a Rcal of 144.4 ohms. With the correction curve, I have to put Wbo2_calibration=187, and fine tune this value in free air. But to have correct values in free air, the value must be changed to 225 ?!?!?!?? Is this big correction normal????
- sounds a bit high, but may be. Take care about sufficiently high supply voltage and proper wbo2_nernstdc_target configuration (and high enough wbo2_pump_pid_ki)
One more, in the bosch LSU4 datasheet, I found the Ip/lambda table. Is it valid for 95 or 98 fuel and did you use this table to build yours???
- Bosch doesn't specify too much about it, but it is the table we (and everyone else) use. Fuels might be different (even 95 octance fuels from different suppliers). Bosch says "measure yourself" :-) Also, EGT should also be considered for best results.
Some suggestions.
-On motorbike motors, the rev range can go up to 14000-15000RPM (see Jose Cortes page) and "need" small bins, about 500RPM.
Did you find any measurements that show that, say >0.1% power gain can be acquired when going from 16 to 32 RPM bins (and the ECM uses interpolation) ? If yes, I understand the "need" word. Without interpolation many bins are nice, but with interpolation (that VEMS uses) 16 should be enough (the difference between interpolated and optimal values stays below tuning error) even with equidistant bins.
So ign/fuel tables need to be bigger than 16x16. For exemple, on the Aprilia RSV Denso ecu, the tables are 16x29, with fixed bins at 400rpm.
-On big bicylinders, it is better to have a fuel table per cylinder. With dual fuel tables, we also can have staging injectors, but to have good results with staging, a smooth transition between stage 1 and 2 is needed.
So Why not implement multiple fuel table, for exemple 4, with choice in configuration for staging, dual, both,...
And also some questions:
-I reverse-engineered the Denso ECU. It have MAP-rpm and TPS-rpm tables. A smooth transition between them is done. At low throttle openings, where the MAP sensor has a big variation for small TPS variation, the system uses only the MAP tables. And at big throttle opening, where the MAP sensor doesn't variate but TPS is more acurate, the ECU uses only the TPS-rpm table. Don't forget the transition.
On different pages,
On GenBoard/UnderDevelopment/AlphaN it is mentioned that VEMS uses TPS at (configurable) low RPM (note: RPM ! not load ) and then MAP above a certain (independently configurable) RPM. Interpolation (blending) is used in between. The explanation is that at higher RPM the MAP is smoothed out (=> usable), while at lower RPM MAP fluctuates during 1 period, and synchronized sampling (similar to what we used for knock) would be needed to use it (often said "MAP impossible to use", but it's rather just hard).
-My motor is a twin, 60°, and uses a crank trigger with 6 tooth (one is longer than the others, that mean no missing teeth) and a cam trigger. It has one coil per cylinder and can't do wasted spark, due to the 60°. Are the 6 tooth enough to run VEMS in full sequential fuel/spark, up to 12500RPM ?????
- use the crank-edge that gives even spacing (rising or falling).
- change the firing condition so it only fires (fire means: stores trigger time and asks for RPM recalc with engine.status |= _BV(new_rpm) and calls ign_trigger_here() ) at odd (or even, as you like) engine.igncount values, and uses the engine.igncount>>1 as index to look up h[2]. This is needed, because h[2] is only 8 wide, while 12 is needed. You can also try a quick/dirty hack HW_TABLE_SIZE=12 or 16 - however, this way max dwell time might be limited!
- After tests, if this behavior is enabled by a my_make define or a config bit, we'll merge it to SVN.