Inkscape is a free vector graphics editor for all major platforms, generally it is aimed at art and design users but it does have an option for generating G-Code for use in your favourite CNC software. While Inkscape doesn’t have many of the functions of proper CAD/CAM software it is an relatively easy place to start for creating basic designs, I have been using it to make boxes out of 3.5mm plywood.
These notes are based around my cheap CNC machine sold as an CNC3018 by a variety of Chinese manufacturers on Amazon and eBay, the included controller is a Woodpecker CNC board (Ardunio clone) I have upgraded to GRBL v1.1 and I am using version 0.92.4 (April 2019) of Inkscape with the included Gcodetools.
This post focuses on setting up Inkscape for the CNC machine and producing the g-code from your drawing, it is not intended to be an Inkscape tutorial.
With a new drawing set your Document Size, this should be the same as your CNC bed, in my case this is 300 x 180mm. From the Inkscape menu go to File > Properties and in the Page Tab set the Display Units (millimeters in my case), the Orientation to Landscape and Page Size width: 300 and height: 180. In the Grids Tab set the Grid Units to mm and the Spacing X and Spacing Y to 1.0. Back on your main page, turn the page grid on with: View > Page Grid.
By default Inkscape scales the stroke/line width when you resize a shape, to prevent this click the the fourth box from the right in the top icon bar “when scaling objects, scale the stroke width by the same proportion”
You can save this as a template, such as: CNC3018.svg or as the document default with: default.svg by saving the file to your templates directory:
On Linux and OS X: ~/.config/inkscape/templates/
On Windows: C:\Users\<username>\AppData\Roaming\inkscape\templates
The lines you draw will need to be the same width as the bit you are using in the CNC machine. Draw a rectangle, Right mouse click on the rectangle and select Fill and Stroke…. In the Fill Tab click the X – no paint box and on the Stroke Style tab set the width to that of the bit you are using – 1.5mm, subsequent rectangles will be in the same style, other shapes will need to be setup this way too. The colour of your lines should be black, there is some functionality for different colours to represent different depths but I have not yet worked out how to do this.
Layout Tips for G-Code Routing
Remember to check the dimensions of the cuts, with an outside cut such as the width and height of a box side you need to measure for the inside of your rectangle, for holes in your box measure to the outside edge, Inkscape sets distances to the outside edge.
For positioning holes for switches and the like, I add thin lines 0.1mm thick as guides and make use of the width/height settings as well as the Object > Align and Distribute options. A pair of digital vernier calipers are a great aid to discovering the required sizes. Remember to delete these before G-Code encoding.
When generating the G-Code each shape will be seen as an individual object, so lets say you want to have two sides of your box cut from a single sheet of plywood, this would be two rectangles abutting each other with a side to be cut overlapping. As it takes four passes to cut each shape 1mm at a time, this means it’ll take six passes down the centre. To fix this select both rectangles and then Path > Combine followed by Path > Difference to make a single object.
Outputting to G-Code
Now that you have completed your drawing, save your work then convert your objects to paths by selecting all objects then Path > Object to Path. You may also want to place your drawing near the bottom left of the document, as this is where the CNC router starts. Now using Gcodetools there are three things you need to do to produce the G-Code file. None of the Gcodetools windows close automatically when apply is clicked, you will need to do that yourself. From the Inkscape menu:
1. Extensions > Gcodetools > Tools Libary…
Select Tools Type: cylinder and click apply In the overlarge green box that appears you will need to set the tool diameter and feed speed.
This can be a bit fiddly as the text can become detached from the box and the settings lost, what seems to work most reliably for me is to change to Text Objects (F8) click on the numbers you want to change and once done go back to Select and Transform (F1). Resize the box afterwards to check that it is still working – if the green box moves but the text does not then Ctrl-Z a few times and try again.
tool bit diameter in mm
speed while cutting through the material in mm/second
Plunge speed in the material in mm/second
Depth of cut on each pass in mm
2. Extensions > Gcodetools > Orientation Points
This tells the g-code where to start, normally bottom-left on the CNC Set the following:
– Orientation type: 2-points mode
– Z Surface: 0mm – this is the top of your surface
– Z Depth: -3.4mm – this is the thickness of material to cut, a negative number
3. Extensions > Gcodetools > Path to Gcode
This creates the G-code file, in the Preferences Tab set the following:
– File: output filename
– Directory: output directory
– Z safe height: 5mm – height above the work surface when moving between cuts
The filename once set doesn’t change, an incremental number is appended to the output filename. Click the Path to Gcode Tab before clicking apply (this appears to be a bug).
Your image will be updated to show the g-code routing, give this a visual check to ensure that all objects have been coded and that it looks right, the path to be taken should be in colour and contain arrows showing the direction of the router.
If there are too many arrows or if a line has arrows pointing in different directions then there may be an object underneath, check on your original artwork, in the image with the three circles below you see that A has not been converted to a path with Path > Object to Path, B has a duplicate object underneath and C is correct.
The generated G-Code does not appear to include the Spindle Motor Start command – So remember to start the spindle manually in your CNC software before running the G-Code – its interesting how easily these bits break with a sideways load. Remember if you are cutting trough rather than engraving, don’t forget to put a layer to sacrifice between whatever you are making and the CNC’s bed, I use 5mm MDF/Fibreboard.
In this video I am adapting a sewing machine pedal to provide variable speed to my small Dremel drill. It’s not really suitable as the pedal is only rated to handle 80 Watts (0.42 Amps at 240 Volts) while the Dremel can take up to 125 Watts (0.52 Amps) of power, it should be alright for light work.
To control the power the footpedal has two stacks made of loose carbon disks, initially when the pedal is pressed power is passed through these and as more pressure is applied these compress to lower the resistance and allow more power through. When fully on, a metal disc engages across two contacts to allow all the current to pass. I think I would like to have a pedal that could handle more current, possibly something based around how a modern dimmer switch works.
Back in April 2016 I posted details on how a Vacuum Fluorescent Display (VFD) works and a method of driving it from an Arduino type microcontroller using transistors, while this worked well it made for a rather bulky clock. I have now rebuilt the display using proper VFD driver chips, added a rotary switch with LED’s, NeoPixel capability and used a WeMos D1 Mini microcontroller to give me internet access over WiFi so the time and date can be set using the Network Time Protocol (NTP).
This rebuild is much more practical than previously, it is now about 3cm deep and comprises of two boards back to back with pin header plugs/sockets as the interconnects. I have been running the clock for over a year without any problems, apart from having to switch the thing off and back on when Daylight Savings Time changes in the spring and autumn, but that’s a software (lazy programmer) problem.
Three different voltages are needed to operate this clock, 16 Volts for the VFD display anodes, 5 Volts for the microcontroller and NeoPixels and 3.3 Volts for the VFD cathode and other hardware.
From the 12 volt source, I split the power to a XL6009 boost module to supply 16V to the driver IC’s, the 5V power module can supply up to 5A which is enough for around 2 meters of NeoPixels. The 3.3V supply is created using a BA033T fixed voltage regulator running from the 5V module, I have used this to power the VFD cathode, the rotary encoder and VFD driver IC’s as this is the microcontrollers operating voltage.
Driving the Display
To drive the anodes on the VFD display I used three MAX6920 Tube Drivers, these have a four wire serial interface and can switch up to 76V on the display.
The physical connections from the driver IC’s to the VFD anodes (grids and elements, see the previous article for definition) are those that are most convenient for the PCB layout without having to use links or through-hole connections as the order of the pins for outputting the display can be mapped later in software.
In this case, the first anode pin on the display is on the right, but the serial data starts with the first MAX6920 chip on the left. I will explain in more detail in the software section below.
The Cathode is run from the 3.3 Volt supply, it has a 3.3V Zenner diode across it to protect against meltdown in case of over-voltage, the cathode is made from of strands of thin tungsten wires and shows as a short when testing in beep mode on the multimeter.
I have used the SparkFun RGB Illuminated Rotary Encoder, as well as the encoding it also includes three LED’s and a push button switch. As the WeMos only has limited number of pins available, I used an MCP23008 I2C I/O Expander. I have covered these encoders in a previous post and have used a similar method here.
In this project it turned out I don’t have much use for the rotary switch, the same result can be achieved with a push button and two LED’s, it goes red when setting the time over WiFi, goes green when the time has finished setting but is off when running normally, the push button displays the date when pushed. I expect the encoder could be used for setting an alarm should I ever have need to add one.
The complete source code I am currently running in the clock can be found on my github repository, it has been written for the Arduino platform and can be considered unfinished and a bit of a mess. In almost all cases this clock will be a custom build with all the scavenged VFD displays being different I’ll be concentrating on how the display is being driven. Note that the software uses Latch and the MAX6920 driver chip uses Load.
To start, here are the physical connections for my VFD display, the display connections are shown looking from the back with pin one on the right, on the anode there are eleven grids and twenty-one elements, each grid illuminates a block of chosen elements. There are three MAX6920 driver chips, the first is on the left data is passed along the serial data line DIN/DOUT to the right:
While I’m not going to worry too much about how the data is sent to the display as this is being handled by the ShiftOutX library it may be useful to have an understanding of the byte order sent to the driver chips.
Breaking out the logic analyser we can see what is going on, in this first image below we can see that between the two markers one and two there are eleven data peaks to match the number of grids on the display the data is processed as a padded eleven character string: ‘ 212848 ‘ the first four contain nothing but the bit selecting grid to be used the next six are busy as they contain the time, and the last is blank. There also appear to be two blank clock cycles after these, this may be a programming error on my part.
the string is iterated so that each grid gets its own character with a very short delay between each this causes the persistence of vision effect and the time appears on the display.
In the next screen capture I have zoomed into more detail, it is showing the fifth grid and is displaying the number two. You can see that there are thirty-two clock cycles sent to the drivers while LOAD is high, this causes the driver chips to direct the data to the outputs. I am not entirely sure why the clock is being run while LOAD is low, I think it may be clearing the buffer before sending the required information.
You can see that 32 bits are sent to the display, but there are 36 pins available on the three MAX6920 drivers, you can also see that the outputs are arranged out of order. How do the drivers know which lines to switch for the display?
First off, an explanation of how the data is constructed then sent to the display. For this example I am sending the number five to the third grid, the data is constructed through the manipulation of a character array in three stages:
blank char array:
set the third grid:
set the number:
Because of the way the bits are ordered when sent to the drivers I have a lookup array VFDlookup to make life easier, in this case grid 3 can be found at position 29 in the VFDdata character array. I start with a blank character array of 32 bits VFDblank and copy this to VFDdata, I then use VFDlookup to find the position of the bit to set: VFDlookup = 29. For the elements the encoding for each character is set in VFDdigits the code for number 5 is 1110000110000111 the code was worked out by experimentation, seeing which element lit up after I had completed the hardware, I have ignored the extra symbols used for the DVD player so I only need to set pins 15-30. Once complete the character array is converted to a unsigned long integer and sent LSBFIRST – Least Significant Bit First via ShiftOut_32.
While that explains the elements encoding to display the correct digit, the grid selection however is a different kettle of fish. I built this clock over a year ago and have forgotten how it works. Grids 1 and 2 are connected to the output pins 1 and 0 on the third driver, pins 2-5 are then skipped, and the rest are connected to the grids, with three more being taken from chip 2. I can’t work out how it knows to skip those pins, or that grid 2 is connected to pin 1. But it is an awesome clock though.
My fridge door tends to rebound when closed staying open a smidgen and letting all the cold out. Rather than just checking that the door is properly shut, I thought it about time to have a microcontroller make a noise when the door has been left open too long.
This circuit uses an Arduino compatible Teensy LC for all the work, it has a phototransistor to sense the state of the fridge door light, a couple of LED’s one to indicate the power and another that comes on when the door is open. There is also Piezo buzzer to make an annoying noise after forty five seconds of door open time. The unit runs of a 3.7v rechargeable Lithium-ion battery and I have added a recharging circuit that takes power via the Teensy’s 5v USB port.
Note: These diagrams show 3.7v as the supply voltage. The Teensy LC can only tolerate a maximum 3.3V on the data pins, so these circuits are driven from the 3V output on the Teensy. They will all work without modification on the 5v Arduino Uno.
I have used a phototransistor to detect the fridge door light, there are two variants of this circuit light activated or dark activated, the 100k resistor can be replaced with a 100k variable if you need to adjust the sensitivity, the 330k resistor provides a weak pull-down on the output. The phototransistor is being used in switch mode to provide a logical output (rather than active mode which provides an output relative to the amount of light), so the output is connected to a digital input on the Arduino. The BC547 transistor is half of the darlington pair to provide extra gain on the output.
I chose the light activated switch, either will do but will provide different logical outputs to your controller. The circuit is enclosed in a small box inside the fridge and connected by ribbon cable to the controller, the ribbon cable is flat and does not upset the magnetic ‘seal’ on the fridge door.
To make some noise I used a piezo buzzer from an old computer, this is driven through a transistor as the Teensy does not provide enough current to drive it directly.
There is also a push button to provide a reset function if the buzzer is sounding while the door is open.
I have also added two LED’s, one to show power and anther that illuminates when the door is opened.
The final circuit if for recharging the battery, it connects to the 5V connection on the Teensy LC so charges the battery when the USB connection is in use. This has been copied from the MCP3831T datasheet.
This uses an interrupt to listen for the light sensor, when the state changes, the door open pin is read to determine if the door is open or not. If it is then a timer is started, this gives you forty five seconds to complete your task before the alarm sounds. With the door closed the timer is stopped and set back to zero. If the sounder goes off while you are rummaging in the fridge the reset button can be pressed, this restarts the timer from zero again.
Fridge Door Open
#define TEST_LED 13
#define FRIDGE_DOOR 6
#define DOOR_LED 8
#define POWER_LED 7
#define RESET_BTN 9
#define BUZZER 10
volatilebooleandoorOpen=true;// when the light is on
unsignedlongdoorOpenDelay=45000;// 45 second timeout before buzzer sounds
This all started with wanting to modify a cheap camping light by replacing the LED’s with some colourful NeoPixels. I made a Printed Circuit Board to match the existing PCB disc that held the LED’s, as well as a board for an ATtiny85 microcontroller which incorporated a microphone and vibrating motor of the type used in a old mobile phone. The battery and charging circuit came from a cheap (Poundland) USB powerbank but it turned out that the battery from the powerbank didn’t fit in the camping light how I liked (in a measure twice, cut once sort of thing). Instead I made this:
I wrote this back in May 2017 but it was never finished, I got distracted by other things and I needed the wireless controller for photography. I wrote all this and it would be a shame to delete it, so I am posting it now on the chance there may be of something of interest within.
I use this Yongnuo Wireless Controller in photography to control a number of flash units away from the camera body. It comes in two parts, a transmitter that connects to the hotshoe on the camera and receivers with a hotshoe that connect to the flash, a single transmitter can control any number of flash receivers within the claimed 300 meter range. The transmitter with a couple of receivers can be gotten of eBay for around £35.
Investigate how the transmitter works – reverse engineer as much as I can
See if I can control the transmitter directly with an Arduino
See if other devices using the same radio chip can also be controlled
Not destroy the transmitter while examining it
Opening it up
[images of the transmitter insides]
On the board inside you will find:
A power on/off switch
Bi-colour Red/Green LED
A dual-press button with two switches for operating the flash manually
A four way code selector (4 way DIL switch)
An anonymous (no markings) microcontroller – µC
A7105 2.4GHz FSK/GFSK ISM band wireless transceiver
On the underside, my board is marked with the following version and date:
Date: 14/04/23 – 23 April 2014
Looking at the datasheet for the A7105 it can work as both a transmitter and receiver and uses an SPI interface for user control, it appears to be popular with the radio controlled RC aeronautical drone community. The receiver looks to be very similar by way of components, using the same radio chip and anonymous microcontroller. I have not examined it in any detail and take care if disassembling as there are three hotshoe connections that need to be desoldered.
On the Canon camera the hotshoe has six connections but we only need to examine three of these. Looking down on the camera with the lens facing away from you, the main plate where the flash slides in is ground, the large central dot is the flash trigger just below this on the left is the camera ready connection. I assume the rest are for the E-TTL functions and I have not looked at these.
Checking the hotshoe with a multimeter, the flash trigger appears to have a high resistance that decreases when the flash is fired, I suppose this is a legacy of when cameras were more mechanical. The Camera Ready connection goes High – around 5 Volts, to tell the flash to wake up, that you have pressed the shutter halfway, the lens has focused and you are about to take a photo.
To find the duration of the flash signal on the cameras hotshoe I connected an almost flat AA battery between ground and flash to give me 1.2 volts to measure against on the oscilloscope (checking a canon flash itself, the voltage across the flash pin and ground is 4.47 volts). I found that the flash signal is sent by the camera for 352ms, which is quite long considering that a typical shutter speed of 1/125 second for flash photography works out at 8ms, although the amount of time a flash fires for is set on the flash and not by this signal.
I spent a while tracing out most of the transmitter circuit, I have ignored most of the supporting radio circuitry and the crystal timer as I am wanting to investigate the data side. The parts are also rather small and troublesome to investigate with standard multimeter probes.
The microcontroller looks to use internal pullup resistors for the input switches, the camera ready signal from the hotshoe switches a transistor to pull pin 16 low on the controller.
Looking at the circuit diagram we see an output to the antenna from pin 8 of the micro controller. This outputs two different square waves when the shutter button is pressed, one for camera ready and another for flash. I think these are being modulated on the transmitter output to produce a radio signal and simplify the transmitter design. Looking at the output from pin eight on the oscilloscope, the two states can be seen quite clearly:
These square wave outputs are always the same, I thought it may change when a different code was chosen through the DIL switches. The transmitter unit does not receive any radio data, and no acknowledgement is made by the flash units.
Using a Logic Analyser
Time to break out the Logic Analyser, this is a cunning device that allows you to see the data being exchanged between the microcontroller and transceiver, I don’t want to get too detailed but think this may help for the following sections.
The data system being used by the A7105 is SPI. The Serial Peripheral Interface bus uses four wires: Chip Select SCS, multiple chips can be on the same SPI bus, but they all have different SCS connections, the master controller chip uses SCS to tell the slave chip it wants to use for data exchange. Serial Clock SCK: This is used to provide time synchronisation for the data exchange with a fixed duration for the highs and lows. Data SDIO: This is the data being sent by the microcontroller and GIO1 is data from the transceiver sent in reply, normally for SPI this is 8 bits, to make a byte.
The naming conventions used here are from the A7105 datasheet, The SPI bus has standard names for data lines; SDIO is MOSI – Master Out/Slave In, GIO1 would be MISO – Master In/Slave Out and SCS is SS – Slave Select. In our case the microcontroller would be the master and the transceiver the slave.
The Logic Analyser displays data in a form that allows you to see the logic, here we can see two bytes of data:
The microcontroller – µC sends data on the SDIO line and listens for replies on GIO1. When the µC sets Chip Select SCS low this tells the transceiver that the µC wants to talk to it. The µC sends a command byte followed by one or more bytes of data – a packet. During the SCS event, data is only transferred while the clock SCK is running.
We can see that the logic on the SDIO is read every-time the clock goes low, falling edge, a clock tick on the SCK line represents a bit of data, eight ticks make a byte. We now have our binary data: 00100101 for convenience this is converted into hexadecimal 0x25.
When examining an SPI bus check any available datasheets to see if the clock is set to tick on a falling or rising edge, the bit order is Most Significant Bit – MSB or Least Significant Bit – LSB, and the data length (normally eight).
Looking at the A7105 Transceiver
From the A7105 datasheet the SPI bus is set for the following:
To activate SPI, the SCS pin must be set low
data length: 8 bits
bit order: Most Significant Bit First (MSB)
I have made the following connections to the transmitter. Soldering test leads to the microcontroller (µC) is the most convenient place to do this.
This table shows the Input/Output pins on the transceiver and microcontroller, as well as the colour of wire used for the logic analyser.
3 Wire Chip Select
3 Wire Clock
Read / Write
4 Wire SPI Data Output
4 Wire SPI Data Output
How the A7105 organises data
The transceiver has two data modes, Strobe and Control. There are eight strobe commands to control the various modes the chip supports, these are four bits in length and always begin with a 1, where the transceiver is being operated in 8 bit mode the final four bits are ignored. The Control registers are eight bits in length and are used to configure and read settings from the transceiver, they are eight bits in length, the first bit is always 0 and the second is either 1 for write or 0 for read. The table below shows examples of a write, a read (or more accurately a request, the transceiver replies on GIO1) and a strobe command sent by the µC.
Write Example: 0x2 0x1
Read Example: 0x42 0xff
Examining the A7105 data
Data is exchanged on the SPI during two events, after the transmitter has been switched on, and when you are pressing the camera shutter or the button on the unit.
When you first switch on the unit, the microcontroller initialises the transceiver with a few hundred bytes of data, I have created this spreadsheet from the SPI data, hex data across is the most useful sheet to view:
In summary the initialisation sequence consists of the following
The microcontroller sets the majority of control registers to default
Internal calibration is started and the microcontroller keeps checking until this is done
Final cleaning up
Place the A7105 into standby mode
On the SPI the shutter press action has two distinct stages, the preamble and the transmission. The preamble takes the camera out of standby mode and sets the channel it is going to be transmitting on. The transmission broadcasts the camera ready and flash states.
At the beginning of the datacaptue I see a preamble packet sent over the SPI:
This preamble looks to only appear when the flash is first operated after the transmitter unit has been switched on, subsequent use goes straight to transmit. The fifth byte changes depending on the DIL switch setting on the underside of the unit, as you can see in the four examples given in the table below.
Taking the first example, we can break this down to see what each byte is doing
It is difficult to work out what is going on here, according to the datasheet you send a packet of data 0xb5 0xf0 to be transmitted to FIFO Data0x5 and follow that with the strobe command TX mode0xd0, but what is transmitted bears no relation to the FIFO packet.
We need to look further back in the initialisation sequence and the datasheet, the A7105 has three modes of transmission; easy, segment and extension. We need to undertake a little bit of detective work to find which this is. Chapter 16.4 of the datasheet shows us the two registers used in the initialisation sequence we need to examine:
The datasheet does not say directly so we need to go through each modes description to see which is the best fit. Segment FIFO looks good: “In Segment FIFO, TX FIFO length is equal to (FEP [7:0] – PSA [5:0] + 1). FPM [1:0] should be zero”. So our settings: (FEP:0b1 – PSA:0b0) + 1 = 2. The number of bytes sent our FIFO Data packet is also 2.
Further reading of the description “This function is very useful for button applications. In such case, each button is used to transmit fixed code (data) every time. During initialisation, each fixed code is written into corresponding segment FIFO once and for all. Then, if button is triggered, MCU just assigns corresponding segment FIFO (PSA [5:0] and FEP [7:0]) and issues TX strobe command.”
Taking an initial look at the data gathered during a shutter press on the Trigger Out (pin 8 of the microcontroller) we can clearly see the transition from Camera Ready and Flash as we saw on the oscilloscope earlier.
GIO2 shows a mirror of the Trigger Out, but zooming in to the data and I see that it follows the Trigger signal. Looking in the initialisation spreadsheet at SCS event we see that the command 0xc 0x1 was sent for setting the function of the GIO2 pin. Looking at the datasheet this appears to be set as an ‘I am transmitting’ signal, WTR – Wait until TX or RX has finished. If I force GIO2 low by sorting it to ground then the flash does not fire when I press the shutter
In my data capture the Camera Ready signal was transmitted six times, and the Flash signal thirteen times, I am sure this is dependant on the length of time I had the shutter button pressed on the camera.
Apologies for the inconclusive ending, I ran out of time to pursue this further
In a previous post I added a control knob to my Tenma 21-10130 Rework Station, but now I am taking a more detailed look at the controller board hardware inside paying particular attention to the microcontroller connections.
Removing the board from the rework station was a bit of a hassle, the screws at the bottom are particularly difficult to access. Eventually I had to unbolt the transformer from the case so I could get the screwdriver in, the transformer bracket catches up against a heatsink and capacitor so it cannot be completely gotten out of the way.
The board can be divided up into five sections, on the left is the mains power supply, with connections to the power switch and rework heater, along the bottom left is the 5V DC power supply for the microcontroller, top right is the control circuitry and connections for the rework heater and hot air, and bottom right those for the soldering iron. In the centre is the microcontroller and associated circuitry.
The rework heater, air pump and soldering iron are all controlled using triacs, these in turn are connected back to the microcontroller through optocouplers. The rework heater and air pump operate at mains voltage, 220V, while the soldering iron works at 24V, these are all using Alternating Current. Essentially the station is a collection of variable dimmer switches controlled by the microcontroller.
There are ten connections to the controller board
Mains in – from power connector
220VAC out to transformer
Rework Air Pump power
Soldering Iron Temperature
Hand Key – Controls for Rework Wand
AC 9V input
Soldering Iron Power
AC 24V input
The connectors CN5 and CN6 are used to provide sensing for the microcontroller; one for the soldering iron temperature and another from the rework wand with the button controls, in cradle detect, and temperature sensing, there is also a row of five onboard button switches.
With the multimeter in beep mode, tracing back the connections to the microcontroller took a couple of days.
The PIC19F916 microcontroller has 24 digital Input/Output pins which are divided into three ports of eight; RA0-RA7, RB0-RB7 and RC0-RC8. In the lists below I have shown the physical connection as well as the I/O port used.
The power control connections are to an optocoupler which in turn switches a triac:
Rework Air Pump
After much tracing of circuitry I found the triacs to be connected to the optocouplers much as shown below. Resistor values vary and on the microcontroller connection side the current limiting resistor is on the low side, pin two, rather than on the 5V line.
There are five front panel control buttons which go low when pressed. Internal pullup resistors appear to have been used in the microcontroller.
Soldering Iron Power
The two LCD displays, both are the same with seven connection pins with pin one at the top. The rework stations designers have not used the PIC’s built in LCD display functionality. The LCD panels are marked JRD90601A on the underside, I couldn’t find anything about this on Google.
Data 3 – LCD Select
At present I have no information about the LCD data pins, I’m thinking that RC1 and RC2 could be Data/Clock while RC3 and RC4 is for selecting the LCD to send data to.
The Hand Key connector CN7 for the Rework Wand with pin one to the left when looking at the component side with the key notches uppermost. I have not opened the wand as it is sealed closed with glue and I did not want to damage it.
GND for temperature
Rework Temperature – through OP07C op-amp
unknown – no connection?
GND for button controls
Buzzer – through Q2 (possibly a SS8550 PNP transistor)
U3: PC817 photocoupler – some kind of mains frequency monitor?
CN6: Soldering Iron Temperature – through op-amp OP07C
Pulled high through 10K resistor – Master Clear Pin External Reset
9v AC monitor?
This concludes the examination of the hardware connected to the microcontroller, further work needs to be done through software and oscilloscope observations to see how the LCD displays, power controls (probably PWM), and temperature sensors work and what the 9V AC and 220V AC monitors are doing.
Here are a couple of diagrams I drew up of the more involved sensor circuits while tracing things out. Values for the ceramic capacitors have been omitted as they are not marked on the SMD package. Both the rework and iron temperature sensors have similar op-amp circuits.
For soldering electronic components I use a Tenma 21-10130 rework station, this is a rebadged Chinese model sold by Farnells under their own brand name it has a soldering iron and hot air station combined in the same box, for me it works well, does the job and is considerably cheaper than those from Hakko or Weller.
The only real problem are the controls, five small fiddly buttons on the front panel, something that appears to be common on all these ‘budget’ stations, while the temperature on the soldering iron only needs changing infrequently, the hot air temperature and flow need to be adjusted more regularly. I guess the manufacturers preference for buttons is to make the machine cheaper to produce.
Under The Cover
Removing the lid reveals the air pump, sundry tubes, a large control board and a fantastic selection of wires to discourage taking the whole thing properly to bits.
The onboard microcontroller is a PIC16F916, this is a 28 pin 8-bit 20MHz controller with 14Kb of program memory, 24 I/O pins and an integrated LCD driver.
Fortunately the connections for the front panel buttons can be just about reached with multimeter probes, and with the mains power disconnected, I was able to buzz out each switch and find where it went to on the PIC controller.
Soldering Iron Power
Hot Air Rework Power
To improve access to the microcontroller connections I built a breakout board to give me access to all the micro-controller pins via standard pin headers. On the side that plugs into the existing socket I mounted a load of 90 degree pin headers and on the other a standard DIP socket with the legs splayed out so I could surface mount it. The pin headers are little on the large side for plugging into a DIP socket so you need to check its fully engaged with the onboard socket when you push it in.
The rotary encoder I used is the SparkFun COM-10982 mainly because it is easy to panel mount, at this stage I have not used the builtin LED’s to add effects. This connects back to the controller board which has an ATtiny84 microcontroller to convert the encoder pulses into suitable button responses. There is also an opto-isolator for the button controls and a small DC-DC 3.3 volt power supply as I don’t know the power characteristics of the rework station. I took the 5v power for the controller from the same supply as for the PIC.
I programmed the controller so that pressing the encoder emulates the set button and cycles through the available settings; the temperatures for the iron and hot air as well as the air speed. Rotating the encoder adjusts whichever setting has been selected. In the code, the Soldering Iron Power button is shown (RW_IRN) as connected; it is not used, the LED flashes when the rotary encoder is turned, its a bit pointless as it can’t be seen once the cover is back on. I wrote this in the Arduino IDE.
There is not much free space available on the front panel of the station, the encoder can only be mounted between the connection for the soldering iron and the mains switch. I have mounted the controller circuit board on the rear panel.
One of the problems with this rotary encoder is when its turned too quickly it gets confused and can skip pulses or operate in reverse.
Also, the speed of change is limited, the PIC controller will only see so many pulses per second, I got this down to 14ms anything lower and it was unreliable, probably this is part of some code to detect button bounce, so a fairly long pause between each button press needs to be made.
A few improvements could be made to the rework station that could mostly be implemented in the PIC software. Those that have occurred to me are; the control for the air speed only needs to go from one to eleven, slow, medium and fast, the speed currently goes between 20 and 100 and changing the speed can be rather slow. Some sort of velocity control on the rotary encoder so the faster its is turned the greater the amount of change in the temperature. An auto-off function for the iron, so when its back in the cradle it cools down and preserves the life of the soldering tip and, most importantly, a volume control for the annoying buzzer.
I have written more extensively about the main board hardware in this teardown.
With one of my electronics projects I am wanting to add a couple of phototransistors to make a crude movement sensor and to do this I first need to discover the best way of using them. A phototransistor is sensitive to the amount of light falling upon it, as this increases higher current is allowed through the device. This in turn can be used provide a variable voltage to an analogue input on your microcontroller.
For this posting I am using two different phototransistors, the SFH3710 is a surface mount device smaller than a red lentil and the TEPT4400 is through hole and looks like small white LED and is easier to prototype with, they are both NPN transistors made to respond to visible light at wavelengths around 570nm.
A bias, or load, resistor is required to produce an output (VOUT). This can be above or below the phototransistor. Common Emitter
The resistor RC acts to pull-up the voltage, as light increases the output voltage drops.
Common Collector (Common follower)
In this case the resistor RE acts to pull-down the voltage, as light increases the output voltage increases.
The Fairchild Semiconductors application notes describe the two modes that phototransistors can be used in; switch and active. The mode is set by the value of the load resistor RL:
Switch Mode: VCC < RL x ICC
Active Mode: VCC > RL x ICC
VCC = Supply Voltage
RL = Load Resistor (Rc or Re)
ICC = Maximum anticipated current
In switch mode the transistor is either on or off, this ‘digital’ output is useful for object sensing or object detection, typically a resistor value greater than 5kΩ is adequate, the output in the ‘high’ state should equal the supply voltage, and for ‘low’ the output should be below 0.8V.
In active mode the output is variable, giving a value related to the amount of light. To use this a low value resistor is required to prevent VOUT exceeding the supply voltage, using Ohms Law you can find the maximum resistance, the value above which the transistor may respond in switched mode: Rmax = VCC / ICC, so: 5v / 4mA = 1.2kΩ. Connected up as Common Emitter, selecting a resistor value 30% below this to ensure a margin of error a 875Ω should give 4.5V at the output when completely dark, dropping to below one volt when saturated with light.
The drawback with active mode is that phototransistors have a non-linear response to light, as light increases beyond a certain level their output will suddenly jump and then flatten out, other factors, such as the ambient temperature and the type of light (daylight, fluorescent tubes, LED’s, etc) also affect the value of the output.
I want to test that the above is actually true, this circuit uses a white LED pointed at a TEPT4400 along a short piece of black straw to act as a stray light shield. The LED brightness is set using PWM on the Arduino. The phototransistor is setup for Common Emitter output, so the output voltage will drop as the light increases. For active mode RC was set to 220Ω and for switched mode this was 10kΩ.
The code below uses PWM to fade the white LED up to full brightness, the reading taken from the analog port is a majority candidate reading, where from the ten readings made the one that occurs most often is used as the phototransistor output bounces around, I think this is caused by the PWM, the results are output on the serial port for use in a spreadsheet.
From the output, I was able to produce these graphs, remember that for the Common Emitter setup being used the voltage drops as the light increases, not quite getting the smooth response to light/time I was expecting.
I am not sure why I got these results, they were consistent and I suspect my test setup. Some more experimentation is needed, but for now I have run out of time.