Electric seat dead after battery test

[MIG]

Where in VIC are you? I do have a spare MQB BCM and have been prototyping a PQ to MQB gateway I might be able to get something working for you.

Sent from my SM-N960F using Tapatalk

[Bezzey]

Where in VIC are you? I do have a spare MQB BCM and have been prototyping a PQ to MQB gateway I might be able to get something working for you.

Sent from my SM-N960F using Tapatalk

Just a stones throw from the Peninsula over at Ferntree Gully. Very interested.

[DV52]

@Bezzey: Hi. Interesting retrofit!!

I'm NOT an expert with this particular module - but according to information on the Ross-Tech forum (where much of the dialogue on this thread is replicated), the 5Q0 959 760 series module is identified as J810 - see this Auto-scan (doesn't matter that this scan is for a MY18 Passat -it's a car with a 3Q0 chassis like many other newer type MQB platform vehicles)

If I look at my MQB wiring diagrams, I find that J810 is wired like this (my diagram shows the module from a CAN bus/power supply perspective only - of course there's lots of other connections on this module):



I note that these pin-outs are different to @mig advice on post #9 - so something odd!! Anyhow, and at least on a MQB platform vehicle, the module gets it's comms messages from the Convenience CAN bus. Where did you hook-up the pins #1 & pin #11 on the 20x pin connector to the recipient car?

Also, have you modified the Gateway Installation List (GIL) on the recipient car to include the new module (i.e. add a new module @ address hex36)?

As for how you have obtained the information in your posts about this module, what is the part number of the CAN gateway module on your test bench?

And finally - one of the fundamental problems on a MQB platform test-bench (at least from my experience on my "virtual Golf mk7" -see picture at the end of this reply) is simulating the ignition key condition. This requirement can be important when attempting to implement many Basic Setting procedures.

As I said, I'm not familiar with J810 - but I know from many failed attempts using a test-bench on other modules that simple stuff such as replicating the physical ignition key positions (like the "C" switch) is crucial to getting these procedures to run correctly! The "C" switch is located at the end of the lock mechanism and it tells the CAN bus that a key is physically pushed into the lock-barrel. It's a fairly innocuous switch, but its status appears to be critical to the operation of many functions - apparently!!

And finally, finally - in respect of the dialogue in this thread about the mirror modules being implicated in the operation of J810, are you aware that on MQB platform cars (and at least as described by the VCDS long-code helper screens) there is a link to seat memory for the descriptor on Byte 4, Bit 1 for the hex52 module - see below?



I'm not sure if the status of this software switch is important in your project - I simply bring this matter to your attention

Don

PS: My MQB test-bench (spaghetti mess) is like this - note the inclusion of the simulated ignition-switch (including the "C" switch) which is connected to the Steering Wheel module @ address hex44

[MIG]

Thanks, DV52, I have been testing the emulation of the Klemmen_Status_01 and the virtual terminal 15 signal and checksum on the CAN IDs; this should wake any modules.

My first test would be to run it standalone, and then to translate the CAN IDs across my gateway.

Those pinouts were for the OBD connector side to hook directly to the module.

I will PM OP and work out something so we can do some experimenting on the module

[cameleon72]

Sorry @MIG and @cameleon72 I didn't get notified of your replies, I just checked the thread and saw your replies. I fully understand and agree now after what I did today:

I took Seat 1 back to the wreckers where I got it from and connected the seat back to the car I took the seat from. Seat controls began working once ignition was turned on. Memory buttons did not work. The guy at the wreckers told me it is due to the left mirror missing (car was complete when I got the seats originally). This confirms the theory that if any single component from the 'memory ecosystem' (anything that is programmable to the memory button) is missing, the memory buttons won't work. I wonder if there is any way to code-out everything else so the memory buttons work without the rest?


Interestingly, the Position measuring values for most of the motors returned to true values, see below. All of the Block 1 & Block 2 measuring values are still reading 65535.

Thats exactly what i was trying to explain you, to not waist your time and also other ppl trying to help you.

Example: say you remove seats say from Tiguan MQB and try to install in another tiguan MQB exact same model ( any MQB car will be the same) , the seats will stop working , as soon they detect new getaway and BCM with different car VIN.
So if that seats have been connect to power on another car , even after you bring back same seats back to original car you take it from, seats control module have detected and have stored change from another config so it stop working
To be able again to get working in original car , memory buttons and calibration basic settings. would require VW original Sw tool and correct flash file to flash seat control module on the current VIN car you installed seats ( or any other MQB different VIN config you want to install that seats) .

I am telling you form my experience, i am not talking reading from forums other people suggestion or guessing etc... . This is how it is in real practice i try it . Maybe is also some other way possible, but i know this will work for you.

If you are in Sydney i would be maybe able to help source tool and proper flash files to flash on your car that want to install those seats. Of-course it must be MQB . Or as give you suggestion that if you have BCM and Gateway from MQB from same car, to connect all per Elsa vw factory configuration to your car and mount under seats, than to flash and see if will work . BCM is monster wiring 3 connectors over 120 think wires. but you basically need only couple wires from BCm including few Power inputs ignition wake up and Can wire's. I dint try this with BCM and getaway, but logical thinking it may maybe work but i didn't tested personal. Maybe even original gateway with seats and proper flashing would be able at least to restore working electrically operating adjustment movement, but memory seats maybe will not working without BCM. but without testing .
I do have all i think from MQB Tiguan BCM , Gateway and also seats somewhere in my garage ,but is to much time to waist for me put and all connect in system and flash and test .

[DV52]

Thanks, DV52, I have been testing the emulation of the Klemmen_Status_01 and the virtual terminal 15 signal and checksum on the CAN IDs; this should wake any modules.

OK- I wish you every success with generating the suite of CAN wake-up signals via emulation. Given the suggestion on my previous response - maybe consider also adding the Klemme_S bits too (what I call "C" switch)

Please tell us about your findings - I'm interested in your results

Don

[Bezzey]

@Bezzey: Hi. Interesting retrofit!!

I'm NOT an expert with this particular module - but according to information on the Ross-Tech forum (where much of the dialogue on this thread is replicated), the 5Q0 959 760 series module is identified as J810 - see this Auto-scan (doesn't matter that this scan is for a MY18 Passat -it's a car with a 3Q0 chassis like many other newer type MQB platform vehicles)

If I look at my MQB wiring diagrams, I find that J810 is wired like this (my diagram shows the module from a CAN bus/power supply perspective only - of course there's lots of other connections on this module):


I note that these pin-outs are different to @mig advice on post #9 - so something odd!! Anyhow, and at least on a MQB platform vehicle, the module gets it's comms messages from the Convenience CAN bus. Where did you hook-up the pins #1 & pin #11 on the 20x pin connector to the recipient car?

Hey mate I have come across many comments from you on various forums and been wanting to connect with you to get your input but respected your profile stating not to PM you. As MIG said, the pins I have been connecting to on the TSVR plug is just CAN Low, CAN High, Power & Ground from left to right as per below Tiguan WD.

Also, have you modified the Gateway Installation List (GIL) on the recipient car to include the new module (i.e. add a new module @ address hex36)?

I haven't looked into any of that on my Amarok as I have come to the conclusion I need to create a standalone system for the seats to operate. This could end up being a Tiguan BCM with Tiguan mirror wiring packaged neatly in order to fulfil the seat control module connection requirements for seat memory functions to work.

As for how you have obtained the information in your posts about this module, what is the part number of the CAN gateway module on your test bench?

My 'test bench' is nothing more than a direct connection to the seat module via a female OBD cable.

And finally - one of the fundamental problems on a MQB platform test-bench (at least from my experience on my "virtual Golf mk7" -see picture at the end of this reply) is simulating the ignition key condition. This requirement can be important when attempting to implement many Basic Setting procedures.

I have found from the beginning that the seats work with simply connecting power and ground to the 17 pin connector as per photos in my OP.

As I said, I'm not familiar with J810 - but I know from many failed attempts using a test-bench on other modules that simple stuff such as replicating the physical ignition key positions (like the "C" switch) is crucial to getting these procedures to run correctly! The "C" switch is located at the end of the lock mechanism and it tells the CAN bus that a key is physically pushed into the lock-barrel. It's a fairly innocuous switch, but its status appears to be critical to the operation of many functions - apparently!!

That sounds like it would be an easy oversight!

And finally, finally - in respect of the dialogue in this thread about the mirror modules being implicated in the operation of J810, are you aware that on MQB platform cars (and at least as described by the VCDS long-code helper screens) there is a link to seat memory for the descriptor on Byte 4, Bit 1 for the hex52 module - see below?



I'm not sure if the status of this software switch is important in your project - I simply bring this matter to your attention

I don't recall seeing anything about mirrors in the long coding Bytes, I'll have a look tomorrow when I connect to the seat module.

PS: My MQB test-bench (spaghetti mess) is like this - note the inclusion of the simulated ignition-switch (including the "C" switch) which is connected to the Steering Wheel module @ address hex44

I came across your thread Testbench setup? on RossTech forums where I thought to myself, that would be handy right about now. I actually used some information in that thread before connecting to the seat module for the first time, so thanks!

[Bezzey]

Thats exactly what i was trying to explain you, to not waist your time and also other ppl trying to help you.

Example: say you remove seats say from Tiguan MQB and try to install in another tiguan MQB exact same model ( any MQB car will be the same) , the seats will stop working , as soon they detect new getaway and BCM with different car VIN.
So if that seats have been connect to power on another car , even after you bring back same seats back to original car you take it from, seats control module have detected and have stored change from another config so it stop working
To be able again to get working in original car , memory buttons and calibration basic settings. would require VW original Sw tool and correct flash file to flash seat control module on the current VIN car you installed seats ( or any other MQB different VIN config you want to install that seats) .

I am telling you form my experience, i am not talking reading from forums other people suggestion or guessing etc... . This is how it is in real practice i try it . Maybe is also some other way possible, but i know this will work for you.

I see and now understand, I have been known to try things even after advice has been given to me and still end up at the same position of 'oh yeah I should have listened'

If you are in Sydney i would be maybe able to help source tool and proper flash files to flash on your car that want to install those seats. Of-course it must be MQB . Or as give you suggestion that if you have BCM and Gateway from MQB from same car, to connect all per Elsa vw factory configuration to your car and mount under seats, than to flash and see if will work . BCM is monster wiring 3 connectors over 120 think wires. but you basically need only couple wires from BCm including few Power inputs ignition wake up and Can wire's. I dint try this with BCM and getaway, but logical thinking it may maybe work but i didn't tested personal. Maybe even original gateway with seats and proper flashing would be able at least to restore working electrically operating adjustment movement, but memory seats maybe will not working without BCM. but without testing .
I do have all i think from MQB Tiguan BCM , Gateway and also seats somewhere in my garage ,but is to much time to waist for me put and all connect in system and flash and test .

We will have to wait and see what happens as I talk with MIG about what we can do using his test bench.

Thank you for your patience with me and taking the time to explain.

[DV52]

@Bezzy: Hmm........... I won't repeat the advice that is in the responses on the Ross-Tech forum about mating the CAN protocols from MQB platform cars on an Amarok that was built on a PQ25 platform - this certainly is a very innovative project!!

I suspect that you probably already know this stuff - but I reckon that it's worth saying as context for your earlier attempts on this project: there are broadly 2 x types of seat modules on MQB platform cars (on those vehicles that DON'T use mechanical controls for seat adjustments) and they are basically distinguished by whether-or-not they have a seat memory function.

Those modules that do not have seat memory are stand alone in the sense that they are NOT connected to the CAN network. These modules basically don't care what the rest of the car is doing - they only need to understand when the ignition is switched-ON. This ignition-ON condition is determined by the status of the T15 voltage pin on the module (it's a type of non-CAN wake-up signal). So, these type of non-CAN seat modules will be perfectly happy operating from an isolated battery in a pseudo-type test-bench arrangement - which I understand from your early posts was the set-up that you used to test the seats from the donor MQB cars.

