Question about 1-bit Analog-to-Digital Converter

Question

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.

Answer 1

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.

Answer 2

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.

Added

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.

Answer 3

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.

Answer 4

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.