TempDoctor Reflow Oven Controller

This is one project that I actually intended to put on kickstarter / indiegogo / crowdsupply, but after I had developed a prototype there was an unexpected shift in my career and now I don’t have the time to pursue this project anymore. I am just publishing my work and perhaps someone else could take the challenge to make it into a crowdfunding.

When I needed a reflow oven for my lab, there was nothing on the market that I liked. Without spending a couple of grands on a professional convection oven for prototyping and small batch assembly, the only available stuff was DIY kits that did not satisfy my performance requirements. Since I was sure I can make a good performance DIY kit with a sleek design which would cost only a few hundred bucks, I set to work.

TempDoctor module

The PCB was designed to fit an already existing case, as custom molding is too expensive for low-volume production. I found some kind of cheap mouse to be a good source of nice round and slim cases that can take a PCB as front panel (details in hardware files).

 

Convection oven integration

http://steba.com/product/baking/bake-oven-kb-14/?lang=en

The solid state relay simply replaces the original electromechanical relay and the controller is attached in place of the original temperature control knob.

I added extra thermal insulation with fiberglass sheets and aluminium tape. This particular configuration is able to ramp up with up to 1.5°C/s.

Functionality

• Superior control with fast set point stabilization and no overshoot
• Automatic parameter learning by step response analysis
• Manual setpoint with simple timer
• Automatic profiles – download via USB and save to memory (up to 8 profiles)
• Intuitive, fast and responsive operation with touch buttons
• Main display shows actual temperature, target temperature, rate of change in actual temperature, heater status (on/off), operation mode and timer count

 

Source code and hardware files

https://gitlab.com/dorinclisu/oven-controller

The temperature control is not based on PID because this method leads to very poor performance in this application (large thermal inertia and delayed response).

I developed a control algorithm based on a first order approximation of the differential equations describing the thermodynamics of the oven, and it is fairly close to optimal control.

Hardware Lab Home Setup

When you first tell your friends that you’ve designed and built an electronics product at home it sounds a bit odd, but not so much after you show them a professional lab in your little apartment balcony!

 

 

 

Capabilities

Power and Signal Generation

• Digital Power Supply: TENMA 72-10495, 30V 5A
• Signal Generator: Rigol DG1022, 25MHz 2ch

Measurement

• Oscilloscope: Rigol DS1054Z, 50MHz 4ch (extended to 100MHz)
• Logic Analyzer: Saleae 8CH 24MHz
• Multimeter: UNI-T UT71D, True RMS 100kHz, 10µV, 1nA, 1pF
• IR Thermometer: UNI-T UT302D, -32 to 1050°C

Soldering

• Soldering Station: Hakko FX-888D, 250-500°C 60W
• Hot Air Station: Atten 858D, 100-500°C 800W
• Reflow Oven: Self Made Smart Controller, 60-240°C 1200W
• Fume ventilation: Bench fan
• Fume extraction: Overhead kitchen hood with external exhaust

PCB Prototyping

• Printing: Lexmark MX310DN, 600dpi, 2 print masks per layer
• Boards: Presensitized Copper 2 layer FR4
• Curing Lamp: UV LED 30W, 3 to 5 min exposure
• Developer: Sodium Metasilicate
• Etchant: Sodium Persulfate
• Trace Width and Spacing: 6 mil (0.15mm)

Miscellaneous

• Passive components (through-hole / SMD 0603), Analog and Digital IC
• Passive tools, Breadboarding kits, Cables, Adapters, Connectors
• Modules: Bluetooth HC-06, Ultrasound HC-SR04, IMU mpu6050, Magneto HMC5883L, GPS, LCD n1100 / n5110, OLED ssd1306
• Development Boards: STM32F4, STM32F3, Arduino Micro, RF cc2530, BLE nRF51822
• Recycled Electronics: GSM modules, Video TX systems, Mechanical and Optical assemblies, Smartphones, etc.
• Medals on Display: Mathematics and Physics

 

While I’ve had several tools, devices and electronics at home to play with for more than 10 years, it was only last year that I setup a proper lab to do R&D work for IoT devices.

There are still several things which are lacking, like a proper drilling machine, LCR meter, VNA, but they aren’t very much needed at the moment so I’ll see how to prioritize my purchases.

