WBo2 Logging Specifications

All Tech Edge's Wideband (WBo2) units include some form of serial (either RS232, USB, or CAN) logging capability. Some include on-board logging memory for data collection without a PC (3A2/3E2, 3B1), and others don't (3A1/3E1, 2C0, 2D0/1, 2J1, etc.) but they all generate a serial data stream that can be sent to a collection device (a PC, etc.) for later analysis.

This page describes WBo2's integrated logging capability including specifications for the serial data frame used.

Note : The 2A1 controller is used as an example below but most of the information presented relates directly to version 3 units and other version 2 units including the newer version 2Y model.

Overview - Serial Logging & On-Board Memory

Serial Logging : The 2A1 WBo2 unit shown (other units are similar) has 9 sources of data it can log:

• Lambda/AFR from the sensor,
• 3 analogue 0-5 Volt channels,
• an RPM channel,
• 3 thermocouple channels.
• thermistor within the unit.

The green connector at the left end of the unit provides the physical connections to 7 of those external data inputs. A time-stamp, the device-status and the unit's internal temperature (thermistor) are also available. The collected data is formed into a serial data frame and sent out on one or more of the RS232 ports (RJ45 socket), the USB port (USB type-B socket), or the CAN bus (for models with that capability).

A number of data frame types may be produced but the default frame is decode by logging software, or one of the intelligent displays (eg. LA1, LX1, or LD02, etc.). Any time the unit is powered it generates these data frames. The power-up frame type, and the frame repeat rate, may be changed (see below), but the display must be reprogrammed if the default frame type changes.

On-Board Logging : Although data is always pumped out the serial port(s), that data can also be stored in memory on-board many WBo2 units. Logging to on-board memory (on-board logging) is controlled by the logging button on the controller (shown at left for the 3A1 unit) or the button on the display (shown at right for the LX1), Logging software can also start and stop logging as well as retrieve stored data for display/analysis later.

All newer controllers with on-board memory have 1 M byte that can store over 37,440 frames of 28 bytes each (the size of the default data frame). The default logging rate is 10 frames/second at 19,200 baud or 1,920 characters/sec so that 3,744 seconds (over 62 minutes) of data can be saved. At the maximum frame rate of around 50 frames/second the maximum storage drops to over 12 minutes. The logging rate can be reduced (by changing the delay between data frames) to enable days (or weeks) worth of data to be stored.

Earlier models had just 32 k byte of on-board memory for about 115 seconds of storage, or just less than 2 minutes (at the default logging rate of 10 frames/sec). It typically takes less than 20 seconds to download the maximum data that can be stored on the smaller 32 k byte memory units.

Logging Control - Button & Serial Commands

Two ways to control on-board logging are possible :

• The logging button on the controller itself controls start, stop, and clearing of on-board memory. Refer to the individual controller's guide for specific instructions.
  
  
• Serial commands can also do the same, but importantly, can also command the downloading of saved data. Note that intelligent displays use RS232 commands to perform the logging stop and start functions. Serial command, are described fully below.

Because there is only one button, and because we want to preserve existing data that may be stored in memory, a combination of short, medium, and long button presses commands the WBo2 on-board logger to enter one of three states - Logging OFF, Logging Enabled and Logging. Refer to diagram at right

• A Short press is from 0.2 to 1.5 seconds (blue arrows).
• A Medium press is from 1.5 to 4 seconds (yellow arrows).
• A Long press is greater than 4 seconds (green arrows).

To understand what the diagram means, here are the simple steps to using on-board logging. The normal power-up state for WBo2 is the logging OFF state :

1. From the logging OFF a short press is ignored to prevent accidentally filling memory.
2. A medium press puts the unit into the enabled to log state.
3. short presses start logging - the Red LED does a double flash (see below).
4. Another short press stops logging - multiple sessions are possible.
5. a medium (or long) press returns to the stopped state.
6. a long press from the stopped state enters the enabled state AND clears all recorded data (use before a new recording session).

Enabled
to
log

On WBo2 units with on-board logging memory, the red LED, which normally shows wideband status, flashes according to a different pattern when on-board logging is enabled.

• Logging OFF - red LED is steady (LED shows normal WB operation).
• Enabled to Log - red LED slow even flash.
• Logging - red LED faster double flash.
• Clearing Memory - red LED fast triple flash.

The status LED will flash this way even if RS232 commands (eg. from a display) enabled on-board logging.

Logging
to
Memory

It is important to differentiate between two classes of commands that control the data saved & generated by WBo2 :

• Trace Commands : control the format of data frames produced by the wideband unit (and optionally saved in on-board memory). They are described in the next section. Once saved, the format of that data cannot then be changed.
  
  
• Logging Commands : control the actual saving and restoring of data to/from the wideband unit's on-board memory. These commands (x, y & z) are described in the section following.

