Adamw

Its not so much the CAN configuration that is the problem - it is more so the control functionality.  A CAN keypad is just a dumb device with no brain.  So the device that it is connected to has to perform all the control and logic - ie, switching functions for button presses such as latch/toggle/momentary/set/reset/count up/down/increase boost/decrease boost etc, functions to control the backlight colours and brightness, functions to control the button LEDs and colours and switch them based on settings, button presses or statuses of other functions, then a whole lot of random stuff such as error checking and fail safes etc so that if for example a CAN wire gets chopped in an accident, you need the ecu to be aware so it doesnt just keep spraying fuel since the last button press it saw was "fuel on".
G4+ doesnt have any of this required keypad functionality.  G4X has a dedicated keypad menu with settings for all of these functions which are built in to the firmware. 

DI = Digital input.  These can be used for on/off type switches or frequency based signals like wheel speeds or ethanol content sensors.  
Volt = Analog input, this is used for sensors that output a 0-5V variable signal - such as fuel pressure etc.
The blank ones are not connected to anything.

With the gain at 50 you are amplifying the signal 50X, so yes any noise would be amplified also.  
 
Possibly this one?  https://youtu.be/_P1LRANeO4A
 
no we don’t.  Hp academy or evans perfomance would be the best option at the moment.

Yeah that should be fine.  You might want to lift that MAP lockout up a bit as many engines wont get below 50kpa when cold.  Set actuator type to none.  

That pinout is wrong I think.  The help file in PC Link shows pin 2 is the TP signal.  It also shows 5V and gnd at opposite ends, but that doest matter, they will work either way.  
Just try moving your TP wire to pin 2.  

 

Subtract 1.0ms from that whole dwell table that you have in your first post (click in grey cell at top left then type "-1" and hit enter), this would be right on what I would start with.  Rarely do these coils need more than about 3.0ms for typical applications, you can go right up to about 9ms when needed (ie 70+psi & methanol) but they are pulling 20A each at that and get very hot fast.  Use the minimum dwell you need to prevent misfire, any more is just making more heat and shortening life. 
The spark duration setting is irrelevent in most 4cyl applications, it only really comes into play with say a single coil on a v8 where you need to dwell & spark the same coil 8 times every cycle.  This setting is used so the ecu can shorten the dwell when there is not enough cycle time left for both full dwell and spark.   

Yes, mixture map can be used from road logs.  Set up a Transient filter Eng speed < 250rpm/sec and another with TP<5/sec will get rid of a lot of the inconsistent data. 
Here's a video I done for someone else earlier with some further info:  https://1drv.ms/v/s!AiYbYlZQuRHPszz5hTxJ8ec0MitL?e=2JbDVh

With engine idling:
Open "set base timing" screen. Set top "lock ign timing to" box to 15deg. With timing light on coil #1 confirm if 15 deg mark on pulley/front cover lines up.  If it does go to step 5, if not go to step 4. If 15deg mark doesnt line up, then adjust it with the middle offset box.  A larger number advances the mark.  You need to hit enter after changing that offset number.   Now the 15deg mark lines up at idle, bring the engine up to say 5000RPM to confirm the 15deg mark stays on target.  If there is some drift then adjust this out using the bottom delay box.  Click done and perform a store.   Make sure you connect the timing light to an old plug lead between the coil and plug, many timing lights dont give accurate timing if you use the timing loop at the back of the engine.

Yeah thats normal in G4+.  Not sure what the reason was, probably hardware related but may have been some other smart OEM idea for bleeding air or something.  The cams wont respond until they see 35% or so.  
 

Ok, counter 1 will just need the timer2 changed to 0.16s to make the count cycle 0-3 instead of 0-255.
For the mux there are several ways you could do this, below is the option I usually go for as it allows fairly complicated sequences to be generated:
I would use a math block to divide our "counter 1" by 3, with decimal places set to 0.  This will give us a 0 result for counts 0,1&2, and a 1 result for a count of 3.  

Now if we consider our MUX decimal value of "37", in binary it is 00100101. 

 
So in our CAN message we can just place the "math block 3" which generates a "0 or 1" in the 3 bit positions where we would have a 1 in Binary to generate dec 37.  

 
Broadcast result (counter in first byte, mux in 2nd):


 
Note also if you have relatively complete CAN information for these vehicles we could likely hardcode this into the firmware as a preconfigured stream in the dropdown selection if you were happy for every user to have access to it.  
 
 

This sounds more like just a frame counter rather than a CRC?  A CRC usually uses all bytes in an algorithm with a polynomial applied so it generates a value that is only true for the speciifc set of bytes.  If it is just a counter that increments by 1 for every 4th send and rolls back to zero once you hit 255 you can just use a timer.   Example below I just modified from one of my files.  For this example you would just send Math block 2 output in the CAN message where the counter needs to be.  0-255 at 25Hz would take 10.2sec. So we set up a timer to reset every 10.2sec.  We then multiply that time by 25 to get an integer that increments by 1, 25 times per second.  Pic below looks like it skips at around 10 but that is just the way I have recorded the gif.  
 
2. Need a better description of how this counter works.  What happens when counter is 4 do we restart?  so 0, 0, 37, 0, 0, 37...?
 

