NefMoto

A client brought me a Golf4 he just bought. No ideas who mapped it or what chip/injectors are in it. It has a neuspeed supercharger kit in it. I took it for a short drive and it was detonating like crazy. I pulled the ECU and dumped the ROM.

It's a 06A906032FQ. I've been hunting for a stock ROM for comparison. No luck yet. I searched high and low to find a ROM/DAMOS/A2L pair that was similar. There is lots of 1.8t stuff but nothing for the little NA cars.

So I got a 06A906032MT from the local breaking yard and set about comparing them. I then used a 1.8t ROM and imported and translated the A2L for table descriptions and math. There many changes and I'm not sure which are from tuning and which are just year to year differences. I'm still waiting to find a 06A906032FQ ROM/ECU.

Some of the tables are proving very difficult to find in the two and I don't want to invest weeks of work reverse engineering both in IDA Pro.

Does anyone have other suggestions on how to attack this problem?

There is a stock file attached.

I have re-tuned one of these cars. I will say it was in the upper 2/3rs as far as difficult jobs I've done.

It is terrible software to work with, and I can't even imagine tackling it as a noob.

Thanks, that is incredibly helpful. The firmware appears to be only slightly modified. Since I don't often work with the ST processor I didn't pull them into IDA but it looks like a few small changes were made and a small routine was added to the end with the firmware checksum being updated too. I'll spent some time and see if I can identify what items were changed. Are you aware of any A2L or mappack available for this software? The thing I appreciate about Bosch is that there is often factory data available so the entire mapping and explanations of the strategy are known.

Are you aware of a way to read/clone the EEPROM on this type of hardware without removing the chip? Not the end of the world if I have to but the easy path is always better.

You can read the eeprom in bootmode with argdubs tool. As for the changes Neuspeed made, they are absolutely terrible. It's amazing any of these cars ran to begin with. You would be best advised to start from scratch (or,something I VERY RARELY ADVISE) hire someone with some (extensive) experience.

I wish I could tell you "Here is a link for the damos", but as I commented in your other thread, that's not going to be possible.

I didn't realize that their tune was _that_ bad. The firmware changes seem very small. Perhaps they've just prevented the ECU from being read via OBD2. I see 1 extra routine and a few bytes patched which I assume are probably a function call. I don't know ST assembly well enough to recognize the byte codes in a hex editor.

Considering that this file is all but hardcoded to lambda 1, I wish you luck.

I spent days on it. You will likely need years.

So I spent a bit of time on it. Found a number of the maps. For ones with external axes they seem to be a bit harder to find so please excuse the errors in 2h of work so far.

I think with fuel they're using an adjustment table like VE and making sure it kicks out of closed loop at higher loads. I have to read the functions definition file to get more acquainted with the bosch way of doing things.

Their ignition maps make no sense. The stockers make sense for an NA engine but why would you add a ton of timing at the top end where the blower is going to heat the crap out of the charge? (ignore bad axes). I'm thinking of just fixing the timing and making sure the fuel is reasonable. I have no idea what injectors they put in this thing but the injector scale KRKTE seems untouched.

Their file is very, very bad. It can and will melt the engine.

You will learn nothing looking at it.

The axis for KFZW are:

0x130B6 rpm
0x1310C olad

The customer is the son of a friend. I don't normally do bosch but I'm balls deep in it now. This is his second engine since buying the car 3 weeks ago. I said I'd help because well... kids are kids.

Thanks for the axes. What method did you use? Just a binary search? Compare against a known rom and look at offset or some other means? With some maps the dimensions are stored in the struct with the axes, others must come from the code. The second part is a bit harder to find and guarantee.

Spent a little time on the axes. Since I started digging into this I found a TT map where the calibration data isn't all that different. This Bosch stuff is significantly easier than what I'm used to.

Looking for KFZWOP, KFZWOP2.
I believe the air charge is at 16438 and the nmot is at 130B6.

The air charge is easier to find because its neighbours are identical and there aren't too many axes of size 0x0b. The RPM is a bit more of a challenge.

Here is how I did it. Since the axis structure starts with the size, I knew that I was looking for a 16 item axis. 16 bit also. So the axis needs to start with 0x0010. I located it on the TT map and tried to find the correct offset. The TT map has more axes but looking at it visually I think I got it right.

