When you click on links to various merchants on this site and make a purchase, this can result in this site earning a commission. Affiliate programs and affiliations include, but are not limited to, the eBay Partner Network.
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).
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
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).
Originally Posted by bebbetufs
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).
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.
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)".
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.
09-06-2013, 04:47 PM