You can also notice some RC models, like a self built flying wing and quadcopter, a commercial boat, and some control accessories like radio transmitter and FPV video helmet. I also have another self built plane and another commercial plane but I keep them in my bedroom since there’s not enough space.

Bike computer with Nokia 1100 LCD

The biggest problem with cheap commercial speedometers is that they have volatile memory, so all data is gone after a battery replacement! There are already a couple of arduino bike speedometer projects, but none with a fully customizable matrix display.
I discovered that some old Nokia LCD’s are fairly easy to use, with a single SPI interface (non standard but it can be bit banged) and since I already had a Nokia 1100 handy, I set to make my own speedometer.

Soldering the wires on the small contact pins

Adding hotglue for strain relief, since the pins are really really fragile

Ready to be plugged in a breadboard!

I then hooked up the LCD to a leaflabs STM32 dev board mainly because the MCU is 3.3v (and the LCD would be damaged by 5v signal levels) but also because it has more RAM than the arduino nano to easily handle the display data.

http://www.aliexpress.com/item/leaflabs-Leaf-maple-mini-ARM-STM32-compatibility/32214664071.html

A voltage divider for low battery detection, light sensor and backlight FET are some additional components on the breadboard.

The rest of the hardware is also very simple, just like any available odometer on the market, a GPIO pin pulled up or down and connected to a reed switch which closes the circuit when the magnet on the wheel passes by.

This is mainly a software project and features:

• main speed  ex. 28.1kph
• total distance  ex. 6.1km
• total runtime  ex. 09min (increments when speed > 0)
• average speed   ex. 38kph
• maximum speed  ex. 98kph (resets after auto power off)
• battery indicator  ex. ~60%
• switched backlight
• data retention after complete power off
• setup navigation menu  (wheel size, reset data)
• ??? add anything you want, like speed logging and graphing

bike_spd_lcd.zip

Schematic.pdf

The code is for the LeafLabs Maple IDE but you can adapt it for anything.

Navigation is done with only one button! One short click of the button means Change (of menu index or digit) and one long click means Select.  I use the on board button (only on leaflabs) for this.

In the video you can see an external button that I use instead of the reed switch to simulate the wheel spinning.

Magnetic Apogee Detector for rockets

While I was playing with a 3-axis magnetometer (and having built rockets before) I had this idea for sensing the moment a rocket reaches apogee so that optimum parachute deployment is ensured.

Commercial solutions that I’ve seen use a barometer to sense the altitude (combined with an accelerometer for reliable operation) and are complex and expensive, so I thought: we know that the rocket will be tangent to its trajectory all the time so at apogee the rocket will be horizontal and then it will point the nose down, so why not take the rocket inclination as indication of apogee?

Using a magnetometer and the Earth’s magnetic field as reference should be a reliable way to determine the orientation, since it is not affected by the (lack of) G forces as an accelerometer sensing the gravitational field would be for example, provided the magnetic field vector is as vertical as possible.

How does it really work?
By having one of the magnetic sensor axis parallel to the rocket longitudinal axis and taking the axis reading, we can know the rocket is pointing up when the value is positive and pointing down when the value is negative.
To be more precise, we can know on which side of the plane that is perpendicular to the magnetic field vector the rocket is oriented.

B is the Earth magnetic field vector (about 60 degrees inclination). The thin blue line is the side view of the plane perpendicular to B. Bz is the rocket magnetomer axis reading, which is positive above the plane and negative below the plane.

The rocket will be considered pointing up while it is inside the positive 60 degrees cone and pointing down while it is inside the negative 60 degrees cone.

The zone in between the cones is uncertain and can cause both a “pointing up” reading and “pointing down” reading, depending in which direction the rocket is tipping over relative to the North (magnetic declination).

In places where the magnetic field is perfectly vertical (inclination is 90 degrees at the magnetic North and South poles) there is no uncertainty zone, while in places where the magnetic field is horizontal (at Equator) all positions fall into the uncertainty zone, meaning that this method will not work.

As you can see, across all US, Canada, Europe, Russia, Japan, South Africa and almost all Australia territory, the inclination is above 45 degrees.

