Interest in CAN and OBD-2 support for Cougar?

[DJBecker]

I'm wondering if there is interest in adding CAN reporting and configuration to the Cougar controller.

Why? CAN provides a standard interface for reporting and diagnosis. All new cars in the U.S. are required to use CAN for their OBD-2 diagnostic interface. You can use standard OBD-2 tools, like the ScanGauge, to report what is going on with the controller or have a digital instrument panel.


When I wrote the support for the MCP2515 CAN controller on our motor controller I took care to make it nominally compatible with the Cougar firmware and hardware.

The added hardware would be a small board containing the MCP2515, a CAN transceiver (typically a MCP2551), two resistors, and likely a crystal with two capacitors. All parts are available in through-hole versions, so a standard protoboard may be used. The component cost is under $5, with the protoboard and mounting likely costing a bit more than that.

The connection to the Cougar would be through the 6 pin ISP programming connector, with one (ugly) extra connection to the processor -- the MCP2515 needs a standard SPI port, with a directly controlled chip select line.

Our hardware actually uses two additional connections: an 8MHz clock generated by an AVR timer output so that we don't need a crystal, and an interrupt line. Using a dedicated crystal for the CAN controller avoids the need for the first line. and my firmware can poll the chip rather than rely on an interrupt. (The hardware interrupt is required for low-power sleep operation, but the Cougar hardware isn't set up for that anyway.)

My software initializes the chip, responds to OBD-2 requests that make sense for an EV, and has hooks to read and set most of the same parameters that the serial port interaction can do. I believe that the only modification needed to the Cougar firmware is a function call in the main polling loop.

If someone is interested enough to lay out a circuit board, I have some ideas on a few no-extra-cost features it should have: a pass-through for the ISP signals, jumpered CAN termination, bringing a few of the controller pins out to a header (they can be used for general-purpose I/O or status LEDs), sleep control for the transceiver and jumpers for optionally using an isolating transceiver.

[jackbauer]

Would this work:
CANSPI Board - MCP2515 Development Tool - mikroElektronika

[sawickm]

Originally Posted by DJBecker

I'm wondering if there is interest in adding CAN reporting and configuration to the Cougar controller.

Why? CAN provides a standard interface for reporting and diagnosis. All new cars in the U.S. are required to use CAN for their OBD-2 diagnostic interface. You can use standard OBD-2 tools, like the ScanGauge, to report what is going on with the controller or have a digital instrument panel.

If someone is interested enough to lay out a circuit board, I have some ideas on a few no-extra-cost features it should have: a pass-through for the ISP signals, jumpered CAN termination, bringing a few of the controller pins out to a header (they can be used for general-purpose I/O or status LEDs), sleep control for the transceiver and jumpers for optionally using an isolating transceiver.

DJBecker,

Thanks for the post.

I'm sure that if you post the schematic or firmware, someone would use your Cougar CANbus interface PCB, I would be interested. I'll post it on the ReVolt wiki for you, or add a link to your project website just PM me.

Would your interface work with a Elithion - Lithiumate - Distributed Li-Ion BMS that uses a CANbus interface.

It would be a very nice add-on item to the ReVolt Cougar PCB family.

-Mark

[DJBecker]

Originally Posted by jackbauer

Would this work:
CANSPI Board - MCP2515 Development Tool - mikroElektronika

Yes, that would work, with some caveats.

* The header pinout doesn't match the pinout on the Cougar. You'll be swapping each signal to its correct location. The DIP switch on the board doesn't make it easier, instead just providing an opportunity to break a working configuration.

* They didn't read the datasheets carefully. They put 100K resistors on inputs that already have internal pull-ups, use a 10MHz crystal when a 16MHz or 8MHz clock would be a better choice for noisy signal sampling, and have a pointlessly low slope control resistor (10K-20K ohms would be a better choice than 10 ohms). And it wouldn't have cost more to put in much bigger decoupling caps, especially with near-zero slope control. The as-built component values might be different, but the brochure schematic didn't give me confidence.


This module was just one of the options I looked at. In the end I decided it was better to just wire the MCP2515 and MCP2551 on my protoboard. But if you have an already-built Cougar board, I can see that this module is the easier solution (and certainly less expensive than a one-off board).

On the plus side, there is pretty much only one way to hook up a MCP2515.
The firmware is mostly the same for all implementations -- there is only a slight adjustment needed for the 10MHz clock, and not using the option to use an output pin for transceiver sleep control.

I would be happy to post the firmware after I have someone check that it nominally works with the target hardware. Are you volunteering? You will need the ability to re-flash your AVR chip, and a CAN OBD reader or gauge.

[jackbauer]

yep i'll be the guniea pig have those facilities and a board on the bench built , one in the car working and two undergoing build for my bike

[DJBecker]

I sent you a private message with a few notes.

What pin are you planning on using for the SPI chip select? And what processor chip does your control boards use? I can put a #ifdef in my code for the change.

If you are short of pins for chip select, it's possible to use the overcurrent clear line for that purpose, and run a wire back from a MCP2515 output. It would only be a two line rewrite of the clear_oc() function.

[jackbauer]

ok thanks. Will get to it asap.

[DJBecker]

The code has been tested with the ScanGaugeII. Although only a few of the built-in display items are useful -- throttle position, temperature and load.

ScanGauge MPG gauge: improve your fuel economy - EcoModder.com

My board also monitors RPM, so I get that output as well.

There appears to be a way to display arbitrary PIDs (parameters) with the ScanGauge, but I haven't explored that yet. I structured the code so that the OBD2 reporting part was easy to understand and change, thus it should be easy to report other internal parameters.

The only hardware note is that the ScanGauge does not supply a CAN terminating resistor. CAN bus should have one on each end, and the diagnostic device is sometimes considered an end point. CAN does work if there is only a single terminator. It won't work with none, for instance if your circuit expects the resistor to be the other device. (I skipped putting the resistor on one of my test boards that I expected to be a "middle" node.)

The other minor note is that the ScanGauge report the voltage supplied to it, not the voltage reported by the controller. My controller code measures and reports the 5V supply, so it's not a subtle difference.

A note to Paul: My controller code uses the same approach as the Cougar firmware, measuring the motor current on alternate A/D measurement cycles. But on the "odd" cycles I sequentially sample all of the ADC channels and store the result in an array adc_raw[]. I initially had a bitmap to skip 'unused' ones, but deleted that code because the optimization was pointless for performance. By making all of the conversions available over CAN, the firmware doesn't need to be changed when a temperature or voltage sensor channel is added.

The only special case is measuring Vcc (nominally 5V) by getting an A/D conversion of the internal 1.1V precision reference and inverting it for the report. I do this only once, at start-up, since changing Vref results in a noisy next conversion.

case 0x42: {
/* Control module voltage: 12V expected, we report 5V supply. */
uint16_t voltage;
/* Measure the 1.1V ref, round a bit to allow exactly 5.000V */
voltage = 1125000L / rt_data.raw_1_1V;
can_cmd.dataA = voltage >> 8;
can_cmd.dataB = voltage;
break;
}

[DJBecker]

Hopefully this directly linked image is visible to others.

It shows one of our controller boards on the bench reporting to a ScanGauge over CAN bus. The four values on the screen are RPM, throttle position, voltage and temperature.

The adjacent industrial panel meter is reporting the RPM measured from a separate sensor. It's actually reporting RPM/10 to get a faster display update rate.

[DJBecker]

The Torque application available on Android displays standard OBD2 data, as well as providing a way to get additional data using extended CAN messages and create customized gauge labels.

It could be better, but that's a future project.