I'm hoping to test with an Arduino soon too, but as a first attempt I was able to get "Hello world!" to transmit from my phone to my laptop with no cable, in open air. Like Richard, I was unable to get the reverse to work, from my laptop to my phone.

Hmm, table formatting seems to have failed. We should write a test for this: https://github.com/publiclab/plots2/issues/617

Send ---- Receive ---- Result

Chrome Android | Chrome/Chromeos | success

Firefox Android | Chrome/Chromeos | success

Chrome/Chromeos | Chrome Android | failed

Chrome/Chromeos | Firefox Android | failed

I'm curious about the browser-to-browser use case, because as a SoftModem compatible protocol, we could also make this available as a general purpose web-to-web serial library -- imagine sending an email from one webpage to another, or something, or sharing a link or a GPS point -- which has the added benefit of compatibility with an Arduino library. Why do you think it's only working phone-to-laptop, but not the reverse? I'm going to try phone-to-phone and laptop-to-laptop soon (once I can borrow some devices).

Oh, also -- for the WebRTC to work, you need to link to the https version of the Github Pages site -- because that's now required for audio access in Chrome.

Cool, thanks for your results!

Chrome Android → Chrome Android did work for me, but not very well. Sometimes I had to repeat sending like 10 times to get one reception, or the received data looks like sh**t. Funny but probably not very usefull: loopback. Played some sounds and the same device recognized it.

I think to be useful as browser-to-browser connection, it should work without a cable. Audio crossover cables are not very common :D

Is there somewhere a link without https?

Huh, it's weird, but I could have sworn I clicked a link earlier and got http. But it seems fine now. I wonder what happened.

Note to future selves: if we set it up elsewhere, we can force HTTPS with a redirect.

Oh, maybe I should add a note for iPhone and Mac users. According to this site, Safari does not support WebRTC yet: http://iswebrtcreadyyet.com/

Indeed -- maybe it could either just say "not safari or iOS" as https://spectralworkbench.org/capture does, or could specifically return an error about browser/os. I was reminded of this today as I tried to test. WebJack in iOS Chrome also can't /create/ sound, which I guess makes sense.

I'm thinking about how we might add some hints for how to most easily do browser-to-browser over a cable. Just an idea -- what if we used these two cables -- if we have devices A and B, and we connected A-Left to B-Video and A-Video to B-Left, would that create a simple crossover cable with no need for wire strippers or soldering?

https://www.amazon.com/Feet-Camcorder-Video-Cable-Sony/dp/B003XOT4T8/

https://www.amazon.com/Maxhood-Female-adapter-Red-Yellow-White-Connectors/dp/B00O9FZC6O/

Also, for folks looking to use/make crossover cables, here are some cheap headset socket boards that could be used: (5-pack for $4.39)

https://www.amazon.com/Breakout-Headset-Stereo-Socket-Extension/dp/B0183KF5KI/

I tried again (after this attempt) and turned down the audio gain, but still didn't receive on the gh-pages demo. It doesn't look blown out:

Here's the recording:

webjack-leonardo-2.aif

This is fun -- I ordered the above cables (worst case i can cut them up and solder them to some boards) for more testing.

I was going to try the Trinket next, but what can I do to help debug this one?

That could work. But you will need an additional adapter for every device with AHJ pinout: https://www.headsetbuddy.com/3-5mm-ctia-to-omtp-smartphone-headset-adapter/

These breakout boards are pretty cool!

@warren this is the tutorial for testing without Arduino :)

Signal looks fine though. Remember to change the frequencies in SoftModem.h

Ugh, oops. I'll move the comment -- had to use someone else's computer which has a non-combined headphone/mic port, so I was hurried logging in and posting.

Wait, though -- can we change frequencies in JavaScript instead of SoftModem.h? Much easier, no? https://github.com/publiclab/webjack/issues/26

Sure, but anything above 7kHz will need disabling echoCancellation. gh-pages is currently set up with 2450 and 4900 Hz, echoCancellation active. For a quick test, changing values on the Arduino will be faster.

Ok! Would it be possible to mention this stuff in the readme?

Have you had a look at quiet.js? Do you think they disable echoCancellation?

Thanks!

Right, that should be inlcuded in the readme.

Yes, echoCancellation is disabled at quiet.js: https://github.com/quiet/quiet-js/blob/master/quiet.js#L358 Turning it off also disables other filters, which is important to get the full and unfiltered spectrum of the captured signal. E.g. ultrasonic signals will be filtered, if echoCancellation is turned on.

Hmm, i received the two cables I mentioned, but it wasn't recognized as a microphone when I connected them, either in Red-Yellow/Yellow-Red or White-Yellow/Yellow-White. I'm going to double-check the wiring diagram for this cable type.

Here's a good resource on many plug standards: http://connector.pinoutsguide.com/4_pin_3.5mm_2.5mm_plug/

But it seems that tip and ring 1 are usually audio left/right, ring 2 is ground, and sleeve is the mic input. I'm on a Chromebook but it works with my Apple headphones, so I assume it's good too.

But it sounds like video cable pinouts are different:

http://pinoutsguide.com/Home/asus_r2h_av_pinout.shtml

That shows: Tip: left, ring 1: video, ring 2: ground, sleeve: right

That means I should cross Red/White and White/Red, I believe.

I tried this and still wasn't able to get the chromebook to recognize a microphone device. But I was able to get the phone to "hear" the chromebook -- i'll attach the recording in a moment.

My_recording__1.wav

Odd -- the microphone seems to have been running along with the input.

According to the first review on Amazon the pinout of the cable is (from tip to sleeve):

• Left (white)
• Right (red)
• Video (yellow)
• Ground

But as you say, your Chromebook probably has mic and ground reversed. So you have to cross that lines before using the RCA cable. That's what this adapter is doing: https://www.headsetbuddy.com/3-5mm-ctia-to-omtp-smartphone-headset-adapter/

That makes sense. I hadn't been able to find a pinout for the Chromebook, but i'll order that and try it out.

@Parsamparham awards a barnstar to rmeister for their awesome contribution!