Revised photodiode amplifier

I designed a new photodiode amplifier. Click on the image for a larger view:

And an associated printed circuit board:


The printed circuit board is available to purchase from OSH Park if you like.

I will update this post after I receive the PCB and test the circuit.


The first part of the schematic is the power supply. VIN is +15V.
The L78L12 supplies regulated +12V to bias the photodiode. The RLC lumped element filter that follows ensures a low noise voltage source for the photodiode bias.
The filter quickly drops below the noise floor above a couple MHz. This is theoretical. Actual performance won’t be quite as nice.

The 47 Ohm resistors thrown into the filter will not measurably affect the photodiode response. The DC power will be no more than a few milliwatts maximum.

The AC power will probably be below the microwatt level, I’ll guess around -40dBm. Again, I’ll update this when I have some results.


The next section I’ll talk about is the photodiode itself and the amplifier.
The photodiode is an OPF432. It comes in a handy package that has an ST style fiber optic connector so you don’t have to have any bulky external mechanical parts to couple light into the diode.

The photodiode is reverse biased at +12V. According to the datasheet this should provide a rise time of about 8 microseconds. I believe this refers to the time constant. The datasheet claims this part can be used up to 100 MHz which is a period of 10ns.

The signal rises in half the period which is 5ns. If the datasheet rise time is accurate at 8 microseconds, I believe the AC output amplitude (peak) of a 100 MHz modulation will be:

Current = (5ns/8us)*50A/W = .03125 A/W

A/W is amps per watt of input power. In my application the input amplitude may be approximately 10uW. Multiplying:

31.25mA/W * 10uW = 312.5nW

This sounds very low, but let’s convert to units of dBm (decibel milliwatts):

P = 10*log10(312.5nW)+30 = -35 dBm

The GALI-74 is an MMIC that conveniently provides a 50-ohm matched input and output with +25dB of gain from low frequencies up to well above the design goal of 100 MHz.

The output will be at about -10 dBm which corresponds to an amplitude of approximately 70 millivolts into a 50 ohm load.


The final section of the schematic provides a low pass filtered output which indicates the DC amplitude of the incoming light.


ESP8266 WiFi module

Recently I received some really cheap WiFi modules.

The Wi07C isn’t much more than a little rectangular board with a WiFi chip, flash chip, and copper trace antenna.



The little board on the left is the ESP8266 board. It’s wired to a CP2102 UART to USB bridge and powered by a 5V – 3.3V buck converter I had laying around.

I bought the ESP8266 board from a store in Korea called Electrodragon

Pinout and AT command reference here

I made 5 connections for this demonstration:
VDD to +3.3v
RX to TX on CP2102
TX to RX on CP2102
RST to +3.3v

On my computer I ran a perl script that listens for connections on port 8001 and simply spits out data that it receives. If it receives the text “PING?” then it responds with “OK”

So I connected to the CP2102 UART bridge using Realterm. The baud rate is 57,600. The line endings are CR but CR+LF will work fine.

I sent the following commands to the module to

1. Connect to my WiFi AP
2. Establish a TCP/IP connection
3. Send data
4. Disconnect


Here’s a screen shot of what was echoed back to me on Realterm:


So I actually sent the PING twice. The last character after PING doesn’t matter in my perl script. You can see the second time I sent 7 characters. PING is 4. There’s a space you can’t see, and then CR+LF for a total of 7. The +IPD,3:OK indicates that the host (the perl script) returned 3 characters: “OK” and then a CR character.

I’m impressed that a $4.50 WiFi module does anything at all, but it actually worked without much trouble so I’m very impressed.

I then ran a command that the module didn’t like, and it’s only responding with “busy now …” to any command I send it. I’ll have to toggle the RST line or power in order to reset the device. An acceptable caveat or will this prove to be a persistent problem?

Here’s the perl script I used:



use IO::Socket::INET;

# auto-flush on socket
$| = 1;

# creating a listening socket
my $socket = new IO::Socket::INET (
LocalHost => '',
LocalPort => '8001',
Proto => 'tcp',
Listen => 5,
Reuse => 1
die "cannot create socket $!\n" unless $socket;
print "server waiting for client connection on port 8001\n";

# waiting for a new client connection
my $client_socket = $socket->accept();

# get information about a newly connected client
my $client_address = $client_socket->peerhost();
my $client_port = $client_socket->peerport();
print "connection from $client_address:$client_port\n";

# read up to 1024 characters from the connected client
my $data = "";
$client_socket->recv($data, 1024);
print "received data: $data\n";

print $data;
# write response data to the connected client

# read up to 1024 characters from the connected client
my $data = "";
$client_socket->recv($data, 1024);
print "received data: $data\n";

if($data =~ m/PING.*/){
$data = "OK\n";
} else {
goto shdn;
# write response data to the connected client
print $data;

# close
shutdown($client_socket, 1);