I'm assuming on this the air charge goes up to 100% since it's an NA engine and the TT goes up to 160 because of boost. Once I make the timing a bit more sane I'll stick it in the car and see if I can log what it's actually doing. The map doesn't need to be perfect, just stop the kid's engine from throwing another rod.

Retarding timing is going to drive EGT's through the roof. You might find you trade thrown rods for melted pistons. You should probably look into fueling. Mine wouldn't request richer than lambda1 under WOT......But then again I started from scratch. Have you even confirmed you can checksum the neuspeed file?

If it were my time at the rodeo the topic on how to tune and engine might be a concern.

Back on topic.

The checksums are not an issue.

The LAMFA table is messed in stock form both for the TT and the stock Golf. I've verified the axes in several ways. The axis is documented as mrfa_w. That comes from the larger of KFPED or FGR (cruise control request). The table itself doesn't make sense because it appears to request a slightly rich condition at low throttle but not high throttle. The Neuspeed map sort of tried to remap it but the axis is again wrong since you expect it to be searched in a strictly ascending fashion.

Below the single map image is what neuspeed did. The double map image is the stock golf and the TT file I'm comparing against.

The S4Wiki says: When requested lambda is <1 (richer than stoichiometric), the fueling system will go "open loop".
This makes sense but if the description were complete then the car would almost always run open loop.

Can anyone point out the main tables needed to get it into open loop?

You're the one asking for help. Judging by some of the things you're asking for, you don't know what's relevant and what isn't yet. My assistance will occasionally come with some comments that seem relevant to me. If you're not ok with that, I'll bow out and you can go back to doing it yourself.

Continuing onto lamfa, the definition files are wrong. The maps are fine. Before tackling something like this you should probably learn to recognize these things in order to prevent unintended side effects.

LAMFA: 0x1CAD2
%: 0x1CAC6
RPM: 0x1CAB6

You still haven't addressed the issue from the very first reply. What are you going to do when changing lamfa doesn't do anything? When the file stays at lambda1 the entire WOT run?

Thanks for the correction. The A2L data is in fact wrong and the offset for the axis is off by 1. Correcting it shows valid info now.

To address your first point. The target lambda has to have come from somewhere. Understanding how target lambda is derived and how open loop is selected should give the ability to change it. I'd be surprised if they hard coded all the targets to 1 but if I have to I'll patch the firmware I can.

It could be possible to push it to component protection enrichments when under boost. I could probably even disable closed loop entirely and fatten it through the MAF function. Or using their VE table. There are many ugly ways to accomplish the result. The first order is to pull some timing so it stops detonating then look at the fuel and see if there even is an issue.

As an aside, in general, these off by one errors are easy to spot: typically, they are for 16-bit maps, which should all be 2 byte aligned (for obvious reasons). You'll notice the off by one errors are always odd.

Definitely a good point and I should have noticed it. In most cases I've worked on we never had official data so it was a matter of pounding out the routines in IDA for weeks at a time so these errors would never occur. For those where ECU data was provided, it was a complete package with either source code or A2L data and binaries directly generated so I've never seen something like an off by 1 error.

Do you know right off what tables I should be looking at to affect the target AFR and affect open loop/closed loop operations? I'm trying very hard not to have to disassemble these roms. I know deep down if I do then I'm going to get stuck decoding and understanding these series of ecus.

I spent some time looking at dynos of stock supercharged neuspeed mk4 golfs. They were still lean to my taste but I don't see any reason why they had to be. Although I'm on the dyno for the next few days I'll be interested in getting this one going. I should probably build a board for the engine sim and go about testing that way but it's oh so much work and a 2004 is too old to make money on. Resisting the urge to go out and buy a VAG car and develop a proper tuning solution.

err sorry, edited my post.

Realized it was NA.

Sorry, IMO that stuff is a waste of time.

Even the SC addons by "pros" are a terrible hack.

Get a FI motor or forget it.

There is a reason nobody bothers with NA files.

I'd say get aftermarket ECU, if you want to drive that car.

Just a thought. For shittys and gigs I calibrated a 1.8t me7.5 file for a avh 2.0 8v. I did this because I plan on converting to forced induction over the winter but I wanted to get warmup, injector calibrated and drivability right. I added a map sensor, deleted vvt and calibrated for 630cc injectors. car runs perfect. No cel and passes state inspection. Possibly this conversion is something you might want to consider?
Good luck
Marty

Was going to say, why not just swap out the loom and ECU for a 1.8t member?

