I will qualify this quick review by admitting that I am a card carrying old fart & a gadget nut. My background includes a mechanical engineering degree from the 2nd third of the 20th Century, instrumentation R&D at NASA, and software development in my twilight years to make a comfortable living.

All testing was done on my '05 Jeep Liberty CRD which has had every single TSB and recall every published done to it - including F31 & F37. Part of my motivation for wanting more instrumentation on it is the seeming vulnerability to EGR related issues (Mine failed at 36k miles). That and I was curious to learn more about the infamous Off-Road-Mod and what actual affect that might have on engine operating parameters.

I started out modestly enough. Purchased a SGII for ~$150 and began to experiment. I did learn quickly that the ORM does indeed reduce the intake air temperature - SIGNIFICANTLY! Some 35-45 degrees F under my test conditions. That alone was comforting info.

But alas, the SGII kept locking up just when I'd want to be observing something interesting. I emailed Ron Delong (software guru at Linear Logic - the developer of the Scangauge II) and he tried some things to improve this situation, but so far the problem presists. It is an annoying more than fatal flaw. It just does not allow me to count on the Scangauge II functioning for an entire trip - unless the trip is relatively short (maybe 5-15 minutes or so). Your experience may vary...

Next I started thinking about this problem and decided that perhaps a different vendor's solution would behave somewhat better. Did some online searches and eventually settled on a DashDyno SPD unit. I sprung for the Pro edition as it included some fancy PC software that I've yet to find a use for - but it may come in handy yet. Don't tell my wife I now have TWO of these types of devices. Maybe I will sell one of them after I learn all I can.

The DashDyno is functionally similar to the Scangauge II - but differs greatly in the user interface and the wider variety of gauge display options it offers. The DashDyno also has dynomometer capabilities that would have appealed to me more in my youth for that old TransAm I had... ahhh - but I'm digressing here...

To answer the basic question - yes, the DashDyno SPD also stops responding at intervals that are recognizably similar to the SGII. One big difference though is that the DashDyno SPD utilizes a 128MB "SD Card" as a solid state disk drive to hold setup parameters for gauge settings. This feature allows me to remove the SD Card and use my PC to change the data acquisition rates independently for each gauge parameter. Thus I can get turbo boost pressure (PSI) every 250 ms, and only ask for say, coolant temperature values every 5 or 10 seconds since they don't change very rapidly. This technique appears to significantly reduce the data traffic on the OBDII bus and the lockups seem a little less frequent and less annoying. But eventually it STILL locks up. No cure has been found. Both gauges require the engine to be shutdown for a minute or so and restarted before they will talk to the OBDII port again. Strange but true...

The SD Card can also be used to log information about the vehicle performance. This could prove very useful for someone trying to document the effects of performance mods, etc. It also can be used as a pass-through via USB cable to a notebook PC to further enhance the data collection and analysis capabilities. A few years back I'd have loved to have had this setup, but so much of it goes unused in my current needs that it is a bit of overkill.

Between these two options, the SGII is the more cost effect purchase. It costs less than half of what a DashDyno does. But then, the DashDyno has that dynomometer capabilty, data logging, etc., along with 0-60, 0-100, 1/8 mile and 1/4 mile timing, speed, horsepower and torque curve data acquisition that the SGII lacks. If you're really into gathering data and documenting performance parameters for analysis - the DashDyno is the more adaptable solution.

Now if only someone on this list could tweak Chrysler/Jeep's Technical Support group and get them to fix the stupid OBDII - ECM data communications failures I could be very happy with both of these devices in my toolbox.

I should also point out that the DashDyno SPD does provide a Fuel Rail Pressure parameter that displays the 5,000 to 22,000 psi of the fuel rail. Its certainly a rapidly changing value.

Neither gauge provides access to the Fuel Temperature Sensor on the fuel filter assy. I have not fully explored the xGauge feature of the Scangauge II - so it might be possible to query this temperature once we figure out how to ask the OBDII for it.

