pcmhacking.net

pc to tool could be serial or usb, at any speed. and vpw time depends on the data itself (which you dont know on a receive until after you have it) and bus activity, so I dont think you can accurately time it at all. You just need an approximation of worst case that works for everyone based on real world feedback. And rightly or wrongly, I think that is what we have. But we could describe the why better instead of documenting a process that is not correct in code.

Not questioning why it's done, or what it does, that's easy to read in code, just why that number was chosen ... It's not 8N1 Serial as the comment states, so it is misleading, not to mention how bad it looks.

It is what it is, if it's an elephant call it an elephant, not a mouse!

So the number came out of testing ... That is all I wanted to know, or need to know.

Well its not my code but I know it seems to work OK and I can explain the real factors in timing.

I'm guessing it was me who put the 9 there because I thought 8N1 was 9 bits per byte.

Changing the 9 to 10 would probably not do any harm. Timeouts would get slightly longer of course.

I don't think users encounter many timeouts in practice, but I'm not certain of that. I guess that's something to investigate.

It turns out that if you add more <Conversion> elements to a parameter in the logger's parameter XML files, you run into some bugs.

Code changes are here:
https://github.com/LegacyNsfw/PcmHacks/ ... gger-fixes

An unofficial release with those fixes is attached.

(And the Release.ps1 script doesn't handle labels like "016.1" but that's something I just now discovered and will work on later... EDIT: it's fine if I just use a hyphen instead of a dot. I will keep that in mind for next time.)

This release fixes a bug in the "math" parameters in the logger.

This fixes a problem with signed values in the logger.

Kudos to turbotech for finding this and figuring out what was wrong: viewtopic.php?f=42&t=7202

This was build from the "nsfw/signed-values" branch, which has not yet been merged to the develop branch. But I'll merge it if testing goes well.

This fixes some issues that came up as a side effect of the previous change.

EDIT: The logger still has issues with large unsigned values. I'll work on that next.

This fixes a bug related to creating new log profiles - sometimes it would overwrite the existing one!

It also adds a bunch of log parameters, based on the list in this post:
http://www.gearhead-efi.com/Fuel-Inject ... #post77393

I added a bunch of "flag" parmeters (on/off, enable/disable, etc) in the last zip file, and they didn't work.
Now they should work. At least, they seem to work on my test setup, but my car is on jack stands so I could use a hand with real testing.

Removed - see next post.