I like your idea. I've read a few different articles but none seemed to cover putting a 1.8t map on the NA hardware. The hw number I have is 0 261 207 925. I have the 7gb map collection the whole world shares around so I wonder if you might know what firmware would work on this hardware?

Can you educate me on this?

The addons that the neuspeed "pros" did seems a little amateur.

Is it that people were not able to find the proper tables to achieve what they wanted? I've worked a lot with Seimens and one thing I can say about the Germans is that they seldom get things totally wrong. Seimens is not bosch but looking at the bosch strategy they are not miles apart in their approach.

Our car is a immo3 me7.5 so any 02-05 1.8t file will cross flash. I'd recommend using the 032hs as a base to start with, there's a really good map pack for this software version on the forum. Changing krkte from 317cc to 240 cc will be enough to start and run the car, tho tvub will need some calibration along with a laundry list of other maps. Adding a map sensor is as simple as it basically sounds. You can use the stock coil pack and wires (at least I did). It really wasn't that bad

So you just flashed a 1.8t file over the N/A ECU?  I'm sure this was documented in another thread the other day.  So, once you've flashed the file, you just manually wired in a MAP sensor to the appropriate pins on the ECU, and Bob's your Uncle?

I'd guess that all the ME7.5 ECU's have the same pinout, so would it be possible to just swap in a 1.8t ECU and hand-wire a MAP sensor?  That would save all the heart-ache/headache of the thread I'm talking about where the user has to get the correct freak N/A ECU.

I think the point I'm trying to make is that if it's possible to just swap out the ECU, this is THE best approach, as attempting to trawl through IDA/boost an N/A ECU is too complicated and time consuming.  Modifying a file already suited for boost is much more suited.

As said, the HS map pack is plenty for what you need.  There's also a well defined CB and HN file.  If you want the HN one, have a look at my post on the ECU section, can grab a copy from there to help you along.  :)

Basicly yes. Car is still running on the 2l ecu. I had a o2 sensor heater code, and open circuit codes from the missing coil packs. Few other things I can't think of off the top of my head. I plan on swapping to a 1.8t ecu after the turbo conversion so I can use n75 to control boost.

I considered running a 1.8t binary, but when it came down to it, I decided to stick to the 2.0 for the experience. It wasn't my first supercharged file, and I knew I COULD do it. I now have a pretty decent 2.0 definition, and an easily portable 2.0 supercharger file for the future, as well as the experience of overcoming the various difficulties associated with it.

I wonder if the OP is now thinking - will you sell it? :P

Negative, but I will gladly help him find whatever he needs.

Marty, did you ever figure out why you had the 02 heater code? I checked, and both ecu's use the same primary 02 sensor, and the pinout was the same. Everything else worked correctly.

Ultimately this car is too old to make any money off a tuning solution. It's not my car and I don't have a huge amount of interest in slogging through it for weeks on end. Tomorrow I'll pull the eeprom off the board and clone it on to another ECU and try to tune it. I'm pretty confident I can make it run well enough that it won't blow up or melt down and send him on his way. I have a number of other bosch based projects I can pick from that can keep me busy and paid.

I just deleted the heater code. It's happened in the past trying to use a 2l ecu for a 1.8t. I never had good results. Ultimately I plan on using a 1.8t ecu when I convert to turbo. Main reason was I had a Cali emissions bbw 8v vvt and it popped. I converted to me7.5 kept the returnless fueling, used a avh non vvt 8v and calibrated for it. Fkvvs needed some tweaking for static fuel.

Thanks for the info, Marty. I wonder if there's a scaler/map to change the threshold for this (the heater code).

Pulled and backed up the eeprom. I'm flashing the new ECU. God it takes forever. If it wasn't so much trouble i'd be tempted to build a socket to plug an old moates ostrich on the board in place of the flash chip.

Small interesting detail about the neuspeed ROM. I noticed that they'd patched the firmware but never bothered to look at it further. Their patch prevents the ECU from being read back over the obd2 port. I read it successfully. Flashed in the neuspeed map, it wouldn't read back. So I flashed a stock file back in and it read back just fine.

If for whatever reason a flash fails in the middle can it still be recovered via obd2 or do you need to bootloader it?

If power isn't interrupted you can just reflash the file soon as you kill power on next power up it will be bricked. Anytime your changing software versions always best to bootmode flash