If you have any specific questions, I'd be happy to try to answer them.

PS - the xGauge capability is NOT duplcated by the DashDyno.

PSS - try as I might, I have yet to find a way to get either of these fine instruments to "automatically" turn off the MIL upon startup.

PSSS - Since the SGII has dual RJ45 ports and is rumored to allow you to daisy chain two such devices together, I'm currently building a suitable cable (the PINOUTS ARE DIFFERENT) so I can test using the two devices simultaneously. I'm not very hopeful here, but am game to give it a try.

Did he try setting a reoccuring initialization routine at beginning or end of each SGII loop counter\machine cycle - the monitored info is constantly running on the DCX bus, or the engine would go all screwy, so the SGII must lose sync, lose it's place in the stream - seems to be the case, as it gets lost sooner the faster the scan rate, takes longer the slower the scan rate.

www.auterraweb.com/dashdyno.html - does appear to have some of the enhanced parameters, which would include Fuel Rail Pressure - looks like even more parameters are included in the PC Windows version

Scanguage II - <175bucks
OBD2 - yes
OBD2 Enhanced - no
Bi-directional control - no
Multi vehicle - yes
Dash module - yes, convenient

Auterra - ~400bucks
OBD2 - yes
OBD2 Enhanced - limited
Bi-directional control - no
Multi vehicle - yes
Dash module - yes - convenient
PC version - yes
Dyno capability - yes

Autoenginuity - ~500bucks
OBD2 - yes, full
OBD2 Enhanced - yes, full
Bi-directional control - yes, full
Multi vehicle - yes
Dash module - no
PC version - yes
PDA version - yes
Palm PC version - yes
Enhanced Dyno capability - yes

_________________
'05 CRD Limited
Pricol EGT, Boost
GDE Hot '11; EDGE Trail switched
SEGR; Provent; Magnaflow;
Suncoast T\C, Transgo Tow'n'Go switch;
Cummins LP module, Fleetguard filter, Filterminder
2.5" Daystar f, OME r; Ranchos; K80767's, Al's lifted uppers
Rubicons, 2.55 Goodyears
Four in a row really makes it go

If this were the case, wouldn't you be able to unplug the SGII for a few minutes (no power to SGII) and plug it back in and have it work? Surely the SGII would try and resynch? I don't think my SGII will start back up after being unplugged for a few minutes unless I actually turn the motor off and back on.

_________________
'05 Liberty CRD
'05 Jaguar S-Type R

I got the impression that these devices were active participants on the bus, rather than passive observers. I could be wrong; I only guess this because it fits the behavior (more bus traffic interaction increases the chance of lockup).

- Chris

_________________
Used to own:
2006 CRD Sport
Suncoast TC, Transgo shift kit, Inmotion, ORM, EHM, Magnaflow SS exhaust, Fumoto valve, EVIC added, Hensley TruControl brake controller, Pirelli Scorpion ATR LR-D in spring/summer/fall, FIA winter front and Blizzaks in winter

Here's what I do know. Once the gauge communication stops updating, the communications log file (one can created using the DashDyno) shows that data packets continue to be exchanged between the gauge and the OBDII. It goes like, "Request for gauge 1 data", followed by a "reply of gauge 1 data". The request/reply conversation appears to continue, although the actual data goes missing...

In place of the hex values (in the comlog file) that represented the actual data on the "reply" packets from the OBDII, the data is replaced by nul (00h) values. Once this begins you can try and go through the manual process on the DashDyno to "Connect to vehicle" in an attempt to restore communications but it doesn't work. The "Connect to vehicle" step goes MUCH slower when the gauge has stopped responding. Instead of 4-5 seconds it takes more like 30-35 seconds in this situation. But curiously the DashDyno display eventually does indicate that it has indeed "Connected to the vehicle". Even so - the gauge parameters will still NOT update - you continue to get only nul responses from the OBDII connection. So far, only a shutdown/wait a minute/restart of the engine will reliably restore communications.

