NefMoto

Hi Guys,  I havent posted much to this forum so i will contribute.

I have been using the Moates Road Runner emulator with great success for quite some time now.

Works with both PSOP's 400/800.  Flash time is about 10 seconds.

The Ribbon cable is from Samtec part number FFMD-22-T-06.00-01-N

The Trick is that the pin orientation is reverse so you have to desolder the pins on the roadrunner board and solder them back in on the opposite side of the board.

If you have questions let me know.  I havent had the time to write and sort of adl for Tunerpro so i have been using this unit stictly as a faster flashing option when tuning on the dyno.

(http://i113.photobucket.com/albums/n235/scarboroughdub/F673A4DE-F074-4D23-8991-38315A09733C-1822-00000134A8A609D3.jpg)

(http://i113.photobucket.com/albums/n235/scarboroughdub/9BEF9870-C4AB-4686-95E9-7D2724C0FF47-1822-00000134AF4D0942.jpg)

enjoy.

Funny you should mention this!

I've been working with Craig at Moates and Mark mansur of tunerpro and very shortly like in the next week, we will have an adapter board specifically for the me7 ecu designed to place the roadrunner inside the case and keep the lid on and have the usb cable out the small rubber bung and to have byte swap built into the board thus edian swap isn't required.

Also tunerpro will be fully compatible and new version released to support both 16bit and 8 bit emulation.

I was going to wait until it had been tested fully but as you mention it seems like a good time.

I've already started creating .adx files so datatracing and gauges can be used.

Good work though...

Plan is also to use the cables you have but as the adapter board is byteswap you can use original cables with no modification allowing 1 RR unit to be used on multiple Ecu's

Where do I sign up!?

if you use winols like i do, you dont have to use winendian,  go to Hardware>swap lines,   and check swap lines.

Now each time you do a file export it will export with swapped lines.

i still use emutility but as long as you maintain the same file name you can set emutility to sense code changes and it will automatically upload,  so essentially  CTRL+E   enter enter enter. and bam your good.

Haha...

Here I guess..
If you've got a roadrunner then the adpater boards will be availble very shortly, I had an email they went into production last week and we should have the first lot for testing in the next week or so. I'll need to check with Moates regarding distribution but I'd imagine they're be purchasable from Moates directly.

Currently Tunerpro supports Roadrunner but it has a few restraints at present. You can use emutility and the tunerpro plugin along side PRj's patch to allow real time emulation, and Tunerpro does similar but presently only supports the 16 bit maps as the tunerpro has a bug so the 8bit tables wont emulate but that's being resolved as we speak and Mark said we would have a beta version this week, so hopefully in the upcoming days all being well it will be ready for testing as well.

I'm hoping that this is going to be very useful to the me7 community..

Goatman, very intersting about Winols, I hadn't pursued it yet as I was just concentrating on getting a working solution from Mark Mansur before exploring other tuning packages and as tunerpro is essentially free $39 registration free it goes well.

I see this in my feature  :)

Oh hello!
Do want!

Well I've just got an email from moates to say test adapter boards are ready for shipping so hopefully I'll have them next week and if all ok production will be straight away .

2 boards will be available , one with byte swap and one standard, cables are also being made which I think will negate the issue goat man had in swapping the header pin over.

I'll probably start a new thread if its ok with the mods with all the details etc .

Hopefully at last we'll have an affordable emulator for the me7

That sounds awesome.
Any idea what the price will be?

Oh and we have a full smt setup at work if anyone needs help soldering their ecu ;-)

I just want to clarify: will it be able to trace the maps like with Ostrich?

I must have a really old copy of tunerpro, I just dropped my jaw when I looked at the v5 RT..

Im definatly switching to Tunerpro if the Roadrunner will support tracing/datalogging.

Have you looked much at tunerpro rt? Live emulation on 16bit maps currently is working, its been tested and works, 8bit is currently being sorted as a bug was found in writing 8bit values back to the emulator in realtime .

Data logging,gauges and data tracing is supported in a similar way to any other realtime data logger or even the me7 logger. In tunerpro rt you create an .adx file which basically configures your tunerpro .xdf to associate known variables such as nmot, wped, etc etc so you bind the axis in the xdf with your variable associated with it. The good news is we take data we can get from me7 logger .ecu file and add it into the .adx . Once you have made your .adx if you look in .xdf file for your Ecu one of the tabs in the edit box says "associations" and here you add the .adx into your .xdf and bingo you're good to go.

Once the adapters are done and tested I think the hardest part will be creating the .adx files but once one is done and posted similar to .xdfs they be easy to customise. I've been getting to grips with making .adx files and its not that hard but I plan on writing a how to. The more people we can get involved the more comprehensive it can be made.

I have not used Tunerpro much at all.. But im sold now :)

Im getting a RT license asap and getting to work with the definitions, thanks for all the info littco!

You can run RT without license but it has a 10 second delay in loading, I have a license solely as mark is putting in extra work to help get this running properly so its a small to pay really .

Are they looking for any additional beta testers?  I would even be willing to pay the projected retail pricing and do testing.  I have literally stopped developing on me7 because of lack of an emulator and my busy schedule.  It may seem silly but it just takes too much time in a given day when trying new things and spending so much time flashing.

I have no problem writing the .adx files either.

Sort of relatred, I almost have openport 2.0 def files ready for the popular 7.1 ecus because I like the standalone data log feature of their hardware, plus the input for a lc-1.  Been testing it on my cars and so far so good.

As far as I know, all that needs to happen is for me to check the adapter board works as planned ie locates in suitable position on me7 and the byte swap is correct, shouldn't take more than a day to function test then the boards will go into production, the road runner guts kit is available now but obviously not as needed. I know Craig @ moates has a couple of spare adapter boards made up so drop him a line , all being well the boards should be available in the next few weeks.

This is is a nice idea for hobbyists.


I think it should be focused around TunerPro as any hobbyist with OLS is likely to be (95%+) using a cracked version and isn't really helping the community.

TunerPro is much more powerful than OLS anyway.
Only real reason to have it are checksums and DAMOS import.

But if you don't have DAMOS and are not working on a standard ECU, or would like to look at data in a slightly less normal way, then you are screwed.
If OLS does not provide a checksum for your ECU, you are screwed too, because it is not possible to write a custom checksum plugin.
Try viewing Smoke limiter as AFR map in OLS or calculating MLOFS into MLHFM ... not going to happen.

I wish OLS also had an ability to define custom equations referencing multiple other values, and not only offset and factor :/

Super cool. I'll be picking up a setup when they are available.

There's a manual checksum that can be used there, if you can't include MLOFS in MLHFM then you don't know enough about OLS :D

As for a smoke limiter as AFR, I doubt it's really possible, because the mg/h value for fuel needs to be relative to a mg/h worth of air, or am I getting my wires crossed here?

That's a joke and won't work for anything non-standard. I mean writing my own .dll module.