The MPPS asks you to turn the key off and on. Does that mean killing power or does the constant power keep you in the green? I will at least have the original ecu on hand if I need it, just needed to know so I'll keep the backup ecu on hand.

Here is something eeprom-curious...
The ECU out of a factory stock ECU has proper data in it but the neuspeed eeprom has a lot of blanked out stuff.

Last update because I'm done for the day. Cloning the ECU was a success. I decided to take it for a quick test drive to see how good/bad the neuspeed tune was. The fuel is pretty close to where I'd want it. The blower is making a maximum of 6 psi. Cold start was OK (temp today is about 40F or 5C). Cruise was OK around stoich. As soon as I made a few pounds of boost it dropped to the low 12's. Without logging and detcans I didn't want to push it too much.

The car doesn't feel great but the fuel seems to be OK. I'll get some logging going to see how the fuel trims and target lambda are compared to what the wideband says. Despite the previous engine dying with a broken rod it feels like it's got too little timing in most areas.

Are there any opinions on how much timing the 2.0l 8v will like with 5-6psi of boost?

Applaud for getting stuck in! :)

Got the car out tuning a little. I think I understand a little more about it now. I am told it has larger injectors and a larger MAF. I think what's going on with the fuel situation is that the larger injectors and maf cancel each other out close enough that it works. The problem currently is that the %load peaks out around 50% so this explains the detonation problems the car suffered in the past.

Can anyone point me toward how the % airflow is scaled?

SMH

MLHFM.

The underscaled MAF ensures the load stays low under boost because the ECU can't handle FI loads. The ENTIRE torque model is screwed up.

This is why noobs shouldn't try to run NA ecus on FI equipment. This includes neuspeed.

It was clear on page 1 that he wasn't interested in doing a proper job, just getting it passable.

MLHFM looks like it's just the MAF table itself. I can rescale this for the proper MAF and change the injector size so the vehicle runs correctly but I'm interested in knowing how the MAF airflow is translated into the UPM % value.

No clue what you mean by "UPM %", but:

http://s4wiki.com/wiki/Load

And if you "fix" the load to be correct, the ECU won't know WTF to do under boost.

Again, for the umpteenth time, you're using an ECU designed for NA, not FI.

UPM was airflow per minute or the axis used on most of the tables. In my case the concern is mostly just the ignition table. I've done some research and found that the car has a VR6 MAF and "green giant" 440cc injectors installed. I expect this explains why the car never goes above 50% load yet the fuel is perfect.

I'm thankful for the help people have been providing but a simple answer "won't work" explains nothing to me. At present the car runs, starts, idles and drives reasonably well considering. The load numbers do need to be corrected so the timing map can be used properly but I'm not seeing anything here that is so critically wrong.

Why will the NA firmware not run boost?

Itemize every map that uses load as an input. Now, rescale the axis for each one, AND its corresponding data.

Now you'd also better pray that the load scaling used doesn't hit a representation max (like the pressure limit in ME7).

Of course, you can then go and scale EVERY single piece of load arithmetic in the system to give you headroom there too.

You can make anything work, that isn't the question. The rabbit hole goes pretty deep. Every hack thinks 'well this is good enough' until something breaks or somebody gets frustrated with shitty drivablility or codes that keep popping up.

Ok, I understand. I know that a number of NA cars have items that actively prevent you from going into boost so I needed to make sure it would not suffer from that.

The car arrived running like crap and it blew up an engine before it came to me. While I'd love to do a perfect job this project is being done as a bit of a favour and to get some bosch experience. I pulled a bunch of timing out of it to stop it from detonating and the guy already thinks it's amazing. With limited resources and no budget to replace sensors, ecu and wiring for a boosted ecu there are not many options. Hope this explains why I didn't go ahead and swap it over to a 1.8t. I'm not going to pay money to work on a guys car.

I'm going to rescale the injector and MAF table to gain the amount of load I need. If the torque system gets in the way too much then I'll strike a balance between the extra 30% power it needs by underscaling them slightly.

With the MAP/Injectors scaled correctly can anyone point out which tables I'm going to need to adjust for the torque system? In other ECUs I'm used to having a gas pedal (APS) versus torque or airflow type table that attempts to achieve the desired airflow based on the APS position. I've been reading the functions descriptions documents but it feels like there should be a strategy document like seimens does to better explain each module and how it operates.

This is not a good way to get bosch experience for a noob; the best route would be to start with basic stage 1 tune of a car with an FI system in it stock.


