Using Tikz in LaTeX to draw a Yee Cell

One of the numerical methods used to simulate electric and magnetic fields is known as the finite  difference time domain (FDTD) method.  In the application to Maxwell’s laws, this method starts by exploding the differential form of Faraday’s law and the Ampere-Maxwell law, the two curl equations in Maxwell’s equations, into  6 coupled partial differential equations.  Then the equations are discretized and the derivatives approximated with finite difference approximations.  If you’re interested in learning more, I highly recommend Dr. Rumpf’s course on the subject.

The purpose of this post is to share some tikz code for drawing a ‘Yee Cell.’  The Yee Cell describes the way that the vector field components must be arranged in a discretized grid to arrive at a stable implementation (the method uses central finite differences so the E & H fields must be staggered so that the finite difference exists in the middle).  The result of the Tikz code is shown below.

Let me know if you have any recommendations for improvements or if you’ve found this useful.  One thing that could be done for the sake of completeness (and the expense of clarity) is to draw the vectors of adjacent cells where they correspond on this cell.

Here is the code:

% * ----------------------------------------------------------------------------
% * "THE BEER-WARE LICENSE" (Revision 42):
% * <bob@bobadams5.com> wrote this file.  As long as you retain this notice you
% * can do whatever you want with this stuff. If we meet some day, and you think
% * this stuff is worth it, you can buy me a beer in return.   Bob Adams
% * ----------------------------------------------------------------------------

\documentclass[12pt]{article}

\usepackage{tikz}
\usepackage{tikz-3dplot}

\begin{document}

\begin{section}{Yee Cell}
\begin{figure}[!h]
\centering
\tdplotsetmaincoords{60}{120}
\begin{tikzpicture}[scale=3,tdplot_main_coords]

% Coordinate axes
\draw[thick,->] (0,0,0) -- (2,0,0) node[anchor=north east]{$x$};
\draw[thick,->] (0,0,0) -- (0,2,0) node[anchor=north west]{$y$};
\draw[thick,->] (0,0,0) -- (0,0,2) node[anchor=south]{$z$};

% Draw the cell outline
\draw[dashed] (1.5,0,0) -- (1.5,1.5,0);
\draw[dashed] (1.5,1.5,0) -- (1.5,1.5,1.5);
\draw[dashed] (1.5,1.5,1.5) -- (0,1.5,1.5);
\draw[dashed] (0,1.5,1.5) -- (0,1.5,0);
\draw[dashed] (0,1.5,0) -- (1.5,1.5,0);
\draw[dashed] (1.5,1.5,1.5) -- (1.5,0,1.5);
\draw[dashed] (1.5,0,1.5) -- (1.5,0,0);
\draw[dashed] (1.5,0,1.5) -- (0,0,1.5);
\draw[dashed] (0,0,1.5) -- (0,1.5,1.5);

% Draw arrows for E field
\draw[ultra thick, color=blue,->] (0,0,0.4) -- (0,0,0.7) node[anchor=south east]{$E_z$};
\draw[ultra thick, color=blue,->] (0,0.4,0) -- (0,0.7,0) node[anchor=north east]{$E_y$};
\draw[ultra thick, color=blue,->] (0.4,0,0) -- (0.7,0,0) node[anchor=north west]{$E_x$};

% Draw arrows for H field
\draw[ultra thick, color=red,->] (0.75,0.75,0) -- (0.75,0.75,0.3) node[anchor=north east]{$H_z$};
\draw[ultra thick, color=red,->] (0.75,0,0.75) -- (0.75,0.3,0.75) node[anchor=north east]{$H_y$};
\draw[ultra thick, color=red,->] (0,0.75,0.75) -- (0.3,0.75,0.75) node[anchor=north west]{$H_x$};

\end{tikzpicture}
\end{figure}
\end{section}
\end{document}


Probing the Microsoft Arc Touch Mouse for its code

Around November of last year (2015), I bought a new laptop.  To complement this new laptop I decided on the Microsoft Arc Touch Bluetooth mouse, which was on sale for Cyber Monday from Amazon.  After two short days of amazing prime shipping, I received my mouse and set it up.  Nothing happened.  I tried my old laptop – still nothing.  Work laptop, friends laptop, my desktop, everything refused to even see the mouse as a Bluetooth device, let alone connect to it.  So, being determined to get something out of the mouse instead of returning it (and summoning the spirit of Dave Jones), I popped it open.

Overview

There are two PCBs in the mouse – one rigid and one flex.  By quick inspection it looks like the rigid PCB controls the BLE functions, the reset button, the mouse buttons, the mouse laser LED, and the power conditioning for the mouse.  The other PCB appears to be for the capacitive sensing mouse wheel and the top status LED.  The haptic feedback item is mounted on the same plastic as the flex PCB but has a wire to the rigid PCB where it is probably controlled.

The design appears to be done by a Taiwanese company called Foxlink.  The brains of the device are split into two microcontrollers:

1. Nordic nRF51822 – Mounted on the rigid PCB.  This IC features an ARM Cortex-M0 core and an embedded 2.4GHz transceiver.  They used the QFAB version in a QFN48 package.  This version of the chip features 128kB of ROM, 16kB of RAM.
2. Cypress CY8C20346A – Mounted on the flex PCB.  This IC features an 8-bit M8C core and 17 analog sensing inputs for capacitive touch buttons/sliders.  The variant they’ve used comes in a QFN24 package with 16kB of ROM and 2kB of RAM.

The first IC is particularly interesting from an embedded software perspective since it can have its firmware extracted regardless of protection settings.

nRF51822

