next topic »

[on:]

I have a rather difficult situation I am in. I have a KAntrak 2610 digital display gauge in an electric vehicle. This digital display has gauges that are for an internal combustion engine and because of this, the fuel gauge cannot be read by my CAN bus. I have an Azure Dynamics motor controller with an incorporated CAN bus with j1939. I would like to convert my fuel gauge to the battery pack level and convert the engine rpm gauge into the electric motor controller rpm gauge. The visual displays with icons with not change, and I do not care much for that, but need my CAN to display via my KAntrak digital display. I've heard that this is possible with Arduino. I've also heard that I need to know the SAE standards for these parameters and searched online and it looks like I need to pay to see them? Any help would be appreciated about how I can approach this. Thanks!

[Reply #1 on:]

Yes the 1939 standard is an SAE document you must pay for but if you dig hard enough on the web you can probably find what you need. One thing you should do is to request a .dbc file for the output of your motor controller and perhaps your display from the mfgs. This is a text file that will describe the messages that are transmitted on 1939...note also some messages may be proprietary so they wouldn't be in the standard anyway.

On hardware the arduino DUE has two CAN ports making it ideal for a "bridge" application as this sounds it could be. You will need to add CAN transceivers which you can read about in this forum under the CAN library thread. I've just finished a prototype of a prototyping board that includes these. The new can library includes sample code which will help get you going, (one uses extended IDs which is part of 1939).

[Reply #2 on:]

I just so happen to know a thing or two about Azure Dynamics DMOC controllers. Which controller are you using: 445, 645 gen1, 645 gen2? This will make a difference. I know something about all of them but their CANBus programming is totally different between the three.

Now, you seem to have a dash display which expects J1939 PID messages from an internal combustion engine (ICE) engine control unit (ECU). This is not as hard as it seems. A bunch of standard PID messages are detailed at this wikipedia page: http://en.wikipedia.org/wiki/OBD-II_PIDs

The gist of how PID works is this: A device sends a request to the ECU for a certain piece of data. This request is sent to the ECU broadcast address which is generally something like 0x7DF. It responds on a different but related address with the info you requested. This is all explained on the page I linked to. What you'd do, in order to show data on the dash display, is pretend to be the ECU. When the display asks for a certain piece of data (like, say, the fuel level) you receive the message and send back the fuel level in the proper format. You will have to get this data by processing frames from the DMOC motor controller. So, the arduino board will be a shim in between the two devices. This can be done with one canbus line or you could use both. It's up to you.

This is all quite possible with an Arduino board and some extra canbus goodies. I worked on canbus libraries that work on both the 8 bit Arduino mega type boards (well, it was a Macchina but that's an Arduino Mega clone with canbus) and on the Due. So, I can vouch that canbus works on both boards. I'll be around if you run into trouble.

[Reply #3 on:]

Collin80 sounds like your guy for the controller output!

On the display just be careful because SAE1939 is not the same protocol as OBDII(SAE 1979). I think your best bet for finding out what messages your display is expecting to receive for RPM and Fuel level from the mfg if possible...if you are certain the display is expecting 1939 messages then it will be easy to "emulate" these on one of CAN ports, whilst reading output of your controller on the other. I'll see if i can do digging on what PGN's RPM and Fuel Level live in if this seems worthwhile to you.

Of course the other problem you may run into with your display is scaling, units, etc...which may be hard-coded and not be a 1:1 with what an IC engine.