Can we make a Wireless Intercom with XMega and a wireless module?

Go To Last Post
18 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was thinking of making a full duplex wireless intercom with two XMegas inside each transceiver as well as two wireless modules like this:

http://robokits.co.in/wireless-solutions/wireless-serial-modem/rfm73-2.4ghz-rf-transreceiver?cPath=7&

Then use the ADC to convert the analog sound signal to digital and transmit it over one wireless module and use DAC to process the incoming signals from another wireless module that receives the sound from the other intercom.

Is this even possible?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is this even possible?

Most people have a device in their pocket right now that does exactly this.

 

However, the difference between a mobile phone and an AVR though is (a) the CPU is astronomically faster and (b) it probably has dedicated G.729 encode/decode. So what you can achieve on an AVR isn't going to be quite the same. You might be able to compress the data a little bit (ADPCM perhaps?) but there won't be time for much more in terms of compression/decompression in real-time. So you will probably just be sending the raw audio samples "as is" which means the amount of quality/frequency range you can pass is likely to be bandwidth limited.

 

But, sure, something like "telephone quality" (0..4kHz, 8bit, mono) should be possible but don't expect to be passing CD quality.

 

What range and what radio frequency band are you looking at using?

 

Of course there is another option cheeky:

 

https://charlespaolino.files.wordpress.com/2010/10/tin-can-1.jpg

 

EDIT: Sorry I missed the link - so at 250/1000/2000 kbps you should have no real limit on bandwidth over the RF - it'll be the actual sampling and feeding (the reconstruction) of the data by the AVR that will be the ultimate bandwidth limit.

 

Last Edited: Thu. May 28, 2015 - 12:50 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As always, the first thing is to look at the specifications of those modules, and think whether they are appropriate:

 

  • Variable payload length from 1 to 32bytes

So you're going to have to think quite carefully about how you get a nice, continuous audio stream from 32-byte packets...

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 full duplex wireless intercom

I wouldn't worry to o much about a continuous audio stream, its an intercom.

If the receiver buffers one packet while playing one packet, and is always one packet behind, two humans speaking to each other aren't going to know the difference.

 

Full duplex would be my bigger concern.

 

Preventing audio feedback could be an issue.

 

Even if the audio is now two packets "behind", for some audio that might still trigger a feedback squeal.

Probably not an issue for human speech in a quiet environment, but potentially a big issue if there is music play8ing in the background, etc.

 

There are several approaches to dealing with this, but they aren't trivial.

 

Having a Push-To-Talk switch at each end, and essentially making it a simplex system would be the easy approach to solving this issue.

 

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There is a fundamental problem, here. That is merging the analog world with the digital. There is also a second problem: full duplex.

 

1) What sample rate do you need? Lets assume that you need 3KHz upper bandwidth limit. Sample rate needs to be more than 2X this, maybe 4X or more. This suggests a sample rate of at least 12KS/s.

 

2) Most Mega/Tiny ADC will do 15KS/s

 

3) Converting binary ADC values into a simple packet format could go pretty quickly at the cost of more bits per second. The problem, here, is that those radios want packets, not PCM, which is one of the formats commonly used for digital audio. One of  the issues you HAVE to deal with is lost packets. There needs to be some sort of error recover or retransmission system. That could significantly lower the throughput.

 

4) I do not think that genuine full-duplex is possible with those radios. It SHOULD be able to switch fast enough to emulate FDX on a half-duplex system. But, it COULD be tight.

 

5) Going from data "stream" back to audio may require significant buffering at the receive end. This gets mixed up with the error recovery process to increase processing time.

 

6) Electrical to acoustic conversion may be another bottleneck. If you have a true DAC driving an audio amp, then its simple. If you imagine that you can get by with PWM, then you have to deal with PWM repetition frequencies that push the clock rate of an ordinary AVR. 

 

All in all, it could be a very challenging project. It MIGHT work.  But you would be right at the "hairy edge" of what works and what does not. It would take some careful design, before you write even a line of code, considering all of the limiting factors of the system. And you will need something more elaborate than a simple packet protocol because packets WILL be lost.

 