We want the uncertainty zone to be as small as possible, therefore the magnetic inclination to be high.
Check for a minimum magnetic inclination of 45 degrees in the intended geographical area of operation:

A quick and dirty prototype with an Arduino and HMC5883L:  https://www.youtube.com/watch?v=MZUnnsldayk

Now the pcb version with all the stuff needed to actually run inside a rocket: Hg switch to prevent the magnetometer to trigger from field perturbations on the ground (especially from the metal launch bar) power MOSFET for igniting the fuse and voltage divider for measuring the resistance of the fuse.

I used an ATtiny85 (same as tiny13 that I had available in Eagle but with hardware i2c support) because of its small size, while being powerful enough for this purpose.

Despite the 5V lines in the schematic, I run everything from a 1 cell Li-Po battery (3.3-4.2V) without any regulator because it is simply not needed. The MCU runs down to about 2.7V and the internal oscillator is stable enough given that millisecond accuracy is not needed.

The switch should be open when the rocket is tilted downwards (contacts towards tail) but the program can be adapted for the other way around.

Any mercury switch should work but I would avoid the big ones and glass casing to prevent breakage and toxic spill in case of an accident.

I know it looks ugly and unsafe but trust me I’ve checked all the solder joints and possible short circuit points under high magnifying lens and it’s alright.

You can make a proper PCB if you want, I just didn’t feel it’s worth it for only one piece.
Also, in case you’re wondering why I’ve used some SMD parts, it’s just because that’s what I had lying around with the suitable values.

If you’re still using the crappy Arduino IDE, do yourself a favor and use Sublime Text with the stino plugin https://github.com/Robot-Will/Stino

For the programming I’ve used some existing Arduino-tiny cores and an i2c library for tiny85.

mag_board_tiny85.hex

project.rar

WARNING: I cannot guarantee this code is free of bugs!!! Therefore I am not responsible for any injury or damage to property that might arise due to failures!

Make sure you understand what you are doing!

Turning on sequence:

• power-up with the nose oriented down (Hg switch in open position) and wait 1s;

-if the fuse is not properly connected (high resistance) or the nose is tilted up then multiple short tones are emitted; turn off and check connections;
-if the fuse is ok then a single 1s long tone is emitted;

• tilt the nose up;
• wait 1s;
• tilt the nose down until a single short tone is emitted; if no tone is emitted then magnetometer is not working properly or there are strong magnetic perturbances in the area; turn off;
• wait 3min; use this time to mount the rocket onto the launch system;
• 5s long tone is emitted; now the system is armed; DO NOT TILT THE NOSE DOWN OR FUSE WILL BE FIRED;

Working sequence:

• the system engages once it senses negative acceleration for at least 1s(configurable); this should happen immediately after motor burnout;
• once ENGAGED the system waits for the nose to go down; this should happen close to apogee; if magnetometer fails to report nose down, the system will time out after 12s(configurable) from burnout;
• the system fires the fuse and parachute is deployed;
• continuous tone is emitted for 1h;
• 1s long tone once every 10s is emitted (to keep it going as much as possible on the battery);

Data logging:

After the mission, you can read the EEPROM memory with avrdude. The first 2 bytes (first 2 numbers in .dec format) are logged as follows:

• first byte: 1 if the microcontroller was engaged by the switch or 0 otherwise;
• second byte: 1 if the microcontroller detected magnetic trigger (nose down) or 0 if the trigger happened after timeout;

Possible logs:

• 0 0 – switch fail or other unexpected fail; parachute trigger was not expected;
• 1 0 – magnetometer fail or timeout value set too small; parachute trigger was expected;
• 1 1 – no fail; parachute trigger was expected at apogee;

Computer soundcard tachometer

Measure the angular speed of a propeller using an IR LED – Sensor, a soundcard and some windows software.
I have originally posted it on the forum: http://www.rcgroups.com/forums/showthread.php?t=1450032

TGY 9X transmitter telemetry hack

This is a simple hack to activate telemetry on the Turnigy 9x  RC transmitter. Someone came with this idea on a forum and I have applied it in a different configuration:  http://www.rcgroups.com/forums/showthread.php?t=1510047
Everything is explained in the video (make sure you have annotations on):

You will also need to to this cut on the other side of the board (I missed it from the video):