Yeah, hardcoding it you mean. And if you change MLOFS you have to update it each time?

Ever looked at what the axis is on the smoke limiter? And what the values are?
I don't know how you tune diesels, but smoke limiter is AFR/lambda rich limit, so makes sense to look at it as such.

Example:
(http://prj-tuning.com/wp-content/uploads/2012/01/smokelimiter2d.png)

Much better as:
(http://prj-tuning.com/wp-content/uploads/2012/01/smokelimiter_afr_2d.png)

So quick update.

Adapters boards should be with me in the next day or so and I've just had an email from TP that 8bit emulation is now working, needs to be tested properly. But looking good.

I'm really sad that you've come to a change of heart like that.  It is completely untrue, and every time I hear that it makes me think about the jerk-off's over at chiptuners.org and their damn elitist ways of talking down to people.

People on this site have done more for the community using TunerPro & whatever version of OLS then anyone on that site or any other to be honest.  And I wouldn't be at all surprised that people on that site are using this sites info in their own tunes without even bothering to give credit.

I totally agree.
I have personally put a lot of time into this with both moates and tunerpro to get a product hopefully equally as good as winols but at £00's rather than £000's.

Hobbiest or pro . Live emulation is live emulation. You still need to know how to map and neithrt winols or tunerpro makes you a good tuner or any more capable. Whether this remains a hobbiest toy or a viable competitor to evc. The more work put into tunerpro the more powerful it becomes.

I hope with this cost effective emulator the me7 can be pushed further than it is already.

I know for 100% certain that a few tuners, over here in the US and over there have taken developments from here and implemented them into their files and even offered updates to old files with things.  Pretty hypocritical after all that screaming for years about how they are the wizards and they wanted to protect us from ourselves and all that bullshit.

Good news is for their customers who now have better tunes. ::)

Jared, that is a given... It's impossible for one person alone to find all of the little secrets ME holds, but here as a collective people are able to work on and (un?)discover things that people would have never thought of.

The one main difference about NefMoto vs. almost ever other forum (or maybe even EVERY other forum) is that most here are genuinely doing it for the challenge and to move the platform forward.  For a long time everyone was in the dark and tuners made it seem like they were performing magic and while they kinda were, it just stopped at the basics for most.

I am absolutely looking forward to this emulator experiment.  I don't really tune for money, I just don't have the time but as long as I either own an ME car or have close friends that do I will always have something to tune/play with. 

Sad how?  Because i think that most OLS copies are pirated?  How is that saddening?  I'm all for this project because it allows people who don't do this for a living get a cost effective solution - what's wrong with that?

People do take credit for what isn't there own work, but there are 'pros' that have done some pretty advanced things that aren't on this forum.  Is that wrong?  I like to get ahead of the competition if I can in order to be financially secure as well as for the buzz!

Rick

It has nothing to do with the legality of OLS.  It has to do with people thinking that if you don't own a legal copy of OLS and use TunerPro that you're not a "real tuner"

I know you know this because you're in the "pro" section on chiptuners.org, but do they or do they not accept people that use TunerPro to tune cars?  They don't, they're a bunch of stuck up people that huddle in a closed circle snickering, pointing and laughing at people willing to learn.  Tell me honestly that they don't talk shit about Nefmoto.  I bet you that you can't.  It's not just them either, it's many other circle jerk types that are in/around Motronic tuning.

Back to OLS, software piracy happens all the time.  It happens because people don't care, or people cannot genuinely afford certain programs in order to learn how to better themselves/learn something.  Is it right?  Of course not.  But that doesn't mean they should be talked down upon, especially the way people go about putting EVC's platform above anything else.  It's all a load of horse shit IMO.

I thoroughly enjoyed your thread about different level users and attitudes on chiptuners.

That is all, carry on.

I would have bought WinOLS a long time ago if EVC would sell it to me.

Until then, anybody who doesn't suck EVC dick and/or knows the magic handshake is stuck with TunerPro.

EVC has the weirdest sales approach ever. "No, we don't want to make money off of you".

I guess the new chiptuners definition of hobbyist is "people EVC won't sell to".

And who the fuck knows what their requirements are. I still have yet to hear anybody explain it to me in a way that makes sense.

Had a similar experience with very good friends of mine who's sole business for over 15 years is tuning.  I mean that is ALL they do.  EVC was beating around the bush and he had to jump through hoops to finally be "allowed" to purchase it (because I told him that for the business he is in, it's a worthwhile investment after spending over 15k Euro on other software/hardware from Italy failed miserably).

Sell it only to a few people and thus you can justify the ridiculous cost of the emulator! While it might be a specialist tuning tool at the moment it suddenly looks very expensive when a product doing the same is available at a fraction of the price!

AFAIK EVC will only sell to a "business" aka, you have a domain name, email address and prove a business(LLC) in my case.  Which i agree is kind of stupid, money is money.  If they sold a stripped down version to hobbyists, that maybe included checksum for only what they wanted for say 4-500 they would be making a TON of extra profit.  I dont understand their business model either.

Have you tried emailing them about a license recently?

I am a legit, brick and mortar licensed, accredited and insured automotive tuning business and have been since 2003, they refused to sell to me.

I work on the highest end cars money can buy and I tune any ecu I can get into.  I am a authorized dealer for multinational companies such as Cosworth.  EVC wouldn't even respond to me after over a year of contacting them.  Then finally they had the nerve to tell me I wasn't the type of tuning firm they dealt with.  No explanation, but I can make an assumption, I have always and will always share information.  Fuck whoever calls the shots at that company, don't need you.

Unfortunately, that is provably untrue. I can back up ST's claim.

EVC are a bunch of asshats.

You think they follow nefmoto closely enough that they know your real name and business' name, and refused to sell it to you based on your online activities?

They're retarded.

Edit: Meaning, that's crazy dumb if they do follow that closely that they blacklist businesses that post on Nefmoto.

so... who can share a full copy then? I tried some downloads in the past but they were virus laced junk....

I have 2.36 (legitimate) through a buddy, I can ask if he'd mind me sharing-lol

^^^ that's probably not a good idea for him if it truly is legitimate.

Think we should probably get back on topic :)

Well I was hoping to have started an official road runner me7 thread by now but I'm still waiting on customs to clear the adaptor boards to test! Got to love Royal Mail!

Anyway, I now have a fully working 8bit/16bit tunerpro RT beta copy. Its fully tested and emulating perfectly. Which is a huge credit to Mark ( mansur of TP)

He has offered to help in anyway he can to make this as powerful as it can be for the me7

Until I actually get the adaptor board and test in the car I'm holding off formally launching the revised TP and RR just to ensure it actually initially works as planned. Its all looking good though.

Estimated price for everything?

Well currently the RR guts kit is $500, tunerpro Rt is free but I'd people will pay the $39 donation to Mark to remove the 10second advert. And I can only imagine the adaptor boards being 10's of $ but no price yet. Custom idc cables are being produced as well and headers for the EcU are $10.

