EcoModder.com

EcoModder.com (https://ecomodder.com/forum/)
-   Open ReVolt: open source DC motor controller (https://ecomodder.com/forum/open-revolt-open-source-dc-motor-controller.html)
-   -   Interest in CAN and OBD-2 support for Cougar? (https://ecomodder.com/forum/showthread.php/interest-can-obd-2-support-cougar-15649.html)

DJBecker 01-02-2011 06:19 PM

Interest in CAN and OBD-2 support for Cougar?
 
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 01-03-2011 03:31 AM

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

sawickm 01-03-2011 08:20 AM

Quote:

Originally Posted by DJBecker (Post 212545)
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 :thumbup:

DJBecker 01-03-2011 09:39 AM

Quote:

Originally Posted by jackbauer (Post 212661)

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 01-03-2011 02:31 PM

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 01-04-2011 12:56 PM

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 01-06-2011 02:33 AM

ok thanks. Will get to it asap.

DJBecker 01-06-2011 11:19 AM

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 01-07-2011 08:44 AM

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.

http://lh6.ggpht.com/_q87kS_ctSWc/TS...10107-0003.jpg

DJBecker 03-10-2011 02:08 PM

1 Attachment(s)
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.

Grimm 06-11-2011 11:08 AM

You can get a 7/8" Chinese import Android tablet these days for ~$100. There are even 10" ones in the $150-$170 range. Just search for tablets that use the WM8650 chipset. I'd be really tempted to dash mount a tablet and load it with Torque and a music player. It's like a poor man's carputer!

Another possibility might be to turn the Cougar into an actual Android accessory. I think there was already one person who ran a Cougar with an Arduino, so it's definitely a possibility.

DJBecker 06-28-2011 08:59 PM

I've created a new project on Google Code named 'obd2-instruments'.

http://code.google.com/p/obd2-instruments/

This project contains multiple subsystem.

The Cougar add-on OBD2 code is there, unchanged from its early January snapshot.

There are more recent versions for both the AVR (e.g. Arduino hardware, and the Cougar hardware) and the STM32.

The AVR version supports multiple chips. Our first motor controller used an Arduino Mega1280 board, which soon added a MCP2515 CAN controller. At that point I rewrote our firmware to be partially compatible with the Cougar config structure in the hope that the CAN interface code would be useful for Cougar users.

I later added a driver for the CAN controller built into the AT90CAN32 series, although that is untested and there is no GPIO setup code for those chips.

The STM32 version started with our use of the STM32VLDiscovery board. We wired up a MCP2515 controller, since I had known-working code. (That was supposed to be easy, but we lost a few *days* to chip bugs that made that specific SPI port unusable.) I later added support for the '103 and '105 chips and their 'bxCAN' on-chip CAN controllers once our controller PC board was fabricated.

BTW, thank you 'Laen' at DorkbotPDX for making it easy and inexpensive to have our controller PC board made, along with all of the other random PC boards for our EV project.

Simy 07-17-2011 08:22 AM

Wow DJ Your really rocking with that. Its awesome! =)

sawickm 08-06-2011 10:54 AM

Quote:

Originally Posted by DJBecker (Post 247427)
There are more recent versions for both the AVR (e.g. Arduino hardware, and the Cougar hardware) and the STM32.

Our first motor controller used an Arduino Mega1280 board, which soon added a MCP2515 CAN controller. At that point I rewrote our firmware to be partially compatible with the Cougar config structure in the hope that the CAN interface code would be useful for Cougar users.

I later added support for the '103 and '105 chips and their 'bxCAN' on-chip CAN controllers once our controller PC board was fabricated.

Our controller PC board made, along with all of the other random PC boards for our EV project.

DJB,

Are you selling these motor controllers your developing? or are they open source EV projects?

-Mark

DJBecker 08-06-2011 12:05 PM

Quote:

Originally Posted by sawickm (Post 254609)
DJB,

Are you selling these motor controllers your developing? or are they open source EV projects?

-Mark

Everything is Open Source -- GPL for the firmware.

I've put most of the CAN related code on

obd2-instruments - Automotive CAN bus implemention including OBD2 reporting and gauge/display drivers - Google Project Hosting
and
arm-utilities - ARM processor toolchain utilies - Google Project Hosting

I haven't yet called this a release or made our circuit boards available because of a long-running problem that was only recently resolved.

Our drivetrain would make a horrible squeal when under load, such as when going uphill or accelerating. Everything was under suspicion, including oscillations caused by the board layout and the firmware. Only recently was the problem tracked down to the armature winding structure slipping on the shaft(!) under high load. We had been sold a bad motor.

That mechanical problem is now resolved, but it delayed development by months and caused me to rip many features out of the firmware. I'm working on the west coast most of the summer which makes development of the motor controller section more difficult, so I've focused on other aspects.


All times are GMT -4. The time now is 07:37 AM.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2022, vBulletin Solutions Inc.
Content Relevant URLs by vBSEO 3.5.2
All content copyright EcoModder.com