Open Issues ToDo
Summary of problem: Megatune reads RPM and MAP correctly but battery voltage is zero. Megatune will write configuration values but only after accepting the low voltage write anyway error warning. Configuration values varified using terminal, however, config can not be written in terminal (probably blocked by low voltage error. A/D must be functional as MAP is correct.
Further... put varriable supply into TPS with TPSL=0 and TPSH=ff zero volts is 0% throttle while 4.3V is 100%. Two A/D channels are working while a third attached to a voltage divider is not.
Hardware: The top of R13 is at Vin (13Vdc), the middle of the divider is about 2.9V. The 2.9V is present on processor pin 61, ADC0 in. TPS is reading correctly and thus I believe Vref is ok. I believe the hardware is functioning just fine.
Is there a way to reflash firmware over riding the low input voltage lockout (which I assume is why I can not flash it the normal way)? The board deffinitely does not have a low input voltage problem. Has this problem occure with other boards?
History on Current Problem: I was working with correctly scaling RPM late yesterday. Returned this morning and assembled V3.3 does not communicate well. Under Megatune the voltage is zero while correctly reading the RPM. I can dump tables in terminal but can not reflash firmware. The unit has not been opened (for that matter, it was not even moved on the bench) and thus I do not suspect we did anything to the hardware. Has anyone seen this problem?
More Information: I can not update the configuration via terminal. However, I can update values using Megatune (like RPMK(0) and RPMK(1)) and they are reflected in a terminal dump of the configuration registers. Megatune gives a voltage too low to flash, flash anyway message. I let it rewrite anyway and the write was successful.
A: Have you changed vbatt calibration? I dont remember exactly the name but you'll find it in the menus. If you have any more config related problems, please upload whole mcd and mct output, or msq file from megatune (dont forget to also write megatune version) //Emil
Trigger Question
12-1 Wheel single cylinder VR primary trigger
Signal being generated by parallel port to op-amp
Signal is zero to -3 to +4 to zero
Total pulse is 1/20 of the pulse to pulse period
single pulse spacing is .794 msec
RPM=[1/(.000794*12)]*60 or 6297rpm
- Megatune displays 1570 which is almost exactly off by a factor of four
- another_trigger_tooth with 12-1 crankwheel, use 24 / cylcount
- rpmk[0] and rpmk[1] (upper and lower bytes, respectively): use 12000 / cylcount
Dump from V3.3
primary_trigger=01 #
secondary_trigger=02 #02 is disabled says Megatune and one configuration example while another configuration example says it is disabled if 0FF?????
tooth_wheel=0B # wiki says actual number of teeth 12 -1 or 11 decimal 0B hex
trigger_tooth=01 #left at one for now as "timing" not yet important
another_trigger_tooth=06 # with 12-1, 06 means 2 events per crankrot, that is 4 events per camrot (4cyl) OK so is another_trigger_tooth=18 or 24 dec acceptable for a one cylinder 4-stroke?????
crank_minper=9C #entered 2000 for now wiki says this should be 60sec / max RPM / number of engine events * 2 which would be 60/8000/1*2 or 15,000 usecs this number was not accepted by Megatune
tooth_wheel_twidth1=0A #wiki says dec=255/(2*imag teeth) or 255/(2*12)=10.xxx phase 240 for 12-1 and twidth1=phase/(imag teeth * 2) or 240/(12*2) or 10 dec/ 0A hex
tooth_wheel_twidth2=14 #wiki says (missing teeth +1)* dec or (1+1)*10 =20 dec or 14 hex
I beleive I have followed the wiki examples and my VR pulse input looks ok. Can anyone provide some guidance.
History
Does the V3.3 firmware calculate base injector pulse width using VE and Required Fuel only or does it factor in A/F values from the A/F table? Put differently, is the A/F table only for autotune or is it also used for open loop injector pulse width calculations? Is there a detailed explanation of exactly how the injector pulse width is calculated apart from trying to decipher the C code?
A: The lambda target table is always in use in the calcs, i dont know where to find the description though //Emil
Please advise on what is connected to the flying green jacketed wire protruding from the front cover with white and green wires.
A: Exhaust Temp sensor I will look to Wiki fof hookup info, page GenBoard/Manual/ExhaustGasTemp, just wire the sensor in and do the calibration described on that page
Projects Underway
MembersPage/BillHart/WinMobileLogger Win Mobile platform to Fat32 memory card logger. Looking for SIPR examples, if any, to ease the adding V3.3 query to Win Mobile code.
[VR_Emulator] is a parralel port based Op-amp circuit that provides a plus or minus pulse about zero to emulate a VR sensor. You build the Basic routine to generate the crank (and cam)input wave form you need. Drop me a note if you need my QB code as a starter.
MembersPage/BillHart/LoggingDongle anyone interested in a small relatively inexpensive logging dongle?
I would like to better understand the inside of what I have worked with for so many years from the "outside". See [LolaCahmpCar] for more info.
Do you have a particular project engine in mind ? Yes, sub-set of V3.3 for highly targeted one to four cylinder 4-stroke fuel and ignition.
We usually call "reverse an existing ignition advance curve" as "alien" logging. Searching for alien on SiteIndex, I found OnlineCourse/AlienIgnitionLogging. Secondary_trigger can still (in recent firmwares) be configured for alien measurements (except for 5cyl), but the alien variables seem to have been ripped from comm.c. Even if they show up on LCD, only useful if they are sent to the PC (like MegaTune) for analysis. Fortunately not difficult to get comm.c send the variables related to alien measurements.
I have read a bit about the status of logging. There is discussion of building hardware to support logging. There are also those who feel PDAs are a better path. I would like to weigh in on the PDA side as there is no value add to recreating the (logger hardware) wheel. A small portion of the hardware data logger work could be devoted to PDA code to generate a log storage device. FAT, touch interface, serial, memory card slot and services are already done. Can someone advise on the current status of group thinking? Is someone working on PDA? The only link I found was a dead end.
I recommend to comment (continue discussion) on the relevant page, not split even more. In short:
- PDA is a good path for display. There is a HW and a SW aspect of GraphicalDisplay.
- Many would like to have a custom display designed for cost and other reasons (see GraphicalDisplay), but getting 100 PDA from the right source could be a good option as well.
- In any case, the display code should be portable (will likely require ARM processor and 256..16000 kbyte RAM depending on functions and compile options), and any code used in display will be useful for an OtherTuningSoftware as well. Which is - surprise - also a bit stalled.
- for just logging, MMC/SD flash is the best. It's a shame the firmware support is delayed so long: read-only FAT, and writing serialized data to MMC/SD shouldn't be that hard (SPI hardware is there since the beginning).
I am working with a 12-1 wheel and wanted to clarify a few points.
- primary_trigger=01 (for toothed wheel, simple enough)
- tooth_wheel=0B (12 minus one is 11 dec which is 0B Hex)
- tooth_wheel_twidth1=0A # decimal 10, so 720 degrees equals 240
- reset_engphase_after=F0 # decimal 240
- tooth_wheel_twidth1 needs to be the phase difference between two incoming pulses (== the width of the tooth plus adjacent gap). Beware that it's not in degrees! Unit is determined by config.reset_engphase_after (=>720 degrees), which is usually 240 or 216 depending the number of teeth on the wheel (60/24/12 or 36). GenBoard/Manual/InputTriggerCamSync should tell more.
- trigger_tooth=00 is the pulse (== max height middle for a normally conected VR) after the missing tooth. 01 is one tooth later and so on. trigger_tooth + ign_tdcdelay together describe the TDC event for the cyl that is in the last slot of h[2]. Check examples from MembersPage, easier to see from them. As you say, these are the "fiddle factor", since the tooth location usually does not fall directly on TDC.