There is, but unfortunately it is probably more general than you want.

http://files.s4wiki.com/docs/Audi_S4_engine_english.pdf
http://nyet.org/cars/info/ME7sw.pdf

Personally, what he's achieved so far is well beyond that of a noob, and his understanding of terms and what he's doing seems to be a little underestimated. 

I really think for what he's done so far deserves a pat on the back; and I don't think he's "that" nooby.  It's been said time and time again that this isn't the right method for doing what he's doing, we get that. 

I'd try and rescale the injectors and MAF, but I think you're going to hit a limit, so while I'm all in for trying, I don't think it's gonna work.  Try it first and see how you get on, and document what you're doing and how you're finding it.

If it doesn't work, stop spending time on it, hand it back and get on with more important things in your shop. :)

+1

I don't like to go on a site and talk about what I know and what I've done in the past. It is far from my first time at the rodeo and I've worked on ECUs and tuning professionally for over 15 years. I've written firmware for standalone computers and I've worked on OEM software so I have a pretty good idea how most strategies work and I've seen Bosch is pretty similar to siemens which I know a thing or two about.

Back on topic. I tried following the instructions for rescaling the MAF. Google told me that the stock size was 65mm and that the VR6 was 73mm. So I tried a 26% gain. I also hacked up a real VR6 file but was told that copying the MAF table from that would not work. I wasn't very successful at finding the stock size injectors to scale the injector size so after a few tries I managed to get about 10%. The load is now maxing out at 70% so it's going in the right direction.

The car idles with a -15% o2 correction but driving it's more like -2% so I think I will go find a file from a car that had the green giants from factory and steal the latency table. For the MAF I'm just going to scale it another 10% to expand the range of the load value. The driveability has gotten a bit better too. Given that this thing is probably going to add only 30% more power I don't think a maximum of 100-110% load is going to have any significant downsides in driveability.

I also invested some time and wrote a tool to decode my collection of A2L/.hex files and find a file that is better matched so in a few hours I managed to buid a competent mappack. I have had no success with me7logger or visualme7logger. I've been logging the blocks using eurodyne.

I also hacked up a perl script to process the logs. The output looks a bit like this:

./stft.pl *.csv
Processing 1445815696.csv
Processing 1445821450.csv
           0.00  500.00  750.00 1000.00 1250.00 1500.00 1750.00 2000.00 2250.00 2500.00 3000.00 3500.00 4000.00 5000.00 5500.00 6000.00 7000.00 
   0.00  ------  ------  ------  ------  ------  ------  ------  ------  ------  ------  ------  ------  ------  ------  ------  ------  ------ 
  32.00  ------  ------    5.08    6.58    7.75    1.90    7.91    8.24    5.64    5.88    3.70   -3.71   -3.60   -1.17  ------  ------  ------ 
  48.00  ------  -11.59   -0.99    1.34    1.66   14.73   -0.72   -0.98    1.16    3.35    0.43    1.55   -0.78  ------  ------  ------  ------ 
  64.00  ------  ------    0.49    2.68   -1.70    6.88    1.60   -3.84   -0.97    2.41    0.09    2.32   -0.59  ------  ------  ------  ------ 
  80.00  ------  ------   -0.48    1.35   -2.34   -0.40    3.50    0.09   -0.66   -0.17    1.51    2.70   -0.39  ------  ------  ------  ------ 
  96.00  ------  ------   -1.51    0.29   -0.64   -0.61    2.95   -1.57    0.92   -0.06    0.31   -0.29  ------  ------  ------  ------  ------ 
 128.00  ------  ------    0.20   -0.72   -0.69   -1.58   -2.42   -2.86    2.37    0.72    6.79    8.12  ------  ------  ------  ------  ------ 
 160.00  ------  ------   -2.93   -0.78   -1.19   -2.28   -3.91    0.08    6.02   -0.18    8.74   14.71  ------  ------  ------  ------  ------ 
 192.00  ------  ------  ------   12.89   -2.34   -3.16    8.05    6.28    5.00   -0.09   -2.00  ------  ------  ------  ------  ------  ------ 
 224.00  ------  ------   13.28  ------  ------   -1.95    1.09    3.20    1.80    3.61   -2.93  ------  ------  ------  ------  ------  ------ 
 256.00  ------  ------  ------  ------  ------  ------  ------  ------  ------  ------  ------  ------  ------  ------  ------  ------  ------ 
 288.00  ------  ------  ------  ------  ------  ------  ------  ------  ------  ------  ------  ------  ------  ------  ------  ------  ------ 

