Can't get it to work with ultra sounds

[boadadf]

DEFAULT_FREQUENCY_BASE = 4000; works

DEFAULT_FREQUENCY_BASE = 5000; doesn't.

[cawfree]

This may be too high a frequency to be detected by your receiver. Have you verified that both your emitter and receiver are set to the same base frequency?

On Tue, 26 May 2020 at 10:01, Daniel F Boada notifications@github.com wrote:

DEFAULT_FREQUENCY_BASE = 4000; works

DEFAULT_FREQUENCY_BASE = 5000; doesn't.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/cawfree/OpenChirp/issues/4, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB4OFHN5XVL6S2OER3LXXQLRTOAOBANCNFSM4NKDUATQ .

[boadadf]

Both are running on the same base frequency. Even with a single device, when I run at DEFAULT_FREQUENCY_BASE = 4000, the same device that sends the 'datadata' receives the 'datadata', however it is not the case when I run at 5000. Something strange I noticed, running at 5000, is that the sound, unlike at 4000, is like choppy, but maybe it's that I am getting deaf. My question here, before getting deeper investigating, have you ever succeeded/tried transmitting at high frequency?

[cawfree]

I tried to get the algorithm to run at the highest rate I could. It’s most likely that you’re hitting the sample frequency limits, since there’s a physical maximum (Nyquist Theorem).

If we’re generating at 44100, maximum theoretical is 22050. Been a while since I worked on this codebase, so it depends how many samples we try to write to generate the waveform shape. For example, if I used ten samples, our maximum would be 44100 / 10 which would limit your generation rate to 4.4kHz.

I’d recommend checking out the Quiet Project, which includes experimental ultrasonic generation:

https://github.com/quiet/org.quietmodem.Quiet

On Tue, 26 May 2020 at 11:35, Daniel F Boada notifications@github.com wrote:

Both are running on the same base frequency. Even with a single device. When I run at DEFAULT_FREQUENCY_BASE = 4000, the same device that sends the 'datadata' receives the 'datadata', however it is not the case when I run at 5000. Something strange I noticed, running at 5000, is that the sound, unlike at 4000, is like choppy, but maybe it's that I am getting deaf. My question here, before getting deeper investigating, have you ever succeeded/tried transmitting at high frequency?

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/cawfree/OpenChirp/issues/4#issuecomment-633945892, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB4OFHP5MT2T4PG7SCLDD3TRTOLQXANCNFSM4NKDUATQ .

[boadadf]

If we’re generating at 44100, maximum theoretical is 22050. Been a while since I worked on this codebase, so it depends how many samples we try to write to generate the waveform shape. For example, if I used ten samples, our maximum would be 44100 / 10 which would limit your generation rate to 4.4kHz.

I thought so after learning your code, that's why I am using 96000, and that could explain the choppy sound at high frequencies. BTW, such great work you have done here. I will try experimenting a bit more, and check this 'Quiet' project. One cool thing of your project is that, if I understand correctly, it could theoretically communicate with iOS chirp. In any case, my idea was trying to create a 'sonar like' application to measure distance between phones.

[cawfree]

Does your device support 96000? From what I remember, you only really guaranteed that every device supports 44100. If you read back the baud rate that you've set, do you get the expected value or does it max out?

Afaik it works with Chirp Share. That was the app I was originally testing against. (One of the share-compatible constants is buried in there somewhere).

Thanks a lot. One crazy weekend of pulling my hair out a couple of years ago. :)

That's a cool idea! I have no idea how you'd go about managing timing/synchronization. I worked on something previously where we used ultrasound to position in 3D. We needed to use microcontrollers to get reasonable timing though.

[boadadf]

Yes, the device supports 96000 (it's a Samsung S8); if you configure a non-supported frequency, it throws an exception, and I can transmit data at 4.000 kHz, so I guess that's fine.

The idea is to detect when two people get too close in the office, to be compliant with the new rules regarding covid 19. I made this attempt (see below), using Wifi triangulation, but it's hard to calibrate and teach to get decent precision, so I thought this would be more accurate. https://www.linkedin.com/posts/daniel-fernandez-boada-14a46184_ai-soprasteria-covid19-activity-6667782354020392960-GGr6

[cawfree]

Wow, that's a cool project!

The NHS official COVID app used low power decentralized Bluetooth. Maybe there's some inspiration here: https://github.com/nhsx/COVID-19-app-Android-BETA

My guess is this is the line that's tripping you:

// Calculate the Number of Samples per chirp.
final int      lNumberOfSamples = (int)(MainActivity.WRITE_AUDIO_RATE_SAMPLE_HZ * (pPeriod / 1000.0f));

If the number of samples is too low, it'd start to deform the shape of the waveform (notice the integer cast), since it uses this number to step through fixed points of the sinusoid. So you might need to find a nice combination of pPeriod and WRITE_AUDIO_RATE_SAMPLE_HZ.

Also, just looking at it, we're using a float. Perhaps if you increased the resolution to double you might be less likely to get affected by rounding errors.

[boadadf]

Thanks for your comments. Will check on this. If I find something confluent, I will try to make a branch and you can review it.

About Bluetooth, I made an early test with it. It was draining my battery, mostly because of the continuously setting the phone in discoverable mode. I could detect other phones, but never estimate how close they were :( I'll have a look to this NHS application.

[cawfree]

Okay, sounds good. Okay, I think I understand the idea, because in order to receive a chirp you have to be within a couple of meters (usually) in working environments. You could probably increase the number of successful checks that are required has to pass in order to increase its symbol validation "strength", which would necessitate a clearer signal and therefore someone standing closer?

Thanks a lot @boadadf, best of luck!

[boadadf]

Hi Thomas, Just in case you are interested... in the end I went for the Audio Web API, that later I can convert to Android or iOS native apps using Apache Cordova (build using phonegap). Result is here: boadadf/boadadf.github.io

|

boadadf/boadadf.github.io

Contribute to boadadf/boadadf.github.io development by creating an account on GitHub. |

|

|

https://boadadf.github.io/distance/ Basically I am using a 'chicken' strategy. I read the incoming media stream from the microphone and I check for the frequency with the highest db to decide if the frequency comes from another phone, and it is close enough. Regards and thanks for your time,Dani.

On Tuesday, 26 May 2020, 14:11:45 CEST, Alexander Thomas <notifications@github.com> wrote:  

Okay, sounds good. Okay, I think I understand the idea, because in order to receive a chirp you have to be within a couple of meters (usually) in working environments. You could probably increase the number of successful checks that are required has to pass in order to increase its symbol validation "strength", which would necessitate a clearer signal and therefore someone standing closer?

Thanks a lot @boadadf, best of luck!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.