Transfer Audio in Real Time

Other Hardware Audio
1

Hi.
Me and my classmate are working on a project and want to know your opinions on the parts we've selected. And receiving a couple of pointers from you guys would be terrific since we're not experienced in electronics.
We want to transfer audio from a microphone to somewhere around 30 meters away which will be receiving the audio and playing it on a speaker in real time.

Parts we've agreed on so far:

  1. For the tranceiver: NRF24L01 (It's a bidirectional connection since we will be sending some data back to the microcontroller with microphone)
  2. Microphone: Adafruit Electret MAX4466 (since we don't want to get into the hassle of building an amp ourselves)
    3)Arduino Pro Micro for the side that sends the audio (because we want this side to be as compact as possible. Please take this into consideration)
    4)Arduino UNO R3 on the receiving side (Size doesn't matter here)
    We haven't decided on which speaker to use that is easy to work with the Arduino and can produce a clear sound.

Things I need help from you guys are:

  1. Taking into consideration that we are not electronic freaks and are not familiar with what resistors or capacitors to use AND want the MOST COMPACT and LEAST COMPLICATED AND STRAIGHTFORWARD solution, are we using the right parts? Specially the transceiver.(There are no major obstacles blocking the two ends. Maybe a wall.)
  2. What speaker to use that is cheap and produces decent quality audio?
  3. What to do to make the delay as low as possible?
  4. Couple of pointers to make our work easier :smiley:

Thank you in advance

2

This is a complex project. A few immediate things spring to mind. These are just my opinion and you’ll probably get others that differ.

The 8 bit devices based on AVR are not particularly suited to the job you want them to do IMHO. I would look at using SAMD (MKR) boards with a built in DAC - digital to analog conversion that can be connected to the amplifier to drive the speaker.

You’ll need to check the settle time and sample frequency of the ADC on the board you choose and see if the quality is adequate. For example on AVR (Uno etc) the sample frequency is a little under 10Khz according to google - I personally wouldn’t use it other than for sensors. That is lower than the top end of the audio spectrum. If all you’re trying to do is simulate a telephone call or intercom then it is probably fine. However if you’re trying to convey high fidelity sound probably not.

Furthermore, the bit depth of the internal ADC is 10 or 12 bits from what I read On most boards. This will be enough for an intercom or telephone line simulation, but not enough for high quality sound.

On the MKR chips you can use components supporting i2s to improve quality but it also increases complexity.

I’m not familiar with that communication device so will not provide any feedback there.

3

Thank you Dave for the reply.
Since the project is only a one time thing and programming an Arduino is easier for me, I chose that MCU.
Phoneline quality is enough for us. We just want the minimum requirements to distinguish what is being said.

4

The MKR boards are Arduino genuine boards too. Their programming is near identical to the 8 bit units to the end user. For your project they may even be easier to work with given what you want to achieve, as they are several times faster.

But at the end of the day you could probably make it work with either. Good luck!

5

The range on the nRF24L01+ is not great, it shares the 2.4GHz band with WiFi and microwave ovens and
often these will interfere noticably and reduce the range, especially on the higher baudrates. I've done
something similar using the 2M baudrate and needed to use the modules with built-in PA to get usable
range. 30m is pushing it, really pushing it.

If your wall is reinforced concrete, it will be a problem due to the metalwork.

What quality audio do you want?

How much latency can you tolerate?

What about clock-recovery after packetization/reconstruction - have you thought about that?

For sending audio from a microphone, a wireless microphone is the obvious solution...

6

The range on the nRF24L01+ is not great, it shares the 2.4GHz band with WiFi and microwave ovens and
often these will interfere noticably and reduce the range, especially on the higher baudrates. I've done
something similar using the 2M baudrate and needed to use the modules with built-in PA to get usable
range. 30m is pushing it, really pushing it.

Hi Mark.
I've read that NRF24L01 has a range of 1000 meters.
In my case, it's probably around 20 meters and the wall is not reinforced.

What quality audio do you want?

Just enough to make out what's being said.

How much latency can you tolerate?

2-3 seconds tops.

What about clock-recovery after packetization/reconstruction - have you thought about that?

I don't know what you mean by this.

For sending audio from a microphone, a wireless microphone is the obvious solution...

Do you have a specific model in mind?

Eventually I will be needing an MCU on the side which has the microphone. Because, as I've said, I will send some data back from the other side that will activate a sensor.

7

MiladFaint:
Hi Mark.
I've read that NRF24L01 has a range of 1000 meters.

Read all you like, it doesn't have anything like that range for reliable high baudrate transmission.

"upto 1000m (no barrier)" means the free-space range where the signal drops into the noise at the lowest baud rate and aligned antennas. At higher baudrates its significantly less. At sensible reliability levels its significantly less, with non-perfect antenna alignment its less, inside a building its less (due to multipath), near a microwave
oven that's operating its a lot less....

True you can use error correcting codes to reduce the reliability requirement, but for audio you essentially
can't afford many corrupt packets, you just end up with horrlble noise splattering over the signal - 99.9%
packet success rate is required, or else error correcting codes (with extra latency and bandwidth
requirements and complexity)...

The version with the PA is better, with a real antenna, but even then I've not seen great range in a building with WiFi and microwave ovens... 20 feet is doable. Its worth doing some experiments with packet error rates at the higher baudrates (always less range with higher baudrates, note).

In my case, it's probably around 20 meters and the wall is not reinforced.
Just enough to make out what's being said.

Then I'd recommend considering only the PA/LNA versions with proper antennas and a careful set of tests
for error rate.

2-3 seconds tops.

Plenty of time for an ECC, which is good

I don't know what you mean by this.

You are at the receiving end, you get a stream of packets coming in, with some lost and a few
bad checksums etc. The data you shovel into a buffer, and you playback from the buffer. But
how fast should your playback clock be? That depends on the sampling clock of the transmitting system.
If you don't precisely stay locked onto that clock, eventually your buffer will drain empty, or overflow,
and the whole thing has to recover somehow...

Do you have a specific model in mind?

Absolutely not - wireless microphones are commodity items designed for this purpose available
everywhere, in many varieties for many applications. The rules for them vary by territory too.
It seems like the thing you need to solve your problem easily...

Eventually I will be needing an MCU on the side which has the microphone. Because, as I've said, I will send some data back from the other side that will activate a sensor.

That doesn't mean you have to send the audio the same way...