How well can I expect org.quietmodem.Quiet to work?

[alexbirkett]

I've made a proof of concept app

I've tested with various quiet profiles but can't make it work reliably. It works occasionally with the phones spaced 30cm apart using the audible-7k-channel-0 profile. I've tested other profiles too without much success.

Is there an official demo app for org.quietmodem.Quiet?

Do you have any tips to make my app work better? I'm not sure if I'm using the API incorrectly or my expectations are too high.

[brian-armstrong]

Hi Alex,

Sorry to hear that. Android phones can be a little tricky because the manufacturers sometimes add noise or echo cancellation to the mic which is nice for voice calls but degrades modem quality. Some also have multiple mics and this is something the library still needs to address.

I just pushed a change to the profiles file, quiet_profiles.json, to tweak the audible profile a little. audible is lower-powered than audible-7k-channel-0 (less CPU required) so I'd ask that you try that one if you don't mind. If that does work then I may need to reconsider the default profile. If it doesn't work then it might be trickier to debug.

One other thing I'd be curious to know is how well it works if you run your receiver in the simulator on your dev computer. And in general, a lower transmit volume is better since speakers tend to distort less at lower volumes. Pointing the transmitter directly at the receiver can help, too.

I don't have an official demo app yet, unfortunately. I've just been using tests to confirm whether things work. It does sound like you're using the library correctly. 30cm is usually the distance I use to test.

[aroldohernandezarmas]

Hi Brian Very interesting this work of yours. I am testing your lib a bit, mostly the not wired profiles cause the speed you talk about seems to be a good achievement in data transmission with sound waves over the air. I am having a trouble when I run the receiver in more than on device. I am getting this Exception when the statement recvLen = receiver.receive(buf); is executed as shown in your example: java.io.IOException: Unspecified I/O Error 9. And later, just after the stack trace gets printed, getting this log line: I/Choreographer: Skipped 302 frames! The application may be doing too much work on its main thread. I would like to know the causes to solve them and test more your library. I am curious about how much of redundancy you set in your frames to get the errors successfully corrected, which algorithms do you use? It would be possible to establish a full duplex communication channel between two devices using your library?

[alexbirkett]

Thanks for the help! The changes to the audible profile unfortunately don't appear to make my app more reliable. Like aroldohernandezarmas my app calls BaseFrameReceiver.receive on the main thread (which blocks the UI). From time to time receive throws a IOException Unspecified I/O Error 9 exception. I'm testing with a Galaxy S5 and Nextbit Robin. I'll try to give the emulator a try.

[brian-armstrong]

I've pushed an update to the .so files that I think should take care of the Unspecified I/O Error.

One thing I'd be curious to know is whether https://quiet.github.io/quiet-js/ works in your mobile browsers, preferably Chrome.

libquiet does offer some diagnostics which are not presently exported to the Java wrapper. I could try to add those but I'm not sure whether the information will be useful here. One thing that might be useful is running https://quiet.github.io/quiet-profile-lab in a mobile browser, though it's worth noting that this page is pretty CPU heavy and might not run at all on a mobile device. It also unfortunately can only test a device to itself, not to other devices.

I'm going to see what I can think of to improve the reliability or diagnose what's happening. Sorry that you guys are the guinea pigs here :)

[alexbirkett]

The profile lab does not run on the Samsung Galaxy S5. Some audio is played but it stutters.

If I run the lab on the desktop browser. I can make the S5 receive what appears to be garbage using my app.

The Nextbit Robin does not appear to be able to receive messages using my app.

[brian-armstrong]

I wonder if I made the buffer sizes too aggressive. What happens if you do

receiverConfig.setBufferLength(16384);
transmitterConfig.setBufferLength(16384);

before passing the configs to the Transmitter/Receiver constructors?

Again, thank you so much for testing. I'm going to do some more testing today and hopefully come up with a better approach to debugging.

[brian-armstrong]

@aroldohernandezarmas Hi, to answer your questions, the reason your app is complaining is because waiting on the frame receiver blocks the main/UI thread from updating. In a polished app you will want to move the receiver to a separate thread and have it communicate to the UI thread with a Handler. However for testing purposes I believe it's ok to run it on the main thread and ignore the ANR warning.

The error correction depends on the modem profile used. This library uses liquid-dsp to do the heavy lifting, and liquid has a variety of options available. Quiet generally uses Convolutional codes and Reed-Solomon error correction.

[brian-armstrong]

@alexbirkett Thanks again for helping me test, I really appreciate it :)

I pushed a change which on my G2 appears to help significantly. I was previously acquiring sound as a stereo source and throwing away the right channel. I've switched to just asking for a mono channel. If you don't mind, I'd like you to try this new build out to see if it helps on your devices. It seems to have made a difference for me.

[brian-armstrong]

Also, the ultrasonic profile generally works best for me. Hard to say if that's just specific to my devices.

[brian-armstrong]

@alexbirkett

I made some changes to the underlying DSP library in order to provide better reception at marginal levels. I also tweaked quiet to take advantage of these changes. All of this has been pushed here. On my device I'm seeing significantly improved reception, with some reception working as far as a few meters out, as long as the devices are oriented toward each other.

I've also enabled the ability to pull the frame receive stats out of the receiver and built a pretty simple app around this. I'll be creating a new repo with that soon.

[brian-armstrong]

I'm closing this for inactivity. Like I mentioned previously I have made substantial improvements to this library so I recommend trying it, and feel free to open a new issue with any questions