RomRaider

I haven't implemented any widebands myself yet but I don't think it would be impossible to do without having one here myself, if you'd be willing to test. If we could get a few people together to donate enough to buy one it would be easier. I've got a sensor and gauge so it looks like $159au would cover it. Do I need to buy a cable and/or harness to work with my Bosch sensor? The site isn't very user friendly.

Yeah, I'd definitely be more comfortable if you didn't buy one based on our word that we'll get it supported. Doing the work isn't a problem, finding the time is going to be the hard part. I'm interested too, though. I'm not all that happy with my LC-1.

Serial Frame Formats for 2.0 (and above) WBo2 & 1.5 Logger

This section lists a number of frame types that can be produced by (most) WBo2 controllers. It should be remembered that the frame types have evolved with the aim of backward compatibility but this has resulted in some strange values for some fields.

In the notes below, [low] and [high] byte groupings form 16 bit words (in Motorola format) with MSB first. User Input values represent voltages between 0 and 5.00 Volts and are 13 bits (in the range 0 to 8191). Thermocouple values are only 10 bits and (when the jumpers are set correctly) cover the range 0 to 0.0495 Volts (or 49.5 mV). This represents an amplification factor of 101 to the raw thermocouple values. Go here for more detail on thermocouples and thermistors.

The first 3 (bytes 1, 2 & 3) and last (CRC byte 12) bytes of all data frames are the same and allow the receiving computer to correctly synchronise with data and to check that data has not been corrupted.


The native mode for version 2 and newer units is the 2.0 mode frame format:

• 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 the inputs are sampled at 10 bit accuracy, the result is multiplied by 8 giving 1024 steps (ie. 0, 8, 16 .. 8176, 8184). This ensure version 1.5 frame compatibility and allows for future hardware having increased measurement accuracy (up to 13 bit accuracy)
• Bytes 16 through 21 are the three thermocouple inputs T1, T2 & T3. These fields are described more fully here.
• 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

2.0 Data Frame Format:
Byte - Description
1 - Frame Header byte 1 (0x5A)
2 - Frame Header byte 2 (0xA5)
3 - Frame Sequence counter
4 - Tick [high] (1 tick = 1/100 Second)
5 - Tick [low] byte
6 - λ-16 or Ipx(0), (or ADC) [high] byte
7 - λ-16 or Ipx(0), (or ADC) [low] byte
8 - Ipx(1) [high] (8192=F/A, 4096=Ipx[0])
9 - Ipx(1) [low] byte
10 - User 1 ADC [high] (V1 input)
11 - User 1 ADC [low] byte
12 - User 2 ADC [high] (V2 input)
13 - User 2 ADC [low] byte
14 - User 3 ADC [high] (V3 input)
15 - User 3 ADC [low] byte
16 - Thermocouple 1 ADC [high] (T1 Input)
17 - Thermocouple 1 ADC [low]
18 - Thermocouple 2 ADC [high] (T2 Input)
19 - Thermocouple 2 ADC [low]
20 - Thermocouple 3 ADC [high] (T3 Input)
21 - Thermocouple 3 ADC [low]
22 - Thermistor ADC or Vss count [high]
23 - Thermistor ADC or Vss count [low]
24 - RPM count [high] byte
25 - RPM count [low] bye
26 - Status/Error [high] byte
27 - Status/Error [low] byte
28 - CRC (1's comp. sum of above)

The native mode for version 1.5 units is the 1.5 mode frame format:

• 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.
• Final CRC byte 12, when added to all the other bytes in the frame, and truncated to 8 bits, should result in the value 0xFF. If not then at least one bit in the frame has been zapped and the frame's data should not be trusted. As the sequence counter constantly changes, then the CRC value will also change.

1.5 Data Frame Format:
Byte - Description
1 - Frame Header byte 1 (0x5A)
2 - Frame Header byte 2 (0xA5)
3 - Frame Sequence counter
4 - SVout ADC [high]
5 - SVout ADC [low]
6 - User 1 ADC [high] byte
7 - User 1 ADC [low] byte
8 - User 2 ADC [high] byte
9 - User 2 ADC [low] byte
10 - RPM count [high] byte
11 - RPM count [low] byte
12 - CRC (1's comp. sum of above)

Error Codes and PID Operational Status
WBo2's hardware and software contains two PIDs (Proportional, Integral & Derivative) feedback controllers for both Lambda sensing and also precise heater temperature control. Each PID samples a signal from the Lambda sensor and in turn provides an output that in turn controls that signal:

• Lambda measurement - Vs (Nernst cell sensing) for Ip (pump current) control.
• Heater temperature - Ri (internal sensor resistance) for heater PWM (Pulse Width Modulation) control.

Because both Ri and Vs are meaningless until the sensor has reached a minimum operating temperature, the two PIDs also operate in a startup mode. During startup the sensor is run in open loop mode where heater current is closely controlled to ensure the fastest warmup while remaining within the sensors operating envelope.

Feedback control relies on a measured signal being slightly different from the setpoint or target value. One measure of the PID's current status is how far away the controlled value is from this setpoint. In the case of the Vs/Ip feedback loop, the Vs setpoint is 450 mVolts, and for the Ri/PWM feedback loop the Ri setpoint is 80 ohms.

Two PID status bytes (bytes 26 and 27 of the logged data frame) are available for possible debugging. Byte 26 is for the Vs/Ip (or wideband) PID, and byte 27 is for the Heater PID. They take the general form shown below (numbers 7 to 0 are the bit positions within each byte):

• Bits 7 to 5 represents the PID code which takes the following values:
  Bit 765 - PID Operation
  000 - operating normally
  001 - Integral accumulator at lower clamp value
  010 - Integral accumulator at upper clamp value
  011 - Output control value at lower clamp
  100 - Output control value at upper clamp
• Bit 4 (E) is set when the IPID error band is exceeded (but this in itself is not an error).
• Bit 3 (0) is always zero.
• Bits 2 to 0 reflect the current PID state and is different for each byte/PID. They are described as followings:
  
  • Byte 26
    Value - Byte 26 Vs/Ip PID (wideband) State - Red and Amber LED action
    0 - null/off state, only seen at system start-up or during debugging - slow, even RED flash, AMBER off
    1 - Sense state, looking for presence of sensor. - Even RED flash and very short AMBER flashes
    2 - Cold state, heating up sensor, PIDs not yet operational - Short RED flash, AMBER shows heater on time
    3 - Warm state, PIDs operational - RED solid ON = PIDs OK or, RED blinking = PID(s) error band exceeded
    4 - Config state, used for system testing - Double RED flash.
    5 - unused - nil
    Note that the "blinking" LED in the operational state does not indicate that either of the PIDs are unlocked, per se, but that one of the PIDs is operating with its error term greater than a pre-programmed threshold value.
    
  • Byte 27
    Value - Byte 27 Heater PID State - Red and Amber LED action
    0 - Normal Operation state - slow, even RED flash, AMBER shows heater on time
    1 - Vbatt high - Even RED flash and very short AMBER flashes
    2 - Vbatt low - Even RED flash and very short AMBER flashes
    3 - Heater short
    4 - Heater open circuit (sensor not present)
    5 - FET failure
    6 - unused - nil