One thing that I've been experimenting with but have yet to find a reproducible situation is to switch between the Scangauge II and a DashDyno SPD when a lockup occurs. I don't know if one can "recover" from the other's confused communications logjam - but when I get a suitable cable configured I'll do some testing. It isn't promising, but I'm game to try some possibilities.

If only Chrysler would see our plight and jump in and fix this right!

Without trying to decipher this, I am showing a short segment of a comlog file typical of that captured by the DashDyno. I don't remember what gauge parameters I was displaying at the time but it appears that I was perhaps using the single gauge display mode.

You will note that there are what appear to be sent packets (s=) and reply packets (r=). The t= parameter is in millisends for a time reference. When the data communcation stops, these packets continue to be exhanged, but the data on the 7th and up bytes become nuls (00 values).


<c s='2d 10 05 68 6a f1 01 23 00 00 00 00 00 00 fc ' t='2231851'></c>
<c r='2d 81 48 6b 12 41 23 0c f6 2b 00 ea 00 c1 ' t='2232016'></c>
<c s='2d 10 05 68 6a f1 01 0b 00 00 00 00 00 00 e4 ' t='2232051'></c>
<c r='2d 81 48 6b 12 41 0b 66 77 00 00 ea 00 59 ' t='2232216'></c>
<c s='2d 10 05 68 6a f1 01 23 00 00 00 00 00 00 fc ' t='2232241'></c>
<c r='2d 81 48 6b 12 41 23 0c f6 2b 00 ea 00 c1 ' t='2232416'></c>
<c s='2d 10 05 68 6a f1 01 0b 00 00 00 00 00 00 e4 ' t='2232451'></c>
<c r='2d 81 48 6b 12 41 0b 66 77 00 00 ea 00 59 ' t='2232616'></c>
<c s='2d 10 05 68 6a f1 01 23 00 00 00 00 00 00 fc ' t='2232672'></c>
<c r='2d 81 48 6b 12 41 23 0d 0c 42 00 ea 00 ef ' t='2232831'></c>
<c s='2d 10 05 68 6a f1 01 0f 00 00 00 00 00 00 e8 ' t='2232861'></c>
<c r='2d 81 48 6b 12 41 0f 3a 4f 00 00 ea 00 09 ' t='2233016'></c>
<c s='2d 10 05 68 6a f1 01 0b 00 00 00 00 00 00 e4 ' t='2233041'></c>
<c r='2d 81 48 6b 12 41 0b 66 77 00 00 ea 00 59 ' t='2233191'></c>
<c s='2d 10 05 68 6a f1 01 23 00 00 00 00 00 00 fc ' t='2233216'></c>
<c r='2d 81 48 6b 12 41 23 0d 22 58 00 ea 00 1b ' t='2233371'></c>
<c s='2d 10 05 68 6a f1 01 0b 00 00 00 00 00 00 e4 ' t='2233416'></c>
<c r='2d 81 48 6b 12 41 0b 66 77 00 00 ea 00 59 ' t='2233571'></c>
<c s='2d 10 05 68 6a f1 01 23 00 00 00 00 00 00 fc ' t='2233616'></c>
<c r='2d 81 48 6b 12 41 23 0d 0c 42 00 ea 00 ef ' t='2233771'></c>
<c s='2d 10 05 68 6a f1 01 0b 00 00 00 00 00 00 e4 ' t='2233816'></c>
<c r='2d 81 48 6b 12 41 0b 66 77 00 00 ea 00 59 ' t='2233971'></c>
<c s='2d 10 05 68 6a f1 01 23 00 00 00 00 00 00 fc ' t='2234041'></c>
<c r='2d 81 48 6b 12 41 23 0c f6 2b 00 ea 00 c1 ' t='2234201'></c>
<c s='2d 10 05 68 6a f1 01 0b 00 00 00 00 00 00 e4 ' t='2234241'></c>
<c r='2d 81 48 6b 12 41 0b 66 77 00 00 ea 00 59 ' t='2234391'></c>
<c s='2d 10 05 68 6a f1 01 05 00 00 00 00 00 00 de ' t='2234416'></c>
<c r='2d 81 48 6b 12 41 05 6e 79 00 00 ea 00 5d ' t='2234571'></c>

