Rubidium Reference – Front Panel

Usually I don’t bother making intricate front panels for my projects, but this reference just didn’t look right. At the front are two LEDs one for power and the other displays when the module achieves the atomic lock. On the rear is a SMA connector for the output along with power.

So for this project I decided to make a front panel, this Rubidium has some bragging rights after all. I’ve read a few blogs recently that suggested using a printable sticky label covered by one half of those non-heated laminate pouches. So a quick trip to the office supplies shop saw me come home with some Avery labels that take up roughly half a (A4) page and some pouches that are also sticky.

Not having any vector/raster tools on this computer saw me install Inkscape for the first time. I’m impressed, it wasn’t hard for the first time to use many of the functions your looking for are easily found. So the label I knocked together is below;

So through the laser printer it went and then laminated. A scalpel made quick work of the holes for the LED bezels. Then using two drills through the holes for alignment the label was carefully lowered onto the front panel and then pressed firmly but slowly onto the surface to prevent air bubbles. For those that were forced to contact their books for school would be well training in the appropriate technique, otherwise hit the scrap booking blogs and websites.

So here’s the final result;

I’ve since shown this to one of my fellow club members and he’s suggested next time I put a 2D bar code that links you to either Wikipedia or YouTube that then explains what a rubidium reference is. I could even refer them back to this blog… Hmm… I’m going to have to try that one day !

For now however my Rubidium reference has a front panel that says it’s all mine and explains the LED’s. I’m certainly happy with the result.

Posted in EME

Rubidium Reference – Thermal Management

These rubidium oscillators run hot, very hot. The Rubidium lamp chamber is heated to over +106°C before ignition occurs, the resonant cavity is kept at +70°C to maintain it’s thermal stability. This means that heat needs to go somewhere, usually to the ambient if we can.

So when I decided to mount my rubidium module to the bottom of my die-cast enclosure I’ve used silicon thermal transfer tape. This material is roughly 0.5mm thick, sticky on both sides and came in a 100x100mm sheet. This is thick enough so suck up any mechanical differences between the die-cast box and rubidium enclosure ensuring the thermal tapes makes contact. This material is typically available from Mouser, Digikey and Element14; however I purchased mine from our local electronics shop Jaycar (NM2790).

Would you believe in the rush I didn’t take any photo’s of this silicon thermal transfer tape being applied, maybe on the next unit I’ll remember !

A few back of the envelope calculations suggested that this material would achieve a worst case thermal resistance of 0.085°C/W, provided the mounting screws were done up tight. This then ensures the difference in temperature between the rubidium module and enclosure could be limited to less than 3°C (worst case).

So to satisfy my own curiosity I decided to mount the rubidium module to the die-cast enclosure without a heat sink and see how hot things got. After 30 minutes of continuous operation the enclosure over the top of the physics engine was found to be the hottest, reaching +40°C in an ambient of +25°C. In a home or lab this would probably be OK, but I’m intending to take this reference with me out into the field in ambient temperatures up to +50°C.

The reference guide recommends using a heat sink with a thermal resistance better than 2.0°C/W in these situations which sounds like a good idea. So just a back of the napkin double check;

Rth(Si) = 0.09°C/W   [silicon pad]
Rth(Al) = 0.008°C/W [die-cast box]
Rth(JG)= 0.25°C/W [jump grease]
Rth(HS) = 2.0°C/W [heat sink]
Tambient = +50°C [typical Australian Summer !]

Rth(total) = Rth(Si) + Rth(Al) + Rth(JG) + Rth(HS)
= 2.438°C/W

Pdiss = 28.8W (peak) 9.6W (average)

Trise = Pdiss * Rth(total)
= 28.8 * 2.438
= 67°C

Tmax = Tambient + Trise
= 50 + 67
= 117°C

OK so this will just scrape in under the typical +125°C limit for silicon devices within this rubidium module. Ditto on the capacitors.

