pcmhacking.net

VL400 wrote:The speed might improve by not closing/opening the port, would need to experiment there. The data rate should really be over both the frames as your wanting to know the rate an item is received - say RPM from the engine frame, with the current setup logging engine and trans its about 3Hz but its possible to get close to 6Hz with no delays.

What also got me thinking was the 4-5Hz on VT and later when looking at the heartbeat, the heartbeat only occurs every 300ms so the best you can get on them is really 3.3Hz getting one frame sent/received in the spare bus time. Logging both engine and trans you are down to around 1.6Hz.

On VR (and VS V8 series 1 and 2) Auto and manual engine data is the same, mode 1 message 0. Same data and size. I can connect to a VR manual ECU by selecting auto, the trans frame is just blank data.

There is no code 32, both VR auto and manual are code 31 for the missing VATS signal.

Yeah, I always close the comport afterwards, just force of habbit I guess but I can experiment there!

I always search for the heartbeat (Dont look for delays) since the space after the hearbeat is always plenty of time to get a read in.
I coult try cram both engine and transmission into the single heatbeat transmission although I dont know how well that goes!

But yes, the frames/s is calculated as both engine and transmission. So grabbing 1 engine and 1 trans Iv calculated as being two separate frames so if it was 4frames/second it would be 2 trans and 2 engine.

Alright, well then the Auto VR adx I have , has code 32 as missing VATS signal, so that could be why its going a bit funny there!

Yeah your definately right VL. I redid the calculation for frames/s

Im definately only getting around 2frames/s. So 1 engine and 1 transmission when going only after the heartbeat.
I could use the disable chatter command... but I find that engine warning Annoying. And also makes the stupid fans go off!

I can add it as a little checkbox maybe? And can be selected?

*Edit
I know its not the same, But I ran the VR calculations using a VT V6 ecu.. just changed the device ID to F5 instead of F4.
Seems to work happily with no errors. Sooo no sure what was happening.

Iv added a bunch of error catching, and a detailed error catch will be output into the console log.

New version up shortly...

Alright, v0.0.0.2 now available!

If an error pops up, head to the console log and copy/paste that error to me!

I tested happily in my VY V6, as well as now Iv been emulating data from a VT V6 and VS V6. I might give a go at emulating a VR chatter as well and see if I cant reproduce those errors.

funny i didnt get any virus warning on download . theres a vx adx somewhere on here i modded that logs without interupting the dash and bcm if your looking for timing settings

delcowizzid wrote:funny i didnt get any virus warning on download . theres a vx adx somewhere on here i modded that logs without interupting the dash and bcm if your looking for timing settings

I uploaded the wrong version. But I compressed the file.. maybe thats why you didnt?! lol

Im about to add the new v0.0.0.2 now

*Edit
Just updated it and added it to the post above!

them gauges are MINT looking man cant wait to try it out in the vx

delcowizzid wrote:them gauges are MINT looking man cant wait to try it out in the vx

Hopefully it works smoothly like it does in my VY!

Also, you can right click any of the gauges and change them to a different parameter
Can even change there colors! Except for the progressbars.


Sooo from some more testing. It looks like a couple people are getting 'errors' because the wrong frame was picked up on their VT, something else on the bus was outputting "F5" in its message which my application recognized as being the response. So when the frame has gone to be processed, it is the incorrect length (too little bytes) thus failing.

My plan here, is to implement the separate 'processing' thread to maintain reading speed, and also to double check the checksum of the frame will be checked to ensure it is valid first before processing.
And finally, Ill look into keeping a constant serialport connection open rather than stop/start. Im actually going to time the "open/close" functions and see how many milliseconds they actually take

Theres been a few VT users without any issues which is good news
Although doesnt look like the VR implementation is doing so well! Hopefully the new changes will help out in obtaining the correct response.. and at least give a more detailed error catch.

I too did not get flagged by a virus. Could I have a license Tazzi.

Tazzi wrote:.. just changed the device ID to F5 instead of F4..

Think this might still be in v0.0.2 for VR....
07:38:09.267 Rx'd Frame = F5, 57, 1, 0, B3,
07:38:09.567 Timeout waiting for frame
07:38:09.696 Rx'd Frame = F5, 57, 1, 0, B3,
07:38:09.996 Timeout waiting for frame
07:38:10.123 Rx'd Frame = F5, 57, 1, 0, B3,

VL400 wrote:

Tazzi wrote:.. just changed the device ID to F5 instead of F4..

Think this might still be in v0.0.2 for VR....
07:38:09.267 Rx'd Frame = F5, 57, 1, 0, B3,
07:38:09.567 Timeout waiting for frame
07:38:09.696 Rx'd Frame = F5, 57, 1, 0, B3,
07:38:09.996 Timeout waiting for frame
07:38:10.123 Rx'd Frame = F5, 57, 1, 0, B3,

Yeah that was the 'old' v0.0.0.2. I uploaded the version I was playing with on the bench setup with the VT V6 ecu!
I change the header to "F5" so the VT would respond then proccessed it through the VR calculations to see if it was the calcs causing the issue. I forgot to change it back to F4 when I uploaded, and a few of you guys downloaded quicker then I could delete it!

Just redownload the v0.0.0.2 above and it should be all sweet!