ALDL stream access must be available on the connector at all times, by federal mandate - the Autoenginuity scantool does not lose sync\communication, so it appears as tho the data is there - possibly the small monitors are not sophisticated enuff to recapture the data sync out of the enhanced stream anytime other than at key-ON ECM initialization.

I get few opportunities to use the AE setup on the little mule, but I do seem to recollect some hassle with logging on after the engine is running - could also be due to my inexperience with the scantool

_________________
'05 CRD Limited
Pricol EGT, Boost
GDE Hot '11; EDGE Trail switched
SEGR; Provent; Magnaflow;
Suncoast T\C, Transgo Tow'n'Go switch;
Cummins LP module, Fleetguard filter, Filterminder
2.5" Daystar f, OME r; Ranchos; K80767's, Al's lifted uppers
Rubicons, 2.55 Goodyears
Four in a row really makes it go

Here's a link for the Scangague II at $159.00 They sell Eurovan camper parts. I also have a Eurovan

Joe

_________________
Atlantic Blue 06 CRD Limited (his)
Joined by a 2000 XJ Classic (hers)

Joe,

ScanGauge is giving us a $149 group by direct. Need me to look it up for you?

_________________
Dave

'06 CRD Limited, Lt. Khaki, MOPAR Slush Mats/Skids, DrawTite Front Hitch, Mag Lite, Yakima Bars, Thule Bike Rack, Fumoto, ORM, 245/70 Revo 2

Wish list: Lift, Boulder Bars, Something Bigger in the Front and Back, More Lights

Hi CC,

I'm interested. If you're volunteering to save me the trouble of looking up this information, by all means feel free. It's probably a good thing to post to this thread for reference anyway.

- Chris

_________________
Used to own:
2006 CRD Sport
Suncoast TC, Transgo shift kit, Inmotion, ORM, EHM, Magnaflow SS exhaust, Fumoto valve, EVIC added, Hensley TruControl brake controller, Pirelli Scorpion ATR LR-D in spring/summer/fall, FIA winter front and Blizzaks in winter

Ask and ye shall receive. Perhaps it should be a sticky!

http://www.lostjeeps.com/forum/phpBB3/vie ... sc&start=0

_________________
Dave

'06 CRD Limited, Lt. Khaki, MOPAR Slush Mats/Skids, DrawTite Front Hitch, Mag Lite, Yakima Bars, Thule Bike Rack, Fumoto, ORM, 245/70 Revo 2

Wish list: Lift, Boulder Bars, Something Bigger in the Front and Back, More Lights

Ok - I cobbled together a custom RJ-45 connector cable to correct the pinout differences between the Scangauge II and the DashDyno SPD. Essentially I ended up with the SGII plugged into the OBDII connector as normal, and the DashDyno "daisy chained" off the SGII secondary RJ45 connector using this custom pinout correction jumper cable. IF YOU DO THIS - REALIZE THAT THE PINOUTS ARE VERY DIFFERENT BETWEEN THE SGII and the DASHDYNO SPD unit. Failing to properly connect the right pins in this cable these could (and likely would) damage one or both units irrepairably! I won't even attempt to document the pinouts - as this is easy enough to do if you are a true DIY type. And I don't want to be held responsible if something goes terribly wrong on your attempt! If you aren't comfortable doing this completely on your own - then don't do it at all!

Now here is what I see happening.

