Another question involving a monostable.

Scheme: I have these three different sources of irregular
low-repetition-rate pulses, no two occurring at the same
time, and I want to send them over a long 2-core shielded
cable. I suppose they could be sent as serial data, but my
knowledge of MCUs is limited and dedicated encoder-decoder
pair ICs introduce uncertainty periods of tens of
milliseconds. Such periods can be tolerated but undesireable
if they can be avoided.

I thought I'd found a clever solution by encoding the
signals to 01, 10 and 11 signals and decoding them at the
receiving end with a 2-to-4 line decoder like the CD4555.
Then it occurred to me that slight differences in wire
length and cable and stray capacitances could introduce
different time delays between the two lines and cause
decoding errors. The 11 signal in particular could be
mistaken for a momentary 01 or 10 pulse. Subsequent
controlled stages will not be adversely affected by an
erronous sub-millisecond 01 or 10 pulse at the rising edge
of the 11 signal, but the falling edge could cause problems.

Proposed solution: Have the decoded 11 pulse at the receiver
trigger a monostable. The 11 pulse is a reset signal and
will override the effect of any spurious 01 or 10 signal
during the mono period..

Have I missed anything?

 

how about voltage levels.

signal the third state by a half-voltage on both wires,
that way timing irregularities give a phantom signal.

 

Maybe send the signal with a gray code, that is, just avoid the 01 to 10
transition.

 

Offhand:

- AC modulate (using a variety of encodings). A simple example would be
keyed tones, one oscillator and one decoder for each signal.

- Make a simple DAC: combine the pulses, with binary weighted resistors,
into a summing amp. Receive with comparators. As miso said, Gray code
helps here.

- Do it in serial, but make it a real hack job, way fewer transistors than
a uC. Example: send a long pulse to reset the receiver (use a timer to
measure the pulse width). Then send a series of pulses, which are gated
into a counter. Counter increments to whatever bit pattern is required
(you might use a "one-hot" shift register since your signals are
one-at-a-time). When counting is done, another long pulse (of opposite
polarity or different time length) can be used to clock a second register,
buffering the data, or to enable the outputs for the pulse.

Regular (asynchronous) serial can be used, too, but you need more accurate
timing. Over a couple of bits, it's probably not a problem to use an RC
oscillator for the job. In which case, you could use the start bit as an
enable to start the timer, which keeps ticking for a certain number of
cycles (an analog counter can be made with a couple of transistors, by the
way, so you don't have to wire up a counter and gates to do it).

Note these will work with a single conductor (and ground) transmission
line, and can be suitable for any combination of signal lines, not just
one-at-a-time (you can usually squeeze them together with an N-to-2^N
decoder, as you noted).

Tim

 

Suppose your encoding will fail Jim. A 08 AND gates output only goes high
when both inputs are high. But this will never happen as according to the
OPs question the pulses are separated in time.

petrus bitbyter

 

message

That's right.

 

Thanks for your interest, everyone and sorry about the late
reply. Different time zones and some social obligations.

Jim, I'm afraid petrus is right. The AND gates will never
change state with my signals.

Jasen, Tim & miso, each of your ideas has its own merit. But
my application can tolerate certain glitches as explained
earlier and I want to keep things as simple as possible.
Here's a simplified diagram of the scheme I had in mind. Do
you see anything wrong with it?
http://img248.imageshack.us/img248/1835/323encodedecode.png

 

"Jim Thompson"

Now I get it. I thought V5,V2,V3 directly represented my
three signal sources and that the rest of the circuit was to
encode and decode them. I also see now that the "Receive
signal & decode side" is not a 2-to-3 line decoder, but a
technique to clean up the 2-line signals.

Thanks. I'll keep it in mind for use if my simpler (and
'dirtier') scheme fails to work properly.

 

One thing I forgot to mention before is that pulse lengths
are not important for the application, hence there's no need
to rebuild the 11 (reset) pulse to its original length. Only
the rising edges are relevant and delays of a few msecs can
be tolerated.

 

only that it's a CMOS part and as all the inputs are via diode it will
will want pull-downs on the inputs.

As cmos inputs are fragile you may want to add other protection too,
eg clamp diodes and a series resistor


(+) --|<-+ :
| |
in -------+--[100K]--| CD4555
| |
+->|-+ :
| |
| [10k]
| |
+----+
|

 