Adaptor boards will be Around $30, obviously 1 is needed. If you plan in swapping around on ecus then idc cable can be used.

Headers are $10 bucks huh. Might have to get a few sets of those.

Question:

Once you have your tune dialed in, what are you guys doing? Removing the headers and installing a normal eprom, or (more likely) putting another ecu in and keeping the emulator in the spare ecu. Noone is actually leaving these things in there permanently are they?

I drove my RS4 with it permanently in for a month... but yeah, I have a few different ECU's with the header in so I can swap it out and then swap the old one back in if I am tuning something.

I bought a collection of ecus to test the RR on. I guess ideally you flash your good map onto a main Ecu . I know PRJ leaves his Ecu/emulator permantely in his car with no issue.

If you plan on using maybe to tune other cars then once you've tuned it with your Ecu setup you put the original back and flash the map. As many of the me7.5's are cross compatible you could in theory use the same Ecu for multiple cars.

I have 1 for all the s3/tt's me7.5 , me7.1 for the f400 , me7.5 for the b6 a4 and me7.5 for the seat lcr . Pretty much covers all the vag 1.8t cars.

Sorry I totally forgot to stick the encryp board in the post to you. I'll do it tonight.

Cool, sounds like progress.

Are you still coding ECU into test mode or checksumming as you go?

Rick

I'm coding it into test mode and there is also a small patch required so it starts with an invalid checksum. But if you sum on save it's not important.
Not coding it into test mode means that if you get unlucky, then at some point you are going to be stranded with a non-starter and checksum error code stored in ECU. Even if you correct the checksums on every read/write.

This is because the ECU is constantly summing itself, and if you change data while it's summing a specific region, the checksum can fail.
I believe OLS300 has the same issue ... so the test model is recommended either way.

Is coding it into test mode a simple change in the flash (like a table/constant) or some other type of hack?

http://nefariousmotorsports.com/forum/index.php?topic=274.0

We should talk to Road Runner to see if they'd be interested in a group buy when this initially hits.

Gracias!

UPDATE

Adaptor boards arrived yesterday, both boards fit perfectly into the me7.5 and allow the lid to close and look like stock .

Normal board has been tested and works perfectly just as Goatman and Prj have said in the past. You need to load the emulator with an endian swapped file then use TP and emutility with a plugin to get it work, changes made and saved to the TP file automatically update the emulator in seconds.

The byte swap board isn't presently working as we need to check we have the right lines swapped, once this is sorted then live emulation will be possible, the new version of TunerProRT is also finished so supports 8 and 16 bit . 

Have to say its amazing, even its current form map changes are so simple. Takes about 10 seconds to make a change in a map.

Does any one have a schematic of the psop44 and lines to byte swap, I have one from Moates but want to check it. 

(http://i45.tinypic.com/359lac8.png)
DQ0 swap with DQ8
DQ1 swap with DQ9
up to
DQ7 swap with DQ15

So the normal adapter is just acting the same way as swapping the header on the Moates?  Presumably just plugging into the existing header?  Do Moates supply a decent PSOP55 to header adapter adapter?  The pics I've seen the horizontal spacing is off, so you'd have to make something up...

Rick

The PSOP44 header they supply is fine. Hot airs right on.

I know someone that has a Moates so I think i'll have a play.  I'll order one of their headers, use OLS to export byte swapped, swap Moates header around, use a test mode bin and see what happens :)

You don't need to swap the Moates header around if you are exporting byte swapped.
You either swap the header, or export byte swapped.

Just run EmUtility to monitor the file you export to in OLS, then export byte swapped binary with OLS and overwrite the file each time, and you should be good.

That makes sense.  The OP seems to contradict himself by saying he is swapping the header, then saying he uses OLS to export byte-swapped.  Guessing he means header is swapped when using Tunerpro.

Rick

Hi Rick,

 The cable he is using reverses the polarity , so you would need 2 cables to use RR with cables, he is using 1 and swapping the header over to the other side to achieve the same thing as 2 cables. With One cable pin 1 becomes 44 etc etc with 2 cables you reverse the reverse ... You then need byte swap..

The adaptor I have is supposed to have the correct byte swap lines then, I need to check them and for shorts..

If pin 1 becomes pin 44 and pin 2 becomes 43 then you can just flip the cable round on the header.  Or are you saying it is mirrored, i.e. Pin 1 becomes pin 23, pin 2 becomes pin 24?

Rick

Not sure Rick, I've been dealing with Moates on this and they said we'd need 2 cables linked to get them to correctly work. They are having some custom made cables made that are correct from the off so only 1 cable is needed.


Also the byte swap adaptor board is WORKING.......... There was a short between pins 4 and 40.. It's fixed and emulating ...

I can connect with Vagcom on the bench and emulate

I will test it in the car tomorrow on the way to work but I am confident it'll work .

Now for anyone who isn't aware with the new version of TP soon to be released, 8 and 16 bit maps are supported. Also if you use the 2d or 3d map to adjust settings it emulates instantly, using the text box to make changes need you to hit the emulate button or E ( or what ever you assign ) to upload the data to the emulator.

With the byte swap now working data trace and gauges should be working...

I have to say, I used the emulator on the way to work today, so so much easier better to map a car.. its so fast I made map changes whilst waiting at the traffic lights.... Sod this waiting 5 mins while you flash the ecu and hoping it doesn't brick!

Great stuff :)

Yes, emulation is awesome but sadly it's a thing of the past nowadays :(

Rick

Not on a hobbyist's budget it isn't.

Not awesome or not a thing of the past?

So what's current then? How many tuners actually have an emulator?

Hobbiest or pro.. There are alot of tuners out there that would benefit from this..

A thing of the past. I think a lot of people here forget that most of us are doing this for the fun of it, and don't really feel the need or desire to spend 10000 dollars tuning a single car.

I think littco did us a great service here, and to insinuate that it's not good enough because there are better methods out there just isn't appropriate.

I assume that Rick meant the fact that there is no emulation available for ME(D)9 and MEDC17 systems besides CCP and ETKs (used by OEMs).
ME7 is kinda "in the past", because a lot of popular "tuner cars" use more modern systems.

/\/\

That's exactly what i mean.  I would love to be able to emulate newer ECU's but so far can't!

littco, thanks for more info! Im sold on one of these :)

What is the hold back to emulate 9 or 17?

Update:

So emulator is working like a dream with adaptor board and new tunerpro.

The ability to change a map whilst the car is still running is brilliant. Only issue I had was once the car failed to start after a new flash but a recycle of the ignition and it fired up .

Took a friends s3 out tonight loaded a stock map and set about mapping it , 25 minutes later numerous map changes and not turning off the car once it was at a very acceptable stage1.

I haven't managed to get data trace working yet but I am in contact with mark Mansur about this so hopefully soon it'll be sorted. Likely to be me not setting up correctly.

