Open mofosyne opened 9 years ago
Could also use: QR image picked up by a front camera. (my device has no flash)
Sound seems the least common denominator. I'm not sure the best way to detect the beep. But if somebody is excited about this and wants to code up the user interface, I'd commit to finding a way of detecting beeps and implementing the rest of the feature.
It would be incredible if qrstream could somehow respond to the beeps produced by existing barcode scanners (zbar, zxing) to automatically advance the code. I bet there's some way to do that without false-positives.
Well if you tried the "DTMF transceiver" app from android marketplace, it's pretty accurate. It's basically phone dial tone.
Thought the beeping would be pretty annoying. Unless phone can do non audio tones, or it's done purely over audio sound... then again if you could do that, you might as well consider exfiltrating the data via audio lol.
Audio tranmission via speaker can be assumed to be wide range. But smartphone audio tends to be filtered. Discussion in http://electronics.stackexchange.com/questions/59157/over-what-frequency-range-can-the-microphone-of-smartphone-receive-the-sound
In general, if you want to receive audio beyond hearing range, you need to test the average smartphone. There are fft apps to check. For iphone smartphone at least, here is a link http://blog.faberacoustical.com/2009/ios/iphone/iphone-microphone-frequency-response-comparison/
I think this is the patent for a software system intended to use conventional phone speakers/microphones to transmit arbitrary data inaudibly: http://www.google.com/patents/US8514662
If both phones use front camera, they can communicate via qr codes. And even if they cannot use front camera, they still can send one stream and then another in oposite direction. You just need to turn phones around here and there.
So, one phone would send qr codes at some reasonable speed. Each QR code would have to contain serial -- starting position in the file. Then, when sending is finished, receiver would send back list of missed byte ranges in single QR code. And then sending would continue as before, but sending only missed pieces. And repeat until something is missing. The first sent QR code should be simple header containing filename, length in bytes and SHA1 hash to verify file consistency.
You probbly only need "ACK" or "NAY"
Could either use: