# Question about 1-bit Analog-to-Digital Converter

I am working on a research project, and for a part of it I have to turn an analog signal into a digital one. Now, electronics is not my forte so I don't know what I am doing and am feeling around in the dark. I have been doing research all of yesterday and today to answer the specific way that I want to do this conversion and I think I have an answer, but I don't know what is best for my project.

Device 1 outputs an analog signal. This analog signal will stay at voltage low until it pulses for some time t to high. Then it will return to voltage low. This analog signal will always be either at voltage low or high.

Device 2 wants to read this signal. However, it can only receive signals with a UART protocol at its internal baud rate. The way that Device 2 will understand this signal is by having some Interpreter to parse the information for it at regular intervals into bits b0 and b1 representing "high at this moment" and "low at this moment".

Interpreter is what I want. Interpreter should check the voltage outputted by Device 1 once every 100 nanoseconds (ideally once every 2 nanoseconds). If the voltage is high then Interpreter should record a signal b1. If the voltage is low then Interpreter should records a signal b0. It should send these bits to Device 2 packaged in a UART protocol so that Device 2 can interpret the bits. Device 2 will have software to process the bits from there.

I don't know what device to use for Interpreter. I know that anything that I code would be too slow, so I was hoping to use some device that could do it faster. At first, I was trying to find a low-bit ADC with a high speed in the >500 MSPS range, but I think that a comparator would work as well. However, despite my research I haven't been able to settle on a product because I don't know what part would work best for my system. The only fast ADCs are expensive and I don't know if a comparator is fast enough for me or will output with a UART protocol. Or, I don't know if there is a part that I could purchase that does the job better than either of them. So if anyone has any good suggestions I will do research on them.

Thank you.

EDIT: Didn't know that TTL wasn't a protocol, and I realized that I wanted a UART protocol. Replaced TTL with UART in the post.

EDIT: If I have a sampling rate of 10MHz it will be sufficient, but a sampling rate of 500MHz is desired if it is affordable.

EDIT: If you vote my question down, please let me know why you did. I am learning and I want constructive feedback.

EDIT: Rewrote the post for clarity and included images below to clarify what I am asking.