The other type of electric seat module (with memory function) is a true CAN module. On MQB platform cars - these modules use UDS/ODX comms protocol and they are fully registered on the CAN network @ address hex36. This means that your MQB seat-modules from the donor cars are designed to operate on what's called a Hub-and-spoke type network with the GATEWAY module (@ address hex19) acting as the director of message communication at the hub.

Now, I'm aware that you managed to get the MQB modules to speak to VCDS using a direct connection and without a Gateway module. Getting these modules to talk to VCDS in this manner does NOT mean that the modules are operating correctly. As you would have observed from the VCDS reports that you posted earlier - the absence of the Gateway module and the other CAN modules that would have been present on the normal set-up for a MQB car means that only very-basic diagnostic-functions in these module are possible with this type of connection - like module identity, error-code reports in fault memory and the identity of basic setting procedures, but not their operation.

Importantly for the test-bench arrangement that has been used thus far with the "extended" form of these seat modules, it's really unrealistic to expect that the initialization values in the modules can be re-established via the Basic setting procedures -IMHO, of course. I suspect that this is because the correct completion of the Basic-Setting procedures will be conditional on the module being happy with its operating environment - which means NO errors in fault memory (other than the specific Basic Setting codes) - which means successful communication with the full suite of other relevant modules on the CAN network as designed for MQB platform cars.