I haven't been around here much since I sold my Audis a few years ago, but I have to say I'm overjoyed to see how Nefmoto has grown and developed into a useful resource for the tuning community.  At Moates, we've always been kind of mystified by the attitudes shown by "tuners" in the German car communities.  The kind of open sharing we see here brings joy to our hearts.

At this point, everyone should give Dan a big thanks for the testing he's done towards making the RoadRunner a more viable option for ME7.  We're continuing to work with him and with TunerPro's author to improve the solution.  Within a few months, we hope to have worked out the hardware and software aspects to the point where using ME7 with our products is well documented and straightforward.

Things are NOT quite there yet.  Things seem to be working fairly well, but I'd consider things "beta" right now.  We welcome early adopters, but please understand that the reason we're not marketing or really mentioning this very loudly is that there are kinks to be worked out.  With that said, if you want to get in on the action early you're more than welcome to.

Current status:
-We have an *extremely* limited number of hardware byte swap boards like what Dan is using.  After we finalize on a design, this will be a regular stocked item.
-The official public version of TunerPro has the issues Dan mentioned.  Beta software is available for testing by emailing us
-Hardware tracing is NOT working, even with the byteswap boards.  We're not sure why.  We're going to try to work with TunerPro's author to resolve this but there is NO ETA at this point.
-There are no public ADX files to allow native logging in TunerPro.  This needs to be worked out.  We can help if need be.

if you have any more questions, feel free to drop us a line.  We're available on the phones M-W-F 10-6 EST.  We're a bunch of friendly enthusiasts.  I promise we won't bite. :)

If this is against vendor rules or something, please contact us and we'll do what we need to in order to come in line with site policies.  We're not trying to rock the boat or piss anyone off - just to be helpful and make it easier for people to get accurate information about using our products.

thanks,

-Dave Blundell
support@moates.net
(225) 341 3547

There is absolutely no need to work this out. All the tools are there and already used, you won't be gaining much at all by this.

Thanks Dave and Dan(littco?) for the updates, I am one happy person to se this coming true  :)

Unfortunatly my car is my daily used car, otherwise I would probably get on and help beta testing this out.

Is there any other way I can contribute? I have some basic disassembly skills regarding ME7.x if thats to any help.

I tune lots of cars but I don't tune any ME7.x stuff at this time.
When using TunerPro, one of the nicest features is the fact that TunerPro RT has an integrated datalogger built in.
The ADX format defines the shape of data packets and the formulas for transforming raw values into real world numbers.
One of the features of the XDF file definition format is to define links to logged data.  You can define the logged data items that correspond with the axes of your tables.
When you have a linked definition pair, you'll have realtime data highlighting. 
As the vehicle is running, TunerPro will highlight in open tables which items are being used, in real time. 
This will work for MANY / all tables at once, unlike the hardware trace feature that is currently not working correctly.
TunerPro can also build histograms based on logged data.  The data acquisition side of the application is really powerful.

I'd be curious to see what the existing stuff is for logging.  I'm curious to see how it works in comparison.

Dave: thanks for your post.

I am unsure of the best way to integrate logging with TunerPro. As prj said there are already some fairly flexible OBD based logging tools available for ME7. I'll try to summarize to help you find the best route.

VAGCOM/VCDS - very rudimentary logger. On ME7, it is extremely sample rate limited, and can only log the things that the ECU is set up to provide vs measuring blocks. Logs to CSV, some rudimentary real time display.

ECUx - Software tool developed by APR that can log much much faster, and can log (in theory) any location in the ECU's memory space. Unfortunately, it is closed source, no longer supported, and not extensible (can't tell it to log locations it doesn't already know). GUI based, so you can see data in real time in graph/gauge/etc format

ME7Logger - Software that uses the same technique as APR, but is easily extensible to log custom RAM locations. Command line based, dumps output to .csv files

NEFMoto Logger - same technique as ME7L above, GUI based, but still logs .csv files, no special real time display

ECUxPlot - very rudimentary GUI to visualize .csv logs from all three above.

Unfortunately, only the source to ECUxPlot is available, so translating the output of ME7L or Nefmoto into packets that TunerPro can interpret might be difficult. Likewise, adapting tunerpro to natively talk to ME7 ECUs over OBD may also be pretty difficult.

It would be REALLY nice if ME7L or the NEFMOTO logger could be hacked to transmit to a network socket (TCP, Unix Domain etc), but lacking the source (or the original authors' attention), that may be a pipe dream.

Maybe someone can pull on the ear of Setzi?  Would be really awesome to have this all streamlined into one package, but I'm not sure he's too keen on sharing the source.

This is very easy to do actually. But not sure why it's needed as you might as well read from the command line on the fly ;)

Yea, I wrote a script that "tail"s me7l into netcat but it is pretty flaky under cygwin.

Would be better to run ME7L natively under linux with a named pipe, but I dont have a linux laptop handy.

Hi Dave

Thanks for taking the time to come on here and help.

I have a few .adx files I've created that I plan on posting,mainly to give an idea of what "could be done" but its really on relevant to individual ecus as the address change from version to version, unfortunately not all me7 ecus are the same, but just like individual xdf files I'm sure in time adx files could be produce very easily. We have all the tools already to get all the info to fill in the blanks in the ADX files and it is a pretty straight forward job of setting them up.

I think , as has already been discussed there are some pretty great tools available for logging already however the ability to data trace would in my mind be a fundemental essential to making the RR truely awesome.

I have been talking to mark ( TP author) quite a bit about this and he seems to think it is possible, its just a question if how. There exists already an ELM327 plugin for TP to allow data tracing but whether this works or not I'll find out soon when my cable arrives. From research I'm not convinced it will but I know soon enough.

Now for anyone that's not familiar. In your ADX file, you create a variable which uses the memory address , conversion etc. you can then assign that to an axis in your xdf or use it in theory to create a gauge or log . Obviously the connection between TP and the Ecu is the sticking point at present and way above my head! I don't know if there is anyway to create a plugin similar to the elm327 one available but for the vagcom cable instead?

Hopefully this week I'll get a full how to guide up with pictures etc . I have a copy of the new TP with 8 and 16bit emulation support, if anyone would like a copy then please drop me a PM. I'm a little reluctant at present to post as this is still Beta and if it gets put in the domain and someone tries to use with anything other than me7 it might not work.

Just to add setting the Ecu in"test" by making the appropriate changes in the EEPROM has worked brilliantly for not chksumming whilst emulating.

Mine is in my car permantly now, just a lead running into the cockpit . With the new adaptor board on the me7.5 you can close the lid fully without the risk of water ingestion onto the board, assuming you seal where the cable comes out ok.

The only issue I've had, which I think prj had as well was the car initially cut out once or twice, it was down to the boards vibrating in the casing. I fixed this by adding rubber mounts to the boards to take the shocks..

Also I've had to add a thin sheet on the top of the case on the inside to protect against the boards shorting on the casing as its pretty tight. A thin piece of foam sheet glued on seems to work well.

great progress Dan + moats guys

If you are an ols user, and have built up a nice set of assorted ols files for ecu's I tune, what would bridge someone like me to emulate with this and tuner pro.. Not being an active user of it, and not having any xdf's for it.  Bridge the gap for an ols user to use TP/Moates without having to re do a lot of invested time porting ols's.  Whats the solution here?

Easiest way is to use emutility which is small program (free) which can be setup up to "monitor" a file and update the emulator in real time with any changes made to a map.

For instance, you have it all setup, road road installed in the Ecu on the car and running on the dyno , then emutility set to monitor the base file you currently have loaded in winols. You do a run and decide say kfldrl needs adjusting so make a change in your map in winols, when you then save that map and it check sums, emutility senses that change in the map and updates the RR automatically whilst engine is running etc. you can continue like this until your happy. Very easy but unlike TP and emulation you need to click save rather than it doing it without prompting.  If you set up a short cut key in winols to save it pretty straight forward. You can of course do a Save As along the way to save individual versions.

I think though I have pretty complete xdfs now for the ECU's you use

Anymore updates on this?

Im ready to go :)

