Can Sniffing PClink

[Stillrolla]

This might be a wild one..(also super crude understanding of can bus) 

Possible to add a can sniffing feature to PC link (Live stream) to identify address, frames, checksums and all.

Ex. Bench powering a G4X>Feeding bus signal from OE Car to G4x Bus> logging or streaming in PClink.

To decode and replicate on car new ecu is installed on?

I guess it would turn the ECU into a tool at that point instead of buying a Arduino or can sniffer and supporting software. It would be all natively supported   

[Vaughan]

Technically possible and kind of already done with CAN Lambda detection and setup, has been mentioned before and is in the list of things to look at doing at some point in the future but no real time frame on it.

[JonoP]

This would be super handy. This would open up a huge amount of possibilities. 

Please consider moving it onto the job list. 

[Gsab]

So would gearbox control...

 

[mapper]

With Can Sniffing function, DBC file creation, In- and Export should be added, too.

[Goingnowherefast]

On 10/29/2022 at 6:49 AM, mapper said:

With Can Sniffing function, DBC file creation, In- and Export should be added, too.

The latter would be a complete game-changer. This would really enhance Links capabilities above many others. 

[Vaughan]

5 hours ago, Goingnowherefast said:

The latter would be a complete game-changer. This would really enhance Links capabilities above many others. 

On 10/29/2022 at 11:49 PM, mapper said:

With Can Sniffing function, DBC file creation, In- and Export should be added, too.

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?

[mapper]

3 hours ago, Vaughan said:

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

[Vaughan]

23 hours ago, mapper said:

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

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.

23 hours ago, mapper said:

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. 

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.

23 hours ago, mapper said:

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. 

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.

23 hours ago, mapper said:

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. 

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.

On 12/14/2022 at 3:01 PM, mapper said:

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

[Adamw]

@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

[mapper]

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. 

[Goingnowherefast]

On 12/13/2022 at 5:15 PM, Vaughan said:

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?

Absolutely. Here's what I'm envisioning for the inclusion and overall enhancement of .DBC integration and CAN transmit/receive streams. In my project, I'm effectively integrating all the OEM controls into Link. I've created a basic example where I'm sending engine speed to the OEM gauge cluster. To do this under the current setup, you have to create a stream, create a frame, manually select the parameter tied to it, then add all the scaling, factor, offset, position etc. 

Obviously, all this information is embedded in the .dbc's format and can be found (for example) by opening a .dbc in Notepad++ or a legitimate .dbc editor like Vector's CANdb++ editor (example below): 

In my eyes, it'd be great if we could import a .dbc and have each message & signal go to a folder under CAN in the "ECU Settings" menu. Then, using the existing CAN setup we'd select the Message ID which would import all the relevant signals into a CAN stream. Then you'd parameterize "DME_RPM" (in this example) with the PCLink's "Engine Speed" parameter. Done. That would definitely make a huge difference in the level of work I'm trying to accomplish with Link (basically a full ECU replacement w/ OE CANbus functionality). 

Another great feature would be the easy ability to inject CAN messages with user supplied "raw" data. I know this is possible through the use of math blocks, but it's very clunky. Something like this, would be an epic feature: 

 

Basically, you choose the message ID, when it would send (so on ignition on etc.), the cycle time, and than you'd choose the raw data to send in hex format for each byte.