Interference caused by mixing of audio tones

[astrickash]

Hi Georgi,

When more than 2 devices are communicating within same area that causes the sound signals mix with each other. Can we implement anything to prevent that interference.

For example, If device A and B both are sending signals to device C then how will device C understands both the messages. If this is possible can you explain what should we implement to avoid this.

Thanks

[ggerganov]

Hi, currently you don't have many options to solve this problem.

One way is the following:

• add a new protocol with a new base frequency, for example F0 = 6750 Hz:
  

  ggwave/include/ggwave/ggwave.h

  Lines 237 to 245 in 9315497

  	static const TxProtocols & getTxProtocols() {
  	static const TxProtocols kTxProtocols {
  	{ GGWAVE_TX_PROTOCOL_AUDIBLE_NORMAL, { "Normal", 40, 9, 3, } },
  	{ GGWAVE_TX_PROTOCOL_AUDIBLE_FAST, { "Fast", 40, 6, 3, } },
  	{ GGWAVE_TX_PROTOCOL_AUDIBLE_FASTEST, { "Fastest", 40, 3, 3, } },
  	{ GGWAVE_TX_PROTOCOL_ULTRASOUND_NORMAL, { "[U] Normal", 320, 9, 3, } },
  	{ GGWAVE_TX_PROTOCOL_ULTRASOUND_FAST, { "[U] Fast", 320, 6, 3, } },
  	{ GGWAVE_TX_PROTOCOL_ULTRASOUND_FASTEST, { "[U] Fastest", 320, 3, 3, } },
  	};

  
  Simply add a line:
  { GGWAVE_TX_PROTOCOL_AUDIBLE_FAST_6570, { "Fast 6750", 144, 6, 3, } },
• make device A use protocol GGWAVE_TX_PROTOCOL_AUDIBLE_FAST
• make device B use protocol GGWAVE_TX_PROTOCOL_AUDIBLE_FAST_6750
• on device C create 2 ggwave instances:
  • the first instance should know only about GGWAVE_TX_PROTOCOL_AUDIBLE_FAST
  • the second instance should know only about GGWAVE_TX_PROTOCOL_AUDIBLE_FAST_6750
  • feed the captured audio to both ggwave instances

This way, on device C, the first ggwave instance will decode data only from one protocol and the second instance will decode data only from the other protocol. Since the protocols don't overlap in frequency space (because we offset the base frequency) you should be able to receive data simultaneously.

Obviously, this approach cannot scale for more devices. If we want to make it scale we need to modify somehow ggwave on a more fundamental level. Most likely #9 needs to be implemented first which would allow to use custom frequencies (currently ggwave uses only the frequencies of the FFT bins). Then we could introduce something like a "carrier" frequency and different devices can use different carrier frequencies. Something along this line - I am not sure about all the details yet, but definitely worth looking into.

[astrickash]

Thanks for your reply. I understand it and will try to implement this.

[HaoyuW]

Hi Georgi,
I implemented some custom protocols that are sending a message with 20kHz+ frequency, it works pretty well.
And tried to let two senders sending a different message with a fixed 4-byte length in the same frequency protocol at the same time, and tried to send the second message while in the middle of sending the first message. The receiver managed to receive both messages without any error. Although I was expecting to have some sort of interference since the message is using FSK.

There is another question I have, the receiver side is able able to decode the message separately even they are sending tones at the same time, just wondering how could this is achieved in the ggwave.

[ggerganov]

There is no special logic in ggwave to handle interfering signals. I would have also expected it to not work when the two messages overlap. However, I think somehow the error correction kicked in and you got lucky to be able to decode both messages.

How reliably do you receive both messages when they overlap?
I would expect it to occasionally succeed and fail most of the times.

[HaoyuW]

I have increased the kDefaultSamplesPerFrame to 2048. I was running the frequency range 21000Hz to 21750Hz.
The message was received by the ggwave-java running on my android phone

For fixed-length 4byte and 8 bytes, at least one sender's message is granted to be received. With no error. With fixed length of 16 bytes, most time the message is successfully received occasionally failed.

For flexible length with the sound marker, the fail rate increase. However, If one sender has much less power, It would succeed most of the time, thanks for the error correction code.

I guess maybe a shorter message length would have something to do regarding the situation