Placing thermal paste between the heat sink and enclosure will also ensure the thermal dissipation is kept low. I prefer to call thermal paste jump grease. Since from the moment you open the tin it will somehow jump on to your elbow and then get everywhere. It’s tricky stuff to master.

I didn’t see any point placing this grease towards the bottom of the box, since the majority of the heat comes from under the physics engine. Once this was done then the heat sink was married up to the die-case enclosure, it’s a good sign when you can see the paste squeeze out from under the heat sink slightly.

This then just requires a bit more cleanup with Turpentine, the odourless stuff is best ! Just watch this stuff, since it has a habit of squeezing out for a while if applied too thick.

Posted in EME

Rubidium Reference – Machining

The Efratom LPRO-101 reference guide has the necessary drill pattern for mounting the reference oscillator within an enclosure. The one thing to watch, that caught me out, is the two screws in the middle are not on the centre line of the unit, it’s offset. It doesn’t look like it until it’s too late. So make sure you measure twice and drill once or you will write off a die-cast box or two.

This module is somewhat difficult to mount to a heat sink since the spacing of the mounting holes do not line up neatly with any heat sink profiles I could find. So instead I’ve mounted my module to the bottom of my die-cast enclosure with countersunk screws and will then mount the die-cast box to the heat sink. So the die-cast box is effectively sandwiched between the rubidium reference enclosure and heat sink.

As a graduate engineer I was once shown by a senior tech a great way of marking up and drilling die-cast boxes without marking the face. Basically you cover the areas where you want to drill holes with masking tape and use a pencil or drafting pen to mark the tape. You can then centre punch your holes, remove the tape and drill. Below is the bottom of my Hammond 1590D enclosure marked out with the holes for the Rubidium reference.

Here I’ve drilled the mounting holes for the Rubidium for a test just prior to making the decision to drill the heat sink holes. After drilling and tapping all necessary holes the box and lid received two coats of etch primer and then two coats of gloss black. There are times I just hate gloss black, it shows all the imperfections and it is so easy to mark. I’ve learnt that if you want a good finish, make sure you spray and bake the final coat in a small toaster oven set to 70-80°C for an hour. So after painting it looked like this;

Paint has a terrible thermal conductivity, so I’ve taken the time to mask off the top of the box so I can put thermal paste (white goo aka jump grease) between the heat sink and box at final assembly. Above you can see the black heads of the 1/2″ 4-40 UNC 2B screws required to pull the rubidium up against the lid. In the thermal management section I’ll talk a little more about how I’m going to get the heat out of this module. This is what it looks like when turned over;

If you look closely you’ll see it’s centred within the enclosure, which means I was paying attention to the two holes in the middle of the enclosure being offset (*grin*). There are also holes in either end of the enclosure for LED’s, SMA connector and power to be connected when final wiring takes place.

Once the body of the box had been done I could turn my attention to the heat sink that mounts on top. Again I used my tape mask trick to mark and drill the holes that went between the fins. Each of these holes was tapped with a M3 thread so that screws could be mounted without the aid of nuts and washers.

The heat sink unfortunately was a little large and had to be cut down. I am luck to have a workshop at work with an engineering band-saw fitted with a bi-metal blade. So it wasn’t difficult to cut the heat sink down to the right size and then repaint. One of these days I must learn how to do black anodising with dye. So dry assembled we get this effect;

Which looks rather snazzy. Now to finish off the thermal design.

Posted in EME

Rubidium Reference – Initial Tests

It is always a good idea to test surplus gear, before trying to mount it in a box. This unit can be tested without a heat sink for periods up to 30 minutes. So I started by making a very simple loom to connect power, monitor the BITE and LAMP VOLT outputs and feed the RF output into my spectrum analyser. Thankfully there is a label on the side of the unit that has all of the information that we need to wire it up.

When powered from cold the unit draws 1.2A at 24V, it heats up for 1-2 minutes and then the current begins to drop. Once unit has warmed up (keeping in mind the Rb chamber is +106degC) the unit will achieve atomic lock and the BITE output drops to zero. Once the unit has reached thermal equilibrium the current drawn falls back to 0.4A or there about.

