How does the logging compare with hptuners in this prototype?

 

Edit: I misunderstood that question. But, this is still true:

PCM Hammer just does reading and writing of bin files.

Tuner Pro RT does logging, but I haven't tried it yet and I'm told that the configuration file (ADX file) needs work to support the AllPro and ScanTool devices. I may or may not create a new app for logging, depending on how things go with Tuner Pro.

 

It'd look just like it does with the AVT 852

 

Well I don't have an AVT 852, so I'm not really sure what that means. I was trying to get an idea on the data rate. In my experience the data rate (frames per second) on the hptuners logging isn't all that great. They do a bunch of smoothing of the data to make it look like the data rate is much better. It would be awesome if there was a way to increase the speed we could log.

 

Do you know what the refresh rate is?
How many pids do you log/will it let you log at once?

 

Your question cost me a lot of sleep for the last 2 nights.....but I've got refresh rate data now and it's using the Obdlink SX

I wrote a mock ADX for Tuner Pro using the extended command set on the OBD Link...meaning this does NOT reflect what the Allpro would be capable of.
P01 capped out at 65hz refresh rate and the P59 capped out at 80hz with both reading 18 bytes of data....it was reading 14 data pids. I should note that this was loading down an overclocked i7 pretty good to pull those kinds of numbers so I backed it down a bit and actually lost very little speed.

Now to put this in number that mean something to you, with out pushing anything super hard I can read 18 bytes(14 pids) of data in 75ms, Slowing it down to levels a halfway decent laptop should have no trouble handling slows it down to 18 bytes(14 pids) in 130ms. And just in case you have a potato for a computer that'll slow it down to around 18 bytes(14 pids) every 200ms.

So middle of the road figures mean its running about 7 fps per pid. If you want more speed get a better computer and you can boost that to over 13 fps. If you throw desk top cpu power at it your going to max the PCM out around 15 FPS. At that point your requesting data faster then the PCM is able to process the request and send a response.

Now if you cut the number of pids down your requesting you can increase the FPS a good bit further but your also going to be limited to just a couple of pids so unless you were trying to track down something super spiky there's no reason to.

I'm pretty happy with the Obdlink Sx overall here, it took some creative thinking and a bunch of trail and error to get dpid to run at this speed but the fact I was able to max out the PCM's transceiver/processor with a $30 tool just goes to show how old these pcm's really are.

 

i mean, thats plenty fast to log all the pertinent data

very rarely do I log more than 10 params, maybe when I'm doing a base tune from scratch with a combo I dont have something to start with

 

Problem is solved. Yesterday MS came up with 128 new updates for Windoze7. After hours of downloading and installing Tuner Pro works.
Now i just have to learn how to use it.
I sure wish Tuner Pro and PCM Hammer worked in Linux.

 

 

As annoying as you may think it is reading the entire thread may be a good idea and will likely answer many of the questions your going to have.

Next time it also might not hurt to at least look at least 1 page back where the link to Release 4 was posted.

https://ls1tech.com/forums/pcm-diagn...l#post20032397

 

 

Pete, can you add this link to the first post?

https://github.com/LegacyNsfw/PcmHacks/releases

That page will always have the latest release at the top.

 

Original post has been updated with the link

 

 

Got a "Dumb Question" for you guys. Little background first, I've been in this game for nearly 2 decades but I'm by no stretch of the imagination a programmer. Background is first the Ford EEC-IV/TwEECer then MS and MS2. Decided to give this a go once it looked like cost/benefit was in the right place. I also have an Industrial controls background.

So the question:. Is USB really noise resistant enough for tuning auto ECMs, particularly logging and "On the Fly" tuning?

I've done a lot of serial comms. it's pretty robust and the signal level is considerably higher than with USB. Automotive is a very noisy environment and keeping the signal out of the grass is pretty important. You got some very tall grass there.

USB came about for the convenience of the home computer market and business, both very noise quiet environments by comparison, and as a result it is pretty sensitive to noise by comparison. Not only could there be issues with data corruption but also with hardware damage. Have these things been taken into consideration, and reliable preventative measures put into place?

I'm in the hardware stage and I'm just wondering if I should be looking for a serial interface. I've had more comms and hardware issues in the past than I really care for.

Jim

 

Literally everything uses USB now, even if it's just doing serial to USB. Efi live, hptuners, gm's own stuff I'm pretty sure, etc

 

Even a lot of USB stuff....are still basically using USB to serial conversions at some point anyway. Because they're still extremely slow at data transfer for proper USB.

A proper modern standalone will use ethernet now....which makes for easy WiFi access. And it's fast.

Actual serial though, really is a thing of the past, although some systems do use it. Which is a pain, as as most laptops these days do not have a serial port, you're into USB to serial adapters anyway

 

Haha I was just doing a cnc machine set up gig and the new owner of the machine was like wheres the USB port?

Lol dude this thing is from 1989 you're lucky it even has an rs232 plug

 

Your question is valid but it was taken into account when GM created all this stuff.
There are 2 parts to this that do the same thing in essence when reading or writing.

The first part is the VPW Checksum. It ensures that the bytes sent by the Tool/PCM are correct when they get to the other end. If any byte is out of place the checksum won't be correct and it flags an error.

During a flash since your dealing with thousands of bytes there is whats called a block sum in place, its similar to the checksum but this is a 2 byte sum of all bytes being read or written other then the 3 byte header and the mode command being used.

If a data block is written to the pcm and the sum is incorrect the pcm will flag an error response, likewise if the pcm sends the software a data block and the sum isn't correct when added up the software will know there was an error and request the data again.

As for logging it just uses the normal VPW Checksum and it more then enough to make sure the data being read is correct.

Some tools like the AVT take it a step further and also will included the size of the message being sent or read with a byte count so the software knows exactly how big the message is and if that was correct or not.

There is no need to worry about the "Noise" interfering with flashing these days. All that was sorted out by the engineers years ago and has proven to be a very reliable method.

 

Thank you for taking the question seriously. I assure you I know how checksums are used and did not ask frivolously. Still, thanks for the reminder. Perhaps you are all correct. But USB had some pretty severe teething pains when it was first tried, perhaps some of you remember that. Had it been all that perhaps this would not have been the case. I don't doubt that it has gotten better, however just because one protocol is old and one is new is not grounds to determine suitability for any specific intended purpose. Serial comm is also quite capable of using checksums, and laptops with serial ports are still available if you search them out. There is a reason it is still a standard in industry, because it works and it is reliable, and it is tolerant of noise. So as much as you might think that's obsolete it doesn't necessarily make me a dinosaur for being in favor of it. Also unless I'm mistaken USB requires additional layers of signal conditioning that serial does not.

Anyway, it seems I'm not going to convince anyone, likely as not that was all rather pointless. USB it'll have to be then, and that isn't a problem either I just wanted to test the waters so to speak before I went out buying cables. But I will say this. No protocol, no matter how robust is entirely proof against errors of all kinds, or impervious to all damage from noise. All of it is somewhere below 100%. How far below is the real question.

Jim