PSA: When can you use the AEM X-Series CAN with other devices on the CAN Bus
 

A question that has been popping up recently.

You have an MS3, an AEM X-Series gauge and you want to feed the wideband signal to the MS3 through the CAN Bus, but you also have other devices on the CAN Bus and you are worried about compatibility.

Let's make a a few remarks.

- The CAN Bus can have BOTH 11bit and 29bit messages running through it at the same time. This is perfectly fine and many new cars do this.
- The MS3 uses both 11bit and 29bit CAN.
- 11bit CAN is used for 1-way communication from the MS3 to other devices ("CAN Broadcasting") where the MS3 broadcasts messages and other devices on the bus receive them. It can also be used as "CAN Receiving", where the MS3 also picks up messages broadcasted from other devices.
- 29bit CAN is used by the MS3 for 2-way communication. It's a custom request-respone protocol (although there are 1-way commands on this protocol as well).
- Each CAN message has an ID, also called an address. On the 11bit CAN, this signifies who sent the message or what it contains. There is no way to interpret this; You have to know for example, that the message with ID: 0x100 is sent by the ECU, and it contains the RPM signal, the TPS, the CLT and the IAT.
- On the custom MS3 29bit protocol, things are different. Because 29 bits is a lot of space, you can put the sender address, the receiver address, the command type (ie request data from ECU, send data to ECU, perform a Burn command, etc), the location of the data to request/store, etc. So when you see an MS3 protocol 29bit ID, you know exactly what it is.

The problem here is that the AEM X-Series uses 29bit CAN. The default ID of each message is 0x180. Translated to MS3 CAN, this ID implies:
* This is a message from the MS3 (CAN ID: 0)
* This message is to be received from the device that has a CAN ID of 3.
* The command type is "MSG_CMD", this tells the target device to store the data attached to this message.
* The table to store this message's data on the target device is 0.
* The offset with the table to store this message's data on the target device is 0.

What does this mean? If you DON'T have a device on the CAN Bus that has ID: 3, it is perfectly safe to install the AEM X-Gauge on your bus.

It might even be safe to install it even if you have a device on the Bus with an ID: 3, if that device doesn't actually implement the MSG_CMD message type (it will just receive it and ignore it) OR if the device doesn't store data on the table 0, offset 0.

How do you know what ID your devices are using? It will be either be in the documentation of your device or the settings of your device. Most MS-compatible devices have configurable CAN IDs. If you still don't know, ask the manufacturer.

Thanks for the information. I have been wanting to add additional CAN devices to my MS3 (With an X-Series wideband connected already) and was concerned about what I had found regarding compatibility.

I am pretty sure I understood your post well enough, my takeaway was:

Use all the CAN devices you want as long as nothing uses ID 3?

Correct.

Can anyone actually confirm this? I've seen multiple forum posts and questions regarding the compatibility of the CanChecked gauge and the AEM X-Series wideband, specifically the 03-0300 but have yet to see someone physically wire it up and test it out and relay their findings back to the forums. If there is somewhere that someone has done this that ive missed please tell me where I can find it because i'd be interested in checking it out.

Rev, everything you have said is correct but I believe you are leaving out an important detail:

You cannot have Megasquirt 29-bit CAN (henceforth MegaCAN after the open-source library that implements it for other devices) enabled and still receive AEMNet WBO2 data over CAN. With MegaCANenabled, the MS3 will attempt to decode any 29-bit CAN messages as MegaCAN messages rather than standard CAN messages. This is, of course, noted in a million other posts here and elsewhere but dropping it here for folks who find this first. This effectively means that the normal 29-bit CAN protocol(s) and the MegaCAN protocol are mutually exclusive -- You can use regular 29-bit CAN or MegaCAN, but not both. Not a big deal considering the limited number of devices that actually use the MegaCAN protocol (because why would you???).

The reason for this mess is that the MS firmware devs decided to roll their own CAN-based message protocol. I'm sure they were shocked to find out that nobody wanted to make devices that supported a custom CAN protocol for a single type of standalone ECU, especially when they don't even provide a library to actually use the damn protocol. The only existing open-source implementation appears to be MegaCAN which is linked below.

MegaCAN repository (you probably don't need to read this): https://github.com/mantonakakis1/MegaCAN
MegaCAN protocol description (As above... If you do, I sincerely apologize): http://www.msextra.com/doc/pdf/Megas...2015-01-20.pdf

TLDR; Do not enable "29bit Megasquirt CAN Enable", do not buy devices that rely on the MegaCAN protocol rather than any normal CAN protocol, and have fun with (11 or 29-bit) CAN via CAN Receiving/Broadcasting menus.

I was very particular with what I said and I made the technical analysis for it. You CAN have ΑΕΜΝΕΤ and MS 29bit can enabled and you will NOT have any problems if you don't have any device with a ID: 3 in your bus. It's that simple. The AEM's (as in PN: 30-0300) CAN conflicts with any device that has an ID: 3, that's it. There is no problem and no harm to the MS3 or to devices with any other ID. The MS3 will NOT parse the AEM's messages, and neither should any other device.

What you have said is absolutely correct. I was just trying to clarify that while the addition of the 30-0300 to the CAN bus will not break/harm anything (assuming no other devices with CAN ID 3 are on the bus), the MS3 will not be able to parse WBO2 data unless MSCan is disabled. MSCan and normal 29-bit CAN receiving are mutually exclusive.

Your final comment probably clarifies my point more accurately:

I am working on a car for a friend, and he is interested in a CAN dash. Currently we only have the AEM X-series UEGO gauge on the CAN system. Based on the above discussion, is the attached diagram a valid setup for use with the MS3PROPNP?

Any nuances to be aware of?

https://cimg9.ibsrv.net/gimg/www.mia...2297541ead.jpg