Done exactly as you said but still no joy - starting to think its this notebook though (EeePC 701SD) as for some odd reason I can't connect to the ALDL at all in V4 or V5 without BOTH the ALDL and Ostrich plugged into the USB ports. Without the Ostrich being plugged in I get a confirmed cable OK in setup, but connection stays at "Connecting". As soon as the Ostrich is plugged in the connection turns blue and data starts coming down.

Backup power from battery pin on the ECM is supposed to keep the Ostrich powered and running when not USB powered IIRC. Not sure how the Ostrich is powered that way or if you need to stop emulating before disconnection of USB etc.
Does the car run the same with the USB unplugged? (besides logging not working)

But the Ostrich shouldn't need to be plugged into the USB port to have ALDL data.

Yes, disable Emulation, before unplugging the USB cable to the Ostrich.

No emulation going on - just by habbit I normally plug both leads in. This time I didn't so I spotted the problem of no ALDL data without both leads plugged in.

Could the fact that the Ostrich is powerd be supplying a feed to the ALDL unit also? Ie maybe I'm not getting enough feed to the ALDL on its own?

Added to say no difference in running - the Ostrich does its job just as it should

So I decided to give v5 a try now. Issue is: my Ostrich 2 is found and connects fine. Data aquisition is found as well, using serial com port 3. Nothing reports on the dash though. I'm using the latest beta xdf and adx files available from code59.org. V4 works like a charm.

I have a question, on my dash the Coolant temp (F) is wrong.
The C reads 88 deg which is good but F reads 230 deg.

I have the MAT C and MAT F which read good so that conversion
should work.

So how do I look at / find / or change the conversion?

I've now down a complete rewire on the ECM and managed to fix my USB problems.

I have however noticed that I do get a counting error number in Tunerpro V4, not enough that it effects your on screen data in anyway.

What does seem apparent is that Tunerpro V5 deals with these errors in a very different way making it completely useless. Is this something that can be addressed?

Dan

Another corvette user with Tunerpro V5 problems as well - different ecu but the same flashing connection box

http://forums.corvetteforum.com/c4-s...post1574745648

add a 20ms pause after the recieve command in your monitor macro.

that solves 90% of people's problems.

I've done this, even had XDFs (can't remeber the V5 name) sent to me by other members to make sure there wasn't a problem with my file.

have a mode8 command worked into your connection macro?

Mode8?? Whats that - and thanks for your help so far

mode 8 more or less tells all of the other modules on the ALDL line to shut up and quite requesting data from the ECM... if they do that when you're trying to log, then you'll see seemingly random errors.

How would I go about adding that to the Macro?

i assume you're running 8D?

Yes Sir

Isn't that the same as the "Silence" command?

Found this, look at post #9.
http://www.thirdgen.org/techboard/di...mething-s.html (Scannerpro finally something that’s work on 90 Corvette!)
It was a ScannerPro file but should give some indication how to make the chatter stop.

should be. i've seen mode 0 being referenced as silence too, but i think that meant to quit sending aldl data after it's already been shooting it out.

Seems like that was more a problem with the CCM? I don't have one as mine has been retro fitted into an 85. I did try adjusting the timeout to 1200ms out of interest but it didn't help at all.

Dan

I had this in my old ScannerPro definition.
Never put it in my V5 definition yet because I didn't need it.
Not sure if this is the same as the one in the post but you can try it and tweak the timing.

I cant get the option to add the time outs etc down the bottom like that...

I may still be having issues with the Ostrich itself - so I may be wasting everyones time here. I still cant understand why V4 can deal with the errors fine while V5 falls down.

Here is a quick vid I recorded earlier. 20ms Pause

Download and Save as:
http://www.autobitzonline.co.uk/V5_error.mp4

This might do it... (got no way to test it)

Add new Item" under commands.
Create this item as a "send command" called "SendSilence"
Give it a Unique identifier and fill in the command sequence.

Create a new item again, this time use the "Listen for silence" type.
Adjust as you think it requires.