It should be no surprise that the output of the module was measured at +7dBm and that the frequency was bang on 10.0000MHz which is the limit of my Spectrum analyser internal resolution.

The LAMP VOLT output requires a special mention since it can be used to estimate the remaining life within the physics engine. As the Rubidium lamp ages it’s output level drops until eventually the unit can no longer achieve atomic lock. A good or healthy Efratom LPRO-101 should output between 6-9V, below 3V they do not lock. The unit I have outputs 4.6V, so it is definitely used and perhaps a few years of continuous use away from the end of it’s life. So used sparingly it should certainly last me a good many years. I will however be out looking for a spare in case I need a replacement, time to hit Ebay.

There are two very good repair guides available on the internet that are not hard to find;

  • “Erfratom LPRO-101 Repair Reference Guide” – Fred de Vries PE1FBO
  • “Efratom Model FRS-C 10MHz Rubidium Clock” – Gerald Molenkamp VK3FGJM

I cant thank both authors enough for sharing their experiences with repairing these units. Once I obtain another unit I may very well be confident to attempt repairing one of my units and “refurbishing” the Rb lamp.

Posted in EME

Rubidium Reference – Spot On !

Being on the right frequency at the right time to make a QSO is always important. Certainly in these modern times of ultra narrow weak signal digital modes this couldn’t be more true.

Recently I was searching through a box marked “various projects” when I uncovered a Rubidium frequency reference that I’d purchased some time ago and squirrelled away for a rainy day. Now that I’ve rekindled an interest in VHF weak signal digital modes it seemed an appropriate time to finally do something with it.

So continuing to rummage around in the “surplus, half completed and one day” project boxes I managed to find a unused heat sink and Hammond 1590D die-cast box that would easily house this project. So with nothing more to purchase I could simply put it together.

Efratom LPRO-101 Rubidium Reference

The Rubidium frequency reference I have is the Efratom LPRO-101 made in the USA. These units were all the rage for a while on places like Ebay and were apparently removed from mobile telephony bases. With a design life of 10 years continuous use before requiring replacement it’s a bit of a gamble on the remaining life you’ll achieve once built. However I’m sure that for intermittent use this will last me a number of years.

There is a heap of information on the inter-webs about these references. There are many others that have made their own frequency references from these devices, the links below are how I put mine together YMMV.

The links above will be completed as I go. However below is a teaster of how the front panel of the unit looks already;

More to come !

I spoke too soon !

I spoke too soon with my recent Elecraft K3 repairs (click). The radio happily sat on the desk for a few days behaving itself nicely when wham the fault returned. Drats I hadn’t fixed it !

So the covers came off and when power was applied the fault had cleared again, here we go again *sigh*.

This time I was suspicious of the cabling between the reference oscillator and the synthesiser. So I spent a bit of time pushing, pulling and prodding this cable. At one point I had slowly bent this cable sharply down towards the main PCB in the bottom of the radio when the LED on the Synthesiser board went nuts. By nuts it started flickering on and off, this time it did not flash or go out. When I slowly released the cable the LED would flash slowly and transmit was restored when the radio was power cycled.

Right so were getting somewhere could the cable could be intermittent ? So I duly dug through the spares box and found a spare 150mm long piece of RG-174 with the appropriate Taiko Denki connectors and replaced the short 70mm cable. Since the replacement cable was longer than the original, I’d put a small loop on the end so that it sat clear of it’s surroundings. I left the radio with the covers off for a few hours with the radio on test, pushing and prodding things and it seemed fine.

After a day and half with the covers off I then screwed the covers back on again. Within 2 hours the radio faulted. What on earth was going on ?

My next move was to pull out a test jig I’d made years ago that allowed me to put a decent amount of RF power (50-70W) through the short 70mm cable into a dummy load. With RF being applied I then push, prod and pull the cable and watch an inline power meter for any reflected power. If the cable is intermittent having RF with some power behind it will quickly show problems.