tn

Trace command - stop/start/one-shot logging to serial port (and to on-board memory if on-board logging enabled).
    n = f, (ie. tf) stops logging - the Auto Frame generation bit is reset to 0 - see below.
    n = 1, (ie. t1) start continuous logging - Auto Frame generation bit is set to 1.
    n = 0, (ie. t0) log just one single frame - Works only if frames are not being generated already.

s03xx

Set logging control byte to xx (hex) where xx bits are defined (default = bold) :
    b7 - Frame generation, 1 = Auto (always produced), 0 = Manual.
    b6 - Frame type, 1 = Binary, 0 = hex/ASCII.
    b5 - USR inputs, 1 = scale to 1.5 format (scaled x8 = 13 bits), 0 = raw.
    b4 - Frame mode, 1 = debug mode (ASCII/Hex), (See * note below)
                                0 = normal (binary).
    b3-0 Frame type (See * note below)
        0 : V1.5 compatible mode.
        1 : V2.0 log mode.
        1 : V2.0 calibrate mode.

s04xx

Set the logging delay between frames to xx (hex) in units of 10 Sec. Minimum value is 1, maximum is 100 (0x64).

xn

Stop/Start logging of data to on-board memory.
    n = 0, stop logging (ie. x0) - same as pressing the logging button to STOP logging.
    n = 1, start logging (ie. x1) - same as pressing the logging button to START logging.
    n = 2 (or more) same as the q command without parameters (described below).

y0040

This is a special case of the set logging pointer command and effectively clears all logging sessions and can be used after all data has been downloaded to a PC. It is equivalent to pressing the on-board logging button (from the logging OFF state) for more than 4 seconds. The status LED will do about 10 very fast flashes to indicate the action.

znn

z

Dump data from on-board memory. The first form dumps saved data from session with ID nn (assuming it is a valid session).
The second form, without parameter, dumps all of memory from the first to last valid session. Session IDs start from 00 (the first) to a maximum of 7E (the 255th session).

q

Query on-board memory status. The first form, without parameter, returns aabb where :
    aa = number of sectors of memory used.
    bb = number of logging sessions saved.
As a logging session uses at least one sector, aa will be equal or greater than bb.

qnn

The second form, with parameter nn returns the byte length of session nn. The length is a six digit hex number hhhhhh.

k

Read the memory type ID string. A 4 digit hex string is returned 
    BF80 = SST memory device of 8 Mega bits used.
    FFFF = No memory device present or readable.

xn

Stop/Start logging of data to on-board memory.
    n = 0, stop logging (ie. x0) - same as pressing the logging button to STOP logging.
    n = 1, start logging (ie. x1) - same as pressing the logging button to START logging.
    n = 2 (or more) returns the current logging pointer value as a 4 digit hex value and is useful to determine how much logging memory remains.

ywwww

Set logging pointer to wwww (eg. minimum y is 0x0040, maximum 0x7FFF). Normally the y0040 command is used to clear logged data memory in preparation for a new recording session and is equivalent to pressing the on-board logging button (from the logging OFF state) for more than 4 seconds.

z

Dump logged data. This is from y = 0x0040 to the logging pointer's current value. The logging pointer is not reset by this command.

The first 3 bytes (frame ID, & frame sequence counter) and last byte (CRC) are as described in the 1.5 frame below.

Bytes 4 & 5 count relative time in Ticks - measured in 1/100 of a second (ie. 10 mSec/tick). The count goes from 0 to 65535 (unsigned) and will overflow in just under 11 minutes (10 minutes, 55 seconds & 35 mSec) and should be sufficient to act as a timebase for most logging tasks.

Bytes 6 & 7 Originally Wblin DAC count, but in 2007 these two bytes were redefined to be Lambda-16 for all controllers except 3H1 where it is Ipx (0).

• Lambda-16 (λ-16) is fully described here and is an accurate way to represent the full range of Lambda values in a simple and controller independent way.
• Ipx (0) - For the 3H1 unit = first channel's Ipx (see below). The next 3H1 field is Ipx(1).
• WBlin DAC count is used to generate the WBlin output voltage. It's a 12 bit value (0 to 4095) that is applied to the DAC (Digital to Analogue converter) and represents the voltage in mVolts produced by the DAC. The DAC is followed by a amplifier with a gain of 1.00 (for newer version 3 units) or 1.22059(=(68+15)/68 for older version 2 units). Note that the WBlin value is looked up in the WB unit's EE PROM tables using the pump current (Ipx) as index.

