xloem / qrstream

Split data across multiple QR codes on Android
53 stars 12 forks source link

Some way for the receiver to inform sender of status of last QR sequence #17

Open mofosyne opened 9 years ago

mofosyne commented 9 years ago

You probbly only need "ACK" or "NAY"

Could either use:

xloem commented 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.

xloem commented 9 years ago

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.

mofosyne commented 9 years ago

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/

xloem commented 9 years ago

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

jkufner commented 8 years ago

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.