^^ x2 :)

x3

I emailed Dave and asked if they have setups available.

If any one of the current beta users would make a short little video showing it in action that would be sweet too! :)

I'm curious if data tracing is working.

If not, what needs to be done to get it working?

Hi guys.

Sorry, partly its my fault as had so much going on I've not had a chance to reasly up date. Roadrunner and me7.5 is now fully compatible. The designed adaptor board functions as it should and the byte swap on it now allows tunerpro to emulate both 8 and 16 bit maps in real time. I have a beta copy of tunerpro solely for nef users which isn't available directly on the tunerpro website as Mark can not provide full technical support as he does for the other versions. Its free but has the 10second delay on startup but a license will clear that. I'd suggest people using pay the license as a thankyou to mark. If anyone has any issues then can you direct them through me as I can collect and pass on to him when needed.
As for the emulator, I need to let Craig know that the boards are good for the me7.5 . Perfect allows case to close and data come out of the vacuum port on the rear if needed. It works on the me7 directly but needs the Edian swap patch and emutility, it would be very easy to get Craig to redesign the me7.5 for the me7.1 on the s4 as I know the 29f chip is located differently but I don't have access to one to assist in this.

Data tracing is still a sticking point. It was originally designed to use with elm327 and its generic pids used on code readers, but we can not get it to work and elm327 in my option is crap for our needs so wouldn't be much use.

Prj mentioned a simple driver plugin would facilitate all this for us on tunerpro using the me7 logger as a base and then parsing the info over, we need to develop this further but is well beyond my means completely! Mark is looking into the data tracing but tbh due to actual work ;-) kids and general life its been on the back burner.

But my TT has been and was running with the emulator plugged in and left in for the last 2 months and never an issue. If I need to make a change, fire up the lap, plug in the cable , start tp make the change and drive. 1minute max...

I'll get a video, simple way to demonstrate is too adjust idle in live time whilst sitting in the back ;-)

This is the best and most stimulating comment that I have read in these amazing forum.

Like the forums around the world doing custom android firmware for mobile phones why we can not take some routes like the ROM mods of the EVO people, check it here --> http://www.evoscan.com/ecu-mods.

At end is just a microprocessor runing a program. Of course is not easy, but as Notorius VR said, one alone is very difficult, but with many people helping is should be easy to reach it.

I will to add something. I know emulation /emulator is really useful for fine / live tuning, but anyone have think about modify the connection protocol between the ECU and our tools through the OBD2 port. Basically ME 3xx, 5xxx and 7xx ECUs use a simple serial communication protocol KW1281 or KWP2000 that can be used for diagnostics or flashing using a dumb KKL or KL interface. But today as an example an USB device using a serial protocol can be really really fast.

The problem is ours ECU uses fast processors with multiple process capabilitires but it connection to the exterior is really poor, slow and small in capacity. That is why reading RAM directly show us so good and useful tuning capabilities. Then maybe I am nuts but can be possible to improve and open it communication channel with our ECUs allowing us a new world of posibilities???

Please explain what ELM327 has got to do with it?  ???
Data tracing and adress watch must be a hardware thing that the CPU/IC on the roadrunner handles. But perhaps it does use obd2 to sync time/rpm with the tracing of memory.
Address hits counter does not work either and that function surely does not use/need obd2 connection working.

I think I need to get myself one of these Emulator setups once I get my car back up and running (should be within a week or so) :-)

One ECU and one RR setup on its way to sweden :D

Here is the link for anyone wanting to use TP with road runner.

This version support the 8/16 bit map emulation. All other versions do not support 8bit maps..

http://www.tunerpro.net/download/SetupTunerProRT_v500_8131.exe

Not even the 8139 that autoupdate finds?

There is no need to update this version works! Its specific for RR update at your own risk.

Littco:
anything to say about http://nefariousmotorsports.com/forum/index.php?topic=3149.msg35417#msg35417 ?
5-6posts above this.

elm327???

I know what you're saying, but the way mark has written it does work, you don't even a road runner to make it work..

It takes the data from elm327 ie rpm, load, timing etc and then translates that from hex to dec to display it on tunerpro. Therefore it doesn't even communicate with RR.. If you have used elm327 then you'll know how pants compared to me7 logger it is..

Everything is there in tunerpro and correctly done should be able to data trace etc but it needs the plugin/driver , comport worked into it.. PRJ has said he can do this but I know he is extremely busy so I don't know how we can move this forward..

Maybe I can convince Tony to give me code to his logger.

I recieved my emulator and ECU now, and the weatherproof connector/cable is no longer supplied with this kit.

How did you guys do yours? I certainly dont want to get any moisture in there...

Would love this for my s4, used to use moates stuff when playing with Hondas, map trace is a must though

littco, how did you secure yours inside the ECU?

I attached two mockup pictures of mine

I don't have a picture's but I had some foam pads, which I cut down to the right thickness and then sort of shaped around the boards so the adapter board sat flat, then did the same for the gap between the adapter and RR, the little pegs supplied where next to useless.

I then took out the bung in the top and cut it out so I could fit the cable in through the case and used a bit of rubber on the top under side of the case to stop the RR from shorting against the case.

Sorry I really meant to do a write up but just been busy.

The foam pads I used/made where left over bits from one of those metal travel cases you can buy with foam inside you can remove to transport different items. I bought one to store the Emulator in and it just happened the foam inside made for the ideal spacer . Plus it allows a little bit of movement which is probably quite handy for the connectors.

I have found that when I first installed it the connectors once locked together where stuck pretty well and seperating them was a little bit nervey as I was worried about pulling the pins off the board, but now it's come apart a few times it's a firm fit but unplugs nicely.

You need to set the eeprom to test so the checksums are ignored.. you aware of that?

