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);




Capacitor impedance

Ever since I began designing circuits, I’ve read about bypass capacitor usage.

Engineers make broad statements about what you obviously have to do. Disagreeing with this advice automatically makes you a neophyte.

Common phraseology of bypass capacitor lore includes:
– You must use a mixture of low and high value capacitors to filter low and high frequency transients.
– You must use a tantalum bulk capacitor
– Sprinkling 1uF or 100nF caps around a board is stupid
and I’ve not made this one up:
– If you don’t know how to properly design capacitor bypassing, you should not be an EE.
[Of course, by “proper” they mean follow their advice]

I’ve been told by other reputable sources that since good MLCC [multi-layer ceramic capacitors] of high value and good electrolyte are now available, that most of these rules are exaggerated as yet another way for some engineers to claim superiority over others.

I decided to perform a few simple measurements to help me figure out for myself what I need to do when designing a circuit with bypass capacitors. Feel free to post below and offer advice as to how I’m wrong and/or what I should do with my graphs.

Test setup:
I have a simple “DG8SAQ” Vector Network Analyzer that I bought from SDR-Kits. It’s a reasonably good value and covers the range of 1kHz to 1.3 GHz. Without any fancy impedance converters, I decided that using this 50-ohm system to measure capacitor impedance would not be an unreasonable analog to what is happening when a capacitor is used for bypassing.

Bypassing for high speed digital systems is demanding. Edge slew rates can easily reach into the GHz range for FPGA designs. Even common LVCMOS digital logic can be extremely demanding – a recent comparator I used (MAX962) will drive it’s output high/low in 2.3ns (specified at 5v. It will be somewhat slower at 3.3V)

What I decided to do is solder a couple SMA connectors adjacent to each other, as in the following picture:
2014-05-27 14.23.57

I calibrated VNA and soldered a few surface mount capacitors into the open space. I used the following values:
1 nF
10 nF
100 nF
1 uF

From basic theory we know that the impedance of a capacitor is, as written in Laplace domain:

s = j*W [complex frequency]
C = capacitance value in Farads

In reality, capacitors have ESR and ESL. ESR is equivalent series resistance, and ESL is equivalent series inductance.
Alternating current by definition makes the impedance of a capacitor change.

My measurement system is not perfect for at least one reason; the ESR of a capacitor is usually << 1 ohm. My VNA is a 50 ohm system. I cannot effectively measure the ESR with this system. These plots will reflect the ESL, which I can measure.

Firstly I measured a 1nF capacitor. This plot is the magnitude of the signal that goes through the capacitor. This is called “S21”
I measured from 10kHz to 100 MHz because this seems to be a range most people would be interested in:

[click image for larger version]
1nf_cap_impedanceNext I tested a 10nF capacitor of the same size and type:

10nf_cap_impedanceLooks pretty nice to me.

Now for the 100nF cap:

I continued on with a 1uF capacitor. The plot is quite boring:

1uf_cap_impedanceIf you’ll notice: these last two plots went all the way up to 300 MHz. I thought there must be something interesting going on at some point. Not really.

My conclusions are based on the measurements that I’ve done. Obviously I have not included PCB parasitics in my test setup.
My conclusion is that for point-of-load bypass capacitors, the actual value of the capacitor makes little difference. I would not hesitate to use 100nF MLC-capacitors all over my PCB. Ideally the capacitors are placed as close to the power pins of the integrated circuits as possible, in order to make the current loops as small as possible.

Bypassing requirements for real circuits are very complicated. If you just have a fundamental sine wave current, you just pick one capacitor and be done with it.

I believe what I’ve shown is that the Fourier components of your load current that exceed about 1 MHz are easily handled by 100nF MLC capacitors, and that your lower frequency bypassing can be handled by a bulk capacitor that is located elsewhere on the board. Of course this depends on the inductance of your PCB traces.

Your system probably has intermittent loads switching on and off, or perhaps you’re building a switching power supply. The best bypassing setup would be an ideal capacitor of arbitrarily large capacitance value. This would theoretically cover your Fourier components from a few Hertz up to hundreds of MHz. Recently I’ve been using MLCC as large as 100uF with the X5R rated dielectric (never use Y5V!) I believe these new enormous MLCC are nearly ideal capacitors. They are expensive but I highly recommend them, especially if your alternative is a tantalum capacitor.

