Nice coding. Has it got a name?

I have a self-clocking line/signaling code in mind. I don’t know what it’s called, and I’m having a rough time finding out.

The other night, I was trying to come up with a self-clocking signal that is simpler than Manchester codes to decode. What I came up with amounted to the above image. I felt like a genius. A signal that carries both clock and data, with all the clocks encoded in the rising edges and all the data a fixed time forward from the clocks. All one needs to re-separate them is a monostable (with a Schmitt trigger if the signal is dirty). No state information

Two seconds later, I thought, hmm, this is somehow too simple. Someone’s probably come up with it before. Oh, well. Since I’m a novice and came up with it independently, at least it must not be patentable…

Here’s a rundown of the encoding:

• Every bit is guaranteed to be made up of exactly two transitions; a rising edge and a falling edge.
• Each of these has “hold time” requirements depending on the hardware in use. The signal needs to be high for a minimum amount of time, t_holdH, before switching to low for an edge to be detected, and vice versa, t_holdL.
• The value of each bit is determined to be the value of the signal t_read after the rising edge.
• Equivalently, the value of each bit is determined by the width of each pulse, with a narrow pulse (narrower than t_read) indicating 0 and a wide pulse (wider than t_read) indicating 1.
• Nominally, t_read is the pulse width of a monostable triggered by the rising edge; actual implementation may vary.
• A 0 is read if the falling edge happens before t_min, generally as soon as possible after the rising edge (after first allowing t_holdH).
• A 1 is read if the falling edge happens after t_max.
  
• Timing:
• The range t_min to t_max is defined by the transmitter as the range of valid values for t_read at the receiver.
• t_min > t_holdH + t_holdL. A larger value allows the transmitter more time to encode a 0.
• t_max > t_min. A smaller value allows higher transfer speeds while a larger value allows higher tolerances on the receiver.
• If the last bit transmitted was 0, the rise for the next bit can start immediately since t_holdL has already passed. The minimum duration is t_max.
• If the last bit transmitted was 1, the signal is driven low after t_max and held t_holdL before starting the next bit. The minimum duration is t_max + t_holdL.
• An arbitrarily long time is allowed between the end of one bit and the start of another as required by the application.

What I found out later is that a variation of this encoding is used in 1-Wire, a bus protocol for small, low-power devices. Unfortunately, as far as I can find, they don’t actually name this scheme. Argh!

If you know a name for this scheme, I’d love to hear an answer.

In the meantime, I’ve developed a couple of possibilities for a receiver, but haven’t tested any of them. I was thinking that this would be a fun protocol for devices that receive flashing messages from your computer monitor, much in the fashion of the Blinky POV but with only one sensor instead of two (since the clock and data lines are no longer separate). Through a bit of logic abuse, I’ve devised (but not tested) a decoder circuit that uses one 74HC14 and a few passives. I do truly wonder whether it would work…

---

Edit: A couple of notes (for myself) on the monostable in this circuit. It’s based on an older design that uses NAND gates from a CD4011 as its inverters. The notes for that version indicate that the output pulse width, in seconds, is 0.69(R₁C₁ + R₂C₂), or 2 × 0.69 × R₁C₁ if R₁ = R₂ and C₁ = C₂. I suspect that the coefficient (0.69 here) might be different with the newer part, but the rest is probably unchanged. (Experimentation is likely to follow.) Also, while there are easier monostables in the HC series (see 74HC221) as well as more well-known monostables in general (like the 555 monostable configuration), Schmitt inverters are (ab)used here because the application already needs one or two of them, leaving four or five left over without increasing the chip count. Plus, I already have a bunch of them and they can be had for as little as a quarter each, making this an interesting decoding option that doesn’t require a microcontroller.