pcmhacking.net

NSFW wrote:

renat wrote:Hey everyone, just found the PCM Hammer soft on github today, I've ordered VXDIAG VCX straight away to check the soft out. I've got two LS cars and I'm a C# developer, hopefully I can be pretty useful here.

Cool! The logger needs a ton of work, how much time do you have?

Here comes a brain-dump that I've been meaning to put into writing for a while...

Right now you have to edit XML files by hand to tell the logger which parameters to use, and that's not user-friendly at all. To fix that, I'd like to reduce the log profile files to just a list of parameter IDs and units, like:

<profile>
<parameter id="VehicleSpeed" units="mph" />
<parameter id="EngineSpeed" units="RPM" />
</profile>

Then we'd have separate XML files to keep track of how the parameters are really defined.
There would be one to describe the standard PIDs that every PCM supports:

<parameters>
<parameter id="VehicleSpeed" name="Vehicle Speed" pid="0xD" length="1">
<conversion units="mph" expression="x*0.61" />
<conversion units="kph" expression="x" />
</parameter>
</parameters>

And there would be one XML file per operating system, containing the "extended" parameters whose addresses need to be reverse-engineered for each operating system:

<parameters OS="12593358">
<parameter id="ThrottleFollowerAir" name="Throttle Follower Airflow" address="0xFF980A" length="2">
<conversion units="g/s" expression="x/1024" />
<conversion units="lb/min" expression="x/24" />
</parameter>
<parameter id="ThrottleCrackerAir" name="Throttle Cracker Airflow" address="0xFF97F0" length="2">
<conversion units="g/s" expression="x/1024" />
<conversion units="lb/min" expression="x/24" />
</parameter>
</parameters>

(Half of the numbers in the XML examples are totally made up.)

With these XML files to describe what parameters exist, the logger UI could give users a list of parameters to choose from. So users could click an "edit profile" button which would open a dialog box with a DataGridView table that has a column of checkboxes to add/remove parameters, and a column of parameter names, and a column of drop-lists to pick the preferred units.

NSFW wrote:Also, before flashing it should check the voltage. If you want a bite-sized piece of work to get started with, this is probably it. We'd need a GetVoltage() in the Device base class, with overrides in the derived classes. Plus a GetVoltage in the Vehicle class that just calls this.device.GetVoltage(). And then have the GUI call vehicle.GetVoltage and check the results before kicking off the thread that does the reading or writing.

Implementing GetVoltage for each device might take some research but you'll have help.

This is probably the highest priority. I'll be very sad if someone's PCM gets bricked because their battery died mid-flash...

antus wrote:I think there are two things going on here. Firstly there is something wrong with the computer which is stopping it from accepting the 4x speed upload. Running at 1x seems like a working workaround. We have seen this before with one of the core developers computer. In his case it was working originally but then for reasons unknown it started rejecting the uploads. We didnt try at 1x. He was able to restore the paramter block from his first read and then the PCM started operating normally again. You could probably ignore this and just continue to use 1x, or you could clone another pcm in, and reset the vin, and either disable vats or re-learn the security IF you wanted to change it.

As for the flash not working at 1x it does seem to be a limitation of the device. I know the MDI2 have less RAM than the original MDI, and pcmhammer was developed and tested against the original MDI. I think your MDI will work if you run at 1x, and we will probably need to put something in future pcmhammer versions to run a smaller packet size when the MDI2 is detected.

I've logged this issue on github here: https://github.com/LegacyNsfw/PcmHacks/issues/201