Bytes 8 & 9 is the (single channel) Ipx or Normalised Pump Current. For 3H1 it's the second channel Ipx or Ipx(1) - After a calibration factor has been applied to the raw pump current, the resulting normalised pump current Ipx has a free-air value of 8192 and a zero pump current value of 4096 (which is not quite the stoich point). A value of 0 represent the richest condition that can be sensed by the WB unit (less than AFR=10).

Bytes 10 through 15 are the three 0 to 5.00 Volt user inputs U1, U2 & U3 (there's an additional user input available on version 2.0 compared to 1.5). Although these inputs are sampled just once, they are shifted to be in the range 0 to 8184 (ie. 1024 steps - 0, 8, 16 .. 8176, 8184) for version 1.5 compatibility.

Bytes 16 through 21 are the three thermocouple inputs T1, T2 & T3. The raw thermocouple voltage is amplified by a factor of 101 before sampling by the ADC at 10 bits of resolution, giving a value from 0 to 1023 (1024=5.00 Volts). For a K-type thermocouple, a sampled count of 512 corresponds to a thermocouple voltage of (512/1024)*5.00/101 = 24.75 mV and, after consulting tables, this is an uncompensated thermocouple temp of about 596 °C. A count of 1023 gives 49.46 mV or a temp of about 1217 °C. Yes. we should have normalised these to 13 bits too!

Byte 22 & 23 represent either the thermistor (models with thermocouple inputs), or the Vss count (vehicle speed sensor) for 2J1 models.

• 10 bit thermistor count can be used for cold junction compensation (CJC) to calculate each thermocouple's absolute temperature. Refer to eXcel spreadsheet thermist.xls for further information.
• Vss count is like the RPM count but counts 100 μSec periods (not 5 μSec). two successive counts are averaged.

Bytes 24 & 25 is the RPM count and has the same format as the 1.5 frame (ie. count 1 = 5 μSec) but with the additional feature of averaging two successive triggering events to cater for odd fire engines that may be triggered from the one coil.

Bytes 26 & 27 Status/Error bytes see Error Codes section below.

Bytes 1 & 2 are the fixed frame signature bytes of 0x5A, 0xA5 (ie. hex values). These value were chooses as they have alternating 0->1 bit patterns.

byte 3 is the frame sequence counter and simply counts from 0 to 255 and then repeats, and allows the receiver to keep track of possible lost data frames. All these values are included in the CRC calculation.

Bytes 4 and 5, the SVout ADC value, is compatible with the version 1.5 unit (and the 5301/LD01 displays). SVout is described in the DIY-WB 1.0/1.5 section as the Vout signal. The SVout value (ie. Vout) varies from a minimum rich value of 0x068E (=1678 decimal, so SVout is 5*1678/8192=1.02 Volts) to maximum lean (ie. free air) value of 0x199A (=6554 decimal, so SVout is 5*6554/8192=4.00 Volts). The Min and Max SVout values are clamped by the firmware.

Bytes 6 through 9 are the two 0 to 5.00 Volt User Inputs U1, U2 (U3 is not returned) On the 1.5 unit these inputs are really a 10 bit value that is sampled rapidly 8 times and summed. On the 2.0 unit there is just one 10 bit sample for each channel, but the result is shifted 3 places to be compatible with the 1.5 data. (ie. there are 1024 steps - 0, 8, 16 .. 8176, 8184) for version 1.5 compatibility.

Bytes 10 and 11, the RPM count measure how many 5 microsecond time periods are counted between successive positive pulse edges on the COIL or RPM Pulse input pins. As the frequency of the pulses increases (RPM goes up), the count goes down. For a four cylinder 4 stroke engine (that produces two spark events per revolution), at 6,000 RPM there are 100 revolutions per second and 200 spark events and therefore the COIL input will measure 5,000 microseconds between sparks, or an RPM count of 1,000 for bytes 10 and 11. Note that if the pulse rate is lower than 20 per second then the unit will "time out" and return an invalid count.

The first 3 bytes (frame ID, & frame sequence counter ) and last byte (CRC) are as described for the standard 2.x frame format.

Bytes 4 & 5 Normalised Pump Current (Ipx)

Bytes 6 & 7 is the xxxx field.

Bytes 8 & 9 is the htr_vh or heater voltage value. Heater Voltage = htr_vh / 51.2 - this is a good diagnostic aid to ensure the controller is operating correctly.

Bytes 10 & 11 is the htr_i or heater current value. Heater current = htr_i / 51.2 - this is a good diagnostic aid to ensure the controller is operating correctly.

Bytes 12 & 13 is λ-16 (Lambda-16). For further info see the λ-16 link.

Bytes 14 & 15 is a representation of the Heater Impedance.

Bytes 16 & 17 is the opstate variable.

Bytes 18 & 19 Status/Error bytes see Error Codes section below.

Byte 20 - CRC (1's comp. sum of above)