Andrew Starr's STM Project Journal

Welcome to my STM Project

This site documents my efforts to design and construct a Scanning Tunnelling Microscope. It is
intended to be a resource for others who have a similar interest.
 
The design goals of the project are:

• an instrument capable of:
  1. Atomic resolution at room temperature and in ambient air (with a suitable sample).
  2. Surface modification and lithography experiments.
• All waveform generation and feedback control to take place in the digital domain.
• Microscope hardware to be of a compact and easy-to-operate design.
• Microscope operation to be highly automated.

Current Task (as at 26/12/2009): Writing a comms framework for the firmware and loading the Piezo HV PSU board

Brief Outline of the Comms Protocol (”STMbus”)

The STM requires a communication protocol to exchange commands and data with the operator interface on the host PC, and will be known hereafter as ‘STMbus’.

 

Request and Response

 

Commands and data are encoded into formatted message frames and sent via TCP/IP over a dedicated ethernet link. Communication between the STM and host PC consists of pairs of messages, a request message and a response message. Either party may initiate a request, but every request must have an acknowledgement response from the other.

 

Message Frame Format

 

I have decided to base the Message Frame on ASCII-mode MODBUS (with a few differences, detailed below).

 

Frame Start	Function Code	Data Length	Data	LRC	Frame End
1 char, ‘:’	2 chars	4 chars	0-65535 chars	4 chars	2 chars, CR+LF

 

Encoding

 

Each byte in the message frame is encoded as 2 chars e.g. 0x4D becomes encoded as 0x34 0x44 (‘4’ ‘D’). This encoding, with the printable ‘:’ denoting the start of a frame and a CR/LF denoting the end, was chosen to make debugging and development easier by allowing the use of text-manipulation tools. The loss of efficiency is not regarded as significant due to the speed of ethernet and the relatively small volumes of data being exchanged.

 

Field Description

• Frame Start indicates the start of a message frame and is a single colon (:).
• Function Code indicates the action or service required. A response message sets this to the same Function Code in the original request message. If the response needs to indicate an error condition, the MSB of the Function Code will be set to 1.
• Data Length is the number of encoded bytes (chars / 2) in the Data field.
• Data contains the parameters, arguments and other information associated with the Function Code action.
• LRC (Longitudinal Redundancy Check) is an error-checking field. It is the result of a computation performed on the bytes of the message frame before they are encoded, excluding the Frame Start and Frame End. It is calculated by successively adding the bytes together, discarding any carries, and then two’s complementing the result.
• Frame End indicates the end of the message frame, and consists of a carriage return (0x0D) followed by a line feed (0x0A).

Differences from MODBUS ASCII-mode

• The Data Length field has been extended to 4 chars (2 bytes) and is always present in the message frame (instead of being an optional part of the Data field).
• The maximum length of the Data field has been extended to 64k chars (32k bytes).
• The LRC has been extended to 4 chars (2 bytes)

Piezo Amp HV Supply Rev A PCB has arrived

The PCB has arrived and Sierra have done their usual high-quality job. I'll be loading the PCB
manually, except for the switchmode IC U3. This is a DFN package, and can only be soldered with
tools that I don't have. Fortunately a friendly contract-manfacturing company that my employer uses
will do it as a favour - yay!

I'll be posting more pics of the loading of this PCB soon.

Microcontroller-side socket listener

Ok, got a simple network service running on the micro board. All it does is listen on port 8080 for incoming connections, and when there is one, echos back text strings that the client sends it. So now I need to add some code to the Java applet to open a socket, send some strings, and check they're echoed back. Then I can start thinking about a format for the STM comms protocol.

Piezo Amp Rev A Design Complete

Here is a PDF of the schematic and PCB of the piezo amp. I'm getting a little ahead of myself with the electronic design - time to turn my attention back to the software while I wait for the HV power supply PCB to arrive. I have a basic 'hello world' Java applet already, now I need to add functionality for opening a network socket back to the microcontroller board.

Preliminary Piezo Amp Schematic Complete

The heart of the amplifier is a LTC1650 16-bit DAC driven in unipolar mode with a precision 3.0V reference. The voltage output is fed to a pair of low-noise op amps (OPA452) in a differential configuration with a gain of 11. The amp should have a full-scale output of 66V.

The waveform data is sent to the DAC via an optoisolated SPI interface. The optoisolation, combined with the isolated supplies, should ensure that there are no ground loop issues, or excess noise pickup from the microcontroller board.

Datasheet for LTC1650

