# Sampling voice and send it over cable, which A-D converter is best for it? [closed]

I'm learning electronics on my free time from zero. So I'm sorry if this question is stupid.

I want to make a system to transfer voice from one floor of my house to another, each side will have a microphone and an speaker, and both will be connected by a cable.

The first problem I have encounter is how to convert the voice to digital. My idea is to connect an opamp to the microphone and then an AD converter to make the signal digital, but this is where I don't know where to start. Searching a little, I have found the MCP3201 very cheap on an online store and reading the specs it looks like it is what I need, but I really have no idea if I'm missing something. Is that thing really useful for what I want? Is there some better converters out there for it?

I know that I can send the voice as an analog signal directly through the cable but I want to make it digital as a challenge (and in case I want to add more terminals in the future, control it with an arduino, or whatever).

Anyone can help me? Thanks

## closed as too broad by brhans, RoyC, Dmitry Grigoryev, PeterJ, Voltage SpikeMar 23 '18 at 15:45

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

• You might consider doing it wirelessly, perhaps with bluetooth or Wifi. Just as challenging, and no holes to drill. There's lots of online application info about the low cost Espressif ESP286 and ESP32 based modules. – crj11 Mar 21 '18 at 18:26
• A simple microcontroller with both the A/D converter and serial port built in is probably the neatest solution and you'll learn a lot in the process. – Finbarr Mar 21 '18 at 18:29
• You are likely to need a lot more than an ADC. IMHO that isn't the place to start. It is likely that you'll need a way to send the data as a serial stream of bits, receive it, decode it and convert back to analogue. I'd start with a microcontroller development board. Maybe an Arduino which has lots of helpful examples, free software, documentation and community. It has a built in ADC, and serial interface, and with a bit of ingenuity can do an okay-ish job of DAC. Or an ARM mbed development board (ST make some under $10), or as crj11 says an ESP32 which has ADC, DAC, WiFi, and wired serial. – gbulmer Mar 21 '18 at 18:32 • If you want to do it over a single (coaxial) cable, look a S/PDIF. Otherwise you are likely to need 4 or so signals and a ground (better, a ground for each). Beware that you will need to consider transmission line effects. – Chris Stratton Mar 21 '18 at 18:43 ## 3 Answers You are likely to need a lot more functionality than an ADC. IMHO choosing an ADC isn't a very useful place to start. EDIT3: Until you understand the problem adequately, choosing a separate ADC or DAC is likely irrelevant. IMHO it is fretting over details, which may never matter, before there is enough experience and understanding of the overall problem. Think about the overall problem. Break it into pieces. Start with the pieces that both contribute progress and are easiest to test and debug. In your problem, that is the digital to analogue output, and not analogue to digital input. I've made a SWAG about the end-to-end problem, and considering your I want to make it digital as a challenge (and in case I want to add more terminals in the future, control it with an arduino, or whatever) it is likely that it'll need: • microphone into an ADC • a way to encode and send the sound-data, probably as a serial stream of bits (to avoid funky or expensive cabling between floors of your house), • receive the serial stream of sound-data bits • decode the sound-data and • convert back to analogue and drive a speaker. If you have access to a ready made analogue audio amplifier and speaker, you could start with the DAC problem. (The amplifier and speakers should be cheap as things can go wrong) I'd start with an off-the-shelf microcontroller development board. Many microcontrollers have all the digital functionality (ADC, DAC communications), but will need analogue microphone input and speaker output. One with a DAC should be able to drive an audio amp, maybe with a few resistors or potentiometer to set volume. Once this is tested and done, you can move on. Summary: Solve the analogue output problem first. EDIT2: Further, I might not start at the microphone end. A problem with starting with the microphone and ADC is how to test it. It is unlikely to work first time. So there needs to be a way to extract the ADC data, and then some way to check the data is okay. An easy way to check the data would be to convert it back to analogue and play it out of a speaker, or convert to analogue and display it, along with the original signal, on an oscilloscope. The point is, getting the output working before starting on the ADC gives a way to test the ADC input. Building pieces in a different order makes testing harder and IMHO less fun. With a PC, and a spreadsheet or the ability to program, sample data for the output could be generated and stored in a program as data (an initialised array containing values for eg a sine wave, or even voice eg. from wikipedia). Summary: build the pieces in an order which is easy to test without needing all of the parts to work. Maybe an Arduino? It has lots of helpful examples with code, free, Open Source development software, documentation and community. It has a built in ADC, and serial interface, and with a bit of ingenuity can do an okay-ish job of DAC. EDIT An Arduino UNO is not ideal for audio, but could just about do voice. It's built-in ADC is only 9615 samples/second, which isn't quick enough for reasonable quality music. It's ADC is a rate comparable to telephone land-line (8k sps). AFAIK, land-line's audio is filtered to be 200Hz-3kHz-ish and is okay for voice (I assume the telephone's 8-bit 'Mu-law' encoding may be comparable to the Arduino's linear 10-bit sample quality). EDIT2: An Arduino M0 might be a better option for a wired system. It has a 12-bit ADC at 350ksps, and 10-bit 350ksps Digital-to-Analog Converter (DAC). If you have software development experience, another option is an ARM mbed development board (ST make some under$10). Some of them have much better ADC than an Arduino, and real DAC, as well as multiple serial ports if you want to extend things.