Just noticed that this is in the XMega forum. Use of XMega increases your odds substantially. Not only do you have faster clock rates (and faster ADC) and higher through-put, but you also have devices available with enough RAM to do significant buffering. XMega does NOT take away the need for a robust, error-correcting packet protocol.

 

Jim 

 

 

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Don't see why not. Should work with counterfeit NRF24L01+ modules. Should be able to exchange data fast enough.

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For a general purpose human voice intercom I don't think you need to worry about data errors.

The system just ignores them.

It re-synch's the Rx buffer on the next good packet, and initiates buffer playback when the buffer is full.

 

If the intercom is at the boarder of range, or in an electrically noisy environment, one has scratchy audio, worsening to the point of no signal.

Within the limits of the system, the audio may be very acceptable.

 

Mission critical: No. 

There are many "better" methods when reliability is required.

 

JC

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I look at at the RF module link.

 

Perhaps not the best module for this project...

 

This module does auto packet retransmission, which, for human voice, non-critical application, is probably not what you want.

You just ignore lost / error containing data packets.

The auto re-transmission will add a variable time delay to the audio, and as Jim mentioned above, will increase the required Rx buffer size.

 

It does have a selectable "channel", (frequency).

That's a must if one still wants to try full duplex.

You need two modules, ideally, in each unit, with a  pair on Channel #1 and a pain on Channel #2, with these channels as far apart from each other as possible.

If you try to do real time, time division multiplexing for Tx and Rx using one module in each unit of the intercom, then one has to work out the time domain packet synchronization issue.

That, also, is a known and solvable problem, but generally non-trivial.

 

Finally, especially with cheap transceivers, the receiver may well be "de-sensitized" by a nearby transmitter on a close frequency.

Using two transceivers, mounted as far apart as possible, and using two external antennas, also mount a bit apart from each other, would likely help this situation.

 

As I mentioned in my first post, switching to simplex operation would solve many, many, design issues.

 

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm confused - who ever used an intercom that is full duplex? Usually there's a PTT (Push To Talk) so it's half duplex? Apart from having an argument on a mobile phone where you both shout at the other party without listening why would a human conversation ever really need to be anything but half duplex?

http://intertalk-sales.com/image/cache/data/wired%20intercom/WC121-new%20photo-500x500.jpg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Send a packet -- turn the link around -- receive a packet -- turn the link around

 

