PCM Hammer Suite development

[antus]

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.

[Gampy Profile]

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.

[antus]

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

[NSFW]

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.

[NSFW]

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.)