Disassembling this product got even better when I flipped over the rigid board and found 4 testpoints neatly laid out in a column.  This happens to be the minimum number of test points needed for accessing the SWD debug interface for the chip.  After a little bit of probing with a multimeter the function of testpoints was determined.

With this information I am able to make the connections to my STLINK/V2 SWD debugger and poke around inside of the chip.  My first attempts at this failed since it appears that there was something wrong with the power conditioning on my mouse which was probably why I couldn’t ever detect it.  After wiring in an external power supply I was able to successfully connect to the target.

Now that I was connected I could talk to the IC and check its protection bytes.  This is controlled by the readback protection register at 0x10001004:

> mdw 0x10001004
0x10001004: ffffffff

All 1’s – awesome!  There are no regions of the code that have readback protection enabled.  One little command in openocd and the code region is mine:

dump_image test.bin 0x00000000 262144

Now I have a nice assembly file that I can examine with arm-none-eabi-objdump.  Hopefully with this I can determine the communication protocol between the two boards.

Cypress CY8C 20346A

The Cypress part does not use the SWD debug interface but instead uses an interface called ISSP, which stands for In-System Serial Programmer.  This interface is not currently supported by openocd and my STLINK/V2 so I had to get a MiniProg1 and download Cypress’ PSoC Programmer software.  With these tools in hand I went to work determining where I could access the 5 signals needed for ISSP:

Unfortunately at this point I hit a roadblock.  All of the code in the Cypress chip is fully protected.

So this is where I have to shelf the disassembly of the Cypress IC.  If you have any ideas for bypassing the security of the Cypress Capsense IC, please get in contact with me.

Flashing the nRF51 with ST-LINK/v2 and openocd

The intention of this post is to aggregate and clear up some of the information available on-line regarding using the ST-LINK/V2 to interface with Nordic Semiconductors nRF51822.  This setup is nice because it allows you to use a tool that costs less than half of the standard SEGGER J-LINK education edition tool.

The Hardware

Starting off with the obvious, you will need an ST-LINK/V2.  This comes in multiple forms – embedded on a development board (as shown in this tutorial) or as a standalone programmer:

Adventures in data – creating & analyzing a South Park dataset

Since I completed the material in Coursera’s Machine Learning MOOC last year I’ve been searching for an interesting dataset to play with.  There are tons of options out there – MNIST, US Baby names, etc. – but they don’t give me a chance to play with data collection and cleaning.

Luckily the Internet is full of data that can be repackaged for interesting purposes.  As a fan of south park I decided to grab the script data and find some analyses to run.  In this post I will explain my methodology and share the results of the analysis.

WARNING: This post will contain adult language due to the content of south park.

Testing the Shikra – I2C Master

A few weeks ago I attended my first Duo Tech Talk in Ann Arbor, Michigan.  The talk was titled “The Insecurity of Things” and was presented by Stephen Ridley of Xipiter.  The talk was fantastic and can luckily be found online.  I liked what I saw so much I went and bought a USB-to-Serial product offered by Xipiter called the Shikra.

Unfortunately it looks like the Shikra is a glorified FT232H breakout board (at 2x the price) with very limited documentation.  This post is my attempt to fix their public documentation hole while testing the board as an I2C master.

First pass at a 7.4V to 5V Buck Converter

If you’ve ever needed to use an RC battery before you know that LiPo battery cells come in annoying, not-standard-digital voltages (1S = 3.7V, 2S = 7.4V, and so on.)  To remedy this for some of my projects I decided to build a buck converter to convert a 2S battery pack to 5V.

A handheld implementation of the “Cyclone” arcade game

If you’ve been to an arcade in the last ten years you’ve probably seen the game with a circular track of lights where the lights illuminate in sequential order, racing around the circle.  Your objective is to hit a button and stop the rotation when the light gets to a certain spot.  Accomplishing this will get you a nice bunch of tickets – probably with substantially less value than you put into the machine.

For some fun I decided I wanted to implement this game on a PCB – LEDs are fun and this has the potential for a lot of them (although I only went with 40 because board space gets expensive….)

OSS Tools for a HW Development Workflow – Part 1. Schematic Entry

When you work in a professional engineering environment you are familiar with many expensive software packages.  These range from relatively cheap solutions like the Microsoft Office Professional package (only $399!) to absurdly expensive CAD packages like Cadence Allegro (without getting a quote I believe other estimates which place it over$20,000 for a single license).

This series of posts is intended to examine free alternatives that allow you to generate some common hardware engineering work packages.  This first post covers schematic entry and considers the interface to other work packages that come later in the work flow (simulation and PCB layout both require schematic entry).

Discovering stdout’s buffer

Happy thanksgiving break everyone!

For this break I’ve been working on a goofy little program in C to test timed output (seconds can be done with sleep(), microseconds with usleep(), etc).  Unfortunately I immediately discovered a problem in a test program for counting to 3 when the program waited three seconds and then immediately printed out the entire line.

After some investigation I discovered this is because stdout is line-buffered.  This means that it won’t output until it reaches the newline character ‘\n.’  This can be solved by disabling the buffering with:

setbuf(stdout,NULL);

Alternatively, the buffer can be flushed at custom times by forcing it with:

fflush(stdout);

With these considerations in mind excellent Karaoke-esque programs can be made for the command line.  You can even try it with everyone’s favorite Rick Astley tune:

Source on github.

Repairing a Metcal MX500

After working in the automotive electronics industry for five years I have come to realize there is one true king among soldering irons – Metcal.   Unfortunately this excellence doesn’t come cheap and used sets can run around $400 on eBay. Broken ones are cheaper (<$100) but you need to be able to take them apart and try to calibrate them.  This is a short guide to the repair process that I recently completed on my Metcal MX500.