Should be able to do this fast enough for audio, even with a retransmit thrown in here and there. For full duplex, feedback might be more of a headache than data.

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I did something similar to this several years ago. With cautions, it can work fine. Technologies have evolved, so there may be a more cost effective way to do this now. When I did this, Atmel was heavily partnered with H&D Wireless, [http://www.hd-wireless.se/], so I used their WiFi module controlled by an AVR32UC3A0512. This was fairly cost effective at the time, but I chose this path mostly because it was easy to implement. I used an external audio A/D and D/A, about $1, but there may also be better integrated choices now. Some things to think about:

  1. Going over a relatively short distance, where any interfering devices may be well managed, means you will have plenty of bandwidth. Need not use fancy speech compression. The simpler schemes are actually more robust to packet errors. You do need to decide how “mission-critical” your device needs to be, and what is allowed when no wireless bandwidth is available.
  2. They stream audio over WiFi all the time. It works great. The real issue is delay; streaming music (or even video) works easily because the stream is buffered over hundreds of milliseconds, and re-assembled. This may or may not be a problem with simplex (Push to Talk), but is a killer for full-duplex. There are ways to implement full-duplex, (or fake-full-duplex using voice activated PTT), but this can be tricky. Echo is bad.
  3. My project was simplex, but even so I wanted to hold the delay below 50mS for other reasons. The big difficulty at the time was that H&D did not include in their API any way to optimize or disable 802.11 MAC layer retries. Single packet errors backed up the retry queue for 500mS or so.  It would have been better just to drop lost packets.
  4. Whatever the MAC re-try strategy, you will need a way to cleanly start and stop the audio stream  (speaker muting control), and to fill in audio holes without bursts of noise. These packet loss mitigation strategies do not need to be highly complex in an “intercom,” but can really muck up your software design if not considered up-front.
  5. The wireless chip sets usually supply most of the Phy and MAC layers, with some of the associated control and security. They may or may not implement parts of the higher layer IP/UDP/TCP/VoIP stack. For a point-to-point intercom, with both ends on the same IP subnet, your upper layer stack need not be comprehensive. The LwIP stack in the AVR Framework is overkill, but is likely a good place to start. Depending on your particular needs, you may be able to cut more corners. But try not to break the network!

Good luck with your project. These may not be the exact solutions you are looking for, but I hope my comments at least help some.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks a million times, everyone. Your replies have been extremely helpful.

I now have second thoughts that this isn't a project as easy as I thought. A good enough compromise for full duplex, as you said, is receive a packet, turn it around, send a packet and so on. This eliminates the need for two RF modules. I'm curious to know why full duplex causes echo. Could you please explain?

Are cellphones and cordless phones switching half duplex?

Last Edited: Sat. May 30, 2015 - 09:30 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I hacked a demo together for a client a couple of months ago.  Two units, each with a 328P running at 8 MHz, driving an nRF24L01+, 8-bit ADC input, 8-bit PWM output.  PTT.  Worked just fine.  Never went anywhere, client found another solution.

 

So yes, definitely doable.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Talking about two different things.

 

Bi-directional pulsing of the RF signal is how WiFi actually works. There is plenty of data capacity to support two voice audio streams.

 

The problem comes in with the total audio delay of the audio paths: near-microphone-->packetization-->WiFi Tx delays-->WiFi Rx delays (if needing retries)-->re-assembly buffer-->far-speaker-->acoustic path between far-speaker and far-microphone--> packetization-->WiFi Tx delays-->WiFi Rx delays (if needing retries)-->re-assembly buffer-->near-speaker. Longer delay makes echoes more difficult to control.

 

Consumer digital cordless phones (such as those using DECT) keep this delay very short. Cell networks have fairly short delays, but also use echo cancellation digital signal processing. Speaker conference phones, even using plain-old-telephone services, need quite a lot of digital signal processing.

 

PTT is easy; you could implement this without a lot of effort. But full-duplex is an attractive feature. I’d *guess* it is possible to make full-duplex audio work with WiFi. Products such as Skype work quite nicely after-all. There are many opportunities for invention and tradeoff, and perhaps your suggestion of using xmega processors and inexpensive wireless modules could lead to an attractive implementation. I do not want to discourage you.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

MRetzer wrote:
Talking about two different things.
Not really.  Although the OP asked about full-duplex, there isn't anything about the demo PTT app I slapped together that would preclude a full-duplex implementation.  nRF24L01+ allows 2 Mbps.  With the maximum payload size of 32 bytes, a 5-byte address field, and 2-bit CRC, a packet is 329 bits.  That's 164.5 us.  TX-to-RX turnaround is 130 us.  So sending 32 bytes and receiving 32 bytes takes at most 589 us.  That's better than 50k 8-bit samples each direction, and at less than 2.5 ms latency.  If you can live with larger latency, then you can transmit as many as 12 32-byte packets in row before turning around to receive.  Throughput increases to over 90k 8-bit samples each direction, or 45k 16-bit samples each direction.  In either case, retransmits are pointless.  It's an intercom, not a studio uplink.  The occasional dropped packet can be tolerated.

 

The point is, all of this is definitely doable.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Joeymorin --I *think* you and I are agreeing? [Some of the earlier posts from different folks need some clarification.]

 

There is duplex RF transmission. Each end transmits; sometimes on a different RF channel, or Time Division Duplex using the same RF channel but sharing time slots.

 

There is duplex audio; where each end can talk and listen at the same time.

 

I agree, this is doable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks so much. Now I understand the cause of echoes. To think, I used to think the cause of echoes was the sound leaking from the earpiece to the microphone. wink

 

Thanks again, so much for your overwhelming, wonderful responses. '

 

This is the best forum I have ever been.