pcmhacking.net

VX L67 Getrag wrote:NO I would have got no data as it was just PCM on a bench I think, but not sure?

Yeah, well the elm device sent back saying "No Data", meaning that the pcm didnt spit out any data.. or the elm device missed it? either one.
I would have thought the pcm would spit out info regardless of being connected up to the car or not, but might not be the case!

And the request vin should have worked even if the pcm is on bench since the vin is stored directly in the pcm, although that got a "NO DATA" as well. So makes me think the elm is missing the message or is timing out before the response is sent back.

Was good to see that it happily connected to the elm cable and sorted out all the settings. Just no damn data back!

Iv just added a new setting to manually set the elms "timeout". If it doesnt pick it up now.. then the pcm isnt sending any info back to the elm for whatever reason!

oh yeah I just thought the VIN part wasn't coded properly as you'd mentioned before to Jayme, but I'll test this out when I get a chance & let you know!

I gave the vin part another go and redid it last version, and it should work.. assuming that the pcm actually sends it back some info.

Working on a gauge design at the moment.. any preferences?
This is what Im currently fiddling with.

Looks good to me. Always wanted a guage of awesomeness

lol!

agree the gauge selection looks good!

real nice gauges man

Cheers guys,
Gauges fully work, needle moves and digit display shows current value. Just need to actually implement it with the data obtained from the elm...

I did a test run using some test data, but just wondering on how quick data can be grabbed from the car.. otherwise itll look like the needles will bounce around if its not quick enough.
Iv seen a few talk about "Hz", which is Bits/s (Same as bytes/s yeah?). How quick would it need to be for a nice "smooth" needle move?
Guess the next question would be how would I calculate it and what should I be aiming for?

Assuming I send a rpm request (010C), and I get back 41 0C XX XX (something like that), would that mean I received 4 bytes of data.. or 8 including checksum and headers. If that takes roughly 200ms, that means I can potentially do 5 requests a second, so thats either 20 bytes per second (10Hz) or 40 bytes per second(40Hz)? Someone let me know if Im well off track here! haha.

Best way I can think of for optimizing speed of application for reading is to simply have one thread continuously requesting data and receiving it (no processing), and a separate thread that will process the new data to the gauges. Too many events raised,paint events and invokes required to do the gauges on the same thread.

the hz is tuner pro hz, being frames per second, rather than raw data rate. In tunerpro we see ~40hz, but each frame is only one pid, so it depends how many your logging at once. Most apps break it down in to priorities, so you can grab eg 4 rpm readings then something less critical and only one in 50 update coolant temp. You shouldnt have to do too much with manual timing, so long as the receive doesnt time out just keep requesting data as quick as the responses come back.

Cheers Ant, So that would be 40 requests per second!.. But that does make sense.. do majority on rpm and speed, and less on other thins such as temp ect. May have to put an option in for what gets priority/most requests.

Easy enough to keep the app from timing out, just need to get some reliable reads from in car on the commodores before I can progress further.
Still dont have the damn elm cable... how can aus post lose it three times in a row!

yeah when you think about it the high priority stuff gets more and more, like maf or map, tps, knock, spark etc they all move very rapidly

on a side note, i got elm back from a mate so i should be able to do some testing for you ?

i have a vz alloytec and a holden cruze i can try it on.