So it was definitely time for a coffee and a re-think.

I spent a bit of time lifting and replacing the lid when I decided to bring ones face down to see what was happening when I spotted something. The speaker is mounted to the top panel of the K3 and as the lid was closed the speaker would interfere with the cable between the reference oscillator and synthesiser; pushing and holding it in a downwards direction.

This then got me thinking, has this interference between the speaker and cable flogged out the Taiko Denki sockets ? A quick check of the circuit shows that sockets J1 and J2 are effectively in parallel, well they will out the same level from both sockets. So I moved the reference oscillator from J1 to J2 and put the radio back on test, this time with the short cable again. I could not get the radio to fault for a further day and a half. All of this silliness had gone away. However unless I can explain what has happened, well I didn’t fix it.

The easiest way to to find out of the connector was flogged was to pull the reference oscillator out of the radio and get it under my microscope. I wish I had a camera attachment for my microscope, but needless to say this was the culprit. I could clearly see that the fingers within this connector had been pushed apart and that contact with the centre pin was intermittent. I can see two ways in which this was being done;

  1. The interference between the speaker and short 70mm cable had over time worked the Taiko Denki plug in the socket, eventually working the fingers open;
  2. That some knuckle dragging rock ape repairman (ie yours truly) inserted the plug incorrectly chasing this issue and opened the fingers

Right now option 2 is the most likely explanation. So for the time being I’ve left the reference oscillator plugged into J2 and have ordered more Taiko Denki sockets and plugs from the interwebs. With luck I’ll find a crimp tool, otherwise I’ll be making my own, Hmm that sounds like a good blog post in the future.

I’m fingers crossed that this fault is now fix and it’s time to find a camera for my microscope.

The K3 that would “sometimes” not Transmit

There is nothing more frustrating than an intermittent fault that only presents itself at a contest or when you’re working rare DX. My Elecraft K3 has been doing just this on and off for the past three years and it’s been slowly driving me crazy.

My K3 had developed a nasty fault where it would refuse to make any RF when in transmit. You could hear the radio getting itself setup trying to transmit but no RF would appear at the output. The photo below is not my best effort it was however made very early in the morning with a mobile phone, but you should get the gist from the display;

What you see above is 0 Watts being reported, no SWR display with the TX LED lit. It certainly wont make any QSO’s like that.

So this wasn’t the first time I’d seen a fault similar to this. A year ago the LPA module failed after copping a static discharge in the antenna port from a dipole in a dry wind storm. With the help of Elecraft support this turned out to be nothing more than a small signal MOSFET that had failed on the LPA and was easily fixed. Well so I thought.

At the last OCDX contest in October 2018 the radio faulted again right at the start of the contest. So the station was quickly reconfigured and the radio removed from service. However once I returned home and turned the radio on, it powered up and transmitted as if nothing had happened. Damn this fault is now intermittent…

All that was left was to keep testing and wait for the radio to fail and catch it in the act. So after much angst I just couldn’t seem to make it fault with anything I could identify as a pattern. I’d do something and it would fault, power cycle it and it would work again; there was no consistency,. So I used every trick I’ve learnt to make radios fault, like;

  • pulling, pushing, prodding and re-seating every cable to see if there was a broken connection, more nothing.
  • pulling, cleaning and re-seating every board from the main board to dislodge oxide buildup, more nothing.
  • tighten and check all screws, long shot… more nothing
  • using a hot air-gun and freezer spray to see if something had become temperature dependant, nothing.
  • Double checking the wiring & build

So this afternoon the radio decided to fault and carry on faulting. Now was the time to get the covers off. Once done I noticed that the LED on the top of the KSYN3A would sometimes not light. Power cycle the radio and the LED would come back on, then power cycle it a few more times and it would stay off. The great part was when the LED was off the radio made no RF. Ah Ha, there is no such thing as a coincidence ! I’d finally caught this fault in the act.

