1. 32
  1.  

  2. 10

    So one day a couple of years ago, I came up with this idea I thought was crazy. Google Tone had just been released and I thought it was neat. I could be in a room of people giving a presentation, and they could follow along in their own web browsers just by me playing back a tone on each slide requiring a transition.

    Tone had some limitations.

    1. Folks had to be using Chrome. This was 2015, so more than 40% of worldwide traffic was Chrome and I’d bet it was probably above 70% in my circles. While not everyone was using Chrome, they were probably sitting next to someone who was. NBD.
    2. People had to have Tone actually enabled. A message of “please enable Tone if you want to follow along” would probably suffice but those who didn’t have Chrome or were wary of Tone and didn’t want it installed would be party to Tone’s tones with no value to them.
    3. The audio had to be loud. It wasn’t very resilient. You might have to broadcast it a few times in order to get everyone’s devices to follow along. Ears? Well, you knew what you were signed up for the moment a presenter said, “please enable Tone if you want to follow along.”
    4. Tone was reliant on Google. Inaccessibility of Google was generally not a thing but in some venues, 30 laptops hitting one URL ~simultaneously could set off IDS systems, or so I was told. Tone tones didn’t carry the whole URL. Rather, they were basically a shortcode that had to be looked up. This was generally fast but it couldn’t really keep up with presenter speech when this lookup plus the time necessary to prompt the user if they actually wanted to act on the received tone, plus the time to load the URL contained with the Tone.

    All of this made Tone a bad user experience, really. Tone was a parlor trick, a neat thing in concept and implementation, but its problems made it all but useless.

    So, I came up with something else. I called it an “audio QR code.”

    It would be a standard and not reliant on any one browser. Its sound would contain the whole message, not a reference to a controlled look-up service. The sound could be super- or subsonic, thereby avoiding the whole ear pain problem. Dogs might not like it, though. Sorry, Fido. Lastly, enabling it wasn’t going away because no system should react without double opt-in user consent.

    I worked out how to encode data in an audio signal. I’m not a hardware engineer. It was a pretty handwavy.

    I did some more research to see if anyone else had come up with this idea.

    I’d basically rediscovered QAM over a weekend.

    I’m still waiting for someone to stick that into a browser.

    1. 6

      Jie Qi and Bunnie Huang use audio transfer for programming microcontrollers in the paper electronics Chibitronics project

      https://chibitronics.com/programming-chibi-chip/

      Bunnie’s LCA2018 talk goes into how they decided this was the best option for beginners and kids to program MCUs, and some of the technical implementation: https://youtu.be/alssfVGrFhI

      (Discussion of audio transfer starts about 27:20 but whole talk - covering a lot of things - is worthwhile.)

      1. 3

        Hiya Gus :-)

        Yeah, I think the way they’re doing it has some hair on it, but overall it is maybe a good idea. I’d like it better if it used a more modern modulation technique. If it’d work just by holding the clip near a speaker instead of needing a little custom cable it’d be better for kids & iphone owners.

        Kinda reminds me of these: https://en.wikipedia.org/wiki/Timex_Datalink#Wireless_data_transfer_mode

        It’s kind of a pity IRDA didn’t really take off … would be perfect for this kind of thing.

        1. 1

          Fancy seeing you here, @nickzoic :)

          I think the challenge is doing more complex modulation (and/or noise cancellation) without a lot of hardware resources (probably easier if it was MCU->PC rather than the other way around.)

          That Timex trick is neat! I wonder how fast I can modulate the backlight of my laptop at, without noticing…

          1. 1

            True, but given the Clip is only receiving I would have thought you could use some analogue tricks to filter & demodulate DPSK or similar. I don’t know how that’d go with their “survives MP3 encoding” point though.

      2. 4

        Found this looking for something like @tscs37’s idea doing doing I2C over 3.5mm audio jacks. There were lots of EE-type problems people brought up in various threads on that. This is pre-made software, though, so more of us might find it useful. Neat part of the video is author piping a whole man page through the connection.

        1. 4

          For a related/amusing/useless game history factoid, Bangai-O Spirits on the Nintendo DS from 2008 also used this technique to transfer custom levels without a link cable or Internet. ( technical details here , IIRC it’s ASK)

          You can still find a lot of them on YouTube under “bangai-o spirits sound load”

          1. 5

            So does the latest model Teenage Engineering Pocket Operator.

          2. 3

            I remember playing with Quietnet a long time ago, which you could send messages using ultrasound.

            I believe Android has the Nearby messages API which

            uses a combination of Bluetooth, Bluetooth Low Energy, Wi-Fi and near-ultrasonic audio to communicate a unique-in-time pairing code between devices.

            1. 2

              I wonder if this can survive a bunch of lossy transformations. It would be awesome if I could call someone on the phone, hold up my phone to my computer speaker, and have them hold their phone to their computer, and for them to end up with the message anyways.

              Perhaps some integrated hashsums that would also play the messages multiple times or something to ensure integrity.

              1. 1

                This is so cool!

                1. 1

                  This is really cool. Thanks for the post!