Ok, counter 1 will just need the timer2 changed to 0.16s to make the count cycle 0-3 instead of 0-255.
For the mux there are several ways you could do this, below is the option I usually go for as it allows fairly complicated sequences to be generated:
I would use a math block to divide our "counter 1" by 3, with decimal places set to 0.  This will give us a 0 result for counts 0,1&2, and a 1 result for a count of 3.  

Now if we consider our MUX decimal value of "37", in binary it is 00100101. 

 
So in our CAN message we can just place the "math block 3" which generates a "0 or 1" in the 3 bit positions where we would have a 1 in Binary to generate dec 37.  

 
Broadcast result (counter in first byte, mux in 2nd):


 
Note also if you have relatively complete CAN information for these vehicles we could likely hardcode this into the firmware as a preconfigured stream in the dropdown selection if you were happy for every user to have access to it.  
 
 

@Vaughan Yeah 3rd party support of DBC's with compound messages is pretty flaky.  Same with 29bit ID's.  Even though DBC's do actually support both compound (they use the term multiplexed) and extended ID's, it seems very few 3rd party devices actually support those - or dont interpret them correctly in my experience.  A DBC is only designed to specify how a CAN message should be received - so you are right in that they dont support counters, checksums, CRC's , or request/response type messages like megasquirt, fueltech or OBD2 devices use.  I've also noticed they only support signed/unsigned integers (not sure if there is any width limit), they dont support floating point values etc.   
A DBC for the generic dash stream attached, made by me but it seems to work with my sniffer.  
I too dont see DBC's as being a good option for importing into PC Link/Link ECU with the architecture we have now.  However generating a DBC as a file that can be used to set up a receiving device seems like it is possibly doable.
Generic Dash.dbc

Ok, counter 1 will just need the timer2 changed to 0.16s to make the count cycle 0-3 instead of 0-255.
For the mux there are several ways you could do this, below is the option I usually go for as it allows fairly complicated sequences to be generated:
I would use a math block to divide our "counter 1" by 3, with decimal places set to 0.  This will give us a 0 result for counts 0,1&2, and a 1 result for a count of 3.  

Now if we consider our MUX decimal value of "37", in binary it is 00100101. 

 
So in our CAN message we can just place the "math block 3" which generates a "0 or 1" in the 3 bit positions where we would have a 1 in Binary to generate dec 37.  

 
Broadcast result (counter in first byte, mux in 2nd):


 
Note also if you have relatively complete CAN information for these vehicles we could likely hardcode this into the firmware as a preconfigured stream in the dropdown selection if you were happy for every user to have access to it.  
 
 

Ok, counter 1 will just need the timer2 changed to 0.16s to make the count cycle 0-3 instead of 0-255.
For the mux there are several ways you could do this, below is the option I usually go for as it allows fairly complicated sequences to be generated:
I would use a math block to divide our "counter 1" by 3, with decimal places set to 0.  This will give us a 0 result for counts 0,1&2, and a 1 result for a count of 3.  

Now if we consider our MUX decimal value of "37", in binary it is 00100101. 

 
So in our CAN message we can just place the "math block 3" which generates a "0 or 1" in the 3 bit positions where we would have a 1 in Binary to generate dec 37.  

 
Broadcast result (counter in first byte, mux in 2nd):


 
Note also if you have relatively complete CAN information for these vehicles we could likely hardcode this into the firmware as a preconfigured stream in the dropdown selection if you were happy for every user to have access to it.  
 
 

You need to contact your dealer with the ecu serial number (508838) and ask for an unlock code.  When you have that you then go to >ecu controls>ecu unlock and enter the unlock code there.  

Right mouse click on table>axis setup, set the Y axis to none.  

You need to use CAN bus, not the USB tuning cable.  http://realdash.net/manuals/supported_can_lin_analyzers.php
I would suggest this one:  https://www.seeedstudio.com/USB-CAN-Analyzer-p-2888.html

I would think something like below.  You wont need a check valve between the reservoir and booster.  Most likely you will want a hobbs switch or press sensor in the reservoir as well so the pump only runs when it needs to.  

Yes similar to what you have done.  Except you wont need one for "position 1", this will just use boost table 1 which is the default.  So you would have a GP output with the condition "switch position = 2" and use this output to enable the 2nd table, then a 2nd GP output with the condition switch position = 3 and use this to enable boost table 3.  
 
Yes you could either put ethanol content on one axis of all three tables, or you could turn on the "GP Boost tables" use that to trim boost based on ethanol content.  

No, they use the factory calibration resistor.  

A quick explanation video of what I suspect is happening.
 
 
Back feed.mp4

Yes I would expect the VE tables would be reasonably interchangeable.    

For wiring diagrams, the BMW WDS must be the most widely pirated automotive documentation systems known to man, you should have no trouble finding factory diagrams.  https://bmwteka.com/ is one example.
For the dash board you can use the mini R53 CAN mode and most of the basics will work.  If you search "E46" on the forum here you will probably find some of my old maps with custom CAN set up for more complete functionality but you will need a good understanding of Link to make use of that.  ABS is a bit hit and miss, there are 2 different ABS systems used in the E46, I know one works with the mini stream and one doesnt, cant remember which.  
A/C request from memory is a bit odd, a duty cycle based signal I think.  G4X should have all the tools you need be able to interpret it, but you will need to reverse engineer how it works on a car with a stock ecu first.
 
 

Yeah a sudden total loss of pressure like that could only be a large leak.  Turbines at 100000RPM have a lot of inertia so there is not much the ecu can do to influence it that much that quickly.