EvoScan v0.98 Now with Power & Torque Graphing - Map Tracing completed also!
Or is this what is being changed - trying to make each cable program specific, depending on who you bought the cable from?
I thought there was one cable design that will work with ECUFlash, Evoscan, Mitsulogger, Log Works, and all future versions no matter who you bought it from or peiced together the connector adapter.
Or is this what is being changed - trying to make each cable program specific, depending on who you bought the cable from?
Or is this what is being changed - trying to make each cable program specific, depending on who you bought the cable from?
Evolving Member
Joined: Dec 2006
Posts: 276
Likes: 0
I thought there was one cable design that will work with ECUFlash, Evoscan, Mitsulogger, Log Works, and all future versions no matter who you bought it from or peiced together the connector adapter.
Or is this what is being changed - trying to make each cable program specific, depending on who you bought the cable from?
Or is this what is being changed - trying to make each cable program specific, depending on who you bought the cable from?
I can't speak for him, but I don't think Colby's issue is with a lone user who downloads his copyrighted schematic and builds a cable. That person is probably just a technical hobbiest, and quite likely a good potential future contributer to Colby's project. Also, unless one values their time at $0, there was no real savings to speak of. Colby prices the built cables fairly competitively with what it would take to do it yourself.
The issue appears to be that Colby reinvests some cable proceeds into EcuFlash. Presumably doing things like renting factory tools, and etc. Colby also presumably interprets Evo4Mad's odd song and dance about PIDs and different drivers for what it is, technical gibberish. The drivers originate with FTDI. VIDs and PIDs reference an INF file, which, in turn, refers to the FTDI drivers. Loaded, or just on disk, no real waste or redundancy is nec.
The only viable reason to not uniquely identify the cable is to make application's recognize it as the original it is cloned from. Some vendors, like us, don't care. We sell Colby's cables as a bundle, but only for user convenience. We give the plug-ins, etc. away, including source, to everone. However, Colby does care because Evo4Mad is not making a reinvestment in EcuFlash and is using that financial advantage to try to undercut Colby's pricing and divert sales.
In other words, Evo4Mad appears to be saying that he is getting into the cable business for altruistic reasons, to save everyone $20-$30 hard earned dollars on their cables. Colby appears to be saying that it is simple profiteering on his work and it threatens future EcuFlash development. Although the specter of international copyright law has been broached, I think this will really boil down to people voting on who is right with their pocket book.
-jjf
new knock fields?
Don't remember these being in .97. Knock looks like the voltage from the knock sensor, but what are the others?
Knock
knock_adc
knock_base
knock_var
knock_change
knock_dynamics
knock_flag
Knock
knock_adc
knock_base
knock_var
knock_change
knock_dynamics
knock_flag
These are all recent finds from the Disassembly effort on Aktivematrix. Its useful information if you have alot of false knock and need to know the dynamics involved in how/why its being triggered.
These new knock MUT requests are useful if you need to make changes to the Knock Filters (we're still learning about the knock filters and these requestID's)
Mitsulogger also has these new entries in the new release thats upcoming.
These new knock MUT requests are useful if you need to make changes to the Knock Filters (we're still learning about the knock filters and these requestID's)
Mitsulogger also has these new entries in the new release thats upcoming.
