GM Can to ALDL

User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: GM Can to ALDL

Post by Tazzi »

Tre-Cool wrote:for starters the coolant temp says 230 degrees when i look at the engineering side, & it sets off the check engine fault. its been a few weeks since i first played with it. If i get time on the weekend i'll plug the uart line back in and see what it does.

Will double check the early ecu again too.

the pim isn't really doing much imo apart from transmitting the ect, the tacho and speedo come directly from the e38 ecu. Had to fudge the ppk count down to the lowest limit the aapl software would go (3000) & then again fudge the shit out of the ecu speedo output pulse to get the speedo to line up with the trans vss. unfortunatly the e38 then reads the speedo higher then the trans, yet my tacho is fine. lol

I can get some pics & video of it if anyones keen to see how the steering wheel tapshift works.
Well.. theres good and bad news from what you said.

Good news is it sounds like the ECU is actually sending data using the same 'headers', bad news is the data may be formatted differently.

Reason Iv come to that conclusion, is the cluster would show -40deg if it was receiving no information. But, its actually receiving something, so the PIM is translating information from the ECU. The embedded way to resolve would be to intercept the information from the ECU, modify and then resend to the PIM.

An example of whats sort of happening (For the interested) would be something like this...
On an early E38, it may be sending:
1040A210 00 10 00 3C 00 00 FF 00

On a late E38, it may be sending:
1040A210 00 10 01 40 00 00 00 FF

Iv highlighted in red the example bytes. So imagine that on an early unit, the value 003C is equivalent to maybe 20degs, which the PIM understands and calculates correctly. The late unit sends 0140, which is also 20degs (to how it calculates) but the PIM calculates that as 230deg.

Second example where both lines have FF. Early unit may have the FF on the second last byte, it could literally mean anything... status byte.. error bytes.. who knows.
On late unit, this byte has been shifted across by one. The PIM will process that data as if it was still an early unit, which could be an error flag byte or something else triggering the cluster to throw a hissy.

Is quite common kinda thing to see as tech updates and they slightly change things up.

Anyways.. enough of my ramblings!
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
User avatar
Tre-Cool
Posts: 265
Joined: Tue Oct 16, 2012 12:17 pm
cars: VY SS UTE, VX Drag Car
Location: Perth
Contact:

Re: GM Can to ALDL

Post by Tre-Cool »

That's great info Taz. I had thought about sending you a message to see what it would cost me for you to develop a fix for me.

I literally got the car running again a couple of weeks before racewars this year, a week before the event after dyno tuning and then the reluctor wheel slipped on the crank, so had to drop another motor in for the event. Going from a 750whp twin turbo motor to a naturally aspirated 480whp jobbie wasn't really that exciting.

If im not logging the ecu on the road with the laptop, i just use the android stereo/obdlink to bring the gear & ect up on the head unit. But it would be much nicer to have a working coolant gauge.
User avatar
Tre-Cool
Posts: 265
Joined: Tue Oct 16, 2012 12:17 pm
cars: VY SS UTE, VX Drag Car
Location: Perth
Contact:

Re: GM Can to ALDL

Post by Tre-Cool »

VX L67 Getrag wrote:Rather than stuffing around with developing a custom code that may never get used by anyone, wouldn't it just be easier to use a pre 2009 e38 & throttle body/pedal to suit it & then job is done?
Yes, if the engine was just a shit stock motor. But as im running 1600cc injectors with a built ls3/twin turbo combo, I would rather not have to scale the shit out of the tune. That & later transmission cals are better too. i.e rev match on downshifts etc.
LabZ
Posts: 13
Joined: Thu Aug 27, 2009 3:50 pm
cars: HZ Wagon [808 Injected Turbo Intercooled 202 On its way]
Location: Gippsland, Vic
Contact:

Re: GM Can to ALDL

Post by LabZ »

I feel Tre's pain... T51R Turbo and E85 tune on my P59 ECM, Haven't been able to get flex fuel to work without losing my DBW control (burnt hundreds of dollars in Hptuners credits trying in vain) and can't go to an aftermarket ECM like a Haltech because I lose my dashboard :(
I actually came looking on here because I figure a few of you mad buggers would have thought of a dash interface by now too.
160plus
Posts: 90
Joined: Thu Sep 21, 2017 3:00 pm