EDIT:
Some of the low-cost ST mbed boards have MCU's capable of 500x faster sampling (5msps) than an Arduino, and at 12 bits. That extra bandwidth would enable higher quality and simpler electronics to filter the microphone input signal.

As @crj11 says an ESP32 is a plausible option. It has ADC, DAC, WiFi, and multiple (wired) serial ports. It also has a 'plug-in' for the Arduino environment, and some examples to get you started.

If you shop around on one of the popular (Chinese) shopping sites, you might find ESP32 development boards which have a microphone and speaker amplifier built in.

EDIT:
AFAIK the ESP32 ADC is about 50k sps, so usefully better than the Arduino. However, some of the ESP32 development boards have external ADC chips, and even audio codecs, though they might be a lot more development effort to use, and restrict your choices of development board.

As @crj11 commented an advantage of using ESP32/ESP8266 would be doing it without wires. Avoiding the cost and hassle of wiring might be the 'killer' feature. With WiFi one end of the system might be an existing computer, which may be interesting and even fun.

EDIT3:
You could probably get an ADC and a DAC which uses the same basic protocol. The one you identified (MCP3201) can use SPI, and there are DACs which use SPI too.

However SPI has a 'master' and a 'slave' [see Role note below], and ADCs and DACs are usually 'slaves', not 'masters', so the 'master' functionality missing.

The 'master' decides when to access the 'slave', and the 'master' generates (at least) clock signals to drive the slave. Common external ADC and DAC devices are 'slaves'. So they can't simply be wired 'back-to-back'. Something else needs to act as a 'master'.

Further, there may be buffering in the ADC or DAC which needs to be triggered by extra signals before or after the right number of clock signals. So a microcontroller is likely in the system just to drive the signals for an external ADC and DAC.

Also, not connecting the ADC directly to the DAC offers valuable flexibility.

First, the ADC and DAC don't need to match in bit-width, bit order, or detailed implementation of the protocol. So there are a lot more options, and they could be chosen based on cost, functionality, convenience, etc. unconstrained by needing to be directly connected electrically.

More usefully, testing the DAC and analogue output is independent of testing the ADC and analogue input.

Further the ADC and DAC don't need to run at the same data rate. So some of the task of filtering the input signal might be made easier by running the ADC at a different sample rate than the DAC.

Summary: there will probably be a microcontroller acting as a controller and intermediary even if there is an external ADC and DAC.

[Role]: SPI master/slave roles can change between transfer transactions, ie. any device might sometimes be the master and sometimes the slave. However for each transaction one device is the master and the other the slave.

• An Arduino is typically a bad choice for audio problems, especially sampling-based ones. – Chris Stratton Mar 21 '18 at 18:51
• @ChrisStratton - I mostly agree. However this appears to be voice (and AFAIK my landline phone is 8k samples/second), and the OP seems interested in using an Arduino anyway. However, I'll update my answer to highlight that. – gbulmer Mar 21 '18 at 18:56
• Yep, that are more or less my milestones, I'm right now at the second one. I was thinking on an arduino but the ones you say seems like much better options, the thing is I want one without ADC built in. That's the part I want to do "manually", the microcontroller would be the third milestone, that receives the stream of bits, but I need something to generate that stream, thats why I thought on the stand alone ADC, but didn't know which model. Anyway I will probably make it with the ESP32, it looks really great, and then try to move forward to separate both parts. Thanks – god Mar 21 '18 at 19:38
• @god - I don't want to come across as pushing you in a direction which is uncomfortable, or damages your interest in the project. Let me ask, how you are going to test your ADC and microphone? It yields some data bits. So you are going to need something to control it, and get the data out. Then you're either going to convert it back to analogue so you can hear it, or see it on an oscilloscope. IMHO, thinking carefully about how you're going to test this is a much stronger driver than choosing an ADC because the ADC is almost useless without a way to get at and use its data. An MCU does that. – gbulmer Mar 21 '18 at 19:58
• @gbulmer - Don't worry maybe I'm not explaining myself right, English is not my mother tongue. Your solution is great, and is more or less what I was thinking, but I also wanted to use the ADC to output the bits on a cable, and then being able to connect that cable to a mcu to read it, or to a DAC to play it on a speaker, or to an osciloscope to see the bit stream (99% of the time it will be connected to a mcu, but I wanted to have all the options to satisfy my curiosity), thats why I asked about the model I need. – god Mar 21 '18 at 20:11

