Light — Data Transfer on Android, cool theory!
Background
It all started with wires, slipped into wireless over Bluetooth, then dived into WiFi and that’s where we are now! An unexplored field is direct light — don’t mess it up with fiber optics which ends up converting light to radio waves (simply routers) and propagate it over the good ol’ WiFi. What’s up about light?
The theory just drives me back to Morse Code. Those days were cool when simple torches were deployed to relay messages — trust me we’ve tried that in college. Impulses of light that just represent the 1’s and 0’s with two simple states — ON and OFF. But we’re no longer in the comfort zone!
The whole thing is just a theory as it’s quite impractical to implement at the moment. It could definitely be bettered down the lane of time! Also the concept isn’t quite similar to LiFi but can be thought of on similar lines.
Scenario
Lets take an example. I’ve got a 1 MB file that I’d like to send across to my buddy Sid. Cross-platform, data, regardless of its type / extension is represented as a file. A file can be represented as an array of bytes in any programming language say Java. What’s within that byte-array is just a sequence of bytes, each element ranging between 0 and 127 since that’s how a byte is define in Java at least. If you’d consider converting 1 MB into bytes, just multiply it by 1024 twice. That’s precisely 1048576 bytes. So the byte-array representing my 1 MB file is 1048576 elements (bytes) in length — each element being a number (byte) within the 0 ~ 127 bracket. Now let’s get into the theory behind transmitting this byte array!
Representation
We’ve now got to deal with representing each element in the array uniquely to Sid’s Android device such that it’s able to precisely understand what’s the number in the array that my phone’s trying to broadcast. Before that, we’ve got to grasp the characteristics of our source and receiver. Our base is light and our source of light is simply the display / screen of my Android phone. Our target is surprisingly the ambient light sensor of Sid’s Android phone. Hands down, our target can’t understand color (an ambient light sensor after-all!) but on the flip side, it can understand the intensity of light. We’ve got to accordingly tune our source. Since an element in our byte array can be anything between 0 and 127, we could divide the intensity (brightness) of the source white light from my device’s screen into levels such that say for instance, 0 to x lux (SI unit of light as understood by Android) corresponds to byte 1, x+d to y lux corresponds to byte 2 and so on till 127. Thus, we’ve mapped our source light levels with each of the 128 bytes (0 ~ 127). Now we’re set to transmit.
Transmission + Reception
I’m not delving too much into the technicalities since this post is merely theory (maybe just impractical theory but fun to know) ! Handlers in Android can be used to schedule code that runs after a specified amount of time. Say my phone is programmed to transmit a given intensity of light from its screen for 1 ms for each number in the byte array, Sid’s device can be programmed such that its ambient light sensor fishes for light every 1 ms and maps that intensity (lux) into a number between 0 and 127 as programmed (may sound complicated but it’s actually pretty simple under the hood) and stores it into it a new byte array. This process continues iteratively until all the 1048576 elements of my 1 MB byte array are transmitted!
At Sid’s device, this byte array is assembled back to a unit called file (as understood by, say Java) and is saved onto the internal storage in his phone. Transfer complete!
Challenges
Let’s take a break! Now we’re cool. Ever wondered how fast this process is? Let me spoil it for you — it’s insanely slow. That’s exactly why the title says, it’s just a theory! Let’s understand the math behind the speed. Heading back to my 1 MB file transfer, 1 MB is precisely 1048576 bytes and if a byte is transmitted for 1 ms as we saw above, unitary method has it that it would take ( 1048576 * 1 ) / 3600 minutes which is roughly 17 minutes to transmit an MB. Holy 17 minutes for an MB! Insanely impractical.
In addition to the speed constraint, we also have a couple of challenges at hand! Since we’re taking a ms to transfer a byte, did we ever wonder if Android can really go as fast? Let me tell you, 1 ms is technically the fastest that you schedule code in Android. Based on CPU speed and the OS optimization itself, perhaps it’s not really flipping light at 1 ms in my phone (the source) ! So that means, it’s technically going to take longer that 17 minutes — crazy again! Another technical issue could be clock synchronization. Mine as well as Sid’s phone would have to be synchronized to start transmitting as well as receive data at the same time — that’s when the 1 ms (the impractically chosen time interval) gap wouldn’t overlap (I’m sorry if that’s too complex) !
Conclusion
Just taps into one’s imagination, yet too complex for a few to grasp I assume as I tried my best to simplify the text keeping it concise at the same time! Though the concept is far too impractical to implement at the moment, maybe someone could come up with a smarter solution without hardware extensions! Cheers, I sign off.