Download PDF of PIEZO AMP Rev A Schematic

I'll post a final schematic when the PCB is complete

Piezo High Voltage PSU complete

I've finished laying out the PCB. PDFs of the PCB and Schematic can be downloaded here.
I get my PCBs made by Sierra Circuits (www.protoexpress.com), using their No touch service. Their Auto
File Verification system catches most silly mistakes, there's no setup charge and the quality
is always excellent.

While the PCB is being made (2-3 weeks), I'll be working on the design of the Piezo driver amp.

Piezo Amp HV Supply Component Update

• L1,2,3 changed to Wurth Elektronik 744773122 (22uH, 1A)
• D1,2 changed to Motorola 1N5819 (40V, 1A)
• 12V DC supplied by Tracopower TEN5-2412WI isolated DC-DC converter module
• LED to indicate when power has been applied to the DC-DC converter module

These changes have been made to reduce the layout size of the switchmode and to eliminate the need for a separate PCB for the isolated 12V supplies in the prototype rig. These changes have no (simulated) effect on the performance of the supply.

I'll post an updated schematic along with the PCB, once completed.

Schematic for HV Piezo Amp Supply

This is the complete schematic for the piezo amp HV power supply. It is supplied with 12V fom an isolated DC-DC converter module (not shown). The 12V is regulated by a LM317 down to 9V to avoid stressing the LT3471. The LT3471 generates +/-37V which is in turn regulated via linear regulators (LM317 and LM337) down to +/-35V.

Download PIEZO AMP HV PSU Rev A

Simulation of Piezo Amp High Voltage Supply

The STM needs a supply of high positive and negative voltage to power the amps that drive the piezo tube. I have chosen a switchmode design to avoid the need for mains power (with its obvious hazards) and large transformers (magnetic fields). The particular switchmode IC I have selected switches at 1.2MHz, so switching transients are at high frequencies that can be easily filtered. The design is physically compact and high current loops are very small. I have incorporated many similar supplies in designs with sensitive analogue circuitry and have invariably found their performance to be excellent.

 

The power supply will be built around the Linear Technology LT3471, a dual supply IC that can accommodate both boost and inverting topologies. The simulation was done with LTSpice IV, which can be downloaded from the website. It's a great tool and can save you a lot of aggravation!

Download LT3471 datasheet

I've chosen the switchmode regulated output to be +/-37V, a couple of volts over the stated design goal of +/-35V. This is because I will be following the switchmode outputs with linear regulators to improve the transient response.

 

The supply will need to be capable of sourcing enough current to enable the amps to drive the capacitance of the piezo tube. The approximate capacitance of the tube (assuming a length of 25mm and outer diameter of 6mm) will be on the order of 15nF (depending on wall thickness and piezo material). Assuming a worst case of:

 

• 1 kHz scan frequency (extremely unlikely in practice)
• Amps driving full capacitance of tube
• Driving waveform +/-35V peak

 

The tube has an impedance of 1 / (2 * pi * 1 kHz * 15nF) = ~11kOhms.

Under worst-case scan conditions the supply must source a peak current of around 6mA. I’ll set the maximum designed current to be 100mA, so that even if my estimates are an order of magnitude out(!) the supply will still cope comfortably.

 

Here's the schematic: 

The soft-start components R5/C5, R6/C6 and inductors L1,L2,L3 have been chosen to keep the peak currents in the switching loops well below the 1.3A limit of the internal switches of the LT3471. Feedback resistor dividers R1/R2 and R3/R4 have been chosen to set the voltage outputs at +/-37V. MBRS360 is a 3A Schottky diode with 60V reverse voltage rating. I have set the loads to be 370 Ohms to be sure the supply is capable of 100mA output. The compensation capacitors C4 and C8 are set to their ideal theoretical values (calculated), but there will probably be some experimentation required to find the best compromise between transient response and stability.

 

And here's the simulated response:

The supply is up and running in about 14ms. The peak inductor current is just under 1A during startup, setting down to around 700mA for L1 and L2.

 

The next step is to lay out the schematic and get a PCB made.

Web and FTP services working

I now have Web and FTP services working concurrently under the uC/OS-II kernel. They are using the serial flash as a file store (FAT16). I also have an 'LED blinker' task running at the same time to function as a 'heartbeat' so that I know everything is fine with the kernel while I'm testing Web and FTP. The RCM5700 has successfully served a 'hello world' Java applet to my browser - the next step is to have the applet make a socket connection back to a listening task on the RCM5700.