MoTeC Global Forum

Not quite sure where to put this so I'm putting it in here. I've got the data sheet that tells the address locations and bit values of the data being sent out by the ECU but I'm trying to experiment with doing a wireless CAN txRx that would allow me to talk with the ECU wirelessly. I know from some past discussions that the can protocols for motec are pretty tight in the ECU and don't allow for a whole lot of error. I've got some CRC code that would allow up to 6 errors in the code before dropping a packet that I'm planning on implementing in the micros for the tranciever to help with this. The parts are pretty cheap but I'm not quite sure on the can protocols. Obviously when talking to the ECU vs a Data logger there's different addresses there. I could do one-way telemetry with the information I've got now but not so much two way. I realize that motec uses their own can protocol so I don't know exactly how "strict" they are about getting that information out there but i figure i'd ask.

Hi,
When you talk about communicating with the ECU there are two different parts to it. One is the communications via ECU manager for tuning the ECU configuration, i.e. changing parameters, table etc. This is MoTeC specific Intelectual Property and we would not be able to send any of this to you.

The second part is ECU channel information coming out of the ECU or going to it. For example, the data that is sent to and from our data loggers, this is no problem to send out to you.

It really depends on what you want to do exactly.

That kind of what I figured. I was looking to communicate through ECU manager wirelessly but thats obviously not an option. Pulling protocols for data logging was the information I already had and we're already pulling that for data logging with our EVO4 unit.

Just out of curiosity is anyone at motec working on doing wirless can through the ECU manager or is it just to cost prohibitive for you to do that?

There are people who do communicate with various ecu's wirelessly.

They use serial-WiFi, Serial-Bluetooth adaptors etc

So it is possible, but all way above my head. But it can be done.

jlangholzj wrote:That kind of what I figured. I was looking to communicate through ECU manager wirelessly but thats obviously not an option. Pulling protocols for data logging was the information I already had and we're already pulling that for data logging with our EVO4 unit.

Just out of curiosity is anyone at motec working on doing wirless can through the ECU manager or is it just to cost prohibitive for you to do that?

Where in the world are you?
It is for an ECU or a logger?
It is possible for a logger.

You should use (or build) CAN to Wifi or CAN to Bluetooth gateways. Use two devices, one on your vehicle connected to the ECU canbus, and one connected to the UTC canbus. The ECU Manager will still see the UTC and will send/receive packets to/from the ECU. No special setup are needed for both ECU and UTC, they don't know comunication is done through air instead of cable.

Some devices I found. But others probably exists.

Bluetooth: http://www.rmcan.com/index.php?id=1067&L=1
Wlan : http://www.rmcan.com/index.php?id=1149&L=1

Angelo

i realize its possible for the logger and moreover its also possible for the ECU. The data is out there to pull the specific values for the motec for one-way telemetry already but I'm looking to have two-way telemetry with the ECU and modify values and parameters wirelessly.

the problem with pre-built solutions is that they're large, and they weigh a lot. The coding was planning on being interrupt driven so that you could have a seamless solution both ways, which is still possible just a little bit more difficult. The reason i wanted to protocol is that I'm guessing there's a header packet sent out when communicating to the ECU, largely because once the CAN to USB converter is connected to the CAN it takes priority and other devices such as the data logger can no longer record data. With knowing what the header frame is would have aided in making a much more "elegant" solution to the interrupt driven case. It is still possible but the system would rely large in part on the communication from the computer side if it were interrupt driven or it would be continually sending CAN packets over the txvr which isn't THAT big of a problem, just a little less elegant than i wanted to.

I'm in central US, South Dakota more specifically.

I'm going to keep working on this, the only hold is that the coding might just take a bit more for the CAN/spi interface on the micro. Granted we're talking mW here but there would have been less power consumption as well with an interrupt driven system.

Using MCP2515 on a micro-controller like ATmega, etc... connected with SPI will difficult. Handling SPI will be time consumming, so the risk to loose CAN packets is high.
I would suggest using more powerfull micros with integrated CAN controllers. Either STM32 or LPC1700 will do the job, they have 1 or 2 integrated CAN controllers with powerfull filtering scheme. They can handle CAN bus and use some wireless module from Xbee, Wifly, etcc. They are fast enough, 72MHz for STM32F103, 120MHz for STM32F2 and LPC17XX.

As an example, I created an interface using a LPCXPresso LPC1769 evaluation board. The IDE is free and powerfull with full debugger and so on. The interface is connected between my M800 and a Marelli MT940 dash. It received CAN packets from the M800 on CANBUS1, translated the data and resend them with a new protocol on CANBUS2. On top of that, it reads a 10Hz GPS module on UART1, resend the data at 5Hz on UART2 to the M800, and send "BR2 like" messages on CANBUS 1 to M800 for lap timming. All this without tricky code, assembly or special compiler directives.

Angelo

Using the UTC connected directly to a wireless router running OpenWrt firmware, with the USB/IP add-on enabled (https://openwrt.org/ and http://usbip.sourceforge.net/) is a very simple way to achieve two-way telemetry between the ECU, viewable within ECU manager. On-board datalogging in the ECU is still enabled and running while the UTC is connected.

One note though, this sort of system has to be used with caution, as full access to the ECU is available, and if caution isn't used could be dangereous changing certain parameters while the vehicle is in use.