Recently I attended Over the Air, which (to borrow from their website) is:
a great vibe of bean bags, gadgets, knowledge sharing, hacking & lots of good geekery.
Or, to be more specific:
a unique tech-agnostic event for and by the developer community, featuring technical workshops where attendees can roll up their sleeves and tinker with new platforms, operating systems, APIs & SDKs; and tutorial sessions that feature real business cases, new insights and a healthy dollop of inspiration. Attendees are invited to stay overnight so that they can work on ideas, apps and hacks on the fly – to be entered into the various hack-athon competition categories and demo’ed on the second day.
And it was awesome. I met some really cool people, was fantastically well looked after and this year it was held in Bletchley Park; which is an amazing place and somewhere I’ve always wanted to visit.
One of the more fun parts of the event was the traditional overnight hack; with people seeing what cool things they could cobble together (often involving some of the tech & APIs shown off at the event), which then got shown off the next day, with the best winning prizes.
This is what I came up with:
QuickeR
The basic idea was to transfer data between ‘devices’ using ‘video’ QR codes, i.e. by splitting the data over multiple QR codes, which are then presented one after another as a video. Another device can then capture this video, split it into the separate QR codes, process them and recombine their contents to reproduce the original data.
So, as an example, I took the following four QR codes:
![]() |
![]() |
![]() |
![]() |
| 1This | 2is | 3a | 4test |
And combined them into the following video (gif):
Note: the numbers are there to denote the order of the elements, as the video will repeat endlessly and we don’t know where it started.
I then created an Android app that could read the video and reconstitute the data:
Now, not to sound too full of myself, but I think is a pretty cool idea and it’s something that I don’t think I’ve seen anywhere before. The initial use case I came up with was for transferring data between mobile phones, particularly in situations when network connectivity wasn’t available or was unreliable (which was unfortunately the case at Over the Air). However it could work between any device that can display a video and any device that can capture that video and run a bit of software. So for example, you could communicate between a TV and a mobile phone – maybe to download a sample app while the advert is on?
Also, theoretically, it has a moderately high transfer rate (for what it is):
15 FPS x ~2,953 bytes per frame = ~43 KB/s.
Comparable to a modem of old :)
Now, the app as it is today is fairly cludgy, as you’d expect for something thrown together in the space of 5 hours, and so I’m not going to shove the code up here – yet. There’s a load of cool things I want to do first:
- Add video creation to the app – allowing you to select a file on the device for transfer.
- Use smarter encoding schemes and maybe data compression.
- Auto-stop & error checking – by adding information about how many frames should be in the data set.
- Harden the code – it has a unfortunate tendency to fall over with out of memory errors at the moment :)
- General UI improvements – creating one for a start.
Who knows, I may even release it as an app on the marketplace.
P.S. I did get some comments about the name. To be honest, I started with the Q & R and worked backwards from there; however I do argue that it’s quicker than scanning multiple QR codes separately and trying to put the stuff back together yourself.




10 Comments
… just don’t tell Roo Reynolds! :-)
Seriously, this sounds awesome – really glad you made it to OTA and made a name for yourself there – you are definitely one of my “top mobile devs” to watch for the future!
Pingback: And that’s a wrap. « Over the Air
Pingback: Audience Vote – The results are in! « Over the Air
Very interesting. And congratulations for OTA prize.
Seems to me that more bandwidth can be achieved by larger QR codes, no? And why stop at 15fps? Is that the top speed for scanners, currently? As that number increases, the animations would be able to go faster and faster until the code looks static again (like a grey square with the 3 markers).
Temporal CRCs should also be considered in the future, I imagine, since resistance to noise is one of the strong points of QR codes but just animating them doesn’t provide it for the time dimension.
Hi Max,
Thanks! It’s turned out to be a much more popular idea than I expected, not that I’m complaining :)
I’ve not tried using larger QR codes yet. They’d definitely allow more data per frame, but I imagine they’ll be a point at which the phone camera has trouble making them out. It’ll be interesting to see what the threshold is.
As for the speed, 15 FPS is the capture rate of my phone (a HTC Desire). I’m currently experimenting with the app and getting it working reliably at the full 15 FPS, as the QR I initally used was nowhere near this rate; it’s looking really promising. I know that newer phones are capable of higher capture rates (the Nexus S can capture at ~30 FPS) and the idea that a really fast QR code could look like a static one is pretty cool.
The Temporal CRCs are also a good idea. I’ve been thinking about the possible ways of error checking and there’s some really interesting possibilities. I’ve also got some interesting ideas about compressing data and the best way to split it. I’m keeping these a little close to my chest for now though :)
Steve
Pingback: OTA11 Hackday Categories & Prizes « Over the Air
Pingback: Hackdays= NSA. AKA: one day at Over the Air | francopapeschi.com
Hi,
This application is very interesting. Congratulations for OTA prize.
Can you help me with the source code? i want to try on my phone with different encoding algorithm, not only qr code, witch transfer rate is limited by size of qr-code.
Thanks and good luck.
Just so you know, 43KB/s is much faster than a 56k modem, the “56″ is in kilobits, not kilobytes, so they max out at only 7KB/s. and 43KB/s in kilobits is 344.
Like most things I think of, someone else has already done it :). Kudos to you on this cool project. I had the same idea, just a couple years too late…