LED as light sensor !!?

Sometime ago there was a post on reddit which claimed that you can use your LED as a light sensor to detect the intensity of light. We decided to try it out and oh boy! it completely changed our perspective on the LED.

We just took a LED and performed an AnalogRead on the Arduino. Check this out:


It is ridiculously easy to generate any audio signal using Python

Now it comes as a surprise to many people when I tell them that generating an audio waveform is extremely simple.

One needs to have basic understanding on how audio signals work and basic python programming to generate any audio wave form. This post will show you exactly how.

Python packages needed: Numpy, Scipy

Screenshot from 2017-06-09 20:58:55


Link to code : GitHub

You can find a list of other waveforms that can be generated using SciPy here

Cigarette Lighter spark detection using headphone jack

This is part-III of the post series on detecting electromagnetic waves using headphone jack. In this we capture the EMW that emanate from the spark gap junction on a lighter. This is analogous to our gas lighter experiment but conducted at a smaller scale.

Screenshot from 2017-06-07 11:41:35

We say that this is analogous to the Gas lighter experiment because the waveforms obtained are extremely similar in nature.

Screenshot from 2017-06-07 13:35:47


Check out:

Part – I – Lightning detector using headphone jack 

Part – II  – Detecting switching ON/OFF tubelight with a headphone jack


Detect switching ON/OFF of Tube-light with a simple headphone jack

Now in our previous post, we established that the headphone jack can be used to successfully detect electromagnetic disturbances ( Sparks and Lightning ). In this post, we explore the interaction of the tube light with the headphone jack.


Here is a close up of the peak that you saw in the video:


Nowadays of course, we have moved on Non-flickering tubelights and it is highly unlikely that we might be able to detect the peculiar peaks that you see on this. But to be sure we are currently working on this and we will keep you guys posted on the results.

Also if we could incorporate this into a IoT network, things will go crazy!!!


*   Image Source

Lightning detector with a simple headphone jack

Okay, this probably one of those posts that is ecstatic to draft because of the shear wonder that it encapsulates. We captured lightning using nothing more than just a mere headphone jack and its so simple that anyone around the world with an access to an old headphone jack can do it too!



Take an old headphone jack and strip off the mic part and you are good to go OR if you have a dedicated USB sound card you can use that!



Sparks of any kind produce electromagnetic disturbances and it is these disturbances made by lightning that we will be detecting. That is the reason we are stripping off the microphone from the headphone jack and keeping only the wire.  The wire will act as an antenna to pick up the signal.

Just to be clear, this is NOT related to the sound of the thunder by any means.

Test with Gas Lighter

Before we test the headphone jack with lightning, we needed to know how the headphone jack reacted to sparks and how a spark looks like when recorded with a headphone jack.

Since gas lighters are capable of producing sparks, we thought that it would be a great place to start. Here’s what we observed:

** Although we use a USB sound card in our videos, this works with an ordinary TRS/TRRS headphone jack as well.

Capturing lightning

Now that we have a good idea of what is going on with a gas lighter, we can predict a similar pattern with a lightning as well. Why ? Well, because lightning is the same phenomenon but, at a much bigger scale.

How do you do it ? First things first, to state the obvious one needs lightning. But besides that the setup is similar to the previous one except that unlike the gas lighter, we have to use the human body as an antenna by holding the wire coming from the mic pin of the headphone jack in our hand

Processing the recording

The audio file that we acquired has been uploaded to Google Drive (links below) but we strongly suggest that you try it out yourself to get a feel for this powerful technology that many people disregard as quotidian.

This is how the raw audio file might look (recorded with Audacity):

Now we amplify this signal on Audacity. (Effect –> Amplify)



Now you see these three prominent peaks, now these are for sure caused by the lightning. How are we so sure? Well, we were able to visually validate the data. What are those other peaks ? They are lightning too (!!!), but ones that are happening at a distance (probably many kilometers away).

Now in order to be completely sure, we repeated the same experiment another evening.. And here’s what we got:

Screenshot from 2017-05-18 10:05:53

This was a much more dramatic day with lots of lightning! ( as is evident from the numerous peaks )

How cool is that you can something as simple as a headphone jack to procure information about lightning that is probably happens kilometers away. This was absolutely ecstatic!

What does one peak look like ?

Here is a close up of one peak that was recorded:


Sampling rate: 44100 Hz

Screenshot from 2017-05-24 12:43:23

Sampling rate: 384000 Hz

This resembles very closely to a Guassian Wave packet . ( In physics, a wave packet (or wave train) is a short “burst” or “envelope” of localized wave action that travels as a unit )


We believe that the electromagnetic disturbance that is detected during a lightning / spark is a Gaussian wave packet.  (If you believe otherwise let us know why by pinging us at 153armstrong@gmail.com or in the comments section)


Video Demo:

Will be uploaded soon! (subject to environmental weather conditions ;P)

If you found this post interesting, check out

Part- II-  Detect switching ON/OFF of Tube-light with a simple headphone jack

Part – III – Cigarette lighter spark detection using headphone jack

Part – IV –  The Headphone jack meets an actual spark gap!!!!!!

Thunder Audio file (44100 Hz): GoogleDrive link

Thunder Audio file (384000 Hz): GoogleDrive link

Simple Mobile Phone Detector using headphone jack