It's interesting to speculate which other relevant modules are linked to the seat memory function (I don't know the answer to this question). The seat memory function is ignition key specific - so my hunch is that the seat-module needs to understand the identity of the key that is inserted in the ignition barrel. This information is obtained from the hex17 module (which houses the dash-panel insert) and there's likely data also provided by the KESSY module if the car has keyless-ignition. And as you have correctly identified in your earlier posts, the side mirrors adjust with the seat-memory profile - so comms messages over the CAN network will be required with whichever modules control the side-mirrors. And there is likely other CAN dialogue that happens with these modules that I can't think-of as I write these words - I guess!

However, I suspect that there is a far more fundamental problem operating CAN based MQB platform equipment on a PQ25 car!! Without delving into the specifics of the CAN topology set-up on the PQ25 cars, the newer MQB platform network arrangement made significant changes to the previous version Golfs - which were PQ platform vehicles.
For example:

• because of the growing number of modules in MQB cars, the older powertrain CAN bus network was relocated to other CAN buses (e.g. ABS and Power Steering modules were relocated).
• MQB platform cars introduced for the first time (other than for the Touareg) a separate running gear CAN bus.
• Importantly for your project and as discussed above - MQB cars no longer have a CAN bus for the dash panel insert. The control unit in the dash panel insert (i.e. hex17 module) is connected to the convenience CAN bus on MQB cars