The KSYN3A is responsible for generating the Local Oscillators (LO) for transmit and receive, no LO and there can be no RF. Right that’s starting to make sense.

So now I could narrow down on the fault. From everything I had observed I had a suspicion that there was a problem with the output of the KREF3 board, either not providing the KSYN3A synthesiser with a signal or one that was out of spec. It was certainly a good place to start..

However before going much further I needed to check that the cabling between these modules was right.

I should also point out that my radio also has the K144XV 2m Transverter fitted, which is just to the right in the image above. It also has a reference locking kit. Hmmm, this immediately raised yet another red flag. Reading the K144XV reference locking kit manual I found the following wiring diagram;

However this is not how I found my radio was configured. It instead had the K144XV REF_IN connected to J1 on KREF3 and J2 connected to the KSYN3A J83. Huh ?

Now looking carefully this wiring diagram I noticed it had KSYN3 not KSYN3A, so perhaps things are different if you use the new Synthesiser. Well here’s the wiring diagram;

Ah Ha ! It seems that when I installed the KSYN3A upgrade I didn’t wire the K144XV module correctly. What I had done is connect the K144XV reference to J1 on KREF3 not J1 on KSYN3A. Damn !

The worst part is this wiring mistake appeared “to work” but it had instead introduced an intermittent fault where the reference output is loaded by the K144XV to the point the signal was marginal and the KSYN3A faulted.

So I have moved the cables to the right locations now and so far over the past 4 hours the radio has not faulted. Only time will tell if I have this intermittent fault nailed. I guess going to another contest will be the acid test. Oh wait there’s one of them on right now, so it’s time to fire this radio up for the John Moyle Memorial Field Day (JMMFD) and see what happens.

GPSd and the HP un2420

At a recent radio club technical night we ran through the setup of ntpd and GPSd for time syncing laptops. This is important when running modes like FT8 and JT65 where transmissions are synchronised to the nearest second, or for satellite tracking.

Picture of HP2420 Modem

During the tech night we used a external USB GPS, however my laptop has a HP un2420 broadband modem inside that includes a built in GPS. So after the tech night I decided to see if I could get GPSd to work with this module.

In a previous post I found that you could send a string to the last of three USB serial ports that this module creates [ttyUSB0-2], that would then activate the GPS functions within the module you can read this here (click).

So to use this module we need GPSd to send a “\$GPS_START” string to the GPS before it tries to use it. It also needs to send a “\$GPS_STOP” string to the GPS when GPSd stops.

It turns out GPSd has internal mechanisms to do this via a device-hook that you can find in the man page, however there aren’t many examples of “how” to do this on the internet.

The device hook file is nothing more than a simple bash script that is called by GPSd as it starts or stops the GPSd service. It will call this bash script using two parameters, the first is the name of the device, the second is the action required i.e.”activated” or “deactivated”. So all we need is a basic script, there are probably more elegant ways to write this script than what I’ve used, but it works for me.

So using your favourite editor create the file below with the following contents;

/etc/gpsd/device-hook

#!/bin/bash
#
#device hook script to start and stop HP2420 internal GPS
#
if [ "$1" = "/dev/ttyUSB2" ] && [ "$2" = "ACTIVATE" ];
then
echo "\$GPS_START" > "/dev/ttyUSB2"
sleep 5
else
if [ "$1" = "/dev/ttyUSB2" ] && [ "$2" = "DEACTIVATE" ];
then
echo "\$GPS_STOP" > "/dev/ttyUSB2"
fi
fi

This script simply matches the USB serial device the HP un2420 creates with the word ACTIVATE and fires the magic string into the USB serial device and will return 0 to GPSd. The same happens when GPSd wishes to stop the GPS device. These internal GPS devices do not like starting then immediately stopping, it can bork the device to the point it requires the laptop to be rebooted. So to prevent this a short sleep delay has been added just after we activate the GPS. I could have equally added it after or before the STOP command, but this might not be a good idea as laptops have a tendency to hibernate and we would like the GPS to stop.

