TXQR is a project for transferring data via animated QR codes. It is written in Go and uses fountain erasure codes. Ivan Daniluk, it’s creator and software engineer has shared his experience in building TXDR and also the results of using animated QR as a data transfer method.
QR codes, a type of visual encoding allows different error recovery levels, with almost 30% redundancy for the highest one. QR Version 40 allows to encode up to 4296 alphanumeric or 2953 binary symbols. But this gives rise to two major issues, firstly 3-4KB might just not be enough and secondly the more data in QR code, the better should be the quality and image resolution. But what if we need to transfer approximately ~15KB of data on the average consumer devices? Using animated QR codes with dynamic FPS and size changes could possibly work.
The basic design of TXQR
A client chooses the data to be sent and generates an animated QR code and shows it in the loop until all the frames are received by the reader. Encoding is designed properly such that it allows any particular order of frames, as well as dynamic changes in FPS. In case, the reader is slower then it can display a message “please decrease FPS on the sender.”
Talking about the protocol, it is simply where each frame starts with a prefix “NUM/TOTAL|”, (where NUM and TOTAL are integer values for current and total frames respectively) and rest is the file content. Original data is encoded using Base64, so only alphanumeric data is actually encoded in QR.
To get .framework or .aar file to be included in your iOS or Android project one can write a standard Go code, then run gomobile bind. Users can refer to it as any regular library and get autocomplete and type information. Ivan has built a simple iOS QR scanner in Swift and modified it to read animated QR codes, fed the decoded chunks into txqr decoder and displayed received the file in a preview window.
TXQR is used for unidirectional data transfer using an animated sequence of QR codes. The approach involved in TXQR included repeating the encoded sequence over and over until the receiver gets complete data. This led to long delays in case the receiver missed at least one frame.
As per the article by Bojtos Kiskutya, LT ( Luby Transform) codes can yield much better results for TXQR. LT codes are one of the implementations of the family of codes called fountain codes. It’s a class of erasure codes that can easily produce a potentially infinite amount of blocks from the source message blocks (K). The receiver can receive blocks from any point, in any order, with any erasure probability. Fountain codes start as soon as K+ different blocks are received. It is named as fountain code as the encoded blocks represent the fountain’s water drops. Fountain codes are easy and they solve critical problems as they harness the properties of randomness, mathematical logic and probability distribution tuning to achieve their goal.
In this article we have covered TXQR’s basic design, basics of animated QR codes, Fountain codes, Gomobile etc. To know more about the experimentation in detail, check out Ivan’s Github.
AWS introduces ‘AWS DataSync’ for automated, simplified, and accelerated data transfer
Google, Microsoft, Twitter, and Facebook team up for Data Transfer Project
MySQL Data Transfer using Sql Server Integration Services (SSIS)