I know that I can send the voice as an analog signal directly through the cable ...

Since you're "starting from zero", I would recommend doing this as a first project. This will teach you a lot about power supplies, handling microphone and speaker signals, and some of the logistical issues associated with the overall application.

You can always "upgrade" to digital later, as a follow-on project, reusing much of what you've already got, including the cable. That will bring a whole additional set of issues, by which time, you'll have more experience to deal with them.

• I'm planning on doing that first, and then move to digital, but I buy components from China, so I need to buy everything one month in advance. :) – god Mar 21 '18 at 19:39

You want to build your own car, and you're starting by deciding what size pistons will go into the engine.

There is a lot more to this project than just the A/D. The fact that this is what you're asking about says that you're a bit over your head. Trying to do all this is a stretch for a first project.

A simpler, but very edjucational project would be just to get just two intercom stations working using analog signals. Use CAT5 cable so that you can re-purpose the wires if you ever end up going digital later. The advantage of analog is that is is easier, and will teach some fundamental electronics that will be a good foundation for anything else you do. Getting the signal to noise ratio down to acceptable levels won't be easy if you're new to this, and you'll learn a lot along the way.

If someone really wanted to do this digitally to allow expansion to multiple stations, here's my immediate knee-jerk reaction to a high level architecture:

Don't obsess over the pistons. Get a whole ready-made engine. In other words, get a microcontroller with a suitable A/D built in. Most microcontroller A/Ds will be suitable. You don't need HiFi bandwidth or concert level signal to noise ratio.

The real design considerations of the project are not how to convert the audio signal to digital - the A/D does that for you - but how to handle the resulting digital data. What protocol and format should it be transmitted in? How can the system be designed to easily allow new stations to be added? These are the real issues.

If I was doing this as a professional product, I'd probably use UDP over ethernet as the digital transport means. However, the firmware for that is rather heavy weight and not very beginner friendly.

I'd look at using a CAN bus running at 1 Mbit/s. Let's see how the numbers work out. I'm doing this on the fly as I'm writing this answer, so maybe they won't.

Figure half the bus bandwidth will be spent on protocol overhead and the like. In reality it should be less than that, but let's see where the 500 kbit/s actual data bandwidth gets us. Voice works well enough band-limited to 3 kHz and 8 bits/sample, especially with some clever non-linear allocation of the 256 possible levels. That is sometimes known as companding, which is another reason for having a microcontroller. It may sound complicated, but the actual implementation is just a lookup table at each end.

For 3 kHz bandwidth, Nyquist says we have to sample at least at 6 kHz rate. Even a low end DSP can run enough of a sync filter to allow you to get reasonably close. 8 kHz sample rate really should be doable.

Let's be pessimistic and see what we get with 8 bit samples at 10 kHz rate. That's 80 kbit/s overall data rate. The bus can handle 500 kbit/s, so that means this system can handle up to 6 simultaneous voice streams. That sounds plenty good enough for a home brew project.

To keep the logic simple, I'd probably have each station always sampling its sound and sending it over the bus. CAN allows for separate out of band IDs with each packet, so the ID would be used to identify the source station. All stations would receive the data from all other stations all the time. The local user choice would only tell each station what to ignore and what to play to the user.

Electrically, I'd devote one of the four twisted pair to the CAN lines. You could use the other three to each carry power and ground. By using a relatively high DC voltage, you can push a reasonable amount of power across the cable. You can have one 48 V power supply in the basement or somewhere out of the way, and all the stations buck-convert that down to whatever voltages they want. Using a high voltage also minimizes the ground return currents, which minimize the ground offset between nodes.

There are plenty of microcontrollers with fast enough A/Ds, CAN, and enough compute power to do the high speed sampling, sinc filter, and decimation to 10 kHz. I'd start with a Microchip dsPIC EP series.

• I understand your point, one of my reasons for this question was that I don't know which components exists, just the ones I found on ebay when I search for ADC, that's why I asked for that model, to see if it'd be useful. As for the rest of your answer, tbh, I haven't think so far yet, but you've give some good ideas and a lot to think about. Anyway I think I need to do some reading before I get there, but looks like a lot of fun. Right now all I wanted was to get a digital signal and I think I will finally use the esp32, as the dspic goes really out of my budget. – god Mar 21 '18 at 22:05
• @god: Worrying about the cost of the microcontroller makes no sense. It will be a small fraction of the overall system cost whether it is $2 or$4. You are again fixating on details when you should be thinking about the bigger picture. Without the larger context figured out, trying to decide details is pointless because you don't yet know the requirements. – Olin Lathrop Mar 22 '18 at 10:52