Electredge

Would something like this be suitable where you can select a percentage fuel trim runtime to 'remove' from the mixture map (i.e. if this trim is adding 20% fuel the lambda value at that point in time will have 20% added to it so that Lambda value displayed is what the lambda would have theoretically been if the trim was at 0%)

Not sure how much value I see in this but will look into it.
Best way to tackle this is to use the conditional filters to remove transients
What filter conditions do you normally use and what would you want to use in addition to your current filters
For more complicated filter setups if you know what filtering you want ahead of time you could setup a gp output, gp pwm or mathblock to create an easy to use conditional runtime.
will look into this

I was just typing the same thing.  The throttle is not even working in either of your logs, you dont have any APS sensors assigned.  The throttle is disabled and the ecu is applying a limiter for safety.   
 

I have both the G4X and G4+ working on a M2 MacBook Air (but should work on any apple silicon laptop).
My setup is as follows
UTM - https://mac.getutm.app/ (Parallels etc should work also) Windows 11 Pro ARM Driver Signature Enforcement has to be turned off Although there are ARM version of the FTDI and CP210X drivers available, they do not include the Link ECU PID's so do not work. I have edited the drivers and added the Link ECU PID's which enable them to work with the ARM drivers (maybe link can update their drivers offered to include ARM drivers now?) but driver signature enforcement has to be turned off as the drivers are not signed.
I have attached the custom drivers here, if this is not allowed please let me know and I can post step by step instead for you to do instead.
Link ECU ARM Drivers.zip

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...?
 

Wow, Thanks Adam. This is honestly epic feedback. Having dealt with ~5+ other standalones at this point I can say that at least anecdotally, Link's support has been absolutely top notch. Answers/details in red. 
1. Yep, in this case it's just a frame counter. I thought there was a CRC in another message, but upon further review of the CAN trace it looks like it's just a counter also. I've attached the CAN trace of both "Count1" and "Mux1" which will paint a better picture of how the two interact and what I'm looking to emulate. 

To recap: 
When "Count1" = 0, "Mux1" = 0 
When "Count1" = 1, "Mux1" = 0 
When "Count1" = 2, "Mux1" = 0 
When "Count1" = 0, "Mux1" = 0x25 (37 in decimal) 
2. Hopefully this was answered in #1. To expand a bit more on this platform, Porsche shares the controls and most modules between the 987 Boxster/987 Cayman/997 911/997 Turbo S etc. In order for PSM to function correctly (as well as mitigate any CANbus errors from each module) the values sent on "Mux2" must match what the controllers are looking for as far as model code, transmission code, engine code etc. Mux2 is a bit more complex, so maybe it's better to talk about that over email or the phone. There's also a good bit of proprietary information concerning the table I've created with all the models/transmissions/options etc. 
 
 

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.  
 
 

Having a look at dbc files at the moment and it looks like they're designed for dash style setups where the runtimes are generic and it's all about displaying that data. Can either of you provide an example (file or explanation) of how you would want to use a dbc file with an ECU?
Would you be wanting to import a dbc file to tell the ECU what to transmit, importing it to tell the ECU what data to receive or a combination of both (loading one file for transmit and another for receive)
Or are you wanting to generate a dbc file from a custom CAN stream setup?

Hi Vaugan 
Basicly i should allow everything you mentioned. 
Export.DBC file with channel names, unot etc. So it can imported in another software. A typical application is a custom dash stream. Setup all channels on ecu > export .DBC > import on AIM Racestudio > select new stream in Race studio in config > Done ✔️
Import: 
Again with the Dash example
Setup the CAN output stream on Race Studio > Export .DBC in Race Studio > Import to PC link > PC Link opens a Mapping Window to map the AIM naming to a PC LINK Can Input channel. Naming should taken over from the .DBC (e.g. CAN Input - AIM name). This would make it much easier to setup custom streams between CAN devices. It's in fact for what .DBC files habe been invented. It works really good between different Mfg. Devices. With Enumerations plane text can be assigned to channel numbers. So for example for fault code count, the enumeration text is shown on the dash when a fault is active instead of just a number. Makes it 300% more user friendly. 
Where I also see very big potential is syncing everything between LINK ECU and PDM whith DBC. In- and export. So the naming is right in the datalog. Means it shows something like "PDM HP 1  - Fuel Pump". ATMO we only see PDM HP 1 in PC link and need to check the calibration on the pdm to know whats connected there. 
On a a later stage idealy Link is aible to generate new channels and can take over 1:1 everything from the .dbc. File. ( think thats what you meant by Dash style). I usually define all my reverse engineering findings in a DBC editor. Once done I import the .DBC into the can device. An in theory everything should work straight forrward. 
It would be very useful if there is a CAN sniffer function on PC link and PDM Link So signals can be spot, defined in the .dbc and ploted in PC Link. Thats whats needed for reverse engineering. And is the feature. Or I should sayn it's now, because everything works with CAN nowadays.  In a perfect world there is a test transmit function also, to send byte streams to the bus (usually to test if something is activated trough the oem bus) 
I will send you much more ideas and feedback as usual via mail.
BR Adrian, Maptec