Now that we have our script we need to make sure it’s executable by GPSd. I found that if you start GPSd and don’t let it daemonise for debugging, it will tell you which user and group that it starts with, we just need to make our permissions match;

$ sudo gpsd -N -D3 -F /var/run/gpsd.sock /dev/ttyUSB2
gpsd:INFO: launching (Version 3.17)
gpsd:INFO: listening on port gpsd
gpsd:INFO: stashing device /dev/ttyUSB2 at slot 0
gpsd:INFO: running with effective group ID 20
gpsd:INFO: running with effective user ID 122

gpsd:INFO: startup at 2019-03-07T23:52:07.000Z (1552002727)

I’ve highlighted the two lines we’re looking for. We can go and match these ID numbers to the specific user and group in the /etc directory. If you press Ctrl-C then GPSd will stop. Looking at the ID’s on my laptop this was user ‘gpsd’ and group ‘dialout’, YMMV.

So now we can set the right owner and permissions for our device-hook file;

$ sudo chown root:dialout /etc/gpsd/device-hook
$ sudo chmod 750 /etc/gpsd/device-hook
$ ls
legend@HP-ProBook:/etc/gpsd$ ls -al
total 20
drwxr-xr-x   2 root root     4096 Mar  8 09:54 .
drwxr-xr-x 130 root root    12288 Mar  8 00:06 ..
-rwxr-x---   1 root dialout   280 Mar  8 09:54 device-hook

Basically owner is left as root and we’ve given read and execute permissions to group dialout. This will allow GPSd to read the file and only sudo users able to edit it.

So using the same command line as before start GPSd in a window. Now in a second window launch a client like cgps. In the GPSd window we should see something like this;

legend@HP-ProBook:$ sudo gpsd -N -D3 -F /var/run/gpsd.sock /dev/ttyUSB2
gpsd:INFO: launching (Version 3.17)
gpsd:INFO: listening on port gpsd
gpsd:INFO: stashing device /dev/ttyUSB2 at slot 0
gpsd:INFO: running with effective group ID 20
gpsd:INFO: running with effective user ID 122
gpsd:INFO: startup at 2019-03-07T23:52:07.000Z (1552002727)
gpsd:CLIENT: => client(0): {"class":"VERSION","release":"3.17","rev":"3.17","proto_major":3,"proto_minor":12}\x0d\x0a
gpsd:CLIENT: <= client(0): ?WATCH={"enable":true,"json":true};\x0a
gpsd:INFO: running /etc/gpsd/device-hook /dev/ttyUSB2 ACTIVATE
gpsd:INFO: /etc/gpsd/device-hook returned 0

gpsd:INFO: SER: opening GPS data source type 3 at '/dev/ttyUSB2'
gpsd:INFO: SER: speed 9600, 8N1
gpsd:INFO: attempting USB device enumeration.
gpsd:INFO: 8087:0020 (bus 2, device 2)
gpsd:INFO: 1d6b:0002 (bus 2, device 1)
gpsd:INFO: 05c8:0403 (bus 1, device 4)
gpsd:INFO: 03f0:251d (bus 1, device 8)
gpsd:INFO: 8087:0020 (bus 1, device 2)
gpsd:INFO: 1d6b:0002 (bus 1, device 1)
gpsd:INFO: vendor/product match with 091e:0003 not found
gpsd:INFO: SER: speed 9600, 8O1
gpsd:INFO: SER: speed 9600, 8N1
gpsd:INFO: SER: speed 9600, 8N1
gpsd:INFO: SER: speed 9600, 8N1
gpsd:INFO: gpsd_activate(2): activated GPS (fd 8)

< BIG SNIP>

^Cgpsd:WARN: received terminating signal 2.
gpsd:INFO: closing GPS=/dev/ttyUSB2 (8)
gpsd:INFO: running /etc/gpsd/device-hook /dev/ttyUSB2 DEACTIVATE
gpsd:INFO: /etc/gpsd/device-hook returned 0