Thoughts on RF spectrum analyzers


Note: I’m contemplating designing a spectrum analyzer. The following are a compilation of my own notes that I’m making public. They might not make a lot of sense as a coherent treatise but take the pieces for what they are.

The classical way of performing RF spectrum analysis is to mix the input with a local oscillator (FLO1) that ramps between two higher frequencies, producing IF1.

IF1 is sent through a narrow band filter which leaves you with a narrow piece of the input spectrum that has been shifted up. The ramping action gives you a sliding window of the input spectrum, shifted up to the center frequency of the narrow bandpass filter.

Stepping back, remember that the IF1 frequency is the result of nonlinear mixing of the input with the local oscillator.
Let’s make some assumptions:

– the input (Fin) is any signal between zero and 1000 MHz.
– the local oscillator (FLO1) ramps between 1050 and 2050 MHz
– the narrow bandpass filter (FBP) is 1050 MHz

Mixing the local oscillator and the input with a non-ideal mixer gives you:

IF1 = N*input +- M*LO

The strongest output spectra will be where N=1 and M=1. This gives you spectra centered at:

(a) Fin + FLO1
(b) Fin – FLO1

Since FLO1 is always greater than Fin, we get a nice strong first image (a) between 1050 and 2050 MHz.
The first negative image (b) is wrapped into the range of 0 to 1050 MHz. Subsequent energies are present at higher orders, however their amplitude is orders of magnitude lower than the main images.

After mixing, IF1 is filtered using a high-Q filter. Q, of course, is a measure of how wide the pass-band is.
Q = Fc/Fbw where Fbw is the -3dB bandwidth.

Common hobbyist spectrum analyzers[1][2] use cavity or helical filters.

A cavity filter has radiative elements (I’ll liberally call antennae) in a conductive can along with a resonator whose length can be changed. They can and often contain multiple cavities

Here’s a paper from M/A COM on cavity and helical filter design.


[1] Scotty’s Modularized Spectrum Analyzer
[2] Andrew Holme – Homebrew spectrum analyser

HF/VHF photodiode amplifier


Recently at work I was tasked with determining the frequency modulation of a laser beam. I designed and tested the above circuit in a couple hours.

I tested the circuit first with no photodiode in place using my DG8SAQ vector network analyzer — a very low cost network analyzer based on the highly respected (by me) AD9852 DDS chip.

The circuit showed >+20dB gain from about 4 MHz to the cutoff frequency of the RLP-137. Hooray for small victories!

For the photodiode, I had no choice because I just had one laying around here that I could find the part number for: a Melles Griot 13DSI001. This particular part has a responsivity of 0.45 Amps/Watt at 830nm, breakdown voltage of 60, and 10pF capacitance.

A photodiode is typically reverse biased as you see above, with a positive voltage on the cathode. In my case I don’t care very much about what voltage I’m using as long as I do not exceed the breakdown voltage (more about that coming up.)

As light becomes incident on the diode junction, carriers are created that allow current to flow from the high potential to the low potential. This holds true for high frequencies; a high frequency alternating current is allowed through the device.

When a current source is terminated into a resistor we get a voltage source having an impedance of the resistor value. The photodiode is terminated into a 50 ohm resistor, hence we have a fairly decent 50 ohm source that is converting light modulation into RF of a convenient impedance. The maximum frequency (as I understand) is limited by the 10pF intrinsic capacitance of D1, combined with the load resistance, R3. This gives a cutoff frequency of 1/(2*Pi*RC) of about 300 MHz. I may not have needed the lowpass filter (RLP-137), however with my shoddy perf-board construction I was worried about the GALI-74 potentially oscillating in the GHz range.

The 1k resistor R1 is to limit the maximum current that can pass through the photodiode. Combined with C3, this provides filtering from feedback or noise that could come through VCC.

I’d be happy to see your comments below if you have corrections or advice.

MMIC photodiode amplifier
MMIC photodiode amplifier

Setting up NFS client on Beaglebone black

Really short HOWTO here. I want to share files from my desktop running Ubuntu, to my Beaglebone Black, which is running Angstrom Linux. Here’s how I did it:

  1. Install nfs-server on the Ubuntu machine