Excuse the fact this example is not actually from a ME7 but you get the idea.

2.0989   1.3202   0.9174   0.6694   0.4987

8, 10, 12, 14, 16 volts. I just rescaled the axis with these values (from 6, 8, 10, 12, 16) for obvious reasons.

Make sure when you scale MLHFM you take into account the offset (200) that must be subracted from it. This will leave you with negative numbers, representing reverse flow areas.

Realistically, the stock MAF and housing can be used, and will drastically cut down on the amount of work you have to do here.

Does the stft perl script average values for every load/rpm from a long log file to present that table? If so, would you mind sharing it?

The perl script does average the values. It is a little simpler than the tuning software I designed since it doesn't know anything about standard deviation but it is effective. It also has some stuff in there to exclude ignition values when the engine is knocking and so on. My intent is to share the script once I've cleaned it up and made it easier to configure. It does work on a unix machine so I assume that will include OSX and I've tested it on windows too.

I LOVE IT

BTW you might want to exclude accell/decel conditions as well, not sure how much filtering it does, but it should throw out samples where rpm or load is changing...

or, even better, generate accel/decel graphs separately!

During accel and decel the vehicle shouldn't be in closed loop so it will by default deal with that. The main intent was to make fuel and ignition trimming easier. If I decide that more is needed then I'll just write a module and use real tuning software. This is quick and dirty and does 99% of what I need.

not talking about total throttle off or WOT, there are partial throttle cases where you are still closed loop (even narrow band)

I'd have to dig through the thousands of pages of EPA standards but I seem to remember reading that in decel fuel cut the vehicle should go into open loop. In fact I think there is even a status bit for it in the mode 1 requests.

For accel enrichment I believe it should be the same deal but not 100% certain. I haven't found a big need for this because accel enrichments usually involve a stab of the throttle and a corresponding jump in load so the settling time passes before the values are used. In any event the script is quick and dirty but quite effective. Any chance you could try to log such a thing to verify? I have not had any luck using me7logger on this ecu.

accel/decel is not just pedal position change. It refers to increasing/decreasing load (req or actual)

fuel cuttoff is an entirely different topic, as is open loop fueling... in general increasing load fueling will NOT go open loop, except if req lambda<1 (BTS, LAMFA, etc).

Not trying to thread jack but this seems like a good place to ask.

I have a Canadian 2008 City Golf (MK4) 2.0L BEV with the Neuspeed SC on it running a ME7.1.1/06A906032RF ECU that Neuspeed "tuned".
Aside from the SC it's got a TT268/260 cam and a PFlow intake but the rest of the engine is stock.

It's been my daily since I drove it off the lot and has run well so far - but reading the comments about how poor the tune is I am wondering if it's time I looked at the tune to make sure it keeps running right. (I always heard rumors it was bad.)

I have backup the NS tune and eeprom (boot mode with a home made bench cable) - learned how to SOFF everything, and I got my orig file from NS as well. (just in case I need to pull the SC off I can just swap in a cloned ECU with my orig file - I picked up a 2nd ECU cheap).

I have no problems flashing things and doing simple stuff, but the tuning side I have zero experience with (I am not really a car guy - I fix PC's all day) and the comments here are making me think it would be a bad place to start. With that being said does anyone have a suggestion for who to talk to about getting a improved tune done for this oddball setup? (If it's even worth it since I am likely not going to be doing anymore to it since its my DD.)

The trouble with the car I had to fix up is that it was a basket case of previous owners and mods that deviated from the original NS setup. It started as a favour to help a friend's son but I'm no stranger to tuning. While I'm new to the Bosch thing I bring with me 15 years of experience in tuning and working factory calibrations. While it ran horribly on this car I suspect it would have run acceptably with a proper set of components.

So don't assume your NS tune is that bad. Also don't assume it will be easy to fix if it isn't great. You probably have to find someone in your area to look at it. Trouble is, only about 1 in 10 tuners are good enough that I'd allow them to tune my grass cutting equipment.

Any news?

No one does custom tunes local for VW's where I am here up in the frozen north. Closest Canadian tuner is over 2300km away - if they even will want to look at it is another question entirely.

I've been too busy lately. I had to shift to the next project for a bit so I haven't had time to work on it.