PCB Cleaning for Beginners

I’ve been doing a lot of PCB assembly of late both re-flowing SMD in a toaster oven and a heap of hand soldering.  One thing that bugs me is cleaning up the various rosin’s, flux and solder paste without making a bigger mess.

My usual clean up method is to use IPA and cotton buds, however the IPA has a nasty habit of dissolving the flux/rosin/paste and redistributing it across the surface of the PCB making a slightly tacky mess worse than when I started.   Dang it !   I then resort to using cotton make up removal pads (stolen from the medicine cupboard) and with a blotting technique try to pick up as much of the mess as I can with copious amounts of IPA.  There simply has to be a better/cheaper/simpler way !

So after speaking to a few production Engineers at work I was pointed towards various brands of PCB wash and the suggestion was made to use an ultrasonic cleaner.   A bit of poking around the internet suggested that a good ultrasonic cleaner could be had for less than A$200 and PCB wash should be A$15 to A$20 per litre.

Thankfully my local Jaycar had both locally available which makes supply and  warranty much easier.  I also like supporting my local shops where I can.

The ultrasonic unit I purchased can be found here (click), part number YH5412.  It has a total transducer power of 160W and a tank that can hold up to 2.1L of liquid.  This unit is manufactured in China and if you look carefully you’ll see the same OEM unit on various sites all for about the same price.   This is certainly big enough to hold quite large PCB’s up around 250mm x 150mm and has an inbuilt heater as a bonus.

The PCB wash was yet another story.  This stuff is far cheaper in large quantities but I just wanted a little bit to see how we go.  So I found Jaycar also sold 1L bottles from Chemtools which you can find here (click), part number NA1070.  This stuff is biodegradable which means it should be ok to go down the sink, however I’ve got some 5L bottles I can decant the used liquid into and dispose of at the local EPA as required.  All of the technical stuff can be found on the Chemtools website here (click).  It’s worth reading the TDS and SDS sheets of this stuff and making sure you take the necessary precautions.

So to clean some PCBA’s !

I filled the machine to it’s minimum level (~700ml) and turned on the heater.  Within 10 minutes the fluid was warm (not hot) so I turned off the heater and loaded a number of small PCB’s into the fluid, being careful not to overlap the boards.  The TDS for this PCB wash says the fluid can be heated to  +40 degrees Celsius but is designed to work between 20-30 degrees Celsius.  So I just used it warm, not hot.   I ran the unit for 180 seconds (one of the presets) with the lid on. The ultrasonic cleaner certainly made the right noises and there were lots of little bubbles ripping into the contaminants.  I really like the lid on this unit as a warm liquid evaporates and with the lid on there was certainly condensation under the lid keeping everything in.

Once the countdown timer expired it was into one bowl of distilled water and then rinsed again in a second smaller bowl of distilled water.  I had a spare pair of plastic tongs I could use to move the PCB’s between tanks without using fingers.  The idea of the two baths is to get the bulk of the PCB wash off in the first bowl and then the last dregs off in the latter.   It helps to change the water in the first bowl often, since it takes the bulk of the PCB wash off in the first instance.

Then it was into the drying cupboard at 50 degrees Celsius for 40 minutes to evaporate the last of the water off the board.  My drying cupboard is a 20L toaster oven that I used to use for reflow soldering, nothing high tech but it will idle along at 50 degrees nicely unlike other ovens I’ve tried.   I’ve seen videos online where others have used a paint stripper gun to blow hot air across the boards, YMMV.

So the result ?  I’m impressed.  Quite simply impressed with how clean the boards have come out of this very simple process.   They are now clean and you’d be hard pressed to tell that they didn’t come from a professional board loader.  Inspecting the results under the microscope I see there is very little residue on the boards, both the flux and rosin from the hand soldering processes have been completely removed.  There is no trace of any solder paste balls either.  They are clean as a whistle.

I will have to work out a way to take photo graphs down my microscope to show the results, my feeble attempts at trying to take a macro shot with my phone failed dismally.

Now I have to hurry up with the Whizoo controller and my smaller 9L toaster oven conversion.  Must remember to blog that too.

Mikrotik OpenVPN Configuration

There is heaps of information about configuring a Mikrotik Router as an OpenVPN server on the net.  The following simply documents what I found when I tried to follow in their footsteps.

The first reference I found was Medo’s instructions on how to configure the VPN, I used this to create the certificates, configure the server and get close to a working solution.

However my configuration was a little different in that the remote device I was connecting too (RB411 over 3G) did not have a FQDN only a fixed IP.  So for the ca-template and server-template I used the Fixed IP (xx.xx.xx.xx) for the common name, for the client-template I used the name of the router (RouterName).