Thanks for the info, I actually have some foam that I can use. Do we have to worry about heat, stuffing it with foam?

Yes Im aware of the checksums. Now im weighing if I should leave the desolder/solder job to someone professional or if I should get some Chipquik and attempt it myself..

Im clear on how its done, but I have not practiced smd soldering before.

Be very careful, don't pull at all! Those pads lift easily. On the same note, don't use too much heat for the same reason. I'd practice on a bad ecu first.

Thanks man, the problem is I only have good ECU's :)

I'll dig up an old grapics card or something.

In test mode, are you able to start the car with an invalid checksum?  OLS300 updates them as you go - i know test mode allows invalid checksum when running, but what about starting up?

Rick

Yes, every so often the car won't start, but you just recycle the ignition and it'll start fine. Only had the issue a few times but a quick off/on and it starts fine.. Ecu never locked so it won't start.

I ordered up some odds and ends and will polish my soldering skills a bit more, should have the stuff I need in about 2weeks.

I have had the header soldered on, emulator is in and I have flashed the emulator with the .bin. All this went fine, but I cant connect to the ECU on the bench.

Do I have to change adress mapping in Emutility?

No, an ASM hack is needed. Test mode only turns off validation of checksums when running.

Send me the thing, I'm pretty close geographically.

I have the header soldered on now, thanks anyway prj!

please look at:

Note: I have not coded it into test mode nor done any ASM hack yet.

bootmode readout, looks like I read out empty memory from the emulator. Leads me to think I am writing the .bin in the wrong memory space.

Also attached the .bin im flashing, the very one I pulled in boot mode of the stock chip yesterday, before I got the header soldered on.

sorry I have been keeping an eye on this but not had a chance to reply.

Have you tried reading the file off the RR you flashed on with emutility and or tunerpro to check its writing correctly? On mine I had an issue where 2 off the solder joints on the adapter where shorting and the data was getting scrambled.. If you do that and then check the maps I tunerpro to make they are correct, might save you a lot of guessing as to whether it was working or not.

Also I've never had any issues with the car not starting with incorrect checksums. The times it has failed to start I just recycle the ignition and its fine.. What's this asm hack that's needed? All I've done it set the Ecu to test mode, or am I miss reading the post?

Thanks for taking time and chime in littco, I have not read back from the emu. Can you verify the memory settings you use in Emutility?

I want to verify that first, then I'll flash to that space and read it back out to see if the data got in there correctly.

Ok, I used these settings:
(http://img254.imageshack.us/img254/9159/emutility.png)

Readout from Emu is 100% to the stock file I flashed.

Have you tried running it in the car? I only ask as I had a similar problem where I couldn't connect on the bench but in the car it was fine and started ok as well.

Settings look ok. I just use tuner pro now to flash the RR now as it seems easier . Just a person use and no settings to worry about:-)

You must be able to read this in boot mode on the bench.
And the ECU must communicate on the bench.

Running it in car will make no difference.

How to turn the ecu into test mode?

alright, took everything apart and put it together again, now I can read out the flash in boot mode 100% match. That means emu > connection is working as intended :)

Still no response trying to connect on the bench though, going to code it into test mode and try.

Like I said I had trouble connecting on the bench with vcds.. Try on the car if you still struggle to connect. I know it should connect and I'm not saying wont but I even when I couldn't connect on the bench the car started and I could read it.. Why I don't know.. I'm just telling you what I found

Coding the ECU as test model is done in the eeprom, you have to change some data values:
in pages 1 and 2 you will find  69,C1, and A5, replace these by 8E,5A, and D2,
then update the checksums of both pages. I believe you (or other experienced users)
can manage this without more detailed instructions (and the noob's anyway shouldn't
do).

I do not know what could be changed by setting to test model besides the following:
 - the data checksum results will be ignored by the ECU,
 - you can start a programming session even if the ECU is locked for some time after
   sending a wrong security key,
 - you can download data to the flash without ciphering and compressing.

On ME7.5 images, when you have started a programming session (85) and
are requesting ecuIdentification with param 9B, the last string you get has 5 characters.
If the last character of this string shows a '*', this indicates your ECU is coded as test model. I think this is not done for ME7.1 images.

Be aware: this results from code reading and simulations, not yet tested by me on real hardware.

Ok, I have immo offed + coded it to test model now.

I have found out if I load the stock readout from the stock flash chip which for some reason contains 4 chksm errors, I can connect to the ECU. But I cannot read fault codes or recieve ECU info(as i could pre-emulator, on the bench). :D

As soon as I get the last parts I will try it in the car as you say littco.

Finally got to test it in the car!

First time i cycled on the ignition everything was fine, connected to it, communicated and read out fault codes NP. Then I cleared the codes(had one million codes from operating at the bench), read them out again and one code popped up: P0600

Then the cooling fans turned on and the ECU stopped communicating. Im i have a feeling something doesnt add up with the 95040.

I did read out the junkyard eeprom and defeated immo + coded it to test model, then flashed it back in and verfied it.

Should I use a blank immo off .bin instead?

I've emulated 1.8T, 2.7TT, 4.2TT and EDC15 at this point without any issues.

Without lo/hi byte swap or did you manufacture adapter boards?

I have a lo-hi swap tunerpro plugin that I wrote :)

any chance this will emerge as a turnkey solution? :)

Alternately, I have a spare ecu that already has a ribbon cable connector on it.

Can you take some pictures of your setup? I'm hoping I can adapt it to my ECU.

what do you mean turn key?
You can buy the emulator and adaptor boards, headers and I've posted the tunerpro version for 8/16 bit.. I currently have 5 different ecu's which all can swap the emulator on and drive away happily..

Did you enhance the plugin to work directly while updating a single map/value or do you have to upload the whole binary to emulator when doing updates? (as I recall you explained it last time)

I was referring to the bitswap issues... are the correct adapter boards now available?

Also, think i want to try to adapt it to a board that i already have connectors on.

Is this all i need?

http://www.moates.net/roadrunnerdiy-guts-kit-p-118.html

and this if i don't want to use what i already have

http://www.moates.net/byteswap-board-for-psop44-p-281.html

What do you use in the eeproms? Matching bin, immo off XXX bin?

I use EmUtility to monitor the byte swapped file and only changes that are made are uploaded, and in real time.

Immo off and test model.

Thanks as always prj!

Emulator running now yay!

But winols cannot overwrite the file while monitoring it with emutility, anyone got around that?

When I try writing over the it says "error: could not open file" then suggests there might not be enough space on the target drive or the file has overwrite protection... Turn of monitoring and it works fine overwriting.

Yeah, don't use WinOLS, and no problem :P

I got my byte swap board and some cables as well.

Yeah, figured as much. Was eager to try it out right away :)

Sweet, will take some creativity to fit inside a 2.7tt box I believe.

I plan to use a cable and make a box for the emulator of some sort and have it outside...
For 2.7TT application I already have the problem solved, as I have an ECU with a modified cover.