Re: GM Can to ALDL

Post by 160plus »

LabZ wrote:I feel Tre's pain... T51R Turbo and E85 tune on my P59 ECM, Haven't been able to get flex fuel to work without losing my DBW control (burnt hundreds of dollars in Hptuners credits trying in vain) and can't go to an aftermarket ECM like a Haltech because I lose my dashboard :(
I actually came looking on here because I figure a few of you mad buggers would have thought of a dash interface by now too.
It's not of much help to you but I have been working on several things for exactly what your looking to do. Unfortunately I'm in the US and ALDL hasn't been used in in over 20 years on our vehicles.

I've done an in vehicle thrown together proof of concept design for black box VPW pcm that used analog gauges to an LS VPW instrument cluster that drove the gauges off class 2 data with success.

I've been working on, GM CAN to Brand X CAN, Can to VPW, CAN to Analog, VPW to Analog and done a little bit of work on VPW to CAN. They are all vastly different projects but are all based on the same general frame work. One of my designs could be ported to ALDL(likely a substitute for the VPW design) but I have no knowledge on ALDL protocol, hardware requirements or even ALDL hardware to test/design on.


If you want something like this bad enough, you can follow the same approach I have and build it your self. You don't need to know a bit about programming or hardware design(although it would really help) if you have access to the Internet. I didn't know much about PIC's or even how to correctly use a transistor/mosfet but I was willing to learn and invest a as much time as was needed to creating what I wanted, the ironic part is once I created the device I wanted (that didn't exist) I just kept on going and started working on hardware for other aspects I saw a potential need.


[youtube]https://www.youtube.com/watch?v=_J1o8HOht-g[/youtube]
User avatar
antus
Site Admin
Posts: 8237
Joined: Sat Feb 28, 2009 8:34 pm
cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Contact:

Re: GM Can to ALDL

Post by antus »

ALDL is very similar to VPW. Just its 8192 baud half duplex serial at 5v, with device ID target byte, then mode/submode/payload/8 bit checksum (not crc). The modes and submodes line up with VPW as ALDL OBD 1.5 was part of the evolution. The timing gets tricky though as being so slow there is not much silence on the bus, and any extra device transmitting on the bus needs to transmit in a very small gap straight after the heartbeat. If only the dash is on the ALDL side though, that wont be a problem.
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
User avatar
Tazzi
Posts: 3422
Joined: Thu May 17, 2012 8:53 pm
cars: VE SS Ute
Location: WA
Contact:

Re: GM Can to ALDL

Post by Tazzi »

Timing definitely comes into play. which is then affected depending on what ALDL modules are present (Such as BCM?) and searching for suitable space to fire off the simulated frames for engine or whatever other module.

So long as the ALDL processing isnt too blocking.... The way I handle it is:
- Read a frame from ALDL if present
- Check if its a frame we want to send immediately after
- If not check CAN for incoming frames and also check timer if another request required
- Repeat

ALDL is frustrating with other modules present... surprisingly easier if simulating everything.
Your Local Aussie Reverse Engineer
Contact for Software/Hardware development and Reverse Engineering
Site:https://www.envyouscustoms.com
Mob:+61406 140 726
Image
ben_att
Posts: 43
Joined: Sun Jul 10, 2022 6:44 pm
cars: VF
VZ
VY

Re: GM Can to ALDL

Post by ben_att »

Was any progress ever made with this?

