Getting a M1 to accept ECUMaster CAN Switchboard Inputs

Hi all,

I am trying to find a workaround to get my M142 to use CAN input from an ECUMaster CAN Switchboard V3. Aside from the M142 using GPR-DI and the CAN Switch, I also have 2x Motec PDM 15s and an AIM MXG dash on the network.

See attached data format.

The problem I see is that the ECU Recieve expects to see 16-bit values for each CAN x Offset y input.

The PDM reads the CAN switch no problem and I can control the turn signals, starter motor, etc as intended. I am trying to bring in a Mode and Launch Enable switch (momentary Otto button) and a Launch Trim CALPOT to the M1 that's on my steering wheel.

Is it possible to have the PDM regurgitate the CAN switch outputs by skipping offsets to pretend to be 16-bit as a custom PDM message and be readable by the M1? Maybe try through the AIM? Surely there has to be a way without custom firmware.

It appears through the PDM won't work as the resolution will be too low. When the switch transmits 1 for pressed, it'll be theoretically read by the M1 as 0.001V (I haven't tested this yet) which is finer than the threshold and hysteresis values.

My AIM MXG however does allow me to use a multiplier in a CAN custom payload so this seems like the most viable option and replicates what one would do if they had a Motec Dash. I can use a multiplier of say 1000, so that the M1 sees 1V when the button is pressed and say 1V, 2V, 3V, etc for my CALPOT.

I'll test this option and report back if it works.

AIM screenshot of custom payload attached. Just using engine speed as I don't have it configured to receive the CAN switch yet.

Since you are sending 8 bits in a 16, bit value, why don't you send the high-order byte (so 0x0100 instead of 0x0001). That will make you value appear as 256mv in the M1 and you can trigger on that.

You could also send the same value to both bytes, so either 0x0000 or 0x0101, then the byte order doesn't matter.

A little disappointed I didn't think of that yet. Thanks David, I'll give that a try.