jenksta

Members
  • Posts

    31
  • Joined

  • Last visited

  • Days Won

    7

Everything posted by jenksta

  1. TunerPro just compares the binary files, and as one uses an offset of X for that table and the other Y it'll be comparing X in one bin and X in the other even though the table is at Y (if you get my drift). Easiest way for you to work with it is open the bin you want to compare in TunerPro with the correct XDF, and copy the table to another instance with a "working bin" of the 607/608 XDF (if you catch my drift). I wrote a simple little script to do this for me when I started with my LPT engine so I just dumped all of the 607 offsets and 609 file offsets in a CSV and it'd copy all the LPT tables over to my 607 at the correct places (ofc I had to manually find the necessary offsets in the 609 bin first using IDA, but was quite easy).
  2. Just in case it bugs anyone else like it did me, I had an issue where the pre-start listener would be hit and miss when sending commands (such as the begin logging command, which meant I'd start the car, see it wasn't logging and have to turn it off and repeat). Whilst looking at something else I found out that while the OBDII/OEM diagnostic stuff is disabled by the prestart listener as it overrides the serial port settings - there is also code that manually checks the serial port for the 5-baud KWP init (which consumes the byte we send before the pre-start listener has the chance to). So to fix the issue above I knocked up a little bit of code to disable this if pre-start listener enabled. @ 0x1B67E place the following (jump to custom code): 0x02, 0xE9, 0x03, 0x00, 0x00 and @ 0x1E903 place the following (custom code, existing bytes should be all 0x02): 0xB4, 0xFF, 0x01, 0x22, 0x90, 0xFD, 0xCB, 0xE0, 0xF5, 0xF0, 0x30, 0xF3, 0x03, 0x02, 0xB6, 0x84, 0x22 (same address in both 607 & 608) TLDR: if you have trouble engaging logging before engine start every now and again patch as per above and should fix it 👍
  3. Yep just saves you a few clicks by TP feeding it from command line params, just don't forget checksums after modifying the bin 👍
  4. It's a slightly modified version of the Motronic Suite flasher with the command line capability added, but whereas it still supports M43 normally - command line only flashes for M44.
  5. No worries, I've been a bit busy working on two way serial comms. Hooked into the tx and rx of both serial channels (so bypassing the single wire k line but still keeping it functioning for oem diagnostic purposes), so I can send messages to the ecu whilst logging at the same time for whatever purposes I need. Hooked up to an arduino and will be shortly adding sd card for continuas logging and bluetooth for wire free comms and flashing (another useful thing also would be wire the bootloader pin to a relay controlled by arduino so flashing could be done without having to manually flick a hw switch). Serial chan 0 is working fine for flashing and logging etc but having trouble with serial chan 1, but it only supports 9600 baud anyways so not a big loss. My aim is to hopefully free up a decent chunk of xram so that I can tweak certain table values on the fly without having to use an eeprom emulator (hence the need for two way comms while logging to make it alot easier to use).
  6. If you have the data sheet for your WB controller I could knock you something up. I assume this'll be put into a bin without the closed loop wideband control right? Otherwise it might conflict as I've never seen Piet's code for it.
  7. Do you mean using both the WB & NB signals from the WB controller? If so that's possible. Or you could just change a bit of code to ignore the stock NB sensor channel and let the ECU make a NB signal from your WB input (that way no messing with any extra connections to ECU), which is similar to how the 'WB control' works (or at least my version of it).
  8. Haha I was originally too, all I know is that eventually I got it working and I now have the extra ~420kg/h flow from the larger MAF and didn't cost anything as had two of the T6 HFM-5 MAFs to hand (I'm a cheapskate haha), plus using the original OE voltage->flow conversion values. If anyone fancies doing the same and needs help just let me know 👍
  9. Apologies meant to say the HFM-2 MAF in my previous post (corrected it). I know the HFM-5 has reverse flow below 1v and this means that the first 52 cells in the MAF table (<1v) are all 0, which ofc loses some resolution down below, but nothing noticeable. If I wanted I could probably scale these down and begin the MAF table at 1v to counter this, and the actual values for the increased resolution are available already due to the double resolution in the ME7 MAF table.
  10. It's been a while but from what I remember 0v on the HFM-2 was giving 0.6 or 0.7v on the normal MAF channel. I think if you backpin the original MAF with a voltmeter you'll probably find this the same too. Took me a good while to figure out as I believed it to be a problem with the MAF table, but eventually found it to be caused by this offset. Also worth noting it's not on the ground side either as all I did was swap the 5v output from the MAF to the accelerometer channel and all was fine.
  11. Just need to change the one or two bytes that reference the maf adc to the accelerometer one. Been meaning to check if the offset on the maf chan is in hw or sw as I believe the 8051 supports software voltage offsets for the ADC chans, so if it is sw then could remove the offset and use the original chan 🤔
  12. FWIW I run a HFM-5 MAF as opposed to the original HFM-2. It did require hw mods as I had to swap the 12v feed to the original maf to a 5v one (aswell as repin to the new style plug), and also had to swap the ADC channel (I used the accelerometer chan) as the original one had a strange voltage offset. The maf I used was 0280218089 iirc (came from my T6 xc90) which again iirc is 3 inch/78mm (and that's ID too not OD), and the conversion table was ripped straight from the original ME7 bin so no messing with conversion etc (just had to half the table resolution iirc as ME7 is 2x the size). Although not a biiig upgrade from original it gives me plenty of flow sensing for what I need atm and could always use a bigger HFM5 if needed and again rip the oe table from the source vehicle bin.
  13. We have all this E10 stuff over here now but I use super anyway which is still E5. As you say dwell is compensated for battery voltage and injector dead times too so wouldn't have thought the increased voltage would make a real difference (or at least not to cause this). Knock enrichment will kick in once knock gets so much, but regardless of enrichment and timing pull it still knocks. If it reacted to the knock and stopped it via adaptive knock then I'd have a better idea but it doesn't. Only other thing I can think of is the acceleration enrichment but can't see why battery voltage should affect it and never had or heard of anyone having to tweak it to fix something like this before. One thing I do notice in the logs is that the timing pull is mostly in 1,3 and 5 and only a small amount on 2 and 4. Not sure if this is relevant or not though.
  14. Literally nothing changed, drove it, parked up, fixed the issue with the battery terminal, then drove it afterwards and stuff loads of tip in knock. I figure either the higher voltage has messed with something or perhaps something has gone amiss when messing with the battery cable? I put some fresh fuel in too (super 99 as per) and no difference. Inlet temp is the only thing I don't currently have logged, although it's not exactly warm here in the UK atm so I wouldn't expect them to be too high. Had new plugs less than 1k ago but didn't think about the spark being affected by higher voltage - but seems like it could make sense. I have my own wideband control implemented and in the knock areas it's dipping to quite rich AFRs (low as 12s) so could heat really be the issue?
  15. Got an odd issue wondered if anyone could shed some light on. Got myself a V70 2.5T (LPT) since I killed the 850 T5 (crashed - not engine failure haha), been tuning and tweaking e.t.c. over the past month or so since I got it back on the road. Since the start I had a voltage issue and was only running at around 12.5v - this turned out to be the crimp at the battery terminal so sorted now and running at 13.5v+. However since sorting this I'm getting throttle tip in knock real bad, regardless of if I'm at standstill or driving along if I blip the throttle I get knock flag and timing pull galore. If I ease the throttle in gently no knock - also no knock on hard pulls e.t.c. Even going back to an old bin I still get the same issue - and looking at my logs pretty much everything is the same if I compare similar behaviour rows from old logs with no tip in knock vs new logs with tip in knock so really stumped on this one. Any ideas please?
  16. What sort of limiters would you want gear based? Would be quite simply to add the functionality depending on what you wanted to use it for?
  17. If its just the error lamp/MIL you want to disable, set 0xF3AB (IAC open fault) & 0xF3AC (IAC close fault) to 0 in the upper & lower banks.
  18. The CEL is on to indicate current/adaptive knock (hence the ignition retard values on the right). The AFR/Boost values will only update if you have the sensors hooked up and configured correctly in TunerPro. Have a read through the wiki to find out how to do so.
  19. I've Added some notes on injector types and tidied up that page a little. As for the 'TPS for WOT detection', someone correct me if I'm wrong but that's simply the throttle position at which the ECU acknowledges you want full throttle and begins using the 'WOT enrichment' table/cells. As the general consensus is not to use this table then you shouldn't need to touch that for basic tuning.
  20. For anyone interested, I tune with adaptive knock on as it's my daily (full flashes no ostrich), so got sick of having to keep pulling battery/ecu to reset the adapative knock/fuel trims/etc when tweaking. Figured out if you set FLGINI (FLAG4.0 - initialization indicator) & clear the power fail counter (XCKPF0), it'll clear everything for next engine start and achieve the same as a full power down. I set this up to work with the pre start listener 'Clear all (0)' command so you can run it when needed (ign on - engine off) via TP or terminal, code is below (patch with hex editor or setup a patch in TP). patch @ 0x8985 02 8A AB 00 patch @ 0x8AAB 90 FD CB F0 90 FA F4 F0 D2 40 02 89 89
  21. What car is your m44 ecu from? If its from an non turbo you need to add two solder bridges inside the ecu or the TCV won't work.
  22. Yeah that one's from VIDA, there's also the list from MotronicSuite, however in regards to the MAF offset this isn't actually documented anywhere that I've seen, the stock 850 sensor doesn't put out 0-5v, I think max it puts out is 6.5 or so volts, and then the ECU sees this as 5v (ADC 255) due to whatever conditioning it has inside the ECU. I didn't do much testing myself but found that when switching to the HFM5 the actual voltage being output by the MAF and what the ECU was seeing was different (at idle it was down by 0.1v or so iirc) which I got around by using the different channel, then found Boxmans post on here since which I think he found it has an offset factor.
  23. For anybody interested, in my 850 I've used the HFM-5 MAF and 2.5bar TMAP sensor from an ME7 (T6 XC90 as I have 2 breakers...). Conversion factor for the MAP sensor is below (figure is in PSI with atmospheric pressure subtracted). ((270.59 * (X / 255)) / 6.895) - 14.7 As for the HFM-5 MAF, on the 850 MAF it has 2 grounds (pwr gnd+sig gnd), 12v and signal whereas on the HFM-5 it has 1 ground, 12v, signal and 5v ref (+NTC bulb on certain sensors). Due to this I had to run a 5v feed to it from the ECU (to save extra wire routing I cut the original MAF power ground from the ECU socket and used that as my 5v ref), also after alot of messing I figured out there is a voltage offset in the ECU for the original MAF (I later found Boxman mention this in this thread actually - here) so for a simple solution I swapped the MAF signal pin with the accelerometer signal pin and then changed the bin to use the accelerometer ADC chan for the MAF instead of the original MAF one. Voltage to flow table I extracted from the T6 bin and used as-is (minus the additional 256 values due to higher resolution in ME7) and seems to work fine so far. This MAF should flow to around 1250kg/h-ish so should be fine for my needs at the moment (TD04HL-20T).
  24. Been doing some comparison on the 607 vs 608 binary as regards to what differs (although I know most accept now to use 608 and simply toggle the KONFIG bit for auto/manual trans, however unfortunately I started my dissassembly with 607 so cba to start over with 608 haha). Majority of the changes are slight differences in ROM vars/maps (as expected) (pastebin link here for all but a few of the changed vars I've tracked - they're based on var names in my IDA DB which with the exception of a few follow the DAMOS naming). However code wise I can't really see anything significant but the biggest (or rather commonly occuring, 45x) is in the autos when setting SCL 0xE012 (injector number to be triggered I believe?) it loops until SCL 0xE010 != 0xFF before continuing, whereas on the manuals it doesn't care if SCL 0xE010 is 0xFF before carrying on its merry way... Anyone know the significance of this? (Perhaps unrelated to auto/manual and simply a code revision that added/removed this?).
  25. Thought this may be of use to someone, I created a 'checksum' plugin with the TunerPro SDK that duplicates the shared lower/upper bank data when the bin is saved. This means that instead of having two items in TunerPro for any of these duplicated data/tables/etc, you simply just set it up with the lower bank address and it'll automatically be duplicated to the UB (& re checksummed) once you save the file. As the TunerPro SDK isn't redistributable I can only share the bin, however it's nothing special and just copies 0xEF2C - 0xFC16 to 0x1EF2C 0x1FC16 (607 bin, haven't checked the addresses for the 608 bin but can do if anyone needs) then re-calculates the checksum bytes. You just need to set it up in the xdf the same way as the current checksum plugin. Also uploaded the latest version of my IDA DB which I've done a load more work on, particularly adding cross references for indirectly addressed memory (RAM, URAM (added another segment for this which wasn't there before, its the upper 128 bytes of the CPU ram that can only be indirectly addressed due to the SFRs using the same addresses for direct addressing) & XRAM) (was a wild ride coming to grips with the indirect addressing in the 8051 CPU haha) and also setup structures for alot of the map tables to document them easier based on their configuration from the DAMOS (table layout, leading bytes, different eeprom/non eeprom headers, map table addresses, e.t.c.). Both the above can be found here