1. Line 1 above shows an example of what could be outputted by Device 1. Notice that the pulses come at random times but are all of length t (as best as I could draw)
2. Line 2 above shows what the Interpreter may do before packaging start and stop bits. Notice that every voltage lines up with the blue lines. I use the blue lines to show the intervals.
3. Line 3 above shows what the Interpreter should output to Device 2 after including start/stop bits.
• Comparator will probably do if there are only two values. How fast is this signal? – pjc50 Apr 15 '15 at 15:49
• You'll need to provide some real numbers before anyone can even try to make any suggestions. What are the two voltages, the b1 pulse duration, and typical time between pulses? – Peter Bennett Apr 15 '15 at 15:49
• TTL isn't a communications protocol like UART; it's a specification for standard logic levels. Specifically, a "TTL-compatible" signal is simply a low (0V) or high (5V) signal with low output impedance ($<500\Omega$), as is typical with most digital signals. Conversion from your arbitrary logic levels to TTL levels will be done by virtually any comparator on the market. – Zulu Apr 15 '15 at 15:50
• (well, <0.8V and >2.0V, but who's counting) – Ignacio Vazquez-Abrams Apr 15 '15 at 15:51
• I still don't get where you think this A/D comes in. The analog signal is already apparently encoded in the pulses. It seems like you need to decode this pulse stream, convert it to a number, then send it on via UART. What's the A/D for? Also, you're not going to send 500 M readings per second over a ordinary UART. Not even remotely close. – Olin Lathrop Apr 15 '15 at 16:04

I think I might understand what you're trying to do. You want to:

1. Sample a pulse train at regular (fast) intervals that has two possible values, and they don't really correspond to any standard voltages for "normal" digital inputs.
2. Report this data to another system.

If that's correct, here's my suggested circuit:

simulate this circuit – Schematic created using CircuitLab

and my suggested theory of operation:

1. Understand #2 of this list and setup the chip to do it with minimal instruction count and maximal instruction rate. (you might need to use assembly on a high-spec chip, which is not often done)
2. Set up a timer interrupt in software to fire at your desired sample rate. When the interrupt fires:
1. Shift a byte variable up (left) by 1.
2. Read the Digital Input into the low bit of that variable. (empty because of #1)
3. Decrement a counter variable.
4. If the counter is now zero, move the byte (accumulator) variable into the UART Send register (whatever your chip calls it) and set the counter back to 8. The UART will send the byte all by itself while you capture the next 8 samples.

Some notes:

• Some chips have the comparator built-in. (the triangle thingy by itself) This can reduce the parts count if it's fast enough. Either way, read the datasheet for the comparator that you intend to use.
• The pulse in must be within the comparator's power supply. I showed 5V here because it's fairly common, but it could be anything allowed by the datasheet.
• The comparator's output will use the entire supply available to it, unless it's an open-collector type (force-low, allow-high), in which case you can add a resistor between Out and your digital supply.
• The UART will probably require 10 bits per byte of data - 1 Start, 8 Data, 1 Stop - so its baud rate will actually be faster than your sample rate. Make sure that works on both ends.
• If the baud rate can't be that fast, you might look at some form of data compression. Perhaps send a report only on each event (not continuously) and include the time since the previous event? That would require a completely different theory of operation, and probably be much easier to implement also.

You have grossly changed the question, so I'm writing a whole new answer. However, while the new version does clear up some things, it still leaves a lot of questions unanswered (despite having been specifically asked by several people), and continues to exhibit misconceptions. The easiest way to go thru this is to respond to individual pieces of your question:

Device 1 outputs an analog signal.

No, it clearly doesn't.

This analog signal will stay at voltage low until it pulses for some time t to high. Then it will return to voltage low. This analog signal will always be either at voltage low or high.

Then it's not a analog signal. It clearly has only two possible states. You said before that T is fixed. This is a sequence of pulses.

The important question, which you have been asked repeatedly, is what is the meaning of this signal. The voltage levels are fixed, the pulse high time is fixed, so information can only be encoded in the pulse low time. You said previously the timing of these pulses are "random" (your word). If that is true, this pulse sequence carries no information at all, in which case this whole execise is pointless. I expect you meant that the pulse times are unpredictable, which is very different from random. That still leaves the question of what data is this pulse sequence carrying, and how exactly is it encoded?

Device 2 wants to read this signal. However, it can only receive signals with a UART protocol at its internal baud rate.

OK, so what is this baud rate? Note that this will inherently limit the bandwidth of the information that device 2 can receive. The fastest common UART speed is 115.2 kBaud, but it can be faster. However, anything over 1 Mbit/s is very unlikely.

Interpreter is what I want.

No, this interpreter is what you imagine as a solution. What you want is apparently to transmit the information encoded in the pulse stream over a UART to device 2. I'll skip the rest of your question since it's pointless detail about your imagined solution instead of the actual problem.

Now that the actual problem is somewhat more clear, what we need to know is also more clear. To come up with something that goes between the pulse stream and the UART, we need to know:

1. What kind of data is being encoded in this pulse stream? Is it a single scalar value? It would help to know what it physically represents.

2. What is the fixed pulse high time?

3. What is the minimum possible pulse low time? This together with #2 also tells us the maximum pulse frequency.

4. How exactly is the data value encoded in this pulse stream?

5. What is the UART baud rate that device 2 expects?

6. What are the high and low voltage levels of the pulse signal?

I expect clear and specific answers to each of these questions, else I'm outta here. These are all asked for a reason. They all need to be answered whether you understand why they are asked or not. And no, you don't get to "interpret" these questions and ask what you think I want to know or what you'd rather tell me.

You have now given real specs on the incoming pulse stream. It is coming from a photon detector, and each pulse represents a photon. The signal is TTL digital, with low ≤ 800 mV, and high ≥ 3.5 V. Each pulse lasts 30 ns, and there is at least 50 ns between consecutive pulses. This means the minimum pulse period is 80 ns, and the maximum pulse frequency 12.5 MHz.

The task is to somehow communicate the information in this pulse stream to a second device over a UART connection. The UART baud rate is not known, so for now I'll assume the fastest common rate of 115.2 kBaud.

Electrically receiving the pulse signal is easy since anything with a TTL compatible input will work directly. This could be, for example, any 74HCTxxx gate running at 5 V. Ordinary CMOS inputs may not work, depending on what their minimum guaranteed logic high level is. The datasheet of whatever is receiving this signal needs to be checked, but finding something compatible will not be a problem. Other than chosing the right digital input to receive this signal, nothing special needs to be done.

To design the thing between the pulse stream and the UART, we need to know what information from the pulse stream is relevant. Do you only care about the average light level? If so, what is the highest frequency of the light level you care about? Or, do you need to know when individual pulses occur? That would be much harder. The basic problem is that there is much more information in the pulse stream than you can possibly communicate over the UART connection. Therefore, some data reduction must be performed.

Let's take a first pass look at the magnitude of the data reduction. Suppose you only needed to know photon counts per time interval. Each UART byte takes 10 bit times at 115.2 kBaud, so 87 µs. At the maximum pulse rate of 12.5 MHz, there can be up to 1085 pulses per UART byte. Since a byte can express 0-255, you could scale the number of pulses observed every byte time by .235. That would give you the light level resolved to roughly 4 photons sampled at 11.5 kHz. The maximum light level frequency is therefore 5.7 kHz. Is that good enough?

A possible trick is to transfer the error from the previous byte to the next byte. That gives you the long term count down to single photons at the expense of some noise on each reading.

Another possibility is to send two bytes each count interval. Now you can have up to 2170 counts per sample interval, but that can be directly transmitted in two bytes. You get full resolution, but the maximum frequency goes down to 2.9 kHz. With a little cleverness you can pack two readings into 3 bytes to get full resolution at a higher frequency, although with more latency.

There are a lot of possible data reduction schemes. It is impossible to pick one without knowing what aspect of the data you care about.

• Preface: I am answering all of these questions to the best of my knowledge. If I answer a question with a misconception, I likely do not know that I have a misconception. I really want an answer to my problem so I am not telling you anything that will impede my goal. 1) The data physically represents photons being collected. When a photon is sensed by my sensor, a pulse of voltage is emitted from Device 1. 2) I don't know the fixed pulse high time. I can find that out. 3) The minimum possible pulse low time is indefinite. continued... – Paul Terwilliger Apr 15 '15 at 18:28
• 4) The pulse represents a photon being collected, so the value of high is not important. The photon is the data and it is recorded as a pulse. 5) I don't know the baud rate, but I can find out. I know from my supervisor that we need a part in the range that I asked, 10MHz-500MHz. – Paul Terwilliger Apr 15 '15 at 18:30
• Hmm, are you counting photons in a preset period of time? Because that would make the problem a LOT easier. Then you could find a dedicated counter chip that can take a clock of that speed and read/reset it at much slower intervals. – AaronD Apr 15 '15 at 18:35
• Note: even though I called it a clock, and the datasheet probably will also, it by no means has to be regular. All it does is count rising or falling edges, depending on the specific chip. – AaronD Apr 15 '15 at 18:39
• We were starting to get somewhere when you finally explained that each pulses represents a event. However, as I warned you, you do not get to decide what is important and what is not. I restate the last paragraph in my answer herein by reference. – Olin Lathrop Apr 15 '15 at 18:39

