Honda D Series Forum banner

1 - 16 of 16 Posts

·
Registered
Joined
·
13 Posts
Discussion Starter #1
I am in search of a way to datalog without having to carry a laptop in the car.

I came across a bluetooth adapter that plugs onto the 4-pin header on the ECU

CN2 Direct ECU Bluetooth Module

It appears to be a Moates product based on the picture.

Has anyone successfully used this to datalog OBD0 with NG63 or NG64?

I am really interested to know any feedback anyone has with this for TurboEdit or Tuner Express.
 

·
Registered
Joined
·
236 Posts
If it's connected to the CN2 port it doesn't matter what system you're using, it's just a replacement for your cable. The NepTune one is specific to NepTune because it is connected to the aux port on the Demon board.
 

·
()*#$(*$
93 Legend L Coupe.
Joined
·
11,404 Posts
It does matter. A lot. The OBD0 serial protocol is different than the OBD1 stuff.

Blundell is working on a datalogger that will support OBD0.

For now, you can cobble together a few things to work, but . . . none of it is as easy as I would prefer.

You could also ask Moates nicely if they would enable a mode for OBD0 logging for the bluetooth adapter. I know a few people that would buy that.
 

·
Registered
ED635,ED456,EE838
Joined
·
5 Posts
Yep those Bluetooth modules for obd1 will work with obd0 and ecucontrol, but logging data will not be useful for any tuning purpose because of huge update interval of values. This happens because obd0 protocol works by transfering one byte at a time. For every needed byte(1 or 2 needed for calculating one value in logger) there will be 1 request and 1 answer message over Bluetooth, and every send/receive action over Bluetooth spp consumes a lot of time. For complete value set logger has to request 16 bytes from ecu and the spp send/receive delay I mentioned is added two times per needed byte(send and receive). Compared to wired connection complete set(let's say time needed for one wired complete set is 1*t) over Bluetooth consumes 1t + 32*spp_message_delay of time. According to my measurements this complete set time over Bluetooth spp is 6 times the wired complete set and it means your gauge update interval time is something between 0,5 and 1s which is unbearable in my opinion. This Bluetooth spp message delay relies in Bluetooth protocols/frameworks and there is nothing we can do about it. But the problem can be solved using batch protocol over single byte protocol which is the way obd1 works if I assume right. If I send all 16bytes at a time, whole consumed time will be 1t+2*spp_message_delay, which is a way closer to wired setup time and will not cause unbearable delays in logger. Implementing this solution needs some kind of protocol conversion between ecu and Bluetooth module and between Bluetooth receiver and logger also if no new logger software is developed. Conversion is needed because as far as I know obd0 hardware/software is not capable enough to support batch messaging reliably.
 

·
Registered
ED635,ED456,EE838
Joined
·
5 Posts
Latest NG(63 to be specific) with latest TE and EC uses send upon request for sure. I have been reverse engineering the protocol lately because I am developing my own logger software on universal windows platform. But if there is also streaming protocol implemented into ng rom I would like to know more about it. Do you happen to know good sources for information about ng development? I have been digging pgmfi archives a lot and as a source for ng development it is somehow limited.
 

·
Registered
ED635,ED456,EE838
Joined
·
5 Posts
FE Connect(only ack) ->
30 #1 ECT
32 2# IAT
39 3# TPS
6C 4# VSS
34 5# BARO
FB 6# O2
47 7# RPM HI
FA 8# RPM LOW
FD 9# COL
3B 10# ROW
F8 11# MAP
6F 12# Inj. Dur.HI
70 13# Inj. Dur.LOW
FC 14# ELD
63 15# Ign. Adv.
FE 16# GEAR

These are the request bytes send by ecucontrol. After each byte ecucontrol waits for response from ecu.
 

·
()*#$(*$
93 Legend L Coupe.
Joined
·
11,404 Posts
You are way behind, then, though I don't think the serial protocol has changed.

NG64 is out and TurboEdit is now dead. Check out TunerExpress.

Ask Joe about the serial protocol since he is the one that is developing the OBD0 stuff now. (You can get in touch with him when you fine the site for TunerExpress.)
 

·
Registered
ED635,ED456,EE838
Joined
·
5 Posts
Oh sorry forgot the NG64 and TunerExpress. I have them, but I still prefer TE and ng63 (NG64 has better gear calculatuon table, but I dont use any gear related features so I haven't had any rush to move to it). The both uses the same protocol so my information is valid for both of them. Must still contact Joe if he knows something about the factory afr/ign corrections so thank you for pointing him out.
 

·
Registered
ED635,ED456,EE838
Joined
·
5 Posts
Maybe I ask him about the protocol to be sure. I just assumed if there is a streaming one, he would have used it.
 

·
Meat Popsicle
91 CRX Si
Joined
·
2,938 Posts
Pretty cool. I had an issue with TE and the logging interval being set too low. ECU control just ends up filling the extra logging rows with identical data until the next polling cycle. I forget what the ideal interval is but I had to tinker with it until I got unique data in each row.

I wonder if there's much to be gained by increasing the polling interval or any side effects of doing so. I wonder what prompted Joe to pick that interval or if that's something that was inherited from the way the stock ECU reads the data from the sensors?
 

·
Registered
Joined
·
90 Posts
In the snippet below, software sends character address to ecu and it spits value saved in that location back to software for processing. I like to give priority to RPM, MAP, TPS, etc and poll those each time thru...ECT, IAT, Baro, etc only need to be updated once in a while so those are only polled after a certain amount of time. I thought about testing a different protocol at one point but haven't got around to writing or trying it...ie send 00h and the ecu spits back multiple values and checksum at one time.

ecuOutput is sent to the ecu as a char
hRevisionID just keeps track of which version of NG code is being used
byteLocation is used for multi byte requirements
sensorCount is only used for older NG code where things didn't exist

Code:
Case "Coolant Temp. (C6)", "ECT"
	ecuOutput = 48 '30h
Case "Intake Air Temp. (C5)", "IAT"
	ecuOutput = 50 '32h
Case "Throttle Position (C7)", "TPS"
	ecuOutput = 57 '39h
Case "Manifold Pressure (C11)", "MAP"
	ecuOutput = 248 'F8h
Case "Column"
	ecuOutput = 253 'FDh
Case "Row"
	If hRevisionID >= 221 Then
		ecuOutput = 59 '3Bh NG63 and up
	Else
    		ecuOutput = 254 'FEh NG62 and lower
	End If
Case "Engine Speed", "RPM"
	If byteLocation = 1 Then
		ecuOutput = 71 '47h RPM HI
	Else
		ecuOutput = 250 'FAh RPM LO
	End If
Case "Barometric Pressure (C9)", "Baro"
	ecuOutput = 52 '34h
Case "Vehicle Speed (B16)", "VSS"
	ecuOutput = 108 '6Ch
Case "Injector Pulsewidth", "Fuel"
	If byteLocation = 1 Then
		ecuOutput = 111 '6Fh Fuel HI
	Else
		ecuOutput = 112 '70h Fuel LO
	End If
Case "Ignition Timing", "Ignition"
	ecuOutput = 99 '63h
Case "Drive Gear", "Gear"
	If hRevisionID >= 221 Then
		ecuOutput = 254 'FEh NG63 and up
	Else
 		ecuOutput = 252 'FCh DNE, go to ELD
    		sensorCount = sensorCount + 1 'increment to ELD
	End If
Case "Electronic Load (B19)", "ELD"
	ecuOutput = 252 'FCh
Case "O2 Sensor (C16)", "O2"
	ecuOutput = 251 'FBh
Case "NA RE_MAP"
	ecuOutput = 54 '36H
Case "Boost RE_MAP"
	ecuOutput = 249 'F9H
 
1 - 16 of 16 Posts
Top