exporting to a dbc shouldn't be too difficult, we can take our runtime names and slap them in a file, little bit of UI work required around selecting what you are saving to a dbc, e.g. saving all channels, just one channel or specific channels and a little bit of hardcoded work around defining built in CAN streams as dbc and merging them into generated files if combining multiple channels into one file.
Note I've only found one example of compound ID/multiplexed messaging with multiple frames for one ID being made into dbc files and that format doesn't appear to be widespread so anything which uses compound IDs might not be dbc convertable.
Would be theoretically possible to import a dbc, throw up a window which the user uses to connect dbc Signals to CAN Analogs, CAN DIs, CAN Frequency, CAN TC and the short list of other CAN receivable runtimes. We don't currently have a way to name CAN Analogs etc in isolation as usually they are fed into a function like Oil Pressure or GP Input instead of having a label on the runtime. Maybe we should add user configurable labels for the runtimes.
We don't have any internal support for user created enumerations at the moment.
This could be covered by just adding labels for the PDM runtimes, feels like a dbc would be a bit redundant here. But again another good point that maybe our CAN runtimes should have configurable labels.
Importing a dbc file into the ECU to use a specification for what the ECU should transmit would the user linking every single signal in the dbc to an ECU runtime when importing  which would still use a lot of time. When reverse engineering a CAN Bus do you create a dbc file for ecu transmit and another for ECU receive as from what I can see there is no way to specify transmit or receive in dbc files, it's all just assumed to be receive.
As another note from what I can see dbc files don't allow you to specify how counters work or to specify fixed values so again very focused on specifying the receiving side rather than the transmit side.
I made a basic sniffer in PCLink but it needs a large amount of user interface improvement to move it beyond a basic list of the messages and values sent over the last set time period. Would like to do a semi live view with a row for each ID and the values displayed and updated realtime and also the ability to save a log but that will take time and time for that hasn't been set aside yet.
 
