WebJack can also be tested without an Arduino/Genuino board. For an explanation of the WebJack pr...
Public Lab is an open community which collaboratively develops accessible, open source, Do-It-Yourself technologies for investigating local environmental health and justice issues.
Public Lab chatroom
Reset your password
Read more: publiclab.org/n/13296
rmeister was awarded the Photo Documentation Barnstar by Parsamparham for their work in this research note.
WebJack can also be tested without an Arduino/Genuino board. For an explanation of the WebJack project and a tutorial for testing with Arduino, take a look on this research note, as I'm going to skip it here.
Instead of an Arduino we can use a second mobile device to replay a recording of the SoftModem signal. But to do so, we need sort of an 'audio crossover' cable. The audio output of one device has to be connected with the microphone input of the other device. Therefore we have to cut off the cable and cross two of the lines. Those are the lines connected to the tip and the sleeve of the connector. For better overview, here is a sketch:
(the colors may not be representative your cable)
After patching up the cable, please follow this steps:
Open the demo website on the receiving device:
Hint for Mac/OS X: please use Chrome/Firefox/Opera. Safari does not support WebRTC yet.
Is there some text arriving at the 'Received Data' box on the demo page?
Yes -> Great, it works! Please leave a comment on which devices you used.
No -> Then please point the receiving device to this WebRTC recorder and record for about 5 seconds (while playing the WebJack_test_signal.wav on the other phone). Please save the recording and post it as comment, attached with information about your setup (smartphone/devices, browser).
That's it, thank you for your help!
I did this Help out by offering feedback!
Browse other activities for "webjack"
None yet. Be the first to post one!
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).
Is this a question? Click here to post it to the Questions page.
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?
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)
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:
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:
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.
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?
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:
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.
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):
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!
You must be logged in to comment.
This is marked this as an activity for others to try.
Try it now
Click here to add some more details.
How long does this activity take?
How hard is this activity?
What is it's current status?