I have some good news. I have almost completed the changes to Sardine that allowed me to talk to the RPI and turn it into a J2534 device. I had to refactor the code to make it work over TCP/IP, I had to also refactor the message handling mechanism to work with multiple messages in one recv operation. I had to write a small python proxy on the Pi , which is still very crude but allows me to spoof some CEM data to get VIDA going.

It took me a week simply because of the awful development environment I set up. Main PC with Visual Studio -> Laptop with VIDA -> RPI. Transferring from PC to laptop, refreshing the localhost/Vida instance via reloading or having to kill the IE tab emulator + needing to restart the RPI python server took a toll on my time. I can't even describe how many times my J2534 dll crashed(bad pointer arithmetic) and I had to manually kill all msedge processes.

All I have to do is wait for my raw OBD2 cable to arrive, set up a charger for my RPI in my car, and most importantly, find a way to relay the CAN messages to VIDA without blocking or saturating VIDA with too many.

Anyway, throughout all this I saw that on my test ECM on the bench, the DLC byte commonly seen here is irrelevant and doesn't actually work with the 2002 HN.2. Perhaps it only works when connected via the CEM.
So commands that should be 000FFFFE#CB7AXXXXXXXXXX do not work, but when removing the 0xCB byte(DLC field) it works just fine, or perhaps I wasn't sending it correctly.

I was working based on this information.

https://github.com/Alfaa123/Volvo-CAN-Gauge/blob/master/Diag_Request.png

Also, which areas do you feel I am lacking in, genuinely asking for constructive criticism so I can improve. However if I can say one or two things in my defense, it's that the information is fragmented between multiple websites, multiple languages, github repositories or forum pages. Even then some of it is subjective based on whoever wrote it and his or her understanding of it. It took me a long while to get to where am I now, even though important bits such as Sardine J2534 being there free to use and extend which saved me quite some time in and of itself. My last goal which I may fail is the bootloader for Denso-based ECUs. I am really surprised that only the subaru people ever went to explore those ECUs.

Anyway, just how many protocols do Volvo use? I mean there's a ton over CAN, ISO15765, K-line, UDS, a few more(quite a few), D2, GGD.

Maybe you were referring to my TCP/IP implementation. The RPI has no native way to communicate with Windows via USB or anything else. I decided to change this by using TCP sockets and using a shared network between the Raspberry Pi and Windows, as Sardine was written to work with Arduino and COM ports. And obviously Linux has native support for pretty much anything I could think of. So it's working nicely.
Anyway, thanks for the pointers. The VAG group are all Bosch. And, at least in my case, my S60 is Denso. And yes, I understood early on that there are less open source tools for Denso than there are for Bosch, but luckily the Subie guys have done the hard part(arguably the hardest out of all of this)

Here is the link in case anyone ever needs a base start on the kernel aka bootloader. https://github.com/fenugrec/npkern . As-is, it's currently not compatible with Volvo for a variety of reasons, but I will get to it in the near future.

I do not believe you are truly wrong. It has been only like 2 months since I started from scratch when it comes to car ECUs and Tuning. I truly had no idea how people did tunes, what maps were nor the software. It was very very difficult to build context between all the information(that is again, very fragmented). It took me a while afterwards to find dumps for my specific vehicle, to compare tunes and see what was changed, guess it's factors. As soon as I had some semblance of understanding I wanted to try and tune myself, I needed to flash my changes(to a test ECU I bought online, I wouldn't dare change anything on my running car), which is where all this lead me. Obviously, all the while reverse engineering the SH2 dumps I have, the SH2 arch is...unusual to say the least. But at least I was able to easily see what was data and what was code, as the architecture is such, that IDA produces almost sensible code from the data.

EDIT:
The subaru bootloader cannot work for me as-is, I know this, because it relies on the Subaru specific semantics, the guy's code will hopefully at least get me started in some direction. I just haven't had time to look at it properly. I am very focused on having VIDA communicate with my RPI.

As soon as I progress further will I have time to look at the next objective. Yes I have split everything into smaller tasks.

Did you asked me over PM or in this Thread, maybe i overread it... my MAF Readings would be actually useless because i have 10% Airleak Somewhere...

Answered you with an PM

Brake booster leak shouldn't be related with boost leak because vacuum hose from engine to BB has one way valve - at least if it's working

"I got my transceiver (NXP TJA1040) from an old XC70 Rear Electronic Module.
There is poetic pleasure in using a Volvo component to recover what was taken from you by Volvo
I'm alluding here to your right to customize or repair your car.
This PIN business or being locked out of using spare parts is really sleazy."

He’s just seeking attention. The more you acknowledge him he’s just getting what he wants.