gpsd:WARN: exiting.

The two lines we need to find I’ve highlighted above. Basically we want to see GPSd execute our script with a return value of 0 (success). I’ve snipped a sizeable amount of information out of the above window to make it more readable. You should also see where I’ve hit Ctrl-C which generates a warning to cgps that GPSd has shutdown, which is neat !

Ok so now we have GPSd starting and stopping the GPS device in my laptop correctly. However this is not the end of the story, laptops are able to be suspended so we need to take care of this as well. So using your favourite editor create/edit the following file;

/etc/pm/sleep.d/96_gpsd

#!/bin/bash
#
# what we want done with our GPS in the laptop
case "$1" in
hibernate)
#stop GPSd
systemctl stop gpsd.socket
systemctl stop gpsd
;;
suspend)
#stop GPSd
systemctl stop gpsd.socket
systemctl stop gpsd
;;
restart)
#restart GPSd
systemctl restart gpsd
;;
esac

Thankfully as soon as we tell GPSd to stop it calls /etc/gpsd/device-hook and DEACTIVATES the GPS module for us. Now we also need to set the permissions correctly;

legend@HP-ProBook:/etc/pm/sleep.d$ chmod 755 96_gpsd
legend@HP-ProBook:/etc/pm/sleep.d$ ls -al
total 20
drwxr-xr-x 2 root root 4096 Mar  8 11:09 .
drwxr-xr-x 3 root root 4096 Apr 27  2018 ..
-rwxr-xr-x 1 root root  273 Mar  8 11:09 96_gpsd

Testing of this script is as simple as calling it with the correct first parameter. Testing that our distros are calling this file is a little harder and may be the subject of yet another post. I’m thinking that I need to measure if there is a performance difference with the GPS running while hibernated or not, this sounds easy but will take many hours. Still pondering.

There we go, the internal GPS within the un2420 should now be available, it would be worth rebooting your machine to make sure everything is working well.

MoonSked and Ubuntu 18.04LTS

Recently I was indoctrinated into the world of 6m EME when a few club members and I decided to give it a try on something of a whim. With a bit of encouragement from Lance W7GJ we raided and cherry picked our way through a few fellow club members shacks and sheds and pieced together a “small” portable 6m EME station. You can read about the activation on our club website once it’s published (click). The picture below speaks volumes;

The moon at moon set (4am) with our 6m EME station – photo by Scott VK5TST

While looking at various Apps and trying to work out how this EME thing works, I discovered MoonSked written by David GM4JJJ.

At first glance it appeared to be a cross platform application that would help me plan and understand how this EME thing works without wasting too many late nights outside. What I liked most is I could run it on both Windows or Linux. My main computer in the shack still runs Windows (for reasons), however for laptop(s) and servers I prefer various flavours of Linux. So the installation of MoonSked on my main shack computer was straight forward, however things rapidly fell apart when I tried the same on my Laptop that runs Ubuntu 18.04LTS. I downloaded the zip file, placed it in my home directory and then tried to run it, sigh it didn’t work.

After a quick check of the website I noticed the last version of Ubuntu that MoonSked was built to run on was 9.10 (karmic koala) which went end of life years ago (2013). Being a binary distribution means recompiling and linking this against 64-bit libraries was not an option, sigh; we had to do this the old fashioned hard way.

So having grown up using Linux for more years than I’d care to admit I had a fair idea that this would be the classic “shared library dependency problem”. I wasn’t to be disappointed and even learnt a little about how the new linux multiarch (well new to me) system worked.

So the crux of the problem was MoonSked was compiled against 32-bit binary libraries and my Ubuntu 18.04LTS distro is entirely 64-bit. It is little wonder that MoonSked couldn’t run. So the place to start with any dependency problem is the infamous ‘ldd utility’. Let’s poke inside MoonSked and see what libraries are under the hood;