Upon startup, the SGII automatically turns on - and syncs up with the OBDII as it always does. I allow time for this to stabalize (30 seconds or so) and then I switch on the DashDyno SPD. Apparently when the DashDyno attempts to sync with the OBDII it "sometimes" interferes with the SGII/OBDII communications. Often the SGII will then timeout within 10-20 seconds and the DashDyno continues working just fine. On some rare occassions, the SGII doesn't timeout and still continues to work along with the DashDyno - both are responding as you'd wish they would. But under these conditions, eventually the SGII gives up and goes to sleep and turns itself off. This happens within 10-15 minutes on most occassions.

The DashDyno continues to work for a while - but eventually the gauges stop responding. BUT - if I leave things alone - the DashDyno usually starts responding again after about 30-45 seconds. I say "usually" because on a couple of occassions it stayed stuck for the rest of a trip - never regaining sync with the OBDII again. The encouraging part is that it does appear to wake up again on most occassions. I don't know exactly what is going on there.

One cautionary note: On a few occassions, it felt like just as the DashDyno woke up again, the engine hesitated like it was shutoff for just a moment of time. Sort of like a misfire - enough that my passenger wife asked me what had happened!

So - daisychaining the DashDyno off the SGII doesn't cure things. But does exhibit some changes in behavior that might indicate some hope that there is indeed a way to restore the OBDII communications on-the-fly. I'll leave that to the experts. Unfortunately the only data logging capability I have is within the DashDyno itself - so I have no way to monitor or log the events as seen by the OBDII connector side of things.

I pass this along for information only. Am not sure what it all means - but thought a few folks might want to know.

John

Thanks John,

I have had the engine respond with CEL while trying out SGII settings. Yes, it is risky territory you are in. I hope we get something to solve this "dropout" problem soon.

B

_________________
----------------------------------------------------------------------
06 CRD LTD - Suncoast TC- Shift Kit - Spicer UJ - FRKNLIFT - F37 - Magnaflow - 22.0 City - 24@65MPH - Fumoto F-102 - AUX T Cooler - Tank Lift Pump

Random thought - the EVIC uses information from the OBD-II connector to do its thing, and it never locks up. I wonder if this means there is a solution possible for the third-party scanners?

- Chris

_________________
Used to own:
2006 CRD Sport
Suncoast TC, Transgo shift kit, Inmotion, ORM, EHM, Magnaflow SS exhaust, Fumoto valve, EVIC added, Hensley TruControl brake controller, Pirelli Scorpion ATR LR-D in spring/summer/fall, FIA winter front and Blizzaks in winter

Monitoring the data streams - the initializing-only SGII poll could be compared the the initializing\re-initializing poll of the Dash-dyno, right?

_________________
'05 CRD Limited
Pricol EGT, Boost
GDE Hot '11; EDGE Trail switched
SEGR; Provent; Magnaflow;
Suncoast T\C, Transgo Tow'n'Go switch;
Cummins LP module, Fleetguard filter, Filterminder
2.5" Daystar f, OME r; Ranchos; K80767's, Al's lifted uppers
Rubicons, 2.55 Goodyears
Four in a row really makes it go

I can't say that for certain. When used independently, the SGII and DashDyno have roughly the same random "time-to-failure" of the data communications. And in the standalone configuration, neither the SGII nor the DashDyno seems to have the capacity to restore the data link.

What is interesting is that when used in series, the DashDyno will (for most situations) restore its communications after 30 to 45 second dropouts. Perhaps during that downtime, the SGII attempts to wake up and tries to re-establish data communications, only to be wrestled for control by the DashDyno. As I cannot see the details of what is really going on - all I can do is describe the outcome. When I speak of the SGII going to sleep - I mean just that - the screen goes completely blank as if it was out of the picture. During those times, the DashDyno (even though it is downstream from the SGII on the data cable) continues to work just fine...at least for a while.

All this could be fixed by Chrysler if they had a mind to do so. Anybody got an inside contact that might shake them up a bit?