Create a new Macro
In your mode 1 "send" and "reply" connection macro...
Above everything that already exists...
Add SendSilence,
Add Listen for Silence,

Hope for the best.
If that doesn't work hopefully someone else has an idea.

You may need a "reply" also but I don't know what to do with that.

I think V4 was not nearly as configurable for different setups.
V5 imported definitions just need the timings worked out. I had very few errors on V4 as well and when I went to V5 I couldn't log correctly until the delays etc were better matching my equipment (laptop, cables, whatever)
I have different settings for different laptops and my desktop even to allow the fastest rates possible.
Generic or long delay settings work the best but won't always get full speed results.

Is there some sort of FAIL SAFE - slowest, most reliable setup I can try? Seems like it would be far easier to tweak it from that direction.

Not sure if this has been covered, but it seems that there are some ADX files where the expected response size has been specified as 66. The correct value is 67 (4 request echoes plus 63 packet).

Change it to 67. There should not be any need for delays really, the communication is synchronous if the whole packet is harvested.

This may not be the case you're working, but I thought I'd mention it.

I list Body Size as 66 and Payload Size as 63.... Simply change the Bodysize to 67 I guess?

I think so, seems like I remember testing that very thing recently. I can go test right now if you want.

A body size less than actual should be safe. A body size more than actual would cause the packet reception to fail.

Dan - email me the definition you're working with. I'd like to take a look at it.

Unfortunately there is a ghost in the machine somewhere that causes errors related to timing. I've spent quite a bit of time trying to figure out what it is, to no avail. This seems to only affect USB-based cables. You can also increase the latency in the USB/COM driver and see if that helps. I'll continue to investigate the cause of these timeout errors.

Ok, I have just spent some time messing around with different delays/timeouts etc and I have managed to get a stable on screen display of around 6.5hz.

I have a Silence command set to 40ms but the only way I could correct the error's I was having was to up the Reply Command Timeout to 2800ms!!

I use V400 $0D.adx with scannerpro and when i use it with tunerpro
the fuel usage gauge is not the same, what's wrong with that?

w/t1500

i believe that's due to the scannerpro ADX format not being 100% compatible with the V5 format. it should be easily fixed though.

check with 0D_maf(mpfi).adx it do the same thing
with mpg gauge .

w/t1500

hmm... in the latest version of V5, i have just a non-existant needle, but i don't have a log to play either.

Thank for the check, i do'nt have needle in tunerpro
but have it in scannerpro,so far it's the only gauge that
do'nt display right.

w/t1500

got a log so i can try and play with it, see if i can find the problem?

Ok thank, i will try to make some logging next week
and post it .

w/t1500

Check to make sure the ADS was imported correctly.

I had an issue with an old build of V5, actually a pre-public beta release, where the MAT wouldn't display correctly, I replaced the MAT sensor, since it could have been suspect anyway, with no change, discovered that the ADX ws imported incorrectly for that value.

Over a year ago I posted in this thread, post #71. At the time it was recommended that since I am using a Prominator setup, it would be better to stick to V4 rather than V5 as at the time, no support for the Prominator was in V5 due to the issue of USB vs parallel/serial port.

Recently I thought about that, and now wonder, since I use Speedtronics Prominator software utility (Mr Bill on this forum) to actually load the Prominator, does it matter that V5 doesn't load the bin in USB directly, as my the other software will? I never used V4 to load a bin directly to the 730 's prominator either! I always used the utility instead.

I'd like to play with V5, but would like to make sure of compatibility concerns first. Am I still I'm missing something important conceptually here?

As mentioned, I'm on a 7730 ecm with a Prominator strapped to it, using an $8D and and Tunerprort V4 as my tuning software at present. Clue me in as to what I'm not catching on to here.

If by this you mean uploading the bin to the prominator with speedtronics software and you merely want v5 to edit a bin I don't see why you couldn't us V5 for editing and saving bins. I am unfamiliar with the promionator and speedtronics but from what I think you are asking there should be no problem.