legend@HP-ShackBook:~/MoonSked$ ldd MoonSked
linux-gate.so.1 (0xf7f48000)
libgtk-x11-2.0.so.0 => not found
libgdk-x11-2.0.so.0 => not found
libgmodule-2.0.so.0 => not found
libglib-2.0.so.0 => not found
libgthread-2.0.so.0 => not found
libgobject-2.0.so.0 => not found
libgdk_pixbuf-2.0.so.0 => not found
libpango-1.0.so.0 => not found
libpangocairo-1.0.so.0 => not found
libpangoft2-1.0.so.0 => not found

libpthread.so.0 => /lib32/libpthread.so.0 (0xf7f07000)
libdl.so.2 => /lib32/libdl.so.2 (0xf7f02000)
libXi.so.6 => not found
libXext.so.6 => not found
libX11.so.6 => not found

libstdc++.so.6 => /usr/lib32/libstdc++.so.6 (0xf7d7c000)
libm.so.6 => /lib32/libm.so.6 (0xf7cb1000)
libgcc_s.so.1 => /usr/lib32/libgcc_s.so.1 (0xf7c93000)
libc.so.6 => /lib32/libc.so.6 (0xf7aba000)
/lib/ld-linux.so.2 (0xf7f4a000)
libcairo.so.2 => not found

Ok so there are a few libraries missing and thankfully I can see some of the lib32 libraries are being found. What is not immediately apparent is that 32-bit libraries can be installed separately and sit alongside the very same 64-bit libraries. The multiarch features of the latest linux kernel and GNU tools is what confuses MoonSked trying to find it’s libraries. So to get MoonSked we need to solve the shared library dependencies separately. So watch the following carefully.

We start by double checking that we are in fact running a full 64-bit system;

legend@HP-ShackBook:~/MoonSked$ uname -m
x86_64
legend@HP-ShackBook:~/MoonSked$ dpkg --print-architecture
amd64

Excellent the kernel is 64-bit and we are using the 64-bit package repository that should be linked against 64-bit libraries. Now we check the following;

expert@HP-ShackBook:~/MoonSked$ dpkg --print-foreign-architectures
i386

Ah Ha ! This is excellent as it means that we can install the 32-bit libraries with the dpkg/apt tools without having to configure dpkg. If you find that i386 isn’t defined as a foreign architecture you’ll need to use dpkg to enable it. There are plenty of websites on the net that can assist here (YMMV), Ubuntu 18.04LTS comes pre-configured for 32-bit and 64-bit multiarch out of the box.

So now we can simply use apt-get to install the dependencies. I simply use a process of elimination to work out what is missing. First I’d use apt-cache and the name of the shared lib to search for library names or resort to the internet, then I’d use apt-get to install it and then re-run ldd again to see the result. The following line works well when the output from ‘ldd’ gets more than a page or two;

$ ldd MoonSked | grep "not found"

This will basically print out any library dependency that was not found to the display. Slowly but surely you work your way through to the end of your list, making notes as you go for your blog (*grin*). Rather than document all of the above steps I’ll just give you the short list;

sudo apt-get install libc6:i386 libpango-1.0:i386 libcairo2:i386 libpangocairo-1.0:i386 libgtk2.0-0:i386 libcanberra-gtk-module:i386 libatk-adaptor:i386 gtk2-engines-murrine:i386 libdlm3:i386

Now the observant will notice at the end of each package is a colon and i386. This tells apt/dpkg to install the 32-bit library and not the default 64-bit package. Depending on what apps you have on your linux machine already some of these packages may already be installed and up to date. If you do find this is the case then simply drop the name off the list above and keep trying.

As I wrote at the very beginning of this post, these are the steps that worked for me on my Ubuntu 18.04LTS installation. I’m hoping that the process used to seek and destroy the missing dependencies makes sense it’s certainly not the only way to do it, works for me YMMV.

At least now I can fire up MoonSked on Ubuntu 18.04LTS and continue my 6m EME experiments. Thanks again to David GM4JJJ for writing MoonSked !

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.