Feedback

[ggerganov]

Post any kind of feedback about ggwave or Waver - ideas, issues, suggestions, things to improve, etc.

[astrickash]

It is a great repository to work with and I am very much excited about future of this technology. I am trying to convert the same thing in python but I didn't understand how you captured the received audio frequency order, I mean when you capture audio between sound markers then how did you find the order of frequencies. I read all the description you have provided on the main page but didn't get this thing. Hope you can explain that a little too.

[ggerganov]

Thanks for the feedback!

Can you be more specific about:

how did you find the order of frequencies

I am not sure I understand which order you are referring to.

Here is some more info, hoping to make things a bit more clear:
Imagine the full spectrum from 0Hz to 24kHz. We are sampling at 48kHz and doing FFT with 1024 bins.This means each bin has width dF = SampleRate/nBins = 46,875 Hz. For the audible protocols, we choose a starting frequency F0 = 1875.000 Hz - this is the 40th bin. We use 96 bins to represent 3 bytes of data - so bins [40, 136) contain information about 3 bytes.

How is the data encoded into sound?
First, consider 4 bits of data - they can represent 2⁴ = 16 distinct values. Let's say they currently represent the value 0 <= k < 16. In order to encode these 4 bits (i.e. the value k) into sound, we add an amplitude with frequency corresponding to the k-th bin. So for 4 bits of data, we need to use 16 bins from the spectrum.

Since we use 96 bins in total, we can encode 96/16 = 6 chunks of 4 bits which is exactly 3 bytes. We now split our payload that we want to transmit in chunks of 3 bytes and sequentially add the necessary amplitudes and transmit. Hope that makes sense.

While writing this, I realized I might have overlooked the way the bins are centered. I am assuming that bin i is centered at frequency i*dF, but probably it might be actually centered at i*dF + 0.5*dF. Not sure if this is correct or if it has any impact on the performance of the method. Will see ..

[astrickash]

Thanks for your reply and this explanation.
So basically what I understand is if we need to send abc then we need to send 0110 0001 0110 0010 0110 0011 which is actually 24 bit data or 6 chunks of 4bit data and because you are using different frequency range for sending different chunks you don't actually need to write the code for which character comes first in the audio.
Also, yes the data is not centered at i*df , it is actually shifted towards positive x-axis but I didn't find any impact of this yet.

[ggerganov]

I looked a bit more into what frequencies the FFT bins really represent and it seems the original assumption is true - bin i is "centered" at frequency i*dF. Here is one article discussing this: link

I also tested that if I generate a sine wave sound with frequency of exactly i*dF I get signal only in the ith bin of the FFT.

[CasualArclamp]

have you though of using Direct Sequence Spread spectrum like the mode ROS? https://rosmodem.wordpress.com/ its at the very bottom

[ggerganov]

Hi I wasn't aware of that technique - I guess I could try spreading the tones randomly and see if that helps. I guess I can also spread the ECC bytes - currently, they are at the end of the message, but I could apply the same technique and spread the ECC bytes in-between the message.

[ggerganov]

I recently implemented a similar technique in the Waver application:

It works by xoring the payload with a magic sequence of bytes, causing the frequencies to be spread more uniformly within the frequency spectrum.

The implementation is here if anyone is interested: 75e3fde

[AngryApples]

Fantastic library, @ggerganov. Kudos!

Is there a utility yet to perform detection of tones within files? I.e. I can generate a WAV file via CLI that includes a tone, but what do I need to do to "scan" the file programmatically for embeds?

[ggerganov]

Thanks for the feedback!

There isn't such a tool currently, but it is easy to implement one.
Thanks for the idea - I will probably add it soon to the project.

[ggerganov]

Just added the ggwave-from-file example - it demonstrates how to decode messages from a WAV file.

[coachaymen]

Hi, I'd like to express my gratitude for the effort you've put in. I wanted to bring to your attention that while using Pico 2040, I encountered an issue with the Ultrasound protocol. Specifically, I was unable to utilize a sample rate of 48khz and a buffer size of 1024, despite testing it with Mic MAX9814 and Arduino nano rp2040 and Pico rp2040. Only a lower sample rate seems to be functional, as decoding at higher rates is taking too long, around 33-35 ms.

[ggerganov]

Hi, thanks for the feedback!
Yes, the 48kHz sample rate is somewhere near the limit of the RP2040.

I think at some point I was able to make it work, but I have lost the details.
You can try the following:

• Use Pico RP2040 with the stock example
• Disable all Rx protocols
• Enable only GGWAVE_PROTOCOL_ULTRASOUND_FASTEST

The decoding speed depends on the number of enabled protocols, so the idea is to disable all unused protocols and leave on the ultrasound one. Try to see if this reduces the processing time. It has to be below 21ms in order to work.