Mobile phones send wireless signals to the nearby station in order to help you send your message or connect with another phone.

But the best part about this is that these signals can be captured whether or not you have a mobile phone or not.  And the even cooler part about this is that this can be accomplished with nothing more than just a simple headphone jack connected to your laptop/phone.


There is nothing at all you need to do besides sticking a headphone into your jack and placing a mobile phone nearby.  Then open Audacity and record it at the maximum sampling rate possible on your soundcard. That’s about it !

Video Demo:


This works remarkably well with older phones (that still use the 2G spectrum), but unfortunately we are still unable to crack into smartphones (that use 3G or 4G spectrum. Argg.. ) using this technique.

But that being said, we are trying our best to crack in. Would highly appreciate any input on this whatsoever. Have a good one!


More interesting stuff:

Sound of the dialup modem

Exploring /dev/input

Linux is one of those operating systems in which once you know your way around, you are unstoppable. In this post, we will explore what you can possibly do with access to /dev/input directory. Now you typically need to have superuser privileges to access this directory but there is a way around it. ( check this stackexchange )

The /dev directory

This is the directory in Linux that contains all the device files for all the devices that are on your system.

/dev/input – The input is a subdirectory that holds the device files for various input devices such as mouse, keyboard, joystick and so on.

Screenshot from 2017-04-18 22:10:46

This is a screenshot of my input directory and as you can see there is the mice/mouse0/mouse1 which are files corresponding to the touchpad/wired mouse/wireless mouse respectively. And then you have these ‘eventX’ files. Yours might look similar but depending on the nature of your device you might have more or less options available.


With so many event files, how can one possibly know which one corresponds to which ? This script is what you need:

cat /proc/bus/input/devices

This script would display relevant information about all the input devices connected to your system. Here’s a sample output for the Lid switch :

Screenshot from 2017-04-18 13:04:47

Now what we want is the event handler number for the lid switch which we can see from the information as event0. And through this one can map all the events with their corresponding devices.

Alternative method:

An alternate approach to doing this is to look at /dev/input/by-id or /dev/input/by-path, they have symbolic links to /dev/input/event<x>. But the only downside to this is that it does not display all the possible devices. We will discuss how to read from both in this post.

Let’s read the data stream !

Say you want to read the mouse file, you only need to open the file using ‘cat’ and start moving the mouse.

(sudo) cat /dev/input/event5

Screenshot from 2017-04-18 22:57:25

You would observe that as you are moving the mouse a stream of data is being dumped onto your screen. This data although seems crazy contains the information for the movement of the mouse.

Interpreting the input stream

The format for the input stream is given in the Linux documentation as follows:

struct input_event {
	struct timeval time;
	unsigned short type;
	unsigned short code;
	unsigned int value;

struct timeval – 16

unsigned short – 2 ( x 2 )

unsigned int – 4

Total size = 24 bytes

What this means is the first 16 bytes of data contain the system time, which in our case is not essential. The rest 8 bytes of data contain the actual relevant values. This is the output format of all eventX files.

Reading the mouse

Reading the mouse is probably the simplest to start with because one does not need to go through the trouble of accessing any eventX files. The mouse file in the /dev/input directory outputs a stream of 3/4 bytes ( Button value, x , y ).

You would get a 4 byte stream if the mouse is configured with the scroll wheel. Unfortunately in my case, even though I use a mouse with a scroll wheel, it was configured as a PS2 mouse. ( If you are in a similar situation – read this)


Map of the (x, y) data with the corresponding directions

My touchpad and wireless mouse do not have any special buttons and therefore when the button values are mapped with the corresponding clicks, I got the following :

Left_Button – 9

Right_Button – 10

Scroll_Button – 12

When I was going through this stackexchange, the code seemed to suggest different values for the each of these buttons.

Python Code for reading mouse:

import struct 
f = open( "/dev/input/mice", "rb" ); 
# Open the file in the read-binary mode
while 1:
  data = f.read(3)  # Reads the 3 bytes 
  print struct.unpack('3b',data)  #Unpacks the bytes to integers

Video Demo:

Reading the keyboard

Much like the mouse, one can opt for an easier way by just reading from the /dev/input/by-id or /dev/input/by-path, but for the love of it let’s try to play around with eventX files. Let’s go about this step by step.

  1.  Find the event handler number for the keyboard ( Mine was event5 )
  2.  Reading the byte data and converting it to the format specified in the Linux Documentation using the struct module in python
  3.  Extracting the relevant information from the converted data.


Python code for reading keyboard:

import struct 
f = open( "/dev/input/event4", "rb" ); # Open the file in the read-binary mode
while 1:
  data = f.read(24)
  print struct.unpack('4IHHI',data)
  ###### PRINT FORMAL = ( Time Stamp_INT , 0 , Time Stamp_DEC , 0 , 
  ######   type , code ( key pressed ) , value (press/release) )

Video Demo:

Other eventX ?

What should you do if you would like to read from another eventX file ? Well, from my experience I can share with you this. : The first 16 bytes in the file are always almost the time stamp and you can read only that data by:


The rest depends on the type of output which you can find out by using the evtest program.

sudo evtest /dev/input/eventX


** Now in theory, using uinput one can reverse engineer to emulate events. But we are still currently working on that. If you know anything about this, please ping us at 153armstrong@gmail.com