MSgpio.com read only forums (Jan.15,2018)

These guys are pretty much untunable due to VW outsourcing the trasmission to Japan. I've been playing with replacement control schemes and I was initially drawn to Megashift because I love B&G products as I have used MS-2 on a different project. However from the get go I realized my transmission was most likely uncontrollable out of the box.

Stats:
6 forward gears
9 Solenoid Valves (3 On/Off, 6 Modulated)
Tiptronic mode (+, - switch to request gear change)
6 selector settings (P, R, N, D, S, Tip)

Now the majority of the modulated SVs are specified as modulating in the tech documents but it doesn't specify how or why for some valves. These valves are:
3,5,9,10
The valves it does specify how they are modulated:
6 - Engine Torque (ie RPM) for system pressure
4 - LoadxSpeed for TCC

Gears:
1st - SV5 (SV1, SV2 together can be used to engine brake in this gear)
2nd - SV5, SV10
3rd - SV5, SV3
4th - SV5, SV9, SV1
5th - SV9, SV3, SV1
6th - SV9, SV10, SV1
Rev - SV3, SV1, SV2

On/off valves are 1,2 and Shiftlock. Shiftlock is used to prevent the selector from coming out of P/N while the engine is running unless brake is depressed. Based on wiring I would be tempted to say this is specified by CAN bus.


This is my idea to make this work:
I obviously cant control the whole thing using one megashift. However I want to put a megashift at the center of the required contraption. It will be set up just like a normal transmission except the solenoid outputs will be used as a 4bit output setup to specify which gear the transmission needs to be in (ie 1st off, off, off, on 2nd off, off, on, off etc) which is fed to the inputs of two GPIOs. The coding of the GPIOs will watch these 4 inputs and have logic as to which of it's controlled SVs it needs to actuate.
GPIO 1:
SV5, SV10, SV6, SV2, shiftlock
GPIO 2:
SV9, SV3, SV4, SV1, one open digital

Megashift doesn't really know what to think of all my selector options from what I can tell so Drive and Sport will be tied together. Sport just changes shift logic and actuates TCC more aggresively. Having only one shift logic means that these two selections will be the same.

I dont know that this is possible but I want to use Megashift as the router for the CAN bus. Megashift connecting out to my ECM and handing out whatever my be pertinent to the two GPIOs.

I have C/C++ programming experience so I can do the coding work for the GPIOs. I just wanted to see if there was something I might have missed or ways people could think to do this better.

cs,

There are a bunch of ways to do this. The existing code has 6 solenoids outputs, and the LED outputs could be used for 4 more (with added driver hardware).

The upcoming code will have chip-to-chip SPI comms in place, and this will allow a number of extensions for the I/O.

The first item out will likely be a LED digital speedo/gear indicator, but added outputs (with something like the MC33800) will be coming soon after, I hope.

Lance.

Wow, that fits like a glove then.

How moldable is the CAN bus on the GPIO modules? I'm pretty sure they had the can bus sitting in front of them and said "Hey lets build a car around this thing." lol From what I can make of the wiring diagrams there is no physical speedometer wire. Just a CAN interface to it's controller. I believe I can get the data off the CAN and determine how it should act. Will it be trouble to get it to play on the stock CAN bus like my stock TC does?

chezzestix,

On MShift, the CAN itself is a fairly standard implementation (there are really only two - these have to do with different bit frame sizes). However, on a CAN bus it isn't like there are variables floating around waiting to be 'plucked' and used. CAN is a push-pull mechanism for the contents of memory at user specified memory addresses. The network infrastructure itself has no info on it unless a controller makes a request, and then it only knows about bytes and where it has been told to get/put them.

So to make CAN work with external devices, you *must* know the memory locations of the values you are interested. That's the hard part, as these addresses typically aren't published. And experimenting likely won't work to find the addresses, due to some 'pokes' being fatal for the receiver, and some 'peeks' returning apparently sensible values, but perhaps not consistently.

Now that all new cars in North America (since 2008), and likely elsewhere, have CAN OBD, getting a set of standard values in known locations is a possibility because of the OBD interface information that is on the web. But lots of older vehicles don't use CAN OBD.

With devices designed for MegaSquirt/MShift, we have the memory map available (in fact, it's included in the INI file), so the problem is trivial.

For your speedo signal, there may be a sensor harness between the sensor and the CAN module that you can tap into to get a signal for the GPIO. Alternatively (if you decide not to try the CAN route) you can set up a VR sensor and somewhere in the drive line (should work even with a single tooth - like a hose clamp on a driveshaft, for example).

Lance.

Well this project just keeps getting better and better. The vehicle this 09G is attached to is a CAN-OBD equipped vehicle. Last night I read through the Bosh CAN 2.0 document linked from your wirteup on CAN bus so I have a basic knowledge of how it works. I also glanced at the Motorola document although I might have zoned out as in depth architecture talk doesn't hold me very long. Then this morning when I read your post I found OBD2 PIDs in a convenient wikipedia table. I think my first angle of attack is to use VAGCOM to log CAN traffic on a short drive to give myself a working example of CAN bus traffic and identify possible VW specific Data/Remote frames. If the CAN-OBD traffic turns out to be pretty easy and useful then implementation of a MShift might just be easier than expected.