CAN interface

[techie66]

SN65HVD230 - 3.3 V CAN Transceiver with Standby Mode
MCP2515 - CAN controller

SPI connection, linux driver for mcp2515

[techie66]

feature-can has basic support for CAN. Several updates to the development branch have been merged in as well. Those changes include logging ignition advance from a TCIP-4.
Next steps are to broaden CAN support to be more general, eventually supporting a wide range of the J1939 protocol as the standard for communication.
Happy testing!

[kurt-k3po]

Not able to log lambda with Ignitech WB-2 via CAN

tried to log lambda value over CAN from Ignitech WB-2 but not able to get a value in the log file.
CAN communication works on Raspbian level. Checked this with candump utility.

I just add 'lambda' to enginedatlogger.conf and restart service.
output-file-format = "time,systemvoltage,rpm,speed,map_kpa,lambda"

Value in logfile always shows 0.00 for lambda. Other values from Ignitech TCIP-4 are changing.

Is there another config I have to adjust? Any idea?

[techie66]

EngineDataLogger/src/cmdline.ggo

Line 27 in d56e100

option "can" - "CAN device to bind to. CAN disabled if not set." string typestr="device" optional

EngineDataLogger/src/cmdline.ggo

Line 39 in d56e100

option "can-id-wb2" - "CAN id of Ignitech WB-2 packets. WB-2 packets disabled if not set" string typestr="0xXXX" dependon="can" optional

These two options need to be given.

[kurt-k3po]

set this in 'enginedatalogger.conf' as well:

can=can0
can-id-wb2=0x322

no success - lambda values not logged in logfile. candump can0 displays lambda values.
Is 'can0' a valid device name in config file?

[techie66]

I have pushed a new commit that adds some debugging output. Please pull the updates and try adding verbose = DEBUG to enginedatalogger.conf
Give that a try and paste the output here.
Please include the output from journalctl -u enginedatalogger as that will include all the debugging messages. You can also run enginedatalogger from the commandline and pass your enginedatalogger.conf and then paste the terminal output.

edit: can0 would be a valid device as long as you have manually brought up the device already.

[techie66]

Bugfix: 7b52a68
Pull the latest and rebuild/test.
libISP2 has a default uninitialized value that fools enginedatalogger into overwriting the lambda value read from the WB-2.
It's not a proper fix, but please test it. If the problem is solved, I will make a better fix.

[kurt-k3po]

Ok. I pulled the latest and build it.
At first, a value for lambda were logged. But I think, it's not the lambda value but a 100th of the AFR. See the last row of the log in picture I added as example.

then, after a reboot, lambda value not get logged. CAN interface is up and running. I think, this have to do with starting enginedatalogger via systemd. Have to play with that. Strange is, that even a systemctl stop engindatalogger and start again doesn't help. After several stops and starts, logging of lambda value was ok again.
Sometimes, even values from TCIP4 weren't logged after stop and start enginedatalogger again.

This is the output of journalctl -u enginedatalogger on a working lambda logging phase:

Jun 08 14:51:27 k3po-pi enginedatalogger[742]: Read Ignitech, RPM: 0, Battery: 14032
Jun 08 14:51:27 k3po-pi enginedatalogger[742]: Select something
Jun 08 14:51:27 k3po-pi enginedatalogger[742]: Select read CAN
Jun 08 14:51:27 k3po-pi enginedatalogger[742]: CAN:Read 16 bytes
Jun 08 14:51:27 k3po-pi enginedatalogger[742]: Ignitech WB-2: 10000
Jun 08 14:51:27 k3po-pi enginedatalogger[742]: Not Running. 00000000

When logging of lambda value ist not working, there is some ioctl device not ready message at the beginning.

[techie66]

I will have to take another look at the WB-2 documentation to make sure I'm pulling the lambda not afr. For the issues of not working consistently, it's because the service is getting started too early in the boot process, and right now the code only tries once at startup to open the device. Both are issues that I have good solutions for. Give me a couple days to push some fixes.Thanks for continuing to test this.

[kurt-k3po]

I had a look in the WB2 documentation.
Protocol:
1) Ignitech - optional ID notification (decimal), adjustable speed. Notification structure: 0.1
BYTE - resulting AFR x 10 ; 2.3 BYTE - resulting . x 100 ; 4.5 BYTE – voltage on
OUT1[mV] ; 6.7 BYTE – voltage on OUT2[mV]. Little endian notification.

That means 2.3 Byte is lambda, 0.1 Byte is AFR

Thank you for your support.

[techie66]

Apologies for taking so long to get back with this. I have just pushed changes that calculate lambda on the correct bytes, and merged changes from the development branch that alter how the system is started by systemd.

Of Note: please do a make uninstall and sudo systemctl daemon-reload before pulling the changes and trying it out. The systemd unit file enginedatalogger.path has been removed and needs to be cleared from your system. If you forget or run into problems, delete the file /lib/systemd/system/enginedatalogger.path if it exists and run sudo systemctl daemon-reload

If you continue to have problems with lambda not getting logged or the TCIP-4 not logging anything, please set verbose = DEBUG in your enginedatalogger.conf and paste the output from journalctl -u enginedatalogger

[kurt-k3po]

payed attention to your Note and pulled latest version from branch feature-can.

A start enginedatalogger from commandline works.
Now, lambda value get logged, but value is 10th to low.
Example: real lambda = 1.45, logged value ist 0.14

[kurt-k3po]

Found a typo in /lib/systemd/system/enginedatalogger.service which prevents start via systemd.
I file a bug.

[kurt-k3po]

Found a typo in main.cpp which results in incorrect lambda value logging.
I will file a bug