-
Thanks Robert, that is perfect! I actually just opened the $A1 ADX to see you wrote it :)
So (using $A1), if I am understanding correctly, I would:
- Send the hex string F4 57 01 00 B4
- Receive 63 bytes of data to be processed/displayed
- Take a short break
- Do this over and over again
And as far as processing the data, I would find the TPS value as the 9th byte of the response.
Is that correct? If so I guess I'm going to go crawl around the attic and see if I can find a 7730.
- Frank
-
you'll actually receive 67 bytes of data back from the PCM, 3 for the header, 1 for checksum, the other 63 for actual values.
no break needed, you can immediately retransmit after the received checksum is finished. i get ~10.67 samples averaged per second on TP.
and yes, TPS A/D is the 9th "value" byte that will come back. the 10th is TPS %.
if you get this pounded out, i'll have to send you the info on mode 4 stuff.... i'm sure that would be quite a hit as well.
-
Good deal. This doesn't sound too difficult to pull off. Time to go dig up an ECM and start playing around.
-
Damn. Now I'm going to have to buy an Arduino and a bunch of dot matrix displays.
I wonder if you can drive Nixie tubes with an Arduino?
-
they can natively drive ~40mA.... i imagine a good FET or two could drive that up though.
-
You guys playing with this Arduino thing and the other day when I was searching for PWM controller for jim_in_dorris I found one for it!
-
i always have uses for a good MCU, whether it's to control my refrigerator the way i want it to run, or if i want to build up my own retained power circuit for the car to power the radio/power windows/etc for 5 minutes after the ignition is off or some other crazy project.
i can do all of these things with a motorola 6811(GM OBD1 P4 ECM), but they aren't exactly easy to come by these days for as cheap a price and as versatile for off the wall applications.
-
Just a few notes for thought...
"ALDL is just 8192..."
Some calibrations play very nicely with this rule. Some do not. $58, for example, is notorious for not working with ALDL displays or software which works fine on $8D. Of course even $8D doesn't work like $8D if it's installed in a Corvette. And there are the Olds / Buick / Caddy systems where "somebody else" wants to be in charge.
"Has anyone seen the GM Display...?"
Rumor has it, or had it, that Doc Plecan (Grumpy from thirdgen) had one for a while. While "I never saw it," it might have been about as wide as a small computer desk, about 8-10" deep, and maybe that much tall. It might have had controls to allow one to change specific values in memory or to simulate sensor data to work through bugs and it might have had various points to connect additional instrumentation. If painted it would have been gray, and it might have looked like images of NASA equipment in the 1960s. It definitely wouldn't have appeared to be the powerful tuning device that it was. Lockers is a hobbyist level version of the GM HUD.
"i can't understand C at all" "In assembler, your good to go once you learn the hardware. "
C is a high level language. You say "Go get this done" without worrying about how it gets done in the hardware. After writing your program it's the job of the compiler to work out the details for the processor. With proper compilers, an EFI control algorithm written in C would work in a 68HC09/11 system, and 68000 system, an Intel based system, or even in a PC based system. The programmer should only need to know how the control algo works, not the details of implementation. In assembly you are making the decisions about how the code operates, what data structures to use, how to use memory in a way you want. In C it's the job of the compiler to translate your instructions to machine code. There are plenty of arguments for and against higher level languages over assembly language for microprocessors but each has it's strength and either can be the best choice in a given situation.
edit: Didn't have time to say this originally. Seeing this conversation here is impressive and rewarding. I'm willing to help if needed with coaching on C or C++ related stuff. Four years chasing CS/EE major gave me a fair amount of practice coding in these languages and if I can give back I'm more than happy to. This is not an offer to do all code writing (boss is in the hospital and I'm spending 80-85 hrs/week at work covering his job and mine) but definitely an offer to help with WT??!!! questions.
-
i was thinking about it...
J1850 VPW: an Arduino can probably be used as a VPW to USB interface, couldn't it? and with the amount of RAM available, i'm thinking it could be the basis for an OBD2 flashing cable without any issues. no idea about CAN stuff, but VPW should be covered.
i need to research this some more, but it looks like it's possible to use it as such.
-
Here is an implementation by Luke Skaff, "Automotive Diagnostic Interface."
http://lukeskaff.com/wordpress/wp-co..._Interface.pdf
There is a complication with ALDL. The ALDL is bi-directional on one pin. With separate input & output pins, you need to merge this data onto one wire. Luke show a circuit for doing this.
Robert
-
SLIGHTLY inaccurate at times, since mode 2 actually dumps 64 bytes per message, IIRC.
mode 4 being deactivated is also false.
ECM reading only up to 6375RPM? also false, i've had nAst1 code run up to 12,750RPM on a bench and nothing bad happened.
otherwise, a good project.
-
That was some really good info from the date though!
-
I actually built the 2 Square wave signal generator to hook up to my still needing to be built test bench. It does work nicely.
After looking over some of this thing, I may have to order one and start playing with it. It would probably work great for some of the things I am wanting to implement.
-
Well, I haven't spent any time thinking about this, but would this work to base a ECM test bench around? It should would be a quick way to get into a test bench.
-
It could possibly be used for a test bench, but I would use the Megasquirt Jim Stim for a test bench, instead of the Arduino.