I've got the same issue, I've put an L77 with 6L80 into my VZ, I've got it running with the E38 from the VF that the engine came from, but obviously there are too many differences in the communication protocols and it doesn't talk. If only there was a VZ E38 OS that would run the 6L80. The car was originally a V6, so I do have a dash loom (that I haven't yet fitted) from a V8 which would change the ECU plug from the E55 to the E38 (and the plug is on the opposite side of the bay) but then if I do this, it screws me with the 6L80.
From the VF, I've got the fuel pump controller, TCM, ECU working in the car and that all works great, (and it drives) however if I tap the GMLAN into the VZ GMLAN which looks like it runs to the ABS unit (via old TCM) and then to the PIM(I've bridged it together where it was running through the redundant TCM), the ECU comes up with U2105 CAN Bus error, but it still runs. If I disconnect the ABS module (and relink the GMLAN at the plug), and only have the PIM connected, the CAN Bus error message goes away, so the ABS module is upsetting it but not the PIM. I'll tackle the ABS later. I didn't expect it to work, but thought it was worth experimenting with to see if I could establish if there would be some chance of modifying it to make it all work.
Next thing I need to play with is to get something to convert the speedo and tacho off the bus to the single wire signal input to the dash as on the VZ OS, these signals come directly from the E38 hard wired (X1 48 Tach/ X1 57 Speedo) which have no connection on the VF OS so I'm tempted to measure these pins to see if by off chance the signals are still there and just not used.
I'm considering trying to convert the BCM from the VF into the VZ because then I could use the VF cluster and have the VATS enabled, but then that causes a range of other issues with the SRS system and so forth (and obviously road worthy issues).

At the moment I've just got the key picking up the starter motor solenoid relay, because it's meant to be sent via the PIM over comms to have the E38 pickup the starter relay, but this doesn't work at the moment. I have tried two PIMS, the original V6 one, being a 92180030 and a gen 4 V8 one 92189621 (this is the same as the one in my 6L crewman with E38). The labels have different HW and SW numbers although the physical hardware to the naked eye appears the same. Out of curiosity, I copied the eeprom from my crewman and loaded it to the V6 PIM and I tried it in the crewman, the engine doesn't crank ( I was curious because I've seen people say they can enable the start input on the PIM via Tech II), so I thought either it doesn't like the eeprom being copied or there must be too many software differences which is why I sourced a 621 version. So then I copied the eeprom to the wrecker one I got and the crewman started, so it must be software related as I can't see any physicals hardware differences looking at the two boards.

Has anyone else done this successfully put the 6L80 into a VZ and ran it off the E38 instead of those stand alone transmission controllers I was trying to avoid and have all the factory features (cruise control, VATS, dash, etc) work? I've been told you can't mess with the VZ 6L OS to get the 6L80 to work instead of it looking for the external module used for the 4L60 but haven't looked too much into it yet.

Thanks
User avatar
antus
Site Admin
Posts: 8237
Joined: Sat Feb 28, 2009 8:34 pm
cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Contact:

Re: GM Can to ALDL

Post by antus »

Completely unrelated I built a 5v arduino pro micro + mcp 2515 to try and do aldl to can (rather than the other way around) for a can data logger to work on 12P. I got it working on the bench properly, then it kinda stalled and thats where its sitting. The speed is pretty slow, though its hard to tell if thats more in the elm clone I was using to test it, or the pc software. In theory it should be able to handle 5-8 60 byte ALDL frames a second on the aldl side, and plenty of requests on the can side. In practice I think the issues were pc app + elm, not the board I built. Can share more details if you want a starting point to build your own tool for your purpose, though you can see what the hardware should look like from the code, which I have attached.
Attachments
aldl2can pro micro.ino
(18.95 KiB) Downloaded 89 times
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
ben_att
Posts: 43
Joined: Sun Jul 10, 2022 6:44 pm
cars: VF
VZ
VY

Re: GM Can to ALDL

Post by ben_att »

Thanks Antus, that's interesting. Silly idea, but I wonder how reliable it would be to pickup what AA is sending the cluster for testing the tacho and speedo and sending that across the ALDL from CAN rather than generating an output to feed into the tach and speedo pins on the cluster or if there would be 'too much' going on and it would be unstable? It would be very minimal wiring modifications then, I'd be able to tap it all in on the back of the DLC.
Be interesting to see if I could somehow create a 'VATS' system using a two way interface if the PIM won't work where the BCM and ECU have to 'handshake' before it'll allow a start. Sounds almost like writing new software for the existing PIM, maybe I could also use a device to listen to the data the VF ECU and 'resend' on the CAN the stuff I want to the PIM with messages it understands without inadvertently having other modules pickup and use. I think there's a range of ways I could try and do it.
Going to be a lot of work and a lot of trial and error either way I think.
Post Reply