Of course, yes. I omitted those in the diagram to avoid
clutter. I probably shouldn't have done that. Here's a more
detailed diagram -
http://img819.imageshack.us/img819/6811/323encodedecode2.png

Not shown before is V4 which has the same effect as V3, but
from a different source. The output of the 4538 is now taken
from Q-.

 

Drawing error. The 'hot' ends of R103 and R104 should go to
the inputs instead of the right-hand sides of R101 an R102
respectively.

 

Think you care too much about the different delay times in the wires. As the
are in the same cable and have the same length, differences in delay time is
a matter of nanoseconds. Even if you get glitches, they can easily be
suppressed. in the schematic below I replaced your diode-resistor ORs with
ordinary ones. Just for my own ease I also left out the protecting
components.

__
W1--------| | ___ |\
__ |\ |& |o--|___|--+---------| >O--P'2
P2-----|>=| W2--| >O--|__| 330 | |/
|1 |-W1 |/ 4012 --- 40106
P1--+--|__| 40106 ---
| 4071 __ |10n
| W1--------| | ___ | |\
| __ |& |o--|___|--)--+------| >O--P'1
+--|>=| W2--------|__| 330 | | |/
|1 |-W2 4012 | | 40106
P3-----|__| 40106 | ---
4071 |\ __ | ---
W1--| >O--| | ___ | |10n |\
|/ |& |o--|___|--)--)---+--| >O--P'3
W2--------|__| 330 | | | |/
4012 | | --- 40106
| | ---
| | |10n
| | |
----+--+---+--------
created by Andy´s ASCII-Circuit v1.24.140803 Beta www.tech-chat.de

On the receiver you find a simple decoder. The CD4555 will also do. Both the
wires and the decoder may insert some delay that can cause some glitches. As
said before, these delays are in the nanoseconds region and they will be
suppressed by the low pass filter.

Now about driving the lines (wires). It depends on the lines type and length
what power you need. If your pulses are powerfull enough, your
diode-resistor ORs will do. If not, the 4071 may do... Or not. These types
of CMOS components are not designed for driving lines, so you may need to
add line drivers.

On the receiving side, things are worse. These CMOS divices have high input
impedances and are prone to all kinds of disturbances, especially in an
(electrical) noisy environment. These may easily cause false pulses and even
damage the devices. The shielding will help a lot and the low pass filter
will kill the short ones but it may not be enough so line receivers may need
to be added. No need to say that short wires are less sensitive but if they
are that short, a third wire will be much easier to implement. With long
wires you should not be astonished if these CMOS circuits do not survive the
next thunderstorm.

Be aware that most line drivers/receivers invert the signal.

petrus bitbyter

 

This is the one I like, only I'd feed the three digital signals to
the address pins of a CD4051 (8-to-1 analog mux) with a
8-tap resistor string on the eight inputs, and feed the output
through the wire. That's the DAC.

At receive end, a small ADC gives out (as its three most significant
bits) the state of the three inputs. To keep noise margin high, you'd want
the resistor string to have taps at 4.5 for binary 100, 2.5 for
binary 010, and 1.5 for binary 001, and the full range of the ADC would be 8.

This would be a great place to use a little five-bit flash ADC.

The non-overlap of the multiple pulses is a don't-care condition.

 

Perhaps. With just this much description of the problem i would most
likely try some thing like this:

Use the signals to generate touch tone dialing signals with a standard IC
and detect them at the other end with decoding SW running on a small micro
at the other end. This works well so long as there is not an interfering
combination at the same time. Otherwise you could just use the same 3
frequencies from just the high band. Might simplify the detection
algorithm a bit. Of course you could use discrete detectors as well.

?-)

 

Hmmm. All CMOS inputs need to be terminated high or low, unterminated
inputs can oscillate or may turn on both n and p channels at the same time
and over dissipate the device or cause localized heating fractures.

?-)

 

What's wrong with that?

Jamie

 

Yes, everything, none of that will work reliably.

 

Bah-humbug. You don't need no old CA3306s, common cheap SAR type ADC will
get the job done in less than a dozen microseconds. Way fast enough for
millisecond tolerant systems.

?-)

 

Both versions work reasonably well, but provide subtly different
properties. It is worthwhile studying the difference.