[help needed] CAN bus WB O2 sensor

[stefanst]

In order to increase non-timing-critical I/O capabilities, using external, cheap and simple I/O modules which communicate with the main module is an effective way of reducing the I/O demands on the central unit. In the automotive environment, the communication is usually done via CAN bus. rusefi already has the hardware capability to deal with CAN bus it seems,
I have a WB O2 sensor that reports O2 percent, sensor temp and error status via CAN bus and I would like to use it with rusefi. It's the Ecotrons ALM und uses a Bosch LSU 4.9 sensor controlled with the CJ125. http://www.ecotrons.com/products/wideband_controller_alm-board/.

The sensor uses as standard the SAE J1939 protocol at 250Kbps. The manual claims that it can be re-programmed to use a different protocol, but so far I've been unable to make that work.

Here's an example of a recorded data package:

Code: Select all

3 0FF00 01	     //page number
55 F7             //=63317   -> 20.54 %O2
FC FF             //=65532   -> 15.99 lambda (need to re-check calculation- 15.99 seems wrong)
8B AF             //=44939   -> 1053K sensor temp
1 0                 //=1,0       -> no errors, and PWM duty cycle high is 1
4C                  //=76        -> PWM duty cycle low -> PWM duty cycle is 332

Details on the protocol can be found in the manual: http://www.ecotrons.com/files/ALM%20Communication%20Protocol%20-%20CAN.pdf

[stefanst]

In order to accept CAN bus data, we would need to be able to set up the following parameters:
- CAN protocol
- Address to listen to
- Bits used for parameter
- High / Low- endian
- Mathematical conversion to readable numerical value

Suggestion: set up a list of generic variables, like CAN 00 to CAN ff. Have a setup page where we can enter address, bits and conversion for each variable.
Then in the sensor inputs we should be able to select any of the generic CAN variables.

I believe that the CAN bus hardware and protocol is even capable of using different data-protocols, albeit at the same baud-rate, at the same time. So we could be listening for different parameters utilizing different protocols and sending different values using yet another protocol if so desired.

CAN bus speed for sensor input should be sufficient for everything that doesn't use interrupt. So only the CAM/CRANK sensors would be out. Maybe MAP/AFM as well. The same is true for outputs- only fuel and spark would need to be controlled directly by the main board. Everything else could also be handled via CAN bus.