add name=ca-template common-name=xx.xx.xx.xx days-valid=3650 key-size=4096 key-usage=crl-sign,key-cert-sign
add name=server-template common-name=xx.xx.xx.xx days-valid=3650 key-size=4096 key-usage=digital-signature,key-encipherment,tls-server
add name=client-template common-name=RouterName days-valid=3650 key-size=4096 key-usage=tls-client

I’ve changed both the IP and RouterName to protect the innocent, I’m sure any readers will figure out where to insert their own configuration.

I also found that if you did not change the common name of the client-template certificate then the signing process of Medo’s post would fail with a weird error message.

sign ca-template name=ca-certificate
sign server-template name=server-certificate ca=ca-certificate
sign client-template name=client-certificate ca=ca-certificate

Now getting the certs off the remote router was also “interesting”.  This wasn’t something that I’d really done before.   So after a bit of googling and some trial and error I ended up using the pscp utility that is part of the PuTTY package.  You can find the relevant certificates using the /file command.

C:\Program Files (x86)\PuTTY>pscp -r -P 22 user@xx.xx.xx.xx:/* \temp
user@xx.xx.xx.xx's password:
ca-certificate.crt        | 1 kB | 1.8 kB/s | ETA: 00:00:00 | 100%
server-certificate.crt    | 1 kB |   1.8 kB/s | ETA: 00:00:00 | 100%
client-certificate.key    | 4 kB |   1.8 kB/s | ETA: 00:00:00 | 100%

Once I had the certs on my local machine I could continue to follow Medo’s blog.

Now I didn’t want the VPN users to end up in a different IP address space, so I changed my VPN DHCP pool range to be just under the usual Ethernet pool and then set the VPN local address to be the next address under the VPN pool.  Here’s a quick overview;

VPN local_address:  xx.xx.xx.64
VPN dhcp_pool:      xx.xx.xx.65-xx.xx.xx.75
ethernet dhcp_pool: xx.xx.xx.100-xx.xx.xx.200

So I ended up modifying the following commands;

/ip pool
add name="vpn-pool" ranges=xx.xx.xx.65-xx.xx.xx.75

profile add name="vpn-profile" use-encryption=yes local-address=xx.xx.xx.64 dns-server=xx.xx.xx.64 remote-address=vpn-pool
secret add name=user profile=vpn-profile password=p4ssw0rd

/interface ovpn-server server
set default-profile=vpn-profile certificate=server-certificate require-client-certificate=yes auth=sha1 cipher=aes256 enabled=yes

Now before anyone says anything you need to change the name and password to suit your own VPN user, at the very least make sure you use a good password.  You’ll notice I dropped the AES-128 and AES-192 ciphers in preference to the 256bit option.   More on this later.

This is where I ran into trouble that took me a while to resolve.

I had installed OpenVPN GUI 2.4.5 which simply refused to connect, it throws TLS errors that are odd.  It turns out that as of OpenVPN 2.3.11 there was a change made that makes it incompatible with older Mikrotik routers, you can read all about it here and there is more information here.

This post also talks about being able to use the tls-cipher parameter to force the client to relax it’s checking of certificates, however I wasn’t able to make this work.  It appears that the latest version of RouterOS have fixed this issue, but that has to wait until I’m next at the console of this particular router to upgrade it.

So after uninstalling the latest OpenVPN 2.4.5 GUI and installing an older version OpenVPN 2.3.10, I was able to connect to my RB411 with v3.2.2 firmware with the following config;

dev tun
proto tcp-client
remote xx.xx.xx.xx 1194
resolv-retry infinite
cipher AES-256-CBC
verb 3
remote-cert-tls server
auth SHA1
redirect-gateway def1
ca "C:\\Program Files\\OpenVPN\\config\\ca-server.crt"
cert "C:\\Program Files\\OpenVPN\\config\\server.crt"
key "C:\\Program Files\\OpenVPN\\config\\client.key"

As you may notice I use Windows for my main machine, so Mac and Linux users will have to do a little more googling on how to specify the paths in this file.   Now the cipher matches the tweak I made to the ovpn-server within the mikrotik router limiting the choice to AES-256 bit.

The proof is in the pudding, after copying all of the certs and config into the approriate directory I could get the VPN client to connect to my remote Mikrotik RB411 router over the VPN.  Many thanks to Medo for blogging his adventures with RouterOS and I hope the suggestions I’ve made above are useful to some.

Stackmatch Initial Tests

Well the Stackmatch PCB’s finally came back from the Manufacturer along with the components from Mouser, so it was time to build.  I’m pleased with the 3D model and the actual final assembly, they are pretty close !

This slideshow requires JavaScript.

I’ve not mounted the LED’s on the left hand side yet, this will wait until I can drill the front panel of the diecast enclosure and begin final assembly.  Since I’ve got more than one of these to make I’m getting a template made from steel that I can mount on the front panel and then drill all the holes.

The assembly in the picture above is the first prototype and I wasn’t going to wait for the front panel and die-cast box to be ready before testing.  The connectors have been attached at roughly the right height using an additional nut as a spacer, I’ve only fitted half the standoffs to save some time.

So the question is does it work?

The first test is simply a test of the isolation between ports.  So taking a spectrum analyser with tracking generator the idea is to measure the insertion loss between the input and one output as we switch between all three outputs one at a time and record the results.  All outputs are terminated in a 50 ohm load.  What is interesting with this stackmatch is we can also select “no outputs” where no relays are energised, this has a surprising result on the measured isolation;

This slideshow requires JavaScript.

OK, so what can we deduce from these series of plots.  The Spectrum analyser (SA) tracking generator was on the Stackmatch input, the SA input was on Output #1 unless you missed it.   As we switch each output from #1 to #3 we can see the insertion loss change.  As you would expect when we select output #1 we measure the insertion or through loss of the stackmatch, when we select any output other than #1 we measure the Isolation between ports.

Here’s the all important worst case summary, which is of course at the high end of the HF band i.e 10m;

  • Insertion Loss < -0.2dB
  • Isolation > 37dB

That is not too bad for a single device covering from 160m to 10m.  In real terms it means when we are transmitting 400W PEP (+56dBm) on 10m that less than 80mW (+19dBm) will be leaking out the other two ports.  The same can be said for helping prevent overload in the receiver from adjacent contest stations (i.e. on 20m).  The AREG typically use Elecraft K3’s and high end Icom transceivers so these typically don’t give too hoots about QRO contest stations on adjacent bands in the first place.     The best part is as we go lower in frequency the Isolation increases a further 10dB which can only improve the situation.

The insertion loss is barely measurable, so nothing should be getting really hot or require further bypassing.

Now what was also interesting is the difference in output isolation with no outputs being selected and just one.   The isolation to an unused port increased by +5dB to +6dB when the input was terminated into just one antenna.  That is something that we’ll need to take care of with our control system, not selecting any output is bad.

So then it was a question of moving the Spectrum Analyser input to Port #2, terminating Port #1 and repeating the above measurements again.  We do the same again for Port #3, shuffling the dummy loads and measuring once more.  I’ll not bother putting up all of these plots, suffice to say all of the isolation between ports were within 0.5dB of each other and insertion loss didn’t move.

Now for the main event, parallel combinations.

To do this we use a Return Loss (RL) measurement, so I’ve placed the RL bridge on the input to the Stackmatch and then terminated every output in a good quality dummy load, this is important !.  Then by switching the outputs in succession I can generate the various parallel combinations (25 ohms and 16.7 ohms) and then switch the transformer into to see the effect.  In all cases a 30pF Silver Mica cap has been tacked across the output of the auto transformer as per our previous experiment (click).  Here’s the measured plots;

This slideshow requires JavaScript.

So from our first plot where only one output is selected our return loss looks excellent with the minor exception of a spike at 8MHz.   I’m not sure that this is real just yet and will be doing some further work on what that resonance could be.  It’s got to be a parasitic capacitance there somewhere, will track that down later.   You might notice that the RL is better than -20dB (1.2:1) anyway, so a moot point really.

When we place output #1 and #2 in parallel we get 25 ohms and the RL rises to -10dB as you’d expect.  Then when we kick in the transformer we see an immediate improvement of RL to better than -18dB (1.3:1) at worst case (10m).

Now when we place all three outputs in parallel our RL is destroyed -6dB, but again if we kick in the transformer we see an improvement in RL of -13.5dB (1.6:1).  If you get your calculator out you find the ratios are smack bang on our design of 2.25:1.    So to summarise;

  • Return Loss (1-output) < -20dB
  • Return Loss (2-output) < -18dB
  • Return Loss (3-output) < -13dB

Yaay it works !

So there we have it, the beginnings of a workable stackmatch design.  As with any new design there is still plenty to be tweaked and played with.  In the coming weeks I’ll be;

  • investigating the effect of the cap across the output
  • chasing down that odd parasitic resonance at 8MHz with one antenna selected
  • measuring the temperature rise of the transformer with 120W of CW being blasted into it, or 300W of RTTY to give it some real curry…
  • Making the final enclosures and seeing what effect (if any) this has on the design
  • Trying #16, #20 & #24 gauge PTFE wire on the same core to see if the performance or characteristics of the transformer changes
  • Seeing what effect the +/- J term from various antennas has on the combined feed point impedance that our radio will see (thanks to David VK5DGR for bringing that one up !)

Yes it’s going to be a busy few months as we explore what this new toy can do.