Is it worth upgrading to EFILive?
You use a company name on these forums but are not a supporting vendor, then you use the "Regards" gig on 1 hand yet use nice words like "artifically inflate"
when we all know what your really saying.
Wait I will get some source code from Ease or GM so you can put it into public domain and then use it in the product you sell, what a joke, you really think even if I know exactly how its done I would violate my ethics to promises I have made.
I do not care how its done, only that it works and as a customer I want the best tool to do my work and its not peddling scanners in cyberspace.
Hate to tell you but its not 50 concurrent PIDS but its 68.
If you want to prove or not what a competing scanner does breakdown and spend all those USA dollars you make and finally buy a Ease scanner and do the right thing, its called benchmark testing competing vendors products.
Then ask yourself why Ease is EPA certified and a supplier to GM,
and other scanners are not, so I would be skeptic of why a vendor in another country for a couple of years has not done their homework and got approved or passed EPA tests, could the answer be cause its not public domain source code to take ownership of and profit from ?
I do no have to inflate squat, I am not a vendor and if I found another scanner that was better then what I use I would swap in a heartbeat so do not play that game for I mentioned high speed transfer almost 1 year ago when I started testing it and clearly if it did not measure up all the others testing it would have said so and the function would not have made it into a new release.
As to the 10.4K baud if that is what you use well that's your problem and I suggest you get with the act for with OBD-III you'll be crawling along with the SOH frames but for now there are other speeds, you should know because you claimed to use the higher exchange speeds, remember when it kept shutting down my PCM into reduced engine mode, I do . . .
Those who do get the V 3 Ease, look for the lightning bolt ICON,
use that to switch warp mode speeds and you'll see the differences on the screen or in your recordings, add the bi directional your getting for FREE and you'll see it is a scanner you can trust your tuning decisions on,
It is easy to artificially inflate speeds by quoting the data transfer rates (as you do) from the cable to the PC - which is not a true indication of the data sampling rate.
Regards
Paul
More bluster, to which I will not respond
No facts yet???
All you need to do is post a single "warp speed" log file that shows data being recorded with 68 *unique* PIDs at 40 *unique* frames per second (heck, 24 *unique* PIDs at more than 10 *unique* frames per seconds will do).
I can't possibly imagine you would be violating any agreements you may have with Ease by posting a log file - since you have posted them on this board before.
I know it is impossible - even at 41.6kbps - which I doubt that Ease is using anyway.
68 PIDs requires at least 12 dynamic frames (6 data bytes per frame). Each frame takes 12 bytes to transmit (6 data bytes and 6 header bytes).
To send 12 dynamic frames 40 times per second requires 12 bytes * 12 frames * 40 times per second = 5,760 bytes per second. That's 57,600 bits per zecond (8 data bits: 1 sof bit, and 1 end of data bit per byte).
How can 57.6kbps be transmitted over a 41.6kbps wire? Much less over a 10.4kbps wire?
I did not make any of those figures up (although they are weighted in your favour). The figures are part of the SAE J1850 specification.
Regards
Paul
P.S. I am sorry if you are offended by my attempts to finish my posts politely. I may disagree with what you say but I will not use that as an excuse for being rude.
When you have a scanner that is designed by input from GM your going to get much more detail on what can be done and you design your interface to function not just to EPA/SAE 100 mSec delays between requests.
Let's put it another way, would you want to flash your PCM at only 10.4K baud considering not only the overhead of the protocol headers, the SOH frames and the other data going over the CAN network ?
Nope so there are other methods and the hardware interface will make or break what the scanner can and cannot do and clearly a tier 2 supplier will get a lot more insight by selling products to GM for a cheaper price but in return does not have to hack or backward engineer to make their product comply with how GM does things within the CAN and signal sets the car has.
Its not about the speed, for that alone is useless, it means the scanner was designed to exact specs of GM thus it also has features the homegrown scanner cannot do and does it with less overhead.
For my own use I tested 68 PIDs at highest speeds for over a 2 hour drive and not once did the engine go into reduced engine mode which is what happened often with another scanner vendor claiming to be faster then other makes so they then sell "it cannot be done" when most of us know we can move a hell of a lot of data on even a 33.6K baud modem esp when your only asking for some values, not file movement.
On the return 2 hour drive I used the SAE speed and PCM cycle count was 25% of the test when warp mode was set to its highest value.
So lets assume its BS, I then tested at double the speed of SAE and again the PCM recorded cycles matched but in any case using speed is a red herring for that really does not make a bit of difference in most cases of what we use a PCM scanner for but its nice to have the feature when needed.