# apt-get install nfs-kernel-server

2. Edit /etc/exports, adding this line:


3. Create the directory on the server side (as normal user)

$ mkdir /home/martin/beaglebone_nfs

4. Install nfs-utils-client on Beaglebone (Angstrom) side

root@beaglebone:~# opkg update
root@beaglebone:~# opkg install nfs-utils-client

5. Re[start] the NFS server on the Ubuntu side

# service nfs-kernel-server restart

6. Mount your NFS share on the Beaglebone side

root@beaglebone:~# mount -onolock -t nfs /mnt

7. And to make it mount every time you reboot, add a line to /etc/fstab: /mnt nfs defaults,nolock 0 0

8. Unmount and remount from fstab to ensure that you got the fstab line correct (without rebooting)

# umount /mnt
# mount -a
# df
Filesystem                                1K-blocks     Used Available Use% Mounted on
rootfs                                      1738184  1175444    472776  72% /
/dev/root                                   1738184  1175444    472776  72% /
devtmpfs                                     255280        0    255280   0% /dev
tmpfs                                        255408        0    255408   0% /dev/shm
tmpfs                                        255408      220    255188   1% /run
tmpfs                                        255408        0    255408   0% /sys/fs/cgroup
tmpfs                                        255408        4    255404   1% /tmp  22145024 15797248   5199872  76% /mnt

And there you have it.

Writing a PCI device driver

I’m writing a Linux device driver for the PCI/PCIe cards 5i25 and 6i25 available from MESA electronics[1]

I’ve never written a device driver before. Currently my driver does nothing except enable the PCI device, map the BAR0 to system address space, and check the “magic value” available in BAR0 + 0x100.

It then prints out all of the probed module descriptors that correspond to available hardware functionality.

The magic value is an arbitrary number to test that your driver is accessing the PCI device correctly.

The next step is to accept module load-time parameters and configure the board as desired. Mesa has made a very capable board with the HOSTMOT2 firmware[4]. It has many options and many configuration registers.

Beyond configuration, the driver will have to accept IOCTL calls from user programs and drive the 6i25.

Here’s the code:

 *  ni25.c
 * Author: Martin Klingensmith
 * Description: Driver for Mesa electronics 5i25 and 6i25 PCI[e] boards
#include <linux/interrupt.h>
#include <linux/pci.h>
#include <linux/slab.h>
#include <linux/module.h>	/* Needed by all modules */
#include <linux/kernel.h>	/* Needed for KERN_INFO */

#define DRIVER_AUTHOR "Martin Klingensmith <>"
#define DRIVER_DESC "A driver for MESA electronics 5i25/6i25 IO cards"
#define DRIVER_NAME "ni25"

#define MAGIC_NUMBER 0x55AACAFE	/* Magic number defined by Mesa */
#define LEDS_OFFSET 0x0200
#define IDROM_OFFSET 0x010C	/* Location of IDROM offset value */

struct ni25_idrom {
  u32			IDROMType;
  u32			OffsetToModules;
  u32			OffsetToPindesc;
  u32			BoardNameLow;
  u32			BoardNameHigh;
  u32			FPGASize;
  u32			FPGAPins;
  u32			IOPorts;
  u32			IOWidth;
  u32			PortWidth;
  u32			ClockLow;
  u32			ClockHigh;
  u32			InstanceStride0;
  u32			InstanceStride1;
  u32			RegisterStride0;
  u32			RegisterStride1;

struct module_descriptor {
  u8			GTag;		/*General function tag					*/
  u8			Version;	/*module version					*/
  u8			ClockTag;	/*Whether module uses ClockHigh or ClockLow		*/
  u8			Instances;	/*Number of instances of module in configuration	*/
  u16			BaseAddress;	/*offset to module. This is also specific register = Tag*/
  u8			Registers;	/*Number of registers per module			*/
  u8			Strides;	/*Specifies which strides to use			*/
  u32			MPBitmap;	/*bit map of which registers are multiple
					  '1' = multiple, LSb = reg(0)				*/

struct pin_descriptor {
  u8			SecPin;		/*Which pin of secondary function connects here 
					  eg: A,B,IDX. 
					  Output pins have bit 7 = '1'*/
  u8			SecTag;		/*Secondary function type (PWM,QCTR etc). 
					  Same as module GTag*/
  u8			SecUnit;	/*Which secondary unit or channel connects here*/
  u8			PrimaryTag;	/*Primary function tag (normally I/O port)*/

struct ni25_brd {
  unsigned long           paddr;
  void __iomem            *regs;	/* Board BAR0 mapped location */
  u32                     iolen;
  int                     irq;
  u16                     bus_num;
  struct device           *parent_dev;
  u16                     num_cs;         /* supported slave numbers */


struct ni25_dev {
  struct pci_dev *pdev;
  struct ni25_brd brd;
  struct ni25_idrom idrom;
  u32	idrom_offset;
  struct module_descriptor module[32];
  u32	num_modules;