There is too much confusion to realistically clear up here, so just a few point:

1. TTL is not a protocol. It is a logic family, although reference to TTL can sometimes mean using the voltage levels of that logic family, whether TTL logic is actually used or not.

2. Apparently you have a sequence of pulses, but it's not clear how the analog level is encoded into these pulse. You say the voltage levels and pulse high time is fixed, so is the analog level encoded by the time between pulses? You have to know this encoding if you want to recover the analog level. Perhaps the average DC level of these pulses is the analog level?

3. "8 bit, no parity, 1 stop" refers to a UART protocol, which makes no sense at all in relation to your pulse train. I can't begin to guess what you mean by referring to this.

4. Designing a A/D system that runs at 500 M samples/second is not trivial. There are too many issues to get into here. At your current level of electronics knowledge, the answer is to get someone that knows how to do this to do it for you. This is not a rooky project.

5. You talk of having this pulse train already, so how this A/D is supposed to fit into the system is a complete mystery.

• 1. I want a UART protocol. I just edited my original post. 2. The pulses are not set to any internal clock. They come at random times. They will last for a set time though. 3. Answered. 4. Thank you. 5. I don't understand this comment/question – Paul Terwilliger Apr 15 '15 at 15:59
• @PaulTerwilliger: So then how do you discriminate a 0? – Ignacio Vazquez-Abrams Apr 15 '15 at 16:06
• @Paul: #5 - Since the pulses apparently already encode the analog signal, what is the A/D for? And again, how exactly is the analog signal encoded into this stream of pulses? – Olin Lathrop Apr 15 '15 at 16:11
• My best guess was to use an A/D, but if it is not needed then I should do without one. My question was open-ended: if I need an A/D then I will purchase one but if not what else should I do/use? This is why I also mentioned a comparator. As well, the other commenter mentioned using a MCU – Paul Terwilliger Apr 15 '15 at 16:14
• @Paul: Use a A/D where, to do what? – Olin Lathrop Apr 15 '15 at 16:15

I would use a MCU with a hardware timer tuned to the bitrate of the input signal, along with some sort of level conversion (schmitt trigger buffer, etc) to shift the signal to ground and Vcc of the MCU.

The timer will be used to sample the signal just after a 1 transition should have occurred. An interrupt can be used to synchronize the timer initially, after which it may be able to be free running based on the characteristics of the input signal itself.

Once 8 bits have been sampled, the MCU's UART will be used to transmit the result upstream.

• Can this method sample as fast as I want it to? My minimum is 10Mhz, but I would ideally like to sample at a rate of 500Mhz – Paul Terwilliger Apr 15 '15 at 17:34
• @PaulTerwilliger: 500MHz is going to be very difficult with cheap, easy-to-use parts. Even 10MHz will be a challenge with typical CPU's around 1MHz-100MHz for direct hardware interfacing kind of stuff. The top end of that range may seem okay, until you realize that most of those chips require several clocks per instruction (variable), and several instructions to read and process a digital input, let alone an analog one. Throw in some more instructions on the reporting side, and you may have blown your budget, even on a fast chip. Nevertheless, it could be possible, given some cleverness. – AaronD Apr 15 '15 at 17:56
• Even if it is expensive I want to know my options. Do you have a recommendation @AaronD ? – Paul Terwilliger Apr 15 '15 at 18:02
• Something from XMOS might be able to keep up, but I can't give a hard guarantee of that. – Ignacio Vazquez-Abrams Apr 15 '15 at 18:22