Basic summary from a quick investigation of dbc files yesterday is that generating them from user streams and providing pre made ones for fixed built in streams  is possible (as long as compound IDs aren't being used) but anything involving importing them as something for the ECU to receive or transmit still involves a lot of user input, the only useful information from the file being IDs, byte order, multi/offset, bit location and width. The signal names and units aren't realistically importable without forcing a parameter selection for each and every one.

@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

Basically, the .DBC file is the raw communication protocol. Means it only define the raw communication format on the lowest layer. All higher layer protocols like OBD, UDS as well as functions like checksum etc. are not defined and are rules that must be handled separately. So for now I would concentrate on the lowest .DBC level.  Basically every car, tractor, industry device manufacturer works with .DBC editors to plan and setup their communication networks. One of the most used tools here in Europe is Vector CAN++. A huge tool for very big CAN projects. 
I think also .DBC file import with a mapping function is well worth, assigning the Link CAN input channels is no big deal. But manually typing all names, offsets, multiplier, etc. is time-consuming and very error-prone. Also for you guys it will save good time in the long run. For example instead of working out a CAN template for 3th part CAN expander and add a template into the software, LinkECU user can just import the .DBC file from the 3th part device.  
 
Vaughan:
- Import function as you described sounds great. Check out the DBC. file import function on Motec's Dash manager. Found it well-made.  In the actual software Can values can only be logged if they are assigned to a ECU CAN Input. It would be great if on next gen ECU (or maybe already on G5) everything on the CAN can be logged, even if the channel is not assigned to a ECU function. With GPS coming on G5 and the 1000hz logging we have now, there is no reason to use any other logger in the car. So the usually Logger on the Display, we use for driver and chassis analysis, can be saved (and the budget spent into a more expensive ECU ;-) ). 
- Multiplexing (Compound). It is available in the .DBC standard and should not be a problem. I found Kvaser Database Editor 3 easy and very straight forward to create .DBC files. Might give it a go. I can send you some example .DBC files. It would be awesome if PC Link CAN setup has the columbs added as in database editor 3,  so you basicly setup the dbc, while you cofiguring the Link CAN. And btw. it would really help to have notes and enumerations to each parameter. For things like counters setup by a Math channel (just like Adam postet it today in another treath). So when you come back later, it's clear for what I was setup.  
- Enumerations: it's not  necessary to have user definable Enumerations in the beginning (of course, would be nice). Just the Link channels Enummerations could be packed into the .DBC file. For example, parameters like "Fault Code". "Antilag-State" should have the corresponding Text put into the enumeration slots of the .DBC. Basically everything should already been there. The CAN test calculator shows all the number>Enumeration(Text) translation. 
- Yes, I usually set up a separate .DBC for transmit and receiving. I'm not sure if there is a combined format available and also have not played a lote with notes in .DBC editing softwares. 
- Can Sniffer would be awesome. Also for PDM Link. Even if it is a basic list of traffic it will be quite useful for quick checks.  Second importan function for me is a static ID list with live data, so it's easy to spot what changes if for example a buton is pressed. Ideally recent changed are coloured like in Savvy or CAN Hacker Carbus Analysis software. On a next step you could basicly add all the function what Carbus Analyzer has. 
 
Adam: 
I found a lot of aftermarket devices support .DBC and find it a huge time saver. For example, I wrote the whole Link generic Dash Stream in Race Studio manually + additional channels in AIM Race Studio, 2-3 years ago. Manually typing in all channel names, offsets, etc. is just a waste of time. On top testing all channels for right format needs some more time. 

Regarding floating point, the raw can messages are sent always in binary form, which are then converted to hex or decimal. Significant figures are  handled by multiplication / divisor. The internal dataformat used in the receiving/transmitting device is depending on the device, so it would not make sense to define that in the communication protocol (.DBC). The same holds true for the content of the message. So all counter, checksums, CRC etc. must be generated by a function in the Receiving / Transmitting device. 

I dont know what they are on about, no common ECU has a filtered 12V output.  Link has an 8V, Haltech have 8V, Old Motec have 8V, new Motec only have 6.3V...
Taarks instructions show it connected to the standard nissan CAS plug which is straight from the main relay - not filtered at all, so I would do that - just connect to the main supply that goes to A5. 

yes, MAP is the actual sensor reading where as Target Boost is a lookup table. Boost control will not work with MAP as the axis, has to be target boost. 

unplug the controller and measure ohms between the 2 can wires, what do you get? 

Ok some options:
If the "Injector DC fault value" (fuel main settings) is set to something low, then you can just increase this value.  If however it is already set to 100% then it cant be set any higher.  It means the ecu is calculating you need more fuel than what the injectors are capable of supplying.  This would mean either injectors are too small, fuel pressure is too low, or you have some trigger error or other problem.  Any of these are potentially dangerous for the engine so you may not just want to ignore that warning.  
If you do understand the risk and just want to ignore it then you can mask this fault from the CE light function by setting as below. 

 
  

It's always been there, typically we have it setup so that new installs will be logging all the new runtimes so most people never need to touch it
But yeah if you log less you can log for longer with less load on the computer

If IAT is not the cause of your issue then the other common cause of lean hot restart is due to the injectors getting hot since they are sitting in a very hot environment and attached to a hot cylinder head, with very hot intake valves right underneath them and without the usual fuel flowing through them to keep them cool. 
The way to work around this is to use a 3D IAT trim table with IAT Vs engine runtime on the axes.  Then at hot IAT's you can add say an extra 15% fuel at initial startup and fade it out over say 2 mins.  

I can possibly help with the flat shift and shift light if you attach the tune, a log, and some info about the car, what engine and what ecu.  
The flames I dont have much interest in.  

Can you attach your tune and give us a log of it happening.  Start the log with engine running, turn off ign (leave log running), wait a few seconds, turn ign back on, (hit F3 to connect if not in auto connect mode), then start engine and record for a little while longer before stopping log and saving.  

In that case your setup will be working correctly as is and needs no changes.  Except I'm not sure how you assigned an analog input to lambda 5.  
FYI, the exhaust pressure compensation is done inside the CAN lambda devices.  The ECU sends calibrated pressure to the CAN lambda, they take it into account in their O2 calculation and send compensated Lambda back to the ECU.  The AFR500 does not have any of this functionality so will always assume exhaust pressure is at sea level atmoshpere.

I'd use CAN 

Or you could set it up through CAN1/2 if they're not used. 

I didn't have a chance to screenshot this but the way he has the stepper reset counter isn't how I normally see it done, and if its changed to reset on the off ignition then the ecu hold settings need to be adjusted to keep power while it counts down.... this one thing could be causing the differing idle settings as well as the no start if he is just cranking it up immediately like 95% of the ppl do

No, it is just a limitation in their software/firmware.  Possibly to stop ID clashes.  
But it tells you in the software if you assign a keypad to CAN2 all other CAN2 functions are disabled.