 * ni25_pci_probe 
static int ni25_pci_probe(struct pci_dev *pdev,
	const struct pci_device_id *ent)
	struct ni25_dev *ni25;
	struct ni25_brd *brd;
	int pci_bar = 0;
	int ret;
	int v=0;
	void __iomem *regs;
	char name[9];

	printk(KERN_INFO "NI25: found PCI card (ID: %04x:%04x)\n",
		pdev->vendor, pdev->device);

	ret = pci_enable_device(pdev);
	if (ret)
		return ret;

	ni25 = kzalloc(sizeof(struct ni25_dev), GFP_KERNEL);
	if (!ni25) {
		ret = -ENOMEM;
		goto err_disable;

	ni25->pdev = pdev;
	brd = &ni25->brd;

	/* Get basic io resource and map it */
	brd->paddr = pci_resource_start(pdev,pci_bar);
	brd->iolen = pci_resource_len(pdev, pci_bar);

	printk(KERN_INFO "NI25: address %04x length %04x\n",(unsigned int)brd->paddr,(unsigned int)brd->iolen);

	ret = pci_request_region(pdev, pci_bar, dev_name(&pdev->dev));
	if (ret)
		goto err_kfree;

	regs = ioremap_nocache((unsigned long)brd->paddr,
				pci_resource_len(pdev, pci_bar));
	brd->regs = regs;

	if (!brd->regs) {
	       printk(KERN_INFO "NI25: ioremap_nocache call failed.\n");
		ret = -ENOMEM;
		goto err_release_reg;

	/* Read magic number from card register */
	v = readl(regs + 0x100);
	if(v != MAGIC_NUMBER){
	  printk(KERN_INFO "NI25: unknown magic number. %04x != %04x\n",MAGIC_NUMBER,v);
	  ret = -1;
	  goto err_unmap;

	/* Get configuration name */
	  name[v] = ioread8(regs+0x104+v);
	printk(KERN_INFO "NI25: config name: [%s]\n",name);

	ni25->idrom_offset = ioread32(regs+IDROM_OFFSET);

	printk(KERN_INFO "NI25: idrom offset: %04x\n",ni25->idrom_offset);

	/* Read IDROM */
	memcpy(&ni25->idrom,regs+ni25->idrom_offset,sizeof(struct ni25_idrom));

	printk(KERN_INFO "NI25: modules offset: %04x\n",ni25->idrom.OffsetToModules);

	/* Read all modules descriptors */
	memcpy(ni25->module,regs+ni25->idrom.OffsetToModules + ni25->idrom_offset,0xC * 32);

	      ni25->num_modules = v-1;
	    printk(KERN_INFO "NI25: module %d \n\tGTag=[%04x]\n\tVersion=[%04x]\n\tClockTag=[%04x]\n\tInstances=[%04x]\n\tBaseAddress=[%04x]\n\tRegisters=[%04x]\n\tStrides=[%04x]\n\tMPBitmap=[%04x]\n"\
							    ,v,ni25->module[v].GTag, \
							    ni25->module[v].Version, \
							    ni25->module[v].ClockTag, \
							    ni25->module[v].Instances, \
							    ni25->module[v].BaseAddress, \

	printk(KERN_INFO "NI25: found %d modules.\n",ni25->num_modules);

	brd->parent_dev = &pdev->dev;
	brd->bus_num = 0;
	brd->num_cs = 4;
	brd->irq = pdev->irq;

	pci_set_drvdata(pdev, ni25);
	return 0;

	pci_release_region(pdev, pci_bar);
	return ret;

 * ni25_pci_remove 
static void ni25_pci_remove(struct pci_dev *pdev)
	struct ni25_dev *ni25 = pci_get_drvdata(pdev);
	printk(KERN_INFO "ni25: unloading...\n");
	pci_release_region(pdev, 0);
 * ni25_suspend */
#ifdef CONFIG_PM
static int ni25_suspend(struct pci_dev *pdev, pm_message_t state)
	pci_set_power_state(pdev, pci_choose_state(pdev, state));
	return 0;
/* ni25_resume */
static int ni25_resume(struct pci_dev *pdev)
	u32 ret=-1;
	pci_set_power_state(pdev, PCI_D0);
	ret = pci_enable_device(pdev);
	if (ret)
		return ret;
	return 0;
#define spi_suspend	NULL
#define spi_resume	NULL

/* Documentation */

static DEFINE_PCI_DEVICE_TABLE(pci_ids) = {
	/* Intel MID platform SPI controller 0 */
	{ PCI_DEVICE(0x2718, 0x5125) },

static struct pci_driver ni25_driver = {
	.name =		DRIVER_NAME,
	.id_table =	pci_ids,
	.probe =	ni25_pci_probe,
	.remove =	ni25_pci_remove,
	.suspend =	ni25_suspend,
	.resume	=	ni25_resume,


Here are the dmesg lines when the module is loaded:

[64520.720535] NI25: found PCI card (ID: 2718:5125)
[64520.720553] NI25: address fe700000 length 10000
[64520.720606] NI25: config name: [HOSTMOT2]
[64520.720610] NI25: idrom offset: 0400
[64520.720635] NI25: modules offset: 0040
[64520.720771] NI25: module 0 
[64520.720771]  GTag=[0002]
[64520.720771]  Version=[0000]
[64520.720771]  ClockTag=[0001]
[64520.720771]  Instances=[0001]
[64520.720771]  BaseAddress=[0c00]
[64520.720771]  Registers=[0003]
[64520.720771]  Strides=[0000]
[64520.720771]  MPBitmap=[0000]
[64520.720783] NI25: module 1 
[64520.720783]  GTag=[0003]
[64520.720783]  Version=[0000]
[64520.720783]  ClockTag=[0001]
[64520.720783]  Instances=[0002]
[64520.720783]  BaseAddress=[1000]
[64520.720783]  Registers=[0005]
[64520.720783]  Strides=[0000]
[64520.720783]  MPBitmap=[001f]
[64520.720794] NI25: module 2 
[64520.720794]  GTag=[0004]
[64520.720794]  Version=[0002]
[64520.720794]  ClockTag=[0001]
[64520.720794]  Instances=[0002]
[64520.720794]  BaseAddress=[3000]
[64520.720794]  Registers=[0005]
[64520.720794]  Strides=[0000]
[64520.720794]  MPBitmap=[0003]
[64520.720805] NI25: module 3 
[64520.720805]  GTag=[00c1]
[64520.720805]  Version=[0000]
[64520.720805]  ClockTag=[0001]
[64520.720805]  Instances=[0001]
[64520.720805]  BaseAddress=[5a00]
[64520.720805]  Registers=[0006]
[64520.720805]  Strides=[0010]
[64520.720805]  MPBitmap=[003c]
[64520.720816] NI25: module 4 
[64520.720816]  GTag=[0006]
[64520.720816]  Version=[0000]
[64520.720816]  ClockTag=[0002]
[64520.720816]  Instances=[0002]
[64520.720816]  BaseAddress=[4000]
[64520.720816]  Registers=[0005]
[64520.720816]  Strides=[0000]
[64520.720816]  MPBitmap=[0003]
[64520.720828] NI25: module 5 
[64520.720828]  GTag=[0005]
[64520.720828]  Version=[0002]
[64520.720828]  ClockTag=[0001]
[64520.720828]  Instances=[0008]
[64520.720828]  BaseAddress=[2000]
[64520.720828]  Registers=[000a]
[64520.720828]  Strides=[0000]
[64520.720828]  MPBitmap=[01ff]
[64520.720839] NI25: module 6 
[64520.720839]  GTag=[0080]
[64520.720839]  Version=[0000]
[64520.720839]  ClockTag=[0001]
[64520.720839]  Instances=[0001]
[64520.720839]  BaseAddress=[0200]
[64520.720839]  Registers=[0001]
[64520.720839]  Strides=[0000]
[64520.720839]  MPBitmap=[0000]
[64520.720848] NI25: found 6 modules.



[1] Mesa Electronics

[2] The Linux Kernel Module Programming Guide

[3] How To Write Linux PCI Drivers by Martin Mares <> on 07-Feb-2000

[4] LinuxCNC Documentation wiki


New L6470 Stepper motor controller board in progress.


Coming soon

4 Channels L6470

USB interface (micro USB)
8 MHz oscillator for L6470 and PIC microcontroller (PIC24FJ64GB002)
Header for external SPI interface if using Arduino or different microcontroller board.
Headers for step and direction interface, for microcontroller or parallel port PC interface.


I haven’t worked on this since October 2, 2013 (and it’s now January 21, 2014) so I’m uploading the Eagle [6] design files for you to use as you see fit. If you actually build this board I would love to see how it comes out!

NOTE: I have NOT tested this board design but I believe it works. I am a professional but that doesn’t mean my work is flawless.

 EAGLE files for this board

DDS Board Revision 2

Recently I created revision 2 of my DDS board:

2013-09-19 14.32.40

The board is basically the same as the last one I wrote about.

On this board I used Mini-Circuits filter modules instead of my homebrew RLC filters. They offer better high frequency performance than I could achieve on my own. Here’s a plot of the filter response, as tested with my VNWA:



The filters allow a usable output from about 40 MHz to 110 MHz. By bypassing the high-pass filter, I can get a usable output from near-DC to 110 MHz.


This board is part of a much larger project. You might have noticed that one PCB is stacked onto the other PCB. The board on the left is a module that will be plugged into a large VME board. The purpose of building the right-side board was to test the module.

USB Interface and control

I’ve done several USB projects, starting back when I worked at Embed Inc. I decided it would be fun to make this a USB controlled board. The microcontroller is a PIC24FJ128GB106 from Microchip. It has a high-speed USB interface. Microchip provides sample code for various interface methods.

I chose to make this a CDC (Character Device Class) because it makes writing the PC software easier. A CDC device presents itself as a VCP (Virtual COM Port) on Windows, and I believe on Linux as well. This means I don’t have to write a device driver or utilize WinUSB or Libusb in order to communicate with the hardware.

I started out with a basic MFC program that I had written to query a laser over it’s diagnostics port, and modified it to control my PIC firmware that, in turn, controls the AD9852. The program is very basic at this point, but the structure now exists to do just about anything with it. I’m not personally invested in amateur radio, but I imagine this could be interesting for creating directly-modulated RF carriers. This board can directly output an RF signal that is amplitude, frequency, on-off, or phase keyed.


In my free time I am working on another version of this board that I may make available to the community. Please leave a comment if you’re interested.



DDS Board testing



I mentioned that I was building a DDS (Direct Digital Synthesis) board for work. Here’s the result:


2013-04-11 09.34.43


Yes that’s a giant block of aluminum that it’s attached to. It keeps the board from sliding around with all those cables attached to it.

It seems to work quite well. The first thing I tested was the bandpass filter. I designed it to have a center of 100 MHz and a bandwidth of 80 MHz. What do you know? Sometimes things work out:



That looks pretty decent to me, but I’m not an RF expert.

Now a chart of the output with the MMIC fully powered up. The AD9852 is being clocked at 260 MHz instead of the desired 300 MHz (for a reason I’ll describe below.) The AD9852 is programmed to output a fundamental frequency of 100 MHz in this test.



I thought I had a screen shot zoomed in on the 100 MHz peak, alas I do not. The noise floor when zoomed in is much better than the spectrum analyzer shows in the above plot (I promise.)

I had to run the AD9852 at 260 MHz carrier instead of 300 MHz because the LMK03001C chip I am using cannot output a 300 MHz clock, given a frequency of 20 MHz. The PLL configuration for the LMK03001C is very flexible, just not quite enough for this. For the next board I am switching to the LMK03000C which has a slightly different VCO. It’ll work.

This synthesizer was a test for my next big project: a huge VME bus board that has 4 AD9852 channels on it. I’m proud to say that this test succeeded.