RusEFI Support

As of SDC Version 2.00, the application supports receiving data from RusEFI via the DBC Support capability. That’s CANBus broadcast of data from RusEFI to SDC.

This section describes what you need to set up to enable this data source, and which features are supported within SDC. As RusEFI was developed independently of Speeduino, and Speeduino was the original target for SDC, some features have limited capabilities due to missing data. So some of the features developed specifically for SDC have limited functionality when the source of data is RusEFI.

Enabling support for RusEFI

SDC settings

To enable support for RusEFI in SDC, you need to do the following:

  • Copy the file rusEFI_CAN_verbose.dbc to the SD card. I suggest using the root folder initially (this is c:\ within SDC) The file you use must match the version of RusEFI firmware you are using. SDC Distributions from 2.00 onwards contain this file by default with its original name. If you upgraded from an earlier release, the file was included as part of the upgrade.
  • Create a [dbc1] section in the ini file and set the dbcname inifile setting to the name of the DBC file you are using.
  • Set dbcnamespace=rusefi in the same section. This namespaces all RusEFI attributes so that, for example, the RPM from RusEFI becomes rusefi.RPM
  • In the [canbus] section of the ini file, you must set the bus speed to match the speed you have configured in TunerStudio in your RusEFI tune. The default speed for SDC is 1Mbit (speed=1000) but in reality this is complete overkill for RusEFI and you can use a lower speed without penalty.
  • Change the datamode to dbccanbus

Optionally, you can add DBC Mappings to populate internal attributes with RusEFI values (where possible). You will probably only need to do this if you are migrating from Speeduino to RusEFI and want to try and retain your existing pageset without changing attribute references.

See below for information on enabling rusEFI’s Haltech broadcast concurrently.

SDC Licensing

You will need an SDC License which has the ‘extras’ support enabled. This contains support for CANBus.

SDC Hardware

You will need an SDC I/O hat for your Raspberry Pi (or an SDC Pro 7 or other pre-built hardware). The I/O hat in these products contains the relevant CANBus hardware to allow SDC to receive data.

TunerStudio settings

In your RusEFI tune, to receive only the RusEFI broadcast, configure it as follows:

The rusEFI Haltech broadcast contains some additional data that is not present in the standard rusEFI CANBus broadcast. You can optionally enable both the Haltech broadcast and the RusEFI broadcast at the same time, and if you set up a [dbc2] section in the ini file for the Haltech DBC file (included with the SDC 2.00 distribution as c:\haltech.dbc) then SDC will process both broadcasts concurrently. There is an example section in the default ini file shipped with SDC but this will not be present in your ini file if you upgraded from an earlier version.

These are the important settings. Anything not mentioned does not matter:

  • Can Dash Type: None (or Haltech if you want to receive that at the same time)
  • CAN write enabled: True
  • Enable rusEFI CAN broadcast: True
  • Enable extended rusEFI CAN broadcast: False
  • rusEFI CAN data base address: 512 (this value can be different but you must supply a DBC file that matches this setting)
  • Primary CAN bitrate - your choice but configure SDC at the same speed. Note that some speeds are not supported by both devices so you must pick one that both have available. If you use different speeds, it just won’t work.

If you enable CAN Read, then some CANBus messages that SDC generates (such as time updates) will be received by RusEFI, although it may not know what to do with them. You can change some of the CANBus Ids that SDC uses here.

RusEFI Hardware

You will need to refer to your RusEFI board as to what is precisely needed. The STM32 has a CANBus peripheral on board but you may also need a CANBus transceiver to connect to it, if your RusEFI board does not already have one.

CANBus termination

The SDC I/O hat has a termination resistor on board if you need it for one end of the bus. The other end of the bus will need to be terminated appropriately through whatever means you have available.

Cabling

Finally, you will need a twisted pair cable for CAN High and CAN Low connections between the devices.

Notes on Application Features

When RusEFI is the datasource, some values that SDC needs are not available. Here are a few of the key ones and some ways in which they can be handled:

Autotune

  • By default, there is no current AFR value broadcast from RusEFI. Instead RusEFI broadcasts a lambda value and this needs to be converted to AFR within SDC. This can be done using a script (a page script for example). In DBC mode, with the rusEFI data namespaced, you can update the internal attribute called o2 with the UpdateInternalAttribute() script function. Only after ensuring that the o2 value is populated, will the Autotune feature work properly.
  • As well as needing the o2 internal attribute populated, RusEFI does not broadcast the current VE value, so SDC will use the VE Table it loads during boot to lookup the current VE based on RPM and Load when running Autotune. It does this if the current VE internal attribute is zero, which is always the case for rusEFI.
  • The Decel Fuel Cut value is not available over the default RusEFI broadcast. SDC can enable Pulse Width=0 as a proxy for Decel Fuel Cut using the dfcotype and pulsewidthattribute inifile settings

Autotune is pretty experimental anyway, but it is active in the demo pages for RusEFI. It only makes suggestions for the VE map and does not in any way try to adjust it. And it works out those suggestions by an averaging algorithm when the engine is in steady state, so it isn’t particularly sophisticated and needs a reasonably well tuned map to work with in the first place. Bascially, it’s not a big deal if it doesn’t work with your datasource.

Map displays do work fully though.

Vehicle Speeds

SDC has an internal attribute called speedmph which is the speed in miles per hour. It also has a setting called speedsource in the general inifile section and another called speedsourceunits. These settings are used to populate both speedmph and speedkph with appropriate values based on the value of the speed source atribute and the units it is delivered in.

For features that require a vehicle speed, speedmph is always used and therefore must be populated. To achieve this, you can do one of two things:

Either:

Or

  • Create a DBC mapping from rusefi.vehiclespeed to either speedmph or speedkph (depending upon which units RusEFI is using)

You should not do both of these, as one will keep overwriting the other, although if both values are the same you won’t actually notice it. But best to just pick one and stick with it.

Map displays for Advance, VE, and AFR Target

The SDC tools application has been updated to be able to read a rusEFI tune and generate the relevant engine maps files for SDC. You may need to alter the factor on the MapGauge to ensure the cell values are displayed properly. Typically, this involves setting the DivideBy to 10 to get decimal places on the display.

See the demo rusEFI pageset for this; the maps have been set up properly for it.

Note that not all features of rusEFI engine maps are supported; only the primary VE, AFR and AFR Target maps are supported (same as Speeduino). So features such as per-cylinder trims are ignored.