Finally - I note your comment:
"This could end up being a Tiguan BCM with Tiguan mirror wiring packaged neatly in order to fulfil the seat control module connection requirements for seat memory functions to work"

hmm....... please don't take any offense (because none is intended) - but good luck with this proposal!!

A BCM is not the same as a stand-alone convenience module. The SCAN report for the Amarok confirms that this car already has a PQ25 style BCM that is registered @ address hex09 on the CAN network. If you are suggesting bolting-on a second BCM with MQB protocols onto a PQ25 car- then expecting the two to operate in harmony has to be exceedingly ambitious - IMHO of course!! Alternatively, if you are proposing replacing a MQB platform BCM on a PQ25 car - I suggest that you try solving world poverty instead - it's a more achievable goal (and you don't need to manage Component Protection errors in the MQB BCM)!!

Plus, on MQB cars, the 2 x side-mirrors operate from the respective front door modules on either car-side. These are fully registered CAN modules (so, no physical connection to the BCM).

However, the door-modules operate as LIN devices on the Amarok because "J386" and "J387" (which is the driver and passenger door modules respectively) are "subsystems" of the BCM on your Amarok scan report. So, very different communications protocols!! Again, if you intend to impose CAN based door modules onto a car that is designed with modules that use single-wire LIN based comms - good luck (and again, no offense intended)!!