That is a great idea to have it separate.

Here is how mine looks

I've just read the whole thread, but I couldn't find a clear statement if tracing is possible.
Can anybody tell us something about that?

Yes, but what we need is a Tunerpro plugin to parse ME7logger.

I haven't tried writing an ALDL plugin just yet, not sure how that works for tpro.

Only thing it'd be useful for really is tuning KFZW/KFZW2 on the dyno.

As I told you before prj, I am more than willing to pay for a solution. I think others are too.

It will also be really good for calibrating the boost control and fueling on the dyno. Corrections based on logs is accurate, but calibrating under controled conditions is even better, and also much faster with the dash functions.

It is also good to have this integrated in Tunerpro for the logs tracing function.

Yeah, I know what you are saying - I do have ALDL tracing for my 2.2T stuff and it is a night and day difference on the dyno.
Just trying to get WinLog to a state where it is stable, as I have tested it on a few other machines now and there are some crashes.

I don't want to release anything that does not work 100% of the time.

100% agree with You

I understand.

Now back to emulating, just came home from a session where I discovered that even if the Emutility monitor updates the flash, it does not always take for some reason. The emutility updates but nothing happens..

What could be the reason? Checksum business?

I have coded the 95040 to test model.

Look for issues on your filesystem rather than on the ECU.
I've never ever had this issue.

Btw, this emulator works just fine for 29F200 found in M3.8.3 as well, you just have to stack the file four times.

I guess its a possibility. But I did suspect that also, when I have overwritten the monitored file I have verified it was overwritten on the disk, I have verifyed the Emutility did update the flash and when I match check the emu memory its a 100% match.

I was editing LDRXN when it noticed this, really wierd.

Have you tried the tuner pro rt on it? Or are you sticking with windows and emulity?

Not yet, I need to write my definition in Tunerpro first and time isnt enough right now.

What Ecu you got?

My personal? 8E0909518M

Bische, mail me your OLS and I'll mail you an xdf ;)

Are you guys checksumming or not?

Getting the plugin was not the fastest..

I have big problems to start with the emulator. I often have to try 2-3 times to get the fuelpump to prime (which tells me that I can let the starter run and the car starts)
I see these faultcodes sometimes:
18057 - Powertrain Data Bus
            P1649 - 35-10 - Missing Message from ABS Controller - Intermittent
17931 - Crash Signal from Airbag Controller
            P1523 - 35-00 - Implausible Signal

I've tried 2 different ECU, with the second ecu I tried the same file and eeprom before mounting emulator to be sure that it was not a faulty ecu.
Could it be a faulty ignition switch or fuelpumprelay? The other day I noticed that I could connect with VCDS to ECU even without key in car, at first I thought it was due to testmode but it was not.

this maybe irrelevant but i had a similar issue with my car "which is completely gutted no radio no interior" where i could not connect to the ecu no matter what while the ignition was in the on position. I was able to connect to the ecu when the key was on the off position. I went straight to the ecu snipped the k line of the me7 plug and ran a cable to my obd port and the problem was gone.

I had the same problem, wrong ECU soft coding.

Now I have problems where as I am emulating, the chksms is not updating which causes a P0606 0x28, and the car wont start until I load a WinOLS summed binary and clear the codes.

Do you have to save each time you make a change and then hit update? Am I doing it wrong?

Were you able to fix the same ABS/airbag problems by changing softcoding? (or do you mean fix the same fuelpump priming problem?)
If yes, I find it a bit strange because if I use exactly the same file and eeprom (including soft coding) without emulator everything works perfect.
I use TunerPro in emulation mode and can click on update without saving first. Without checksums! (ecu in testmode)

Thats is strange for sure, I had one ABS code and one steering angle yada code. But my softcoding were off, had fwd coding on the emu ECU stock e2p which I used first. I corrected the softcoding and those were gone.

Yes, I can just hit update also, but if I do the ECU wont init and as you say, the fuel pump is not priming which gives it away. If I hit save first it seems to work, I have to do some more testing to verify though.

I now use my ori e2p which I changed the two immo bytes + the six bytes for coding it into test model and summed it.

Are these still available?

Hi,

Yes they are, the emulator is just the roadrunner, and the adaptor board is available from Moates as well. You need to ensure you have the edniam swap board.

This works very nicely with either the latest tunerpro RT or the utility that moates has..

I personally prefer using ultility as i changes the map on the fly and with corrected checksums where as tunerpro doesn't and the more you use it the more likely the ecu will brick as the checksums aren't correct, not an issue as it normally starts after an ignition recyle or worst case eeprom reflash...

Do you know how much they are roughly?  Could be interested when my car is fully up and running,

Just ordered one of these (go me!)

From what I gather if exporting with OLS you can avoid the byteswap board as long as you export with swapped lines. Can anyone give a brief summation on that? I saw the diagram earlier (page2) but it leaves a bit to be desired.

Thanks!

just ordered a roadrunner.
cant wait to get this thing into my hands.  ;D

btw:
is anyone interested on using the roadrunner with older m3.8.1 / m5.9 ecus (equiped with plcc44 eprom)?
i'm thinking about designing an adapter board with plcc44 plug to psop44 because I want to use it in my m3.8.1 vr6 ecu too.

Yes, I will gladly pay for a such adapter.

the roadrunner can emulate the 27c1024? I am very interested in the adapter

I don't see why not. Or you can use 2x Ostrich with a clever adapter.
I have 2x Ostrich and a Roadrunner, so makes no difference to me which way.

Yes RR works fine in place of 27c1024, i have had it running on M3.8.2.
I made my own adapter, but would also be interested in more professional one :)

Btw, every M3.8.3 and up, that i've seen, use 29f200 so44 flash.

Great work friend. Can you post some pics? Do you use TunerPro with the RR and your own XDF definition?

500$USD for the emulator, 30$ USD for adaptor

@terok:
good to hear that it works. how did you do it? with wires?

27C1024 uses the same signal levels and pinout can be mapped to 28f800.

 anyone sell the adapter?

I've got mine now also set on a board and i could be ready to go....but: I can't connect to the ecu, as soon as the RR sits in the place of the 29f800. Neither Nefmoto Flasher nor VCDS could even find the ecu. If i read it out in Bootmode everything's fine! the read file is the same as loaded to the emulator before. This is already the second ecu, as i thought the first one might got smashed while i tried several EEprom contents to make it possibly work. It doesnt matter if i put a immo off + testmodel file on the eeprom or the stock content: i cant connect. Any ideas on this?

Bische: did you manage to find the ecu on the bench via vcds? Also: how did you overcome the problem with replacing the file while monitoring it? shut off monitoring, save it and monitor it again?
I think i'm going to try it tomorrow in the car, although i would guess, that it wont be really successful...

ok...at least its possible to export the file to another folder and copy it over to the monitored folder/file and replace it this way....little script should do the job.
with the main problem: No communications.....no succeed till now on the bench

Hi..

