Rogue Tuning: DME Logger!
#92
Burning Brakes
Rogue. I'm up for it but it will take a while. A buddy of mine already has some working OBD2 translation code which I could adapt. I'll contact you once I'm ready to pick up the programming.
Yes, there would be a delay, but I'm unsure how significant it will be. The best would be if Rogues DME logger would output OBD2 directly as that would open a vast range of possibilities, but there are many reasons for why Rogue may not want to do that. Lack of time possibly the biggest, but it would possibly require a hardware change? (As far as I know OBD2 is request based meaning a request is sent to the DME which then replies, while Rogues DME logger simply sends a continuous stream of serial data).
Yes, there would be a delay, but I'm unsure how significant it will be. The best would be if Rogues DME logger would output OBD2 directly as that would open a vast range of possibilities, but there are many reasons for why Rogue may not want to do that. Lack of time possibly the biggest, but it would possibly require a hardware change? (As far as I know OBD2 is request based meaning a request is sent to the DME which then replies, while Rogues DME logger simply sends a continuous stream of serial data).
#93
Addict
Rennlist Member
Rennlist
Small Business Partner
Rennlist Member
Rennlist
Small Business Partner
Thread Starter
Yep - 3 please.
No matter what system, there is always a slight latency between the ECU and laptop. A decent converter box should (ideally) not add any noticeable latency (say only a few mS).
One of the problems with OBD2 is it generally uses newer communications hardware than what we have in the DME.
For example, one protocol uses PWM (pulse-width modulation); another uses VPW (variable pulse-width). The DME does not have the hardware to support this type of communication.
Yet another protocol is CAN, which again the DME does not have the hardware to support.
The remaining protocols are: ISO 9141-2, and ISO 14230. These are closer to what the DME has (hardware). However, the maximum standard data-rate is only 10.4k Baud... This is only 1/11th the rate of what my logger currently does. This means that the rate is really slow, and will reduce the update rate for all values coming from the DME. Currently the update rate is 15-20hz; conforming to 10.4k would reduce the update rate to only 1-2hz.
Furthermore, these two protocols also specify bi-directional communication, which is not possible without modifying the DME hardware (the production DME can only output data, not receive). It might be possibly that bi-directional communication is not needed, though I doubt it - regardless, I would have to really look into the protocol to find out.
Finally, hitting 10.4k Baud is also not possible with the stock DME hardware. Even if bi-directional communication is not needed, we would still have to update the DME hardware just to be able to hit that slow Baud rate.
Really, if OBD2 communication is desired, then the best thing would be a MitM box which has the newest/fastest communication hardware (CAN), and it reads the DME output data, stores it, and then sends it to the OBD2 logger when that data is requested from your OBD2 device.
Here's a question if OBD-2 was to happen... Would the data rate not be real time, since the Motronic code gets translated into M-Tune code- then would have to go to another box and convert to OBD-2 code, Your refresh rate/data rate would suffer I'd think, even our $8,000 Toyota Techstream at work has a slow refresh rate
Rogue. I'm up for it but it will take a while. A buddy of mine already has some working OBD2 translation code which I could adapt. I'll contact you once I'm ready to pick up the programming.
Yes, there would be a delay, but I'm unsure how significant it will be. The best would be if Rogues DME logger would output OBD2 directly as that would open a vast range of possibilities, but there are many reasons for why Rogue may not want to do that. Lack of time possibly the biggest, but it would possibly require a hardware change? (As far as I know OBD2 is request based meaning a request is sent to the DME which then replies, while Rogues DME logger simply sends a continuous stream of serial data).
Yes, there would be a delay, but I'm unsure how significant it will be. The best would be if Rogues DME logger would output OBD2 directly as that would open a vast range of possibilities, but there are many reasons for why Rogue may not want to do that. Lack of time possibly the biggest, but it would possibly require a hardware change? (As far as I know OBD2 is request based meaning a request is sent to the DME which then replies, while Rogues DME logger simply sends a continuous stream of serial data).
For example, one protocol uses PWM (pulse-width modulation); another uses VPW (variable pulse-width). The DME does not have the hardware to support this type of communication.
Yet another protocol is CAN, which again the DME does not have the hardware to support.
The remaining protocols are: ISO 9141-2, and ISO 14230. These are closer to what the DME has (hardware). However, the maximum standard data-rate is only 10.4k Baud... This is only 1/11th the rate of what my logger currently does. This means that the rate is really slow, and will reduce the update rate for all values coming from the DME. Currently the update rate is 15-20hz; conforming to 10.4k would reduce the update rate to only 1-2hz.
Furthermore, these two protocols also specify bi-directional communication, which is not possible without modifying the DME hardware (the production DME can only output data, not receive). It might be possibly that bi-directional communication is not needed, though I doubt it - regardless, I would have to really look into the protocol to find out.
Finally, hitting 10.4k Baud is also not possible with the stock DME hardware. Even if bi-directional communication is not needed, we would still have to update the DME hardware just to be able to hit that slow Baud rate.
Really, if OBD2 communication is desired, then the best thing would be a MitM box which has the newest/fastest communication hardware (CAN), and it reads the DME output data, stores it, and then sends it to the OBD2 logger when that data is requested from your OBD2 device.
#95
Joshua, I someday hope to learn the foreign language that you speak.
#96
Rennlist Member
Ask Lart to help you with that. ;-)
#98
Rennlist Member
Join Date: Oct 2002
Location: Melbourne, Australia
Posts: 1,110
Likes: 0
Received 0 Likes
on
0 Posts
TunerPro load definition file problems
Anyone else getting a failure to load their M-Tune adx definition file?
I've had it working in the past, but have re-installed the 951 bundle via Joshua's website link on a new laptop. TunerPro v5.00. I get a message saying "Unrecognized encoding (parser does not support utf-8 encodings)".
cheers
I've had it working in the past, but have re-installed the 951 bundle via Joshua's website link on a new laptop. TunerPro v5.00. I get a message saying "Unrecognized encoding (parser does not support utf-8 encodings)".
cheers
#99
Rennlist Member
Join Date: Oct 2002
Location: Melbourne, Australia
Posts: 1,110
Likes: 0
Received 0 Likes
on
0 Posts
looks like an issue relating to the recently released latest version of TunerPro RT (5.00.8414).
I installed v5.00.8202.00 and the definition file load was OK.
I installed v5.00.8202.00 and the definition file load was OK.
#100
Addict
Rennlist Member
Rennlist
Small Business Partner
Rennlist Member
Rennlist
Small Business Partner
Thread Starter
Glad you figured out the issue...
I've occasionally ran into that error - just haven't had time to pursue it.
I've occasionally ran into that error - just haven't had time to pursue it.
#101
Rennlist Member
Join Date: Oct 2002
Location: Melbourne, Australia
Posts: 1,110
Likes: 0
Received 0 Likes
on
0 Posts
#103
Rennlist Member
#105
The engine end gets left hanging for dead, you don't do anything with it (it just goes back to a grounding point). Tape it off.
The DME end connects to the blue wire of the DME logger.