[info] AFR via CAN bus

[stefanst]

The main reason why I had little time to play with my shiny new rusefi board just yet is because I was working on another pet project that turned out to be much more involved than anticipated: Reading AFRs via CAN bus on my Megasquirt.

If you're interested, you can find my thread on the subject on Miataturbo.net: http://www.miataturbo.net/megasquirt-18/%24130-bosch-4-9-sensor-can-bus-wb-87232/

It's a cheap WB controller ($130 for controller and sensor) that can send data via CAN bus: http://www.ecotrons.com/products/wideband_controller_alm-board/

It's just a PC Board that can be included in the ECU case and gets hooked up to a Bosch WB sensor. Communication with the ECU is via CAN bus which eliminates the error sources of going digital -> analog -> analog -> digital as we do with the current breed of commonly available widebands. I know that most of them also offer standard serial (RS232 or TTL level) communication, but most aftermarket controllers can't read that directly and in any case, I think that for vehicle sensors and controls CAN bus is the way to go at this point in time.

I have so far managed to read the values from the WB controller with an Arduino with CAN bus shield and I can also send values to Megasquirt from the same Arduino. The current problem is that the WB controller and the MS use different protocols, but the controller setup can can be changed by software.

In any case: I would love to see implementation of reading sensor data via CAN bus on the rusefi at some point. This is not something of high priority, but since I'm working on this problem right now, I thought I should mention it.

[AndreyB]

https://sourceforge.net/p/rusefi/tickets/270/

The current problem is that the WB controller and the MS use different protocols, but the controller setup can can be changed by software.

What do you mean different protocols exactly? Are they using different CAN message lengths?

Our current CAN support is pretty minimal but reading from CAN as long as the message length is right should be really easy. https://svn.code.sf.net/p/rusefi/code/trunk/firmware/hw_layer/can_hw.cpp

[stefanst]

Megasquirt uses standard 11 bit frames and 500kbps and the ALM WB uses extended 29 bit frames and 250kbps. Since the ALM WB claims to offer an easy way to change the setup, I will attempt to do this tonight.

What protocol/bitrate is implemented in rusefi at the moment?

[AndreyB]

It has been a while since I've played with it but looks like 11bit 500kbps

Code: Select all

/*
 * 500KBaud
 * automatic wakeup
 * automatic recover from abort mode
 * See section 22.7.7 on the STM32 reference manual.
 *
 * speed = 42000000 / (BRP + 1) / (1 + TS1 + 1 + TS2 + 1)
 * 42000000 / 7 / 12 = 500000
 *
 * 29 bit would be CAN_TI0R_EXID (?) but we do not mention it here
 * CAN_TI0R_STID "Standard Identifier or Extended Identifier"? not mentioned as well
 */
static const CANConfig canConfig = {
CAN_MCR_ABOM | CAN_MCR_AWUM | CAN_MCR_TXFP,
CAN_BTR_SJW(0) | CAN_BTR_TS2(1) | CAN_BTR_TS1(8) | CAN_BTR_BRP(6) };

[kb1gtt]

I seem to recall the ecotrons guy uses a CJ125 for the core chip. To get CAN does it use a CJ125 into a micro? You might still be doing the analog conversion thing. Do you have a coms spec for your board?

[stefanst]

The only chip that looks like it would be dealing with reading the wideband is a Bosch 30617.
It's very hard to read the chip names- the manufacturer just completely covered the board in lacquer....

[AndreyB]

Bosch 30617

it is the one

[stefanst]

I don't really know, what this means, but from the tone of what you're writing I infer that this is not a good thing....

[kb1gtt]

I'm very certain that the intent was not be be negative. I believe he was trying to show a picture of the CJ125, which would allow you to compare against your lacquered chip, as well he was showing these chips are available on the china market. See red underline on picture. I see this CJ125 china chip notes 30617. Does the below look like the chip you have in hand?

1351830015.jpg (120.14 KiB) Viewed 10439 times

[kb1gtt]

If it's CJ125, here are some links about that chip. It might help in identifying the CAN parts vs the WO2 parts of this board. If it's CJ1215, there would need to be a separate MCU with CAN capabilities.

http://www.bosch-semiconductors.de/media/ubk_semiconductors/pdf_1/einzeldownloads/engine_management/CJ125_Product_Info.pdf

I seem to recall a more detailed datasheet for the CJ125 exists, but it's hard to find, and was listed under a bosh part number or something like that. I can't seem to put my hands on it now.

[AndreyB]

CJ125 is out best shot for having an on-board AFR but I suspect that this would never happen simply because too much of a commitment. See also http://rusefi.com/forum/viewtopic.php?f=4&t=456

[stefanst]

This is indeed the chip on the board. If I had the ability to read, I could also have found that info right there on their webpage :
http://www.ecotrons.com/wp-content/uploads/2015/09/ALM-B-system-new.jpg
The board does also have an additional MCU. From the description again:
Main-Processor
• CPU: FreeScale 16-bit micro-processor S12P (auto industry rated)
• Speed: 32MHz
• Memory: 128k Flash, 6k Ram, 4k Data

As I said, it seems to work and broadcast correct data on the CAN bus. It costs $59 plus the actual sensor and is certainly small enough to fit within the footprint of frankenso. This may be a viable option for a daughterboard until somebody goes through the trouble to create an on-board solution.
It can also be configured (from factory) to use analog out or SPI communication. But if the rusefi team decides to use one of those two, I have another $60 electronic brick sitting in my parts bin

[kb1gtt]

I like the CAN option, as it allows you to place the board closer to the sensor. AKA less electrical noise getting into things. Can is currently very young, and could be formed such that it allows the use of this board.