Don

PS: Riddle me this, please - even if @MIG succeeds in communicating with this (these?) modules on his/her MQB test-bench and even if the initialization values are reestablished on the module (very, very unlikely IMO) - how does this outcome advance your project objective? This project appears to be one where a PQ25 based car needs to accept MQB equipment - it's NOT the other way around !!! What am I missing?

EDIT: maybe a picture is worth 1000 words - here's how the comms network is arranged on your Amarok (from SSP 463):

J533 is the Gateway module and J519 is the BCM in my diagram. Notice how these 2 x modules are shown as one box. Even though VCDS reports 2 x separate part numbers for these modules - I suspect on this car that these 2 x modules are physically one unit. My hunch is that VCDS formally separates the devices for the Gateway's diagnostic activities - but in truth J533 is simply a diagnostic interface chip with some allied circuitry that physically lives inside the BCM housing on this car. This is certainly NOT the case on MQB platform vehicles - both J533 and the BCM are functionally and physically completely separate units!

The other interesting observation about the diagram above is the positioning of J386 & J387 (the 2 x front door modules) on what VW calls the "LIN door databus". This arrangement confirms the way that these modules are reported in your SCAN - these modules are LIN slaves to the BCM master!! Given the simplicity of this arrangement, I wouldn't be surprised if J386 & J387 are nothing more than the motors for the fast-glass facility on your Amarok. Again, this is NOT the case on MQB platform vehicles - both J386 & J387 are fully registered CAN modules with much greater functionality!!

This car might be built on a B-VX62 platform, rather than PQ25 (i.e. this could be a 7N chassis vehicle - rather than 6N as identified in the SCAN report)?

And notice that there is NO j810 module shown in my diagram - suggesting that this car was never designed for electrically operated seats with memory function - a telling omission IMO .

Maybe a retrofit with MQB electrically operated seats (sans memory function) is a better choice for this vehicle-perhaps ?

[MIG]

My original input with this was to see if we could wake the unit and operate in a more standalone mode (not registered with the gateway). Still, it looks like OP has the seat working minus the memory function by temporarily putting the seat back in the donor vehicle.

I have been developing a development platform based around a Teensy 4.1; this can communicate with three independent CAN buses and act like multiple LIN clients or masters.
While I am very much in the devolvement stage, having one bus on the PQ 100 kBit/s CAN (comfort \ infotainment) and CAN 2 500kBit/s connected to the seat controller, you could, in theory, create software that translates the states between the systems, aka a gateway in itself.

But.. my software and test bench are not that mature yet, and it would be an excellent experiment to write software to translate the PQ ID 1394 (Klemme) and the MQB 960 (Klemmen_Status); I can generate the counter and checksum the MQB platform needs easy, this could wake modules, but not much else, I guess you could pass 0x700-0x7FF - UDS diagnostics too to allow the VCDS tool to talk.

As @DV52 said tho, it would be very hard to track down what other signals the seat is looking for. If it's from a vehicle that had customization via the infotainment, you need to deal with it maybe needing to talk over BAP, a protocol layer on top of CAN that is even more challenging to deal with.

My thoughts still stand. A PQ-based controller swap on the MQB seat, as per the guide posted a few pages back, would be your best option.

But hey, I love this discussion on things that have not been done before and working out what experiments we could do, so if you have a bunch of time, happy to throw ideas around