# What is the use Data Strobing

It seems that instead of sending a data and clock line, you send a data and strobe line. The strobe line is the data and what the clock would have been xored together.

So the real question is: Why would you do this (other than it is "cool")? Are there any practical uses of this data sending method?

• Think of a noisy environment where both data and strobe changed state
– user16222
Commented Aug 6, 2016 at 15:45

It is because the data strobe encoding scheme improves skew tolerance to just under 1 clock period vs. just under half a clock period for a traditional data + clock encoding scheme.

With data + clock, if the clock transition is half a period earlier or later, it is no longer clear which data bit belongs to which clock cycle.

With data strobe encoding, since the data line and the strobe line can never change at the same time (but one of the two always changes for each encoded bit) you can still “line up” the data and strobe even with significant clock skew. (I.e. you can recover the clock with up to - almost - one full period of skew.)

Thinking again about the example where the skew is one-half the clock period:

With data/clock, you won’t know whether a transition on the data line corresponds to the previous or subsequent rising edge on the clock line.

With data/strobe, there can never be two transitions for the same bit. So in the case of skew equal to one-half the period, you will have some cycles where data and skew both change, and others where neither changes. You then shift the waveform to correct this. The only cases where it will be unclear how to correct will be if the data line never changes or if it always changes. But in those cases it doesn’t matter since you are encoding either all 0s or all 1s or alternating 0s and 1s and you can tell which by just looking at the state of the data line.

In practice, you don’t need to “tell” how to shift the waveform. You just extract the clock via XOR - the duty cycle will not be 50%, but the encoded bits will always line up with the (halved) clock periods.

I’m sorry I can’t add timing diagrams, which would certainly help. Hopefully this is still useful.

Figure 1. Data strobing. Source: data strobing.

I have never heard of this system before either but I can see that it does solve a problem with asynchronous data transmission.

Figure 2. RS232 waveform. Note that the start bit is required to trigger the receiver to begin a receive data cycle. Source: Wikipedia Commons.

In any asynchronous system - RS232 being the most widely used - it is necessary to have the transmitter and receivers set to the same baud rate and to send a start bit to tell the receiver that data is coming and to start its timing cycle. Effectively, once the receiver sees the start bit it waits 1.5 cycles (so that it's reading in the centre of the mark or space) and performs a read. This is repeated 7 or 8 times (depending on the protocol) with a one-cycle delay between reads. Hopefully the clock tolerances are tight enough that the reads are still away from the pulse edges by the end of the 7 or 8 bits. Crystal oscillators have made this a minor problem but Telex machines, for example, were mechanical and to minimise timing errors used 5-bit data transmission. See Baudot code.

From the Data Strobing article:

These have the property that either Data or Strobe changes its logical value in one clock cycle, but never both. This allows for easy clock recovery with a good jitter tolerance by XORing the two signal line values.

There is an equivalent way to specify the relationship between Data and Strobe. For even-numbered Data bits, Strobe is the opposite of Data. For odd-numbered Data bits, Strobe is the same as Data. From this definition it is more obvious that the XOR of Data and Strobe will yield a clock signal. Also, it specifies the simplest means of generating the Strobe signal for a given Data stream.

This means that, for example, if a string of zeros or ones is transmitted on the data line that the strobe line will change state on each bit. The advantage is that very long strings of data bits can be transmitted without the need for start and stop bits while ensuring accurate timing at the far end.

• Isn't this the same as Manchester encoding? Commented Aug 6, 2016 at 16:06
• Couldn't you have the same advantage if you simply use a normal clock with rs232? Commented Aug 6, 2016 at 16:07
• @DwayneReid No manchester encoding transforms the data....this encoding transforms the clock Commented Aug 6, 2016 at 16:08
• @Darth: That sounds like arguing over the use of words. The clock AND data are combined, either way. Have you examined IEEE 802.3 Manchester encoding? Looks like an XOR to me.
– jonk
Commented Aug 6, 2016 at 18:02
• Manchester Encoding "encodes" the clock into the data so a SINGLE dataline is needed (at the expense of the twice the baud). This still needs 2 lines so it isn't comparable. This is more comparable with GRAYCODE which is used when sequential increment of data is permitted (encoders etc). That is why I stated in my comment error detection.
– user16222
Commented Aug 6, 2016 at 19:27