pcmhacking.net

I like the change. I just have a couple of minor changes that I'd like to see before merging it.

I've also got a kind-of-related question... Are we ready to get rid of the "If your PCM stops working, will that make your life difficult" warning? I kinda think we are, but I'd appreciate a sanity check.

P.S. Y'all know what happens if you press the . key while looking at a pull request?
Try it some time. It's the biggest easter-egg ever.

I think we are, as well as the "you have no retried packets. were not sure what normal is, please report this to pcmhacking.net". Perhaps it could just be a number of retries to be informational, but I think we know now with the current kernel 0 is normal.

@NSFW pull request for the 838 branch. Ive verified the 852 is still solid, and hquick verified the 838. https://github.com/LegacyNsfw/PcmHacks/pull/243

NSFW wrote:P.S. Y'all know what happens if you press the . key while looking at a pull request?
Try it some time. It's the biggest easter-egg ever.

Nothing ...

Now I'm curious.

It worked for me, but I wont post a spoiler, at least not yet. I'll send you a PM

Thanks Antus ...

On another note, can we please get away from using 'null' and using 'string.Empty' and 'string.IsNullOrWhitespace(value)' instead.

Thank You!

I made a copy of pcmlogger, modified it to .net 4.0 compatible (removed J2534 support) and included to UniversalPatcher.
Not published yet, fixing...

Now I try to make "FAST_MODE" (Passive mode?) logging work (user selection), but it is not really fast mode. (Yes, responseType = 0x24)
Is it possible that PCM is not sending data with full rate in this mode?

Using OBDX Pro, P59 PCM
With 8 parameters, query time:
Passive: 200 ms
Active: 75 ms

With 24 parameters:
Passive: not working
Active: 175ms

So... maybe it is better to forget "FAST_MODE" ?

I still think it should be possible to get the FAST_MODE approach to work, and be faster than the way logging works now. I just haven't figured it out.

Pete posted something here that might do it:
viewtopic.php?f=27&t=7195&p=113864#p113864

FAST_MODE is gone, and there's now FastLogger class and a SlowLogger class, depending on whether or not the device supports streaming.

Or more accurately it depends on whether or not I/we have figured out how to get the device to listen to a stream. The XPro definitely does, and I think AVTs and any J2534 device will as well, but I'm not sure about AllPro and ObdLink.

If anyone wants to play with it, the changes are in the nsfw/logger-improvements branch. I'd love to know whether the current code works with AVT and J2534 devices.

The only catch is that it won't start streaming until the logging profile has enough parameters to require four DPIDs. For now you just have to pick a bunch of parameters at random until you get there... I need to add some code to fill the unused DPIDs automatically, but I'll get to that soon.

I also need to play around with ObdLink and AllPro some more to see if they can be made to work.

I just re-read Pete's message and I think I see how to get the PCM to stream less than 4 DPIDs - pass 0xFF in place of the unneeded DPIDs. I'll try that before I go filling up unnecessary DPIDs. But I'm out of time for tonight.