10-27-2015, 11:05 AM
Last edit by: IB Advertising
See related guides and technical advice from our community experts:
Browse all: Engine and Powertrain
- Ford Mustang V6 1994-2004: Engine Codes Diagnostic Guide
Guide to diagnose trouble and recommended solutions.
Browse all: Engine and Powertrain
ELM327 OBDII recomendations.
11-14-2011, 11:40 AM
#1
1st Gear Member
Thread Starter
Join Date: May 2006
Location: Michigan
Posts: 69
ELM327 OBDII recomendations.
I am looking into getting a Bluetooth ELM327 OBDII to match my 01 Cobra and work off my phone. Being noobish in this particular area, does anyone using one any particular one or app? Seems like the Soliport ELM 327 Bluetooth OBDII works and the price is right on the actual adapter but you still need an app.
My thought is I don't always need a tuner and the Bluetooth factor makes it very unobtrusive.
My thought is I don't always need a tuner and the Bluetooth factor makes it very unobtrusive.
11-14-2011, 01:07 PM
#2
5th Gear Member
Join Date: Aug 2005
Location: Whitehall, Michigan
Posts: 2,638
The ebay bluetooth adapters are fairly slow, but they work. I can't recall getting more than 15 PID updates/second. It's certainly not the speed of logging you'll get with the handheld tuner. You will also only get basic logging capability unless you know the PID's and offsets.
If you have an Android phone, Torque is a great app for it. The pairing code for the bluetooth adapters from ebay is typically 1234.
Any other specific questions?
If you have an Android phone, Torque is a great app for it. The pairing code for the bluetooth adapters from ebay is typically 1234.
Any other specific questions?
11-14-2011, 03:01 PM
#3
1st Gear Member
Thread Starter
Join Date: May 2006
Location: Michigan
Posts: 69
Torque was what I was looking at from the APP side. It seems to be the one everyone keeps talking about as the best most error free.
If the "ebay" adapters are slow - what other ones might be better? It looks like there is a newer one that I throw in with the Generic eBay ones that is supposed to be updated. Better connection, etc. Any knowledge of it? All of the comments I see are the older ones. How many PIDs should I really want to see per second? Is that a limitation of the wireless or the adapter? If you don't mind - what was your setup?
Any recommendations for faster ones? I see some pricey options out there that are complete kits like the Kiwi one. But if I can do it for $30 why pay $100 is my thought. I would like some logging data to analyze.
If the "ebay" adapters are slow - what other ones might be better? It looks like there is a newer one that I throw in with the Generic eBay ones that is supposed to be updated. Better connection, etc. Any knowledge of it? All of the comments I see are the older ones. How many PIDs should I really want to see per second? Is that a limitation of the wireless or the adapter? If you don't mind - what was your setup?
Any recommendations for faster ones? I see some pricey options out there that are complete kits like the Kiwi one. But if I can do it for $30 why pay $100 is my thought. I would like some logging data to analyze.
11-14-2011, 07:25 PM
#4
TECH SAVANT
Join Date: Dec 2006
Location: Saint Augustine, FL
Posts: 10,938
10-15 PIDs/S is about the limit for anything requested through the OBD2 port on our (EECV J1850 PWM protocol) cars--in fact the SAE spec says no more then 10/S, the bus data rate is after all just 41.6 kBaud for the whole "enchilada".
I have a great deal of experience with the ELM 327, and while it is a very capable module it is also a bit slow. Though other I/O rates up to 500 kBaud (though not reliably) can be programmed as the hardware set "high" rate the defaults are 9600 and 38,600--hardly blazing. I have one hardwired to a serial port at 115k and making sequential PID requests with no delays will hang up the ELM327 (due to the 327's data response timeout setting¹) after 15 seconds at a rate 35 to 40 PIDs/S on my '03 GT.
Sometimes I have even made it screw up the lower priority bus packets, like speedometer and tach messages to the cluster, making them go nuts and wave all over the place.
Requesting proprietary PIDs is even a bit slower because of the need to serially load the new packet headers.
--------------------------------------------
¹ - the shortest possible timeout is 4.0 ms (theoretically 250 requests per second), the default is 200 ms (5 requests/S if they all timed out). Setting this timeout to 40 ms (25 timeouts/S) and using the most aggressive adaptive timing switch value of 2 seems to work OK on our cars.
================================================== =======
Oh, re other OBD2 scan tools--they just make the logging rate look faster by saving data rows more often and assigning higher priority to the more important PIDs. Examine a log file closely and you'll see that lower priority PIDs will have exactly the same value for as many as half-dozen rows--they weren't really sampled just repeated 'til the next time they come round. It took me the longest time to figure how "they" were scanning the J1850 bus so fast?
However, all that said keep in mind that at 6000 rpm, on a 4-stroke/cycle engine the firing rate is only 3000/min, which is only 50 firings per second. so you don't really need all that fast an OBD2 scan rate to get a good picture of what's going on.
I have a great deal of experience with the ELM 327, and while it is a very capable module it is also a bit slow. Though other I/O rates up to 500 kBaud (though not reliably) can be programmed as the hardware set "high" rate the defaults are 9600 and 38,600--hardly blazing. I have one hardwired to a serial port at 115k and making sequential PID requests with no delays will hang up the ELM327 (due to the 327's data response timeout setting¹) after 15 seconds at a rate 35 to 40 PIDs/S on my '03 GT.
Sometimes I have even made it screw up the lower priority bus packets, like speedometer and tach messages to the cluster, making them go nuts and wave all over the place.
Requesting proprietary PIDs is even a bit slower because of the need to serially load the new packet headers.
--------------------------------------------
¹ - the shortest possible timeout is 4.0 ms (theoretically 250 requests per second), the default is 200 ms (5 requests/S if they all timed out). Setting this timeout to 40 ms (25 timeouts/S) and using the most aggressive adaptive timing switch value of 2 seems to work OK on our cars.
================================================== =======
Oh, re other OBD2 scan tools--they just make the logging rate look faster by saving data rows more often and assigning higher priority to the more important PIDs. Examine a log file closely and you'll see that lower priority PIDs will have exactly the same value for as many as half-dozen rows--they weren't really sampled just repeated 'til the next time they come round. It took me the longest time to figure how "they" were scanning the J1850 bus so fast?
However, all that said keep in mind that at 6000 rpm, on a 4-stroke/cycle engine the firing rate is only 3000/min, which is only 50 firings per second. so you don't really need all that fast an OBD2 scan rate to get a good picture of what's going on.
11-14-2011, 11:03 PM
#5
5th Gear Member
Join Date: Aug 2005
Location: Whitehall, Michigan
Posts: 2,638
10-15 PIDs/S is about the limit for anything requested through the OBD2 port on our (EECV J1850 PWM protocol) cars--in fact the SAE spec says no more then 10/S, the bus data rate is after all just 41.6 kBaud for the whole "enchilada".
I have a great deal of experience with the ELM 327, and while it is a very capable module it is also a bit slow. Though other I/O rates up to 500 kBaud (though not reliably) can be programmed as the hardware set "high" rate the defaults are 9600 and 38,600--hardly blazing. I have one hardwired to a serial port at 115k and making sequential PID requests with no delays will hang up the ELM327 (due to the 327's data response timeout setting¹) after 15 seconds at a rate 35 to 40 PIDs/S on my '03 GT.
Sometimes I have even made it screw up the lower priority bus packets, like speedometer and tach messages to the cluster, making them go nuts and wave all over the place.
Requesting proprietary PIDs is even a bit slower because of the need to serially load the new packet headers.
--------------------------------------------
¹ - the shortest possible timeout is 4.0 ms (theoretically 250 requests per second), the default is 200 ms (5 requests/S if they all timed out). Setting this timeout to 40 ms (25 timeouts/S) and using the most aggressive adaptive timing switch value of 2 seems to work OK on our cars.
================================================== =======
Oh, re other OBD2 scan tools--they just make the logging rate look faster by saving data rows more often and assigning higher priority to the more important PIDs. Examine a log file closely and you'll see that lower priority PIDs will have exactly the same value for as many as half-dozen rows--they weren't really sampled just repeated 'til the next time they come round. It took me the longest time to figure how "they" were scanning the J1850 bus so fast?
However, all that said keep in mind that at 6000 rpm, on a 4-stroke/cycle engine the firing rate is only 3000/min, which is only 50 firings per second. so you don't really need all that fast an OBD2 scan rate to get a good picture of what's going on.
I have a great deal of experience with the ELM 327, and while it is a very capable module it is also a bit slow. Though other I/O rates up to 500 kBaud (though not reliably) can be programmed as the hardware set "high" rate the defaults are 9600 and 38,600--hardly blazing. I have one hardwired to a serial port at 115k and making sequential PID requests with no delays will hang up the ELM327 (due to the 327's data response timeout setting¹) after 15 seconds at a rate 35 to 40 PIDs/S on my '03 GT.
Sometimes I have even made it screw up the lower priority bus packets, like speedometer and tach messages to the cluster, making them go nuts and wave all over the place.
Requesting proprietary PIDs is even a bit slower because of the need to serially load the new packet headers.
--------------------------------------------
¹ - the shortest possible timeout is 4.0 ms (theoretically 250 requests per second), the default is 200 ms (5 requests/S if they all timed out). Setting this timeout to 40 ms (25 timeouts/S) and using the most aggressive adaptive timing switch value of 2 seems to work OK on our cars.
================================================== =======
Oh, re other OBD2 scan tools--they just make the logging rate look faster by saving data rows more often and assigning higher priority to the more important PIDs. Examine a log file closely and you'll see that lower priority PIDs will have exactly the same value for as many as half-dozen rows--they weren't really sampled just repeated 'til the next time they come round. It took me the longest time to figure how "they" were scanning the J1850 bus so fast?
However, all that said keep in mind that at 6000 rpm, on a 4-stroke/cycle engine the firing rate is only 3000/min, which is only 50 firings per second. so you don't really need all that fast an OBD2 scan rate to get a good picture of what's going on.
I've got a moates quarterhorse to tune my car, which just goes on the J3 port. So I'm not flashing my ECU directly. This, now, gives me more capability by a longshot (direct logging of many more memory values at much higher rates than are allowed by the OBD port) and live-updating of my tune. But I'd like to be able to apply my skills to other people's cars and possibly earn some money on the side.
A friend of mine has become big in the Audi circles, with my guidance. He's partnered with someone and has started J-Fonz tuning. I've become quite handy with PID boost control and general tuning of 02+ subarus and have done some work for some local people. I'm no bin hacker, but it just seems like there really should be a standardized communication protocol the Ford ECU's use to flash because SCT, Diablo, and Sniper are all capable of doing it. But it isn't really documented anywhere?
That's just an aside
back to the topic of the thread...I'd say just get the cheapest ebay one you can find that's located in the US. If it's located in Hong Kong like most of them will be, it'll take about three and a half weeks to show up. Once you get it, plug it into the car, turn on bluetooth from your phone, and search for devices.
You'll be looking for CBT, add it with a pairing code of 1234. It should pair, but not connect. Go ahead and start up Torque, tap menu, settings, and scroll down to preferred devices, choose CBT... then Torque should connect with no problems. You'll want to play with Torque as it's fairly capable. Try to limit the amount of things you're viewing at one time because of the inherent speed limit. Adding too many things will result in very slow updates.
11-15-2011, 10:01 AM
#6
TECH SAVANT
Join Date: Dec 2006
Location: Saint Augustine, FL
Posts: 10,938
6+ years digging on the web and working with Ford tuning system makers.
I am familiar with Bluetooth. I don't like it, but have used it more than I would ever care to. It was not designed for telemetry and is not very good at it.
I did once design a ELM/BT based data logger, and in testing we used it to log a run at the strip using industrial BT interfaces from SENA (this on the OBD2 device and this on a netbook). They claim up to 1000 m (3300 ft) range, we had no problems over 1500+ ft. The BT worked fine even though the collected data was not worth much--but that's another story, so here we go...
Beyond the J1850 PWM bus speed of only 41.6 kBaud it is important to realise that the EECV main processor runs at just a piddly 18 MHz¹. Because of this and the need to keep the engine running--and talk to the ABS and air bag modules, and instrument cluster--it responds to diagnostic PID requests only between timing/fueling/monitoring/learning/internal reporting operations when it get's bored and has the time.
EECV is not as bad as the earlier EEC-IV (15 MHz, with crappy I/O and 1/4 the memory), however between PID requests being a low priority and the 41.6 kBaud bus OBD2 logging is sluggish at best.
Another issue is that nothing is calibrated, the temperature sensors being of particular note as they are just cheap thermistors. All that is important is that they be repeatable so that the PCM's adaptive learning can come to rely on whatever they report to adjust fueling and timing. Even the MAF is a far less than precision device, it doesn't need to be because in closed-loop operation (99.44% of the time for most drivers) the O2 sensor feedback will let the PCM maintain the desired average target AFR (14.68:1).
---
On to the ELM327 a really nifty and capable device, that is a bit sluggish in it's default modes--9600 or 38,400 Baud external data rate, 200 ms response timeout, and full respect for the OBD2 bus's protocols (more about that later).
I have only briefly used it with a modern CAN bus and newer PCMs many of which run at 1 GHz+, performance was much better, however the 327's practical external data rate limit of 230 kBaud does start to step in.
If you buy a 327 based device make sure it's a real ELM chip, not a clone. The early ELM chips had poor code protection and ELM's v1.2 firmware was widely decrypted and cloned. Though most of the Asian knockoffs will claim to be v1.3a or 1.4a (the latest) and even report same when powered up--nonetheless they are actually v1.2 or earlier firmware, which really kinda' suck compared the v1.3x and 1.4x.
Real v1.4x ELM327s are $32.50 each in quantities of 1-9, going down to $20 in 1000+ piece orders. So if you see a ELM327 device selling for less than $75 (with support circuitry, BT interface, case, OBD2 connector, etc.) it's probably a clone. One caveat, v1.3x chips are still available from ELM for $19 each and $11 or so in quantity, so it's not inconceivable someone could make a legitimate ELM 1.3x OBD2 device and retail it for $40--maybe...
I have yet to find an ELM based logger (including the ones I have designed/built) that makes me say WOW; I have five of them, 2 mass produced real ELM 327 units, 2 prototypes, and one Asian clone; I rarely if ever use them and instead fall back on a 14-year old system I got from a fellow named Alex Peper (www.obd-2.com). I currently use his TriCAN/Tricom/Indo-3 interface.
So there you go, a synopsis of my KSAs and opinion regarding OBD2 data logging.
------------------------------------------------------
¹ - These MCUs are labeled 8065 and was derived by Ford's Microelectronics division from the Intel 8061 used in the EEC-IV, and was sourced from Motorola and later Toshiba. It runs at just 18 MHz though I have seen refereneces this may have been bumped to 24 MHz in '02-1/2 to '04).
I am familiar with Bluetooth. I don't like it, but have used it more than I would ever care to. It was not designed for telemetry and is not very good at it.
I did once design a ELM/BT based data logger, and in testing we used it to log a run at the strip using industrial BT interfaces from SENA (this on the OBD2 device and this on a netbook). They claim up to 1000 m (3300 ft) range, we had no problems over 1500+ ft. The BT worked fine even though the collected data was not worth much--but that's another story, so here we go...
Beyond the J1850 PWM bus speed of only 41.6 kBaud it is important to realise that the EECV main processor runs at just a piddly 18 MHz¹. Because of this and the need to keep the engine running--and talk to the ABS and air bag modules, and instrument cluster--it responds to diagnostic PID requests only between timing/fueling/monitoring/learning/internal reporting operations when it get's bored and has the time.
EECV is not as bad as the earlier EEC-IV (15 MHz, with crappy I/O and 1/4 the memory), however between PID requests being a low priority and the 41.6 kBaud bus OBD2 logging is sluggish at best.
Another issue is that nothing is calibrated, the temperature sensors being of particular note as they are just cheap thermistors. All that is important is that they be repeatable so that the PCM's adaptive learning can come to rely on whatever they report to adjust fueling and timing. Even the MAF is a far less than precision device, it doesn't need to be because in closed-loop operation (99.44% of the time for most drivers) the O2 sensor feedback will let the PCM maintain the desired average target AFR (14.68:1).
---
On to the ELM327 a really nifty and capable device, that is a bit sluggish in it's default modes--9600 or 38,400 Baud external data rate, 200 ms response timeout, and full respect for the OBD2 bus's protocols (more about that later).
I have only briefly used it with a modern CAN bus and newer PCMs many of which run at 1 GHz+, performance was much better, however the 327's practical external data rate limit of 230 kBaud does start to step in.
If you buy a 327 based device make sure it's a real ELM chip, not a clone. The early ELM chips had poor code protection and ELM's v1.2 firmware was widely decrypted and cloned. Though most of the Asian knockoffs will claim to be v1.3a or 1.4a (the latest) and even report same when powered up--nonetheless they are actually v1.2 or earlier firmware, which really kinda' suck compared the v1.3x and 1.4x.
Real v1.4x ELM327s are $32.50 each in quantities of 1-9, going down to $20 in 1000+ piece orders. So if you see a ELM327 device selling for less than $75 (with support circuitry, BT interface, case, OBD2 connector, etc.) it's probably a clone. One caveat, v1.3x chips are still available from ELM for $19 each and $11 or so in quantity, so it's not inconceivable someone could make a legitimate ELM 1.3x OBD2 device and retail it for $40--maybe...
I have yet to find an ELM based logger (including the ones I have designed/built) that makes me say WOW; I have five of them, 2 mass produced real ELM 327 units, 2 prototypes, and one Asian clone; I rarely if ever use them and instead fall back on a 14-year old system I got from a fellow named Alex Peper (www.obd-2.com). I currently use his TriCAN/Tricom/Indo-3 interface.
So there you go, a synopsis of my KSAs and opinion regarding OBD2 data logging.
------------------------------------------------------
¹ - These MCUs are labeled 8065 and was derived by Ford's Microelectronics division from the Intel 8061 used in the EEC-IV, and was sourced from Motorola and later Toshiba. It runs at just 18 MHz though I have seen refereneces this may have been bumped to 24 MHz in '02-1/2 to '04).
Last edited by cliffyk; 11-15-2011 at 10:46 AM.
12-14-2011, 10:33 PM
#7
2nd Gear Member
Join Date: Mar 2008
Location: NJ/PA
Posts: 330
cliffyk - I am using ebayed ELM and ScanMaster ELM software. I was trying to diagnose o2 sensor problems and catalyst efficiency monitor. There is a page/function in software that goes mode $06, monitored test results. When one monitor fails by going outside of the limits range I get the code and eventually the CEL... The problem is that the TIDs and CIDs all look messed up and the results are very hard to interpret. Any idea how to deal with those?
12-15-2011, 12:46 AM
#8
TECH SAVANT
Join Date: Dec 2006
Location: Saint Augustine, FL
Posts: 10,938
cliffyk - I am using ebayed ELM and ScanMaster ELM software. I was trying to diagnose o2 sensor problems and catalyst efficiency monitor. There is a page/function in software that goes mode $06, monitored test results. When one monitor fails by going outside of the limits range I get the code and eventually the CEL... The problem is that the TIDs and CIDs all look messed up and the results are very hard to interpret. Any idea how to deal with those?
What particular O2 sensor issues are you pursuing?
12-15-2011, 12:17 PM
#9
2nd Gear Member
Join Date: Mar 2008
Location: NJ/PA
Posts: 330
cliffyk - First of all thanks for your quick reply. I really did not expect much help since no-one seems to know much about that kind of thing. I was troubleshooting catalytic converter P0430 code and also had some issues with misfires on Champion plugs, thats when I stumbled upon this mode that can supposedly tell you misfire rates and also a relative cat converter efficiency number.
What I am still trying to trouble shoot is code P0430 - catalytic converter efficiency below threshold. This code popped up at around 90k miles, passed federal emissions warranty and since my car is stock and I only drive highway, and did not have any engine issues, I just do not see a reason why my cats would die so soon! I have a Toyota with 300 000 miles and everything is OK OBD and o2 sensor wise.
From what I understand, OBD reads o2 sensor voltages and counts the peaks of upstream and downstream sensors, then divides downstream number by upstream and gets a kind a relative efficiency number - the less peaks downstream the better. I just replaced all o2 sensors and the downstream 02 graph got much smoother but I am still trying to gather as much information as possible about this issue.
I noticed from before that when one monitor in Mode $06 fails in Monitored test results list in ScanMaster software I get the cat code... The one that is failing is TID$80 CID$BC ( I suspect this TID CID info is wrong but can say why and how ), Min 0.000 max 0.598 Value 0.609. I think a relative monitor is with the same TID CID but Min 0.000 Max 0.777 Value 0.645. Also I suspect that TID $81 CID $FC ( thats what my program shows ) with min max 0.465/3.00 have something to do with o2 sensors ( and may be two more monitors with 0.220/3.00 limits )... I read in the Ford manual some information on this but all the TID CID seem to be messed up on my PC screen, probably something to do with software... Seems like different monitors share the same TID CID which can not be right... However I am very interested in being able to interpret that kind of data.. I should probably upgrade my ELM software/chip... I think this info can be very useful...
What I am still trying to trouble shoot is code P0430 - catalytic converter efficiency below threshold. This code popped up at around 90k miles, passed federal emissions warranty and since my car is stock and I only drive highway, and did not have any engine issues, I just do not see a reason why my cats would die so soon! I have a Toyota with 300 000 miles and everything is OK OBD and o2 sensor wise.
From what I understand, OBD reads o2 sensor voltages and counts the peaks of upstream and downstream sensors, then divides downstream number by upstream and gets a kind a relative efficiency number - the less peaks downstream the better. I just replaced all o2 sensors and the downstream 02 graph got much smoother but I am still trying to gather as much information as possible about this issue.
I noticed from before that when one monitor in Mode $06 fails in Monitored test results list in ScanMaster software I get the cat code... The one that is failing is TID$80 CID$BC ( I suspect this TID CID info is wrong but can say why and how ), Min 0.000 max 0.598 Value 0.609. I think a relative monitor is with the same TID CID but Min 0.000 Max 0.777 Value 0.645. Also I suspect that TID $81 CID $FC ( thats what my program shows ) with min max 0.465/3.00 have something to do with o2 sensors ( and may be two more monitors with 0.220/3.00 limits )... I read in the Ford manual some information on this but all the TID CID seem to be messed up on my PC screen, probably something to do with software... Seems like different monitors share the same TID CID which can not be right... However I am very interested in being able to interpret that kind of data.. I should probably upgrade my ELM software/chip... I think this info can be very useful...
12-18-2011, 05:30 PM
#10
2nd Gear Member
Join Date: Mar 2008
Location: NJ/PA
Posts: 330
OK, actually after some tweaking of connection protocol ( changed to 11 bit CAN 500 from auto ) I was able to get the right IDs and descriptions on those monitored results... Now I wonder why the error threshold on catalyst efficiency is set higher on one bank (0.595 vs 0.777)... Should it be equal? And I am talking about S197...