We need some proof before it'll be believed that you are getting updated data <font color="red"> FROM <!--color--></font> the PCM at a greater rate than anybody else, or is it just faster data rates from the ADAPTOR to PC?.
I still can't see how you can get the PCM to send out data any faster than what is coded into it's firmware as the limits
When you have a scanner that is designed by input from GM your going to get much more detail on what can be done and you design your interface to function not just to EPA/SAE 100 mSec delays between requests.
Let's put it another way, would you want to flash your PCM at only 10.4K baud considering not only the overhead of the protocol headers, the SOH frames and the other data going over the CAN network ?
Nope so there are other methods and the hardware interface will make or break what the scanner can and cannot do and clearly a tier 2 supplier will get a lot more insight by selling products to GM for a cheaper price but in return does not have to hack or backward engineer to make their product comply with how GM does things within the CAN and signal sets the car has.
Its not about the speed, for that alone is useless, it means the scanner was designed to exact specs of GM thus it also has features the homegrown scanner cannot do and does it with less overhead.
For my own use I tested 68 PIDs at highest speeds for over a 2 hour drive and not once did the engine go into reduced engine mode which is what happened often with another scanner vendor claiming to be faster then other makes so they then sell "it cannot be done" when most of us know we can move a hell of a lot of data on even a 33.6K baud modem esp when your only asking for some values, not file movement.
On the return 2 hour drive I used the SAE speed and PCM cycle count was 25% of the test when warp mode was set to its highest value.
So lets assume its BS, I then tested at double the speed of SAE and again the PCM recorded cycles matched but in any case using speed is a red herring for that really does not make a bit of difference in most cases of what we use a PCM scanner for but its nice to have the feature when needed.
This is what I feel like after having read that.
Nice touch. Class act.
This is Deja Vu all over, again.
joel
CAN is not a generic term, there are 3 different types of CAN, none of which are installed in our LS1 cars. It is what GM is switching to for OBDIII. Please stop using it as a synonym for the GM Class 2 network.
I logged with EFILiveV6 for over 2 hours last saturday, and never once has it put my C5 in Reduced Power Mode. Neither did V5. You can stop repeating your complaint about a beta version you were testing.
Paul (EFILive) is on this board supporting a product sold by the sponsors. Thunder Racing is running a group purchase right now. You can talk about, and support Ease all you like, but posting sales ad's is a privledge granted by the owners of the site to paying sponsors.
300us between frames.. If you utilize the bus to "push limits" then serious arbitration must occur. Lets see some logs.
If the scanner *doesn't* comply with "EPA 100mSec delays between requests" then how can you say
How can it be EPA certified but still not comply to EPA standards?
The Best V8 Stories One Small Block at Time
When you have a scanner that is designed by input from GM your going to get much more detail on what can be done and you design your interface to function not just to EPA/SAE 100 mSec delays between requests.
Since the scan tool is making no requests to the PCM for data, the 100ms delay does not have any relevance whatsoever to the speed of scanning data this way.
Regardless, if you kept up with the latest SAE specs (2003) then you would know the requirement for the 100ms has been dropped, I quote:
SAE J1979 Section 4.1.3.2
SAE J1850 – Minimum Time Between Requests from External Test Equipment – For SAE J1850 network interfaces, [the] external test equipment shall always wait for a response message from the previous request, or a “no response” time-out [of 100ms] before sending another request message. If the number of response messages is known and all responses have been received then the external test equipment is permitted to send the next request immediately.
That means it is now acceptable to set the message throttle to zero (in the appropriate circumstances) and still be SAE J1979 compliant.
But maybe you’re trying to say that Ease is using the PCM’s block transfer mode (as used when reflashing) to transmit scantool data. If so then you would be seriously contradicting your earlier attacks on EFILive when you claimed EFILive was doing just that – which it doesn’t, by the way.
It may be that Ease has finally implemented the high speed logging that EFILive has had for a few years now. If they have it just goes to show how wrong you were last year when you said it was impossible and did not work on the C5.
As for you statement about homegrown; EFILive has been developed in conjunction with some of the top LS1 performance tuning companies and workshops available.
Professionals who make and repair electronics for the LS1 vehicles have carried out the PCM work.
EFILive has been built without any “official” assistance from GM and without any “official” engineering documentation from GM (if you know what I mean).
Just for your information TeamZR1, there are powertrain engineers at GM who are using EFILive – even on non-LS1 vehicles.
Let me pose a question:
If EFILive is a failure because you believe it does not have the blessing of GM or the EPA then why do you use LS1Edit? I’m fairly sure that LS1Edit is not an EPA certified tool and I’m fairly sure it has not been developed with the full assistance of GM engineering.
Maybe its because tools developed without "official" help from GM engineering can and do work.
Let’s see, generic scanning can scan 1 PID at about 40 frames per second. That’s 40 Pids per second. 4 times that is 160 PIDs per second which is 16 PIDs at 10 frames per second.
EFIlive will scan (up to) 24 PIDs at 10 frames per second. Depending on how many channels each PID takes; you can get about 18-19 PIDs at 10 frames per second.
It’s no coincendence that those two figures are so close. Definitely NOT 68 PIDs at 40 frames per second.
By the way, I think that speed matters a lot – the more data points you log and the closer they are together the more accurate the data. And that’s a well-known fact in analog to digital conversion – which is essentially what scanning does.
Regards
Paul
Team ZR-1, how about you post some logs or something? I'd be willing to believe you if you could provide some more factual information, like proof.
. very easy to use and logs a shitload of data. what more can you aske for. He's got the fork...
He's sticking it in this thread!
It's done!
Should a valid reply be posted, you'll need to start a new thread. Invalid replies will live their lives in squalor and misery.