I can connect with vcds etc, it shouldn't be any different..

Are you using the byte swap board on your setup?

With regards to the file saving, what I do ,depending on how I'm actually using it , is either use tuner pro rt and just make a change and save the file as is, or use the monitor feature of the emutility. With this is use tuner pro and use the "save as" to create a new different file but the "save" on the monitoring file.. Thus creating an ongoing monitored file and a new version to refer back to if needed.

I much prefer using emutility and monitoring as when you save it obviously does the checksums at the same time and doesn't lead to a locked up emulator , which can occur sometimes after a lot of changes and an ignition recycle . Sometimes fixed with another ignition recycle but sometimes needs a reflash of the EEPROM

Prj did a tuner pro plugin, that created a second byte swapped file that could be monitored instead regardless of what the actual file was named saved as.. I'm sure it could be reworked to duplicate the saved/saved as file.. But I don't think it's really needed..

yeah i'm using the byte-swap board! I did it step by step this time, because on the first ecu i did everything (soldering+re-programming of eeprom) in one step. With the same result. So i took a second one (both 06a906032HN 001) and programmed the eeprom first (original content immo offed and test model). Before programming the eeprom Nefmoto Flasher couldnt read it because immo seemed to be active (dont know why).  after reprogramming eeprom it was communicating with the non-bootmode progs more or less as normal, only one thing: Nefmoto Flasher couldnt read the content as the ecu seemed not to support security login? I thought it wouldnt matter quite a lot, as i wouldnt need to flash it via OBD anyways.

After soldering the header on, installing the RR and sending a file onto it via emutility - no communication at all... I'm really wondering what it is, as it's as already the second pcb, as said before. I think i'm going to take the first one and resolder a flash on it and check whether this one works like before i did the emu-conversion....never had any bricks after reflashing till now...

what might be worth to mention: I'm using argdubs programmer for the 95040 and i have to use v1.31, as 1.40 doesnt really work as intended (always errors, no connections etc.). Maybe i should take the eeprom out and program it direct? Although i checked the content again and again...



EDIT: ...ok....shame on me  ;D after writing the post i took a look whether all pins of the header are good and by doing so i realized that i also have to have blown off the resistor near the flash while desoldering it and i was just too tired yesterday to see it....
its communicating now with vcds!


EDIT2: it worked for like 10 minutes orso....then tried to read the flash-content with nefmoto and at 4% an error occured and since that = absolutely no communication?
anybody had this before?

EDIT3: after soldering the flash back to ECU#1 and using original eeprom-content : works as if never anything happened....so its only while having the emulator on the pcb....

Sorry for the 2nd post in a row, but some good news and maybe also quite useful for everyone who might be stuck in the same problem after me:
Although being unable to communicate with the ecu(s) (both same problem) i decided to give it a try and testet it in the car and....everything worked fine! after the first start i was able to communicate via vcds etc!
now back on the bench: no communication :D but as long as it works in the car i'm happy.

My roadrunner with byte swapping board works fine in a M3.8.3. Used it to tune an AGU engine last weekend.
The only thing I noticed is that hit-tracing is currently broken (tried various TunerPro versions).

Next test will be in a ME7 ecu. :)

tracing doesn't work on this or roadrunner.. It needs an elm327 cable and to be configured with the same channels as vagcom, but even then it doesn't work.. It basically was only designed to give channel data, a bit like vagcom, so you could have a Nmot and load axis or anyother channel elm can log, but again it doesn't work with the me7...

I did speak to tunerpro about it and although he looked into it it wasn't really a big thing for him..

A plug in that used me7 logger would be better

According to moates the roadrunner protocol should be very similiar to the ostrich protocol. So it should be no big thing to get hit-tracing working with the roadrunner. I'm currently requesting docs from moates to play a little bit with the TP SDK / roadrunner.

Yes, me7logger plugin would also be nice for me7 but unusable on M3.x

btw: I'm also in contact with TP author about this bug.

Bringing this back from the dead...

Having issues with checksum death codes in my 01 Allroad running the 8d0907551M 0002 -

I have the e2p in test mode, checksums updated, have done the asm hack (searching for 47 F8 55 00 CC 00 CC 00, searching for E6 F4 FF DF from there, taking the last 2 bytes of the address, and updating the original string with EA 00 XX XX in loHi).

I can drive the car for hours with emulation enabled and making changes to the running flash.

The second I turn the car off, I get the death code, and have to re-write the e2p.

Even if I shut the car off, save the running flash, update the checksums, and write it back, it still sets the code.

Just curious if there are any other fixes for this out there, or if anyone has looked at the routine and modified it to write 00's instead of 33's to the e2p?

Bonus pictures attached of how I have it packaged for the 2.7T - this fits inside the factory ECU box - I got the idea after seeing the way this is done with Bosch development ECU's.

Find where it writes death code into eeprom.
There is basically a branch in code, checksum ok or failed, make sure it always branches to "OK" and it will even clear the death code for you.

I've used this emu on this ecu (and BEL 2.7T's) and have never run into this issue using the same methods as Jason.  ???

Nor have I.

I think this is a problem specific to the Allroad.  I'm not sure why.

I don't have a single issue in my S4.

Can you run the same binary on both?

I already do run the same binary - 8D0907551M.

Also to note the Allroad has been a fickle bitch in the past with OBD flashing regardless of speed - random failures and hiccups - flashes just fine on the bench.  Hence the emulator purchase.  I've also tried 2 different ECU's with the same results.

Jason:

I would suggest to log the eeprom mirror in RAM with me7logger during shutting down to see how it looks compared to what you read from eeprom after death code situation.

Not the same problem as yours but I have been addressing another by setting a low TNLSGM described in http://nefariousmotorsports.com/forum/index.php?topic=10267 which still might relate to the same RR phenomenon.
There I report that 2sec was to little, but from what I can see now I used 2sec last time I ran the RR.

Today I saw the following on moates site but perhaps it's been there from the beginning, this is probably the cause of some ME7 problems with RR http://support.moates.net/roadrunner/

Depending on when and IF this reset occur in ME7 and might relate to your problem if it happens during write sequence of eeprom.

We really should have a FAQ topic on the Moates RR, now we have two or more threads with information.

btw, this was quicker than creating a custom pcb for byteswap and also enables fitting inside different ecu's without a handful of different byteswap boards.


 

You can do the byteswapping in software, my OLS tool already does this automatically.

Yes, true, but I think he's referring to just getting the hardware to work within the ecu.

Of course, I know.  :)
But I've gotten used to work with tunerpro direct emulation and this cable took less than 30min to fix. Since 2013 I have had the Moates psop44 header extended with ribboncables soldered in one single daily drive ecu to be able to fit it with cover closed. It was really ugly.
Sure, Mark Mansur the author of Tunerpro should be able to quite easily add a toggle setting for HiLo<->LoHi  